Don't you really mean the USR Routing cards for these hubs? You can put a Cisco AS5100 in them and they route just like a Cisco 2511. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine.
Don't you really mean the USR Routing cards for these hubs? You can put a Cisco AS5100 in them and they route just like a Cisco 2511.
I beleive the reference was to the NetServer cards, which are a Livingstone based product, and do *not* do CIDR. BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR. Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
Livingstone based product, and do *not* do CIDR.
BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR.
Another reason why some people are thinking that workstations and generic micros sometimes look pretty good as replacements for "real" routers. You get software that works, full source code, faster CPUs, and fewer memory limitations. At a cost low enough to get a "free" spare.
From: jon@branch.com (Jon Zeeff) Subject: Re: CIDR FAQ
BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR.
Another reason why some people are thinking that workstations and generic micros sometimes look pretty good as replacements for "real" routers. You get software that works, full source code, faster CPUs, and fewer memory limitations. At a cost low enough to get a "free" spare. Look, I really hate to sound like I have sour grapes, but this thread keeps coming up and I all hear about the PC router issue is a lot of talk about price and CPUs, but I don't actually hear any operational experience about them. PCs have been around for years, and even 4.4+reno/gated boxes have been around as long as cisco/bgp4 boxes. If they really are such a great value, why the hell aren't "those evil router vendors" out of business in the Internet market yet? Call me thin skinned, but this is really starting to get old. I would like to personally see the folks who keep extoling the virtues of roll-your-own solutions either put up or shut up. Can we kindly return this thread to: "What boxes don't do classless routing?"
Look, I really hate to sound like I have sour grapes, but this thread keeps coming up and I all hear about the PC router issue is a lot of talk about price and CPUs, but I don't actually hear any operational experience about them.
OK. Here we are. We use them in a mission critical environment. For Ethernet to Ethernet routeing with a full routeing table they are wonderful. Trying to make them work as fast serial routers is another matter. But they *do* work.
PCs have been around for years, and even 4.4+reno/gated boxes have been around as long as cisco/bgp4 boxes. If they really are such a great value, why the hell aren't "those evil router vendors" out of business in the Internet market yet?
There are a large number of reasons, from the technical to the commercial to the marketing-people-on-steroids reasons. Reason 1. Special boxes are better. In some cases. Especial for the non technically competant organisations that don't want to or need to roll there own. There are of course also Cisco/Bay Networks hackers too. Reason 2. "Know one ever got fired for buying Cisco." Remember where that saying has been adapted from. Reason 3. Marketing. "We use Cisco/Bay/router-of-the-day in our core network. We must be profressionals". Hmm.
Call me thin skinned, but this is really starting to get old. I would like to personally see the folks who keep extoling the virtues of roll-your-own solutions either put up or shut up.
We have. Thanks. We are very happy using Pentiums running NetBSD as *core* routers. Three PCI 10/100Mb Ethernet cards. Great stuff. 35,000 dialup SLIP/PPP customers can't be that wrong.
Can we kindly return this thread to: "What boxes don't do classless routing?"
We did - the CIDR FAQ started out as an ad for Cisco, some of us are trying to get some balance in this area. Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
On Tue, 15 Aug 1995 peter@demon.net wrote:
I would like to personally see the folks who keep extoling the virtues of roll-your-own solutions either put up or shut up.
We have. Thanks. We are very happy using Pentiums running NetBSD as *core* routers. Three PCI 10/100Mb Ethernet cards. Great stuff. 35,000 dialup SLIP/PPP customers can't be that wrong.
Isn't that 600% growth in customers over the past year? Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com
We have. Thanks. We are very happy using Pentiums running NetBSD as *core* routers. Three PCI 10/100Mb Ethernet cards. Great stuff. 35,000 dialup SLIP/PPP customers can't be that wrong.
Isn't that 600% growth in customers over the past year?
At *least*. We know. Ouch. Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
On Tue, 15 Aug 1995, Paul Traina wrote:
From: jon@branch.com (Jon Zeeff) Subject: Re: CIDR FAQ
BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR.
Another reason why some people are thinking that workstations and generic micros sometimes look pretty good as replacements for "real" routers.
You get software that works, full source code, faster CPUs, and fewer memory limitations. At a cost low enough to get a "free" spare.
Look, I really hate to sound like I have sour grapes, but this thread keeps coming up and I all hear about the PC router issue is a lot of talk about price and CPUs, but I don't actually hear any operational experience about them.
Well we are going to use a PC router if all works out for our MAE-East connection. But we do have a cisco 4500-M if it des not work out. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest ---------------------------------------------------------------------------
Livingstone based product, and do *not* do CIDR.
BTW Any BSD4.4 based *NIX (NetBSD, FreeBSD, etc) *does* do CIDR.
Another reason why some people are thinking that workstations and generic micros sometimes look pretty good as replacements for "real" routers.
You get software that works, full source code, faster CPUs, and fewer memory limitations. At a cost low enough to get a "free" spare.
Let's excuse the fact that gated consumes more memory than a cisco for the same amount of routes for a second... Okay, so let's talk functionality. Are there HSSI PCI cards available? Can you do SMDS over this card? Frame? What about a DS3 ATM card, or higher? I know we can do Ethernet, FDDI, sync, and T1 FR, so that's half of it, but there are still lot's of reason's to buy Cisco gear. I'm not excusing the possibility of being able to use PC's, but the additional management issues of having to manage Unix box's in addition to internal routing policies, and expansion efforts sounds like a headache. Managing a network of Cisco's requires a relatively small amount of time, and my staff and I can concentrate on real problems. Dave -- Dave Siegel Director of Engineering, Net99 http://www.webcity.com/ (602)249-1083 24x7 NOC line http://www.rtd.com/~dsiegel/ (520)318-0696 My Tucson Office
On Tue, 15 Aug 1995, Dave Siegel wrote:
Let's excuse the fact that gated consumes more memory than a cisco for the same amount of routes for a second...
Okay, so let's talk functionality.
Are there HSSI PCI cards available? Can you do SMDS over this card? Frame? What about a DS3 ATM card, or higher?
I know we can do Ethernet, FDDI, sync, and T1 FR, so that's half of it, but there are still lot's of reason's to buy Cisco gear.
I'm not excusing the possibility of being able to use PC's, but the additional management issues of having to manage Unix box's in addition to internal routing policies, and expansion efforts sounds like a headache. Managing a network of Cisco's requires a relatively small amount of time, and my staff and I can concentrate on real problems.
Ok, yes you are correct you can't drop a DS3 into the back of a PC, but why not use a 4500 or 7000 for your ds3's and then use a PC to do the major BGP4? On a 4500 I only can put in 32 megs or ram. Yes gated will use more ram for the same number of routes, but I can put 128 meg or more in a PC. I think we need to talk about using PC route servers and cisco together for a solution, the cisco's just can't hold the ram needed. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest ---------------------------------------------------------------------------
Ok, yes you are correct you can't drop a DS3 into the back of a PC, but why not use a 4500 or 7000 for your ds3's and then use a PC to do the major BGP4? On a 4500 I only can put in 32 megs or ram. Yes gated will use more ram for the same number of routes, but I can put 128 meg or more in a PC. I think we need to talk about using PC route servers and cisco together for a solution, the cisco's just can't hold the ram needed. That's why there's the 4500M, and the 7000, and ... Tony
On Tue, 15 Aug 1995, Tony Li wrote:
Ok, yes you are correct you can't drop a DS3 into the back of a PC, but why not use a 4500 or 7000 for your ds3's and then use a PC to do the major BGP4? On a 4500 I only can put in 32 megs or ram. Yes gated will use more ram for the same number of routes, but I can put 128 meg or more in a PC.
I think we need to talk about using PC route servers and cisco together for a solution, the cisco's just can't hold the ram needed.
That's why there's the 4500M, and the 7000, and ...
and ... ? And what? That is the problem, I go out get a 7000 and then need more ram in a few month I need to get a new router that is vary expensive. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest ---------------------------------------------------------------------------
and ... ? And what? That is the problem, I go out get a 7000 and then need more ram in a few month I need to get a new router that is vary expensive. That's why we want to deploy CIDR. So we're not caught in this bind... As to the specifics, please consult your cisco salesperson and ask for a nondisclosure presentation on high end futures. Tony
That's why we want to deploy CIDR. So we're not caught in this bind...
That's back to the mainstream discussion now. I would hope we all realise that CIDR is a sticking plaster and not the ultimate solution to the possible problems in the future ? I am certainly of that mind, and I think that "the CIDR working group" and all of us out here should not become the "Cisco workaround comittee". If you router is non-expandable then bitch to your supplier, be they Cisco, Bay, the-guy-down-the-road-in-the-garage - anyone. BTW - I have not studied the RFC's - so what will IPv6 do for us in the contect of routeing aggregation and latger boxes etc ? Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
If you router is non-expandable then bitch to your supplier, be they Cisco, Bay, the-guy-down-the-road-in-the-garage - anyone. I see we still have an education problem. Sigh. The intrinsic problem is that the routing table is growing faster than we can develop bigger routers. It's not just us. It's growing faster than the computer industry can grow memory either. [The computer industry doubles memory sizes every two years or so. The routing table doubles every nine months.] BTW - I have not studied the RFC's - so what will IPv6 do for us in the contect of routeing aggregation and latger boxes etc ? Absolutely Nothing. You end up back at hierarchical routing. IPv6 gets you a bigger address space, so it actually hurts in that it takes more memory to store a prefix. Tony
BTW - I have not studied the RFC's - so what will IPv6 do for us in the contect of routeing aggregation and latger boxes etc ?
Absolutely Nothing. You end up back at hierarchical routing. IPv6 gets you a bigger address space, so it actually hurts in that it takes more memory to store a prefix.
Tony
the plan is that IPv6 addresses will be allocated hierarchically from day 1, and with proxy aggregation it should be possible for sean's stated goal of "4 routes in the table on some defaultless networks" to be reached. the routing table is no longer doubling every nine months. we've been sort of hanging out in the 25,000 - 30,000 range for almost six months now. the largest single component of the table size comes from old allocations of class c nets, which are 2/3 the total. thus if ipv6 actually comes to pass, and we do start over with new prefixes allocated pseudohierarchically, we may have a lot fewer prefixes, each taking more memory than an ipv4 prefix, yet taking dramatically less memory overall. that's the _plan_, mind you. i don't believe any of it.
On Wed, 16 Aug 1995, Paul A Vixie wrote:
BTW - I have not studied the RFC's - so what will IPv6 do for us in the contect of routeing aggregation and latger boxes etc ?
Absolutely Nothing. You end up back at hierarchical routing. IPv6 gets you a bigger address space, so it actually hurts in that it takes more memory to store a prefix.
Tony
the plan is that IPv6 addresses will be allocated hierarchically from day 1, and with proxy aggregation it should be possible for sean's stated goal of "4 routes in the table on some defaultless networks" to be reached.
the routing table is no longer doubling every nine months. we've been sort of hanging out in the 25,000 - 30,000 range for almost six months now.
the largest single component of the table size comes from old allocations of class c nets, which are 2/3 the total.
Why can' the NIC reallocat the old class c's and use CIDR? Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest ---------------------------------------------------------------------------
Paul,
the plan is that IPv6 addresses will be allocated hierarchically from day 1, and with proxy aggregation it should be possible for sean's stated goal of "4 routes in the table on some defaultless networks" to be reached.
the routing table is no longer doubling every nine months. we've been sort of hanging out in the 25,000 - 30,000 range for almost six months now.
the largest single component of the table size comes from old allocations of class c nets, which are 2/3 the total.
thus if ipv6 actually comes to pass, and we do start over with new prefixes allocated pseudohierarchically, we may have a lot fewer prefixes, each taking more memory than an ipv4 prefix, yet taking dramatically less memory overall.
The most serious problem we're facing is NOT how to route to the existing allocations, but how we're going to route to all the new allocations that are due to the exponential growth of the Internet. With this in mind, why do you think that IPv6 allocation would be any different than CIDR IPv4 allocations (which is how all the new allocations suppose to be done) ? So far all the documents I've seen on IPv6 address allocation are quite similar to IPv4 address allocation documents.
that's the _plan_, mind you.
I think this is not even "the _plan_". I think that is what some of us could wish be "the plan". Yakov.
Yakov writes:
The most serious problem we're facing is NOT how to route to the existing allocations, but how we're going to route to all the new allocations that are due to the exponential growth of the Internet.
From this and an earlier mail (somewhere you said we should "deploy CIDR") I sense some kind of fundamental problem in this discussion.
From -my- point of view CIDR -is- deployed:
- we've been allocating from provider blocks for probably two years now, and the number of prefixes announced has been growing -very- slowly (with respect to -new- allocation of addresses), even with customers not returning their addresses when they leave us. Do you have -any- hard data that anything else is happening at a global scale? - there is naturally a tendency for the provider address space to fragment over time, however do we have -any- data that this is causing any of the problems we are seeing (it surely isn't creating a large increase in prefixes -now-)? - nearly -all- of the prefixes we announce are pre-CIDR allocations (B and quite a large number of C's (that we are trying to clean up)), I don't believe this to be different with any other ISP. Yakov, if you have data that CIDR is -not- working for new allocations please present it here. Simon
From the last CIDRD meeting (Erik-Jan Bos's slides), we have strong data which indicates that the routing table sizes are again growing at
Yakov, if you have data that CIDR is -not- working for new allocations please present it here. Simon, the double-every-nine-months rate. Thus the obvious concern. The exact source of this growth has not been determined quantitatively. Tony
Yakov, if you have data that CIDR is -not- working for new allocations please present it here.
Simon,
From the last CIDRD meeting (Erik-Jan Bos's slides), we have strong data which indicates that the routing table sizes are again growing at the double-every-nine-months rate. Thus the obvious concern. The exact source of this growth has not been determined quantitatively.
Tony Which somewhat explains why this group reminds me of a bunch of decapitated hens. Would it be correct to interpret your last sentence as: We don't what the underlying cause of the growth in prefixes is (new allocations, old allocations, ISP's not aggregating). With other words, we don't even know if the I-D in question is fixing the right problem. Simon
Simon,
The exact source of this growth has not been determined quantitatively.
Which somewhat explains why this group reminds me of a bunch of decapitated hens. We welcome folks who would like to study it in more detail. We have a surplus of folks interested in flaming, a shortage of those actually interested in the problem (and I include both pro and con participants). Would it be correct to interpret your last sentence as: We don't what the underlying cause of the growth in prefixes is (new allocations, old allocations, ISP's not aggregating). This is overly broad. We have been doing periodic (but irregular!) top-20 non-aggregating ISP reports which clearly show that there are major gains to be had by certain ISP's aggregating. Determining if a particular prefix is the result of someone using an address in the "portable" model is rather difficult as you have to understand their motivation and plans, as well as just the routing data. For example, they may be in the process of doing the renumbering within the organization and may quite legitimately be using multiple prefixes, some from the old provider or a legacy allocation. With other words, we don't even know if the I-D in question is fixing the right problem. I think we have a small misunderstanding here. Erik-Jan's figures as presented in Stockholm are evidence that we still have a problem. The address ownership I-D is _not_ a direct response to that presentation. In fact, the "ownership" presentation was first given in Danvers. This is not cause and effect and I certainly didn't intend it as such. I apologize if I was misleading. To summarize: - We know we still have a bad problem. - We have end users who want "portable" addresses. - Some of them are actually getting them. - There are some ISP's who are not doing a reasonable job of aggregation. - We would like the ISP's to do a better job of aggregation. - "Portable" addresses, by definition, are not aggregateable. - If we can substantially reduce the number of "portable" addresses which are assigned, then we can alleviate one _clear_ cause of the problem. - Other measures are in place to encourage ISP's to aggregate. - Even more measures still remain to be developed. - Most of the Evil Greedy Bastards who espouse CIDR have done a good job of aggregating already. Tony
Simon,
With other words, we don't even know if the I-D in question is fixing the right problem.
The "I-D in question" addresses the incompatibility between CIDR and the notion of "address ownership". This incompatibility is *fundamental*. Ignoring it (or pretending that it does not exist) does not make the incompatibility less fundamental. Yakov.
In message <199508170611.XAA19283@greatdane.cisco.com>, Tony Li writes:
To summarize: - We know we still have a bad problem. - We have end users who want "portable" addresses. - Some of them are actually getting them. - There are some ISP's who are not doing a reasonable job of aggregation. - We would like the ISP's to do a better job of aggregation. - "Portable" addresses, by definition, are not aggregateable. - If we can substantially reduce the number of "portable" addresses which are assigned, then we can alleviate one _clear_ cause of the problem. - Other measures are in place to encourage ISP's to aggregate. - Even more measures still remain to be developed. - Most of the Evil Greedy Bastards who espouse CIDR have done a good job of aggregating already.
Tony
Tony, This would be a good outline for an information RFC giving the status of CIDR deployment. CIDR deployment status is an important issue for the Internet. It is not well understood outside of the NANOG, IEPG, CIDRD community (which are all the same people anyway). With the move to discourage portable addresses, CIDR deployment directly affects a large body of users who don't understand the issues or the broader picture. These users might be less inclined toward accusations that users are taking the brunt of the changes and twoard conspiracy theories if the bigger CIDR deploymnent picture was more clearly presented to them. Curtis
Curtis, This would be a good outline for an information RFC giving the status of CIDR deployment. CIDR deployment status is an important issue for the Internet. It is not well understood outside of the NANOG, IEPG, CIDRD community (which are all the same people anyway). With the move to discourage portable addresses, CIDR deployment directly affects a large body of users who don't understand the issues or the broader picture. These users might be less inclined toward accusations that users are taking the brunt of the changes and twoard conspiracy theories if the bigger CIDR deploymnent picture was more clearly presented to them. Thank you, yes I agree. I would very much like to see a volunteer step forward and write such a document. They are welcome to the "outline" and I'll forgo any credit for it. ;-) Tony
Tony,
Thank you, yes I agree. I would very much like to see a volunteer step forward and write such a document. They are welcome to the "outline" and I'll forgo any credit for it. ;-)
I think I can voluneer for this. Yakov.
I write:
Which somewhat explains why this group reminds me of a bunch of decapitated hens.
Would it be correct to interpret your last sentence as:
We don't what the underlying cause of the growth in prefixes is (new allocations, old allocations, ISP's not aggregating).
With other words, we don't even know if the I-D in question is fixing the right problem.
[the CC list is getting very long, I've tried to trim it a bit] Just to provide some hard (haha) data I wipped up a perl script and dumped a full routing table from one of our routers. Daniel Karrenberg has produced similar numbers before if I remember correctly. In any case this allows a large amount of finger pointing (located in Europe I particulary happy with the performance of 193/24), in particular visual inspection of 199/24 would seem to indicate a -lot- of aggregation potential. Format /24 prefix #of prefixes %of total address space announced All usual disclaimers apply (I've not done more than a couple of sanity checks on the data). 6 1 100 9 2 00 12 1 100 13 1 100 16 1 100 17 1 100 18 1 100 20 1 100 26 1 100 32 1 100 33 1 100 34 1 100 35 1 100 36 1 100 38 1 100 39 25 00 40 1 100 44 1 100 45 1 100 46 1 100 50 1 100 57 1 100 128 175 68 129 180 70 130 147 57 131 129 80 132 90 70 133 153 59 134 215 75 135 11 04 136 56 25 137 159 66 138 117 57 139 100 39 140 148 57 141 168 81 142 121 100 143 111 45 144 118 46 145 15 05 146 125 48 147 149 60 148 100 40 149 151 58 150 148 59 151 65 23 152 84 49 153 56 24 154 3 01 155 123 53 156 58 22 157 125 49 158 136 61 159 118 45 160 106 47 161 109 42 162 64 25 163 106 41 164 104 41 165 124 50 166 71 24 167 90 46 168 121 47 169 26 13 170 72 28 171 5 26 192 6743 25 193 1953 100 194 1298 28 195 1 100 196 280 04 197 1 00 198 4109 55 199 3372 54 200 273 09 202 1243 19 203 580 33 204 3013 69 205 1217 33 206 329 19 208 3 00 Simon
Simon Poole wrote:
Yakov, if you have data that CIDR is -not- working for new allocations please present it here.
Simon
CIDR doesn't work as it should. We had to inject all of the more specifics of 194.45/16 cause Sprintlink isn't able to handle CIDR routes correctly. Arnold
Peter,
BTW - I have not studied the RFC's - so what will IPv6 do for us in the contect of routeing aggregation and latger boxes etc ?
Couple of observations: 1. The ability to aggregate routing information depends on how addresses are assigned, but does not depend on whether addresses are 32 bits wide or 128 bits wide. 2. IPv6 address allocation architecture (see draft-ietf-ipngwg-unicst-addr-allo-01.txt) is the same as IPv4. (just so that folks who read this note would have no doubts, the IPv6 Address Allocation Architecture document was written by Tony Li and myself - the same people who wrote the CIDR Address Allocation Architecture document). Conclusion: In the area of routing aggregation IPv6 will do for us *exactly the same* as what IPv4 does. Yakov.
From: peter@demon.net Subject: Re: CIDR FAQ
That's why we want to deploy CIDR. So we're not caught in this bind...
That's back to the mainstream discussion now. I would hope we all realise that CIDR is a sticking plaster and not the ultimate solution to the possible problems in the future ? I am certainly of that mind, and I think that "the CIDR working group" and all of us out here should not become the "Cisco workaround comittee". I don't understand why some folks continue to believe that CIDR is a band-aid or a "Cisco workaround" or some other such rot. That is an utter falacy. CIDR is the exponential growth in resource requirements workaround comittee. It doesn't matter if you're using a PC, a pair of tin cans, or a router, if the number of routes required to maintain connectivity doubles every 6 months, the cost of business for operating on the internet will be prohibitive for everyone except "the big players" you guys are spending your time smacking around. We would be more than happy to sell you a new box, or more certified memory every few months...hell, that sort of stupidity in the marketplace would give us more than enough business justification for high-priority projects. When CIDR was dreamed up, there were two problems it was trying to solve, routing and addressing. If you don't do heirarchical addressing at some places along your heirarchy, then you need to deal with the fact that (a) everyone has all routes (b) everyone is ANNOUNCING all routes (c) when a route flaps, it affects everyone If you router is non-expandable then bitch to your supplier, be they Cisco, Bay, the-guy-down-the-road-in-the-garage - anyone. I rarely see products that are capable of standing more than one or two doublings in CPU and memory capacity. They usually don't sell when they are produced because their initial investment cost is 3x the competition. BTW - I have not studied the RFC's - so what will IPv6 do for us in the contect of routeing aggregation and latger boxes etc ? It's a pity you haven't. IPv6 makes the addressing problem much less of an issue, but raised the number of routes in the internet from 2^32 to 2^128. The only sane way to deal with this is aggregation, AGAIN. So, the same pathetic fools who brought you CIDR are going to ruin your IPv6 dreams before they've started. I would ask that folks consider moving this OFF of the CIDR and NANOG mailing lists and onto com-priv where it is much more "on-topic." Paul
Let's excuse the fact that gated consumes more memory than a cisco for the same amount of routes for a second...
HA HA HA HA. Sorry, had to laugh. Is my PCI Pentium limited to 64Mb RAM and can only carry ~30k routes? No. Architechture first, penis length second. Memory is only relevant if you can use it efficiently. Same for CPU.
Okay, so let's talk functionality.
Are there HSSI PCI cards available? Can you do SMDS over this card? Frame? What about a DS3 ATM card, or higher?
I agree, this is where "real" routers are required. However, by the time you can afford the high bandwidth connections you can most definately afford the routers. So the argument goes away. For a T1 line or Ethernet, especially locally in the US (not here) the cost of the router *outweighs* the cost of the line, and so commercial decisions will be made based on router cost. Regards, -- Peter Galbavy peter@demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/
Let's excuse the fact that gated consumes more memory than a cisco for the same amount of routes for a second...
HA HA HA HA. Sorry, had to laugh. Is my PCI Pentium limited to 64Mb RAM and can only carry ~30k routes? No. Neither is your 7000. ;-) Wherever you got your numbers from, they're wrong. For a T1 line or Ethernet, especially locally in the US (not here) the cost of the router *outweighs* the cost of the line, and so commercial decisions will be made based on router cost. For a T1, perhaps the monthly charge, but over the lifetime of the line, I don't believe this. Tony
participants (14)
-
Arnold Nipper -
Curtis Villamizar -
Dave Siegel -
jon＠branch.com -
Michael Dillon -
Nathan Stratton -
Paul A Vixie -
Paul Traina -
peter＠demon.net -
poole＠eunet.ch -
pst＠shockwave.com -
sob＠academ.com -
Tony Li -
Yakov Rekhter