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.

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/

...

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/

...

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

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

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

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

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 ---------------------------------------------------------------------------

have a 30,000 element core routing table -- endpoint growth never stopped, but new prefixes are all fairly short, and there has been a nearly corresponding drop in old (long, expensive) prefixes in recent months. As Randy pointed out, though, we've probably about squoze all the water out of the old classC sponge.

Not quite yet. We've got a long way to go yet... if I read these graphs correctly. -- --bill

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

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,

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.

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

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

[Yakov]

Paul,

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.

New allocations are (as of 1466bis) being done through providers, on CIDRized lines. Whether IPv4 or IPv6, new allocations are not going to badly impact the core routing table size.

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.

They're identical, because CIDR works and there's no reason to stop using it; in fact there's every reason to go on using it, especially given that longer addresses would otherwise lead to longer (and more numerous) prefixes.

...

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".

I've seen no evidence that IPv6 addresses will be allocated on anything other than CIDR lines. There are crackpots who think otherwise, but there are always crackpots. CIDR works. The IAB's job is to make sure the internet works. QED.

Paul,

Does that mean that all the internet registries no longer allocate /24 (or longer) prefixes that have nothing to do with the actual Internet topology (these prefixes aka "portable addresses") ? Perhaps folks from various Internet registries would be able to answer this question.

Immaterial. What matters is if providers continue to route them.

CIDR works as long as addresses are assigned in a topologically significant fashion. And this precondition is crucial.

Not quite. CIDR works. Routing remains stable when providers route prefixes in a topological fashion.

Yakov.

-- --bill

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

One should differentiate between the table needed by a router to route and the table needed to calculate routes. As has been discussed, the former isn't a problem - you can route 16M different routes with 16M of memory by simple storing the interface number in a table indexed by the address. If your router has 15 or fewer interfaces, you can route 16M routes with 8MB (one interface per nibble). That's every /24 address there is. There is no size problem here. Calculating routes takes more memory and does eventually need to be limited, but machines that can do that with 256MB + virtual memory are readily available. So this problem is a ways off. IMO, this "routing table size problem" has started to create too much momentum towards "reduce the size" and too little towards "how can we handle the size". Perhaps it is because the people deciding some of these things aren't the ones who have to spend thousands of dollars renumbering thousands of machines on an end user network and/or don't need their small network to be dual homed.

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. 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