April 2001 - Test - lists.nanog.org

Router Servers in a lab
by Perry Jannette 11 Apr '01

11 Apr '01

I am interested in generating several thousand BGP routes from different AS's to simulate Internet routes in a lab environment. I would like to generate these routes from a downloaded copy of real route tables and save them to a file. Then have something, possibly a route server, import this file and inject these routes into my lab network. Any ideas/suggestions? Is this possible without having a live BGP feed into my lab network? Thanks Perry

5 5

OT: RE: Getting a "portable" /19 or /20
by abender＠taqua.com 11 Apr '01

11 Apr '01

> Date: Tue, 10 Apr 2001 13:27:37 -0700 > From: Roeland Meyer <rmeyer(a)mhsc.com> > Subject: RE: Getting a "portable" /19 or /20 > > > Please let me know when your Linux box is capable of doing > > line rate forwarding on an OC-192. > > I actually saw a Linux box capable of doing this. It was on IBM S/390 > hardware. Admitedly, that would be a waste of horsepower. OC-192 is far to > slow to keep that box busy. > > <GRIN> AFAIK, the S/390 architecture (as of G7) does not have any network or channel devices that run anywhere close to this speed. GE is the best they're doing right now. Also, Linux390 runs in VM, (i.e. not native) and as such is not exactly running away with IO performance. If you have information to the contrary, I'd certainly be interested, off list of course. The proper place for interested parties is: http://www.marist.edu/htbin/wlvindex?linux-vm Andrew taqua.com

1 0

APNIC IP-request procedures
by Arnd Vehling 11 Apr '01

11 Apr '01

Hi there, has anybody experience requesting a routable block from APNIC? Ive a a customer on the philippines and would like to know if the apnic staff can be as picky as RIPE and ARIN when it comes to obtaining a routable ip-block. best regards, Arnd -- NetHead Network Design and Security Arnd Vehling av(a)nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Cologne, Germany Fax : +49 221 8809212

2 1

OT: hehehe
by Matt Levine 11 Apr '01

11 Apr '01

http://www.techweb.com/wire/story/TWB20010409S0012 __ Matt Levine <matt(a)deliver3.com> "I used to think that the brain was the most wonderful organ in my body. Then I realized who was telling me this." -- Emo Phillips

2 1

Re: APNIC IP-request procedures
by Arnd Vehling 11 Apr '01

11 Apr '01

Hi, Leigh Porter wrote: > > has anybody experience requesting a routable block from > > APNIC? > > > > Ive a a customer on the philippines and would like to know > > if the apnic staff can be as picky as RIPE and ARIN when > > it comes to obtaining a routable ip-block. > > Why, are they afraid that they will find out that they do not need it and > refuse the application? No way. I just wanted to know if the workload to be expected is the same as with ARIN and RIPE because i am doing this on a freelancer basis for ISP companies. Judging from the replies ive got so far now APNIC is as picky as RIPE and ARIN. It can be tough to get an routable assignment alltough the company really needs it, you know. And at least the RIPE became more and more picky within the last years. Like they allways want an deployment plan now which was only asked for on special occasion like 2-3 years ago. thanx for all that answered so far. regards, Arnd -- NetHead Network Design and Security Arnd Vehling av(a)nethead.De Gummersbacherstr. 27 Phone: +49 221 8809210 50679 Köln Fax : +49 221 8809212

2 1

Re: In search of perfection (was Re: Getting a "portable" /19 or /20)
by Sean Donelan 11 Apr '01

11 Apr '01

On Wed, 11 April 2001, Dave Crocker wrote: > Early IPv6 work explored use of geography-based addressing, but rejected it > essentially because it would require more localized provider > interconnections than existed, or else it requires some rather bizarre > routing information exchanges. Network chickens and eggs. The telephone system has tandems in every LATA because the network architecture requires it, or the network architecture developed because there was tandems in every LATA? International country codes are assigned by country because there was only a single PTT in each country, but now there are several companies. Is the lack of localized provider interconnections an accident of the Internet architecture or a requirement? Are other network architectures really bad, or has the current architecture driven the protocol development which in turns reinforces the same limitations of the current architecture? If you assign CIDR blocks by provider, and multi-homing becomes the norm, things grow worse on the global level. If you assign CIDR blocks by geography, and multi-homing becomes the norm, things grow worse on the local level. Which is worse for the global network, ugly local problems or ugly global problems? We seem to go through the same circle every time. People built the current network around the current limitations of the protocol. If we changed the protocol, perhaps folks could build a different architecture around its limitations. If we had an aggregation strategy which supported aggregation at the region/state/city level, perhaps network architecture would be built the same way. > Still, being able to avoid the tyranical capture effect imposed by > provider-based addressing, AND getting better route aggregation, sure does > make geography-based approaches appealing. > > If only someone could work out the technical kinks... Necessity is the mother of invention?

1 0

In search of perfection (was Re: Getting a "portable" /19 or /20)
by Sean Donelan 11 Apr '01

11 Apr '01

On Tue, 10 April 2001, Sean M. Doran wrote: > Perfectly aggregated networks are star-shaped. > > Any more complicated topology cannot be perfectly aggregated. > > In real networks, aggregation at best follows a "reasonable" > trade-off between optimizing and stabilizing route selection. > Not everyone will agree on what is a "reasonable" balance. Oh great, I'm having flash backs to my Data Structures class. A balanced tree is an example of something which can be perfectly aggregated. It also has a nasty habit of generating extremely long paths. A full mesh is an example of something which has no aggregation potential, but has the shortest possible paths for every link. When folks add a cost component, you generally end up with a set of interconnected hubs-and spokes. The current CIDR allocation method assumes aggregation (and the hubs and spokes) will occur along network providers and their network topologies. The other alternative, used by the telephone system, aggregates hubs and spokes along geographic boundaries. Which requires multiple providers within a geographic region exchange more data, but requires less network information visible on the global level.

1 0

RE: gigabit router (was Re: Getting a "portable" /19 or /20)
by Roeland Meyer 10 Apr '01

10 Apr '01

> From: Craig Partridge [mailto:craig@aland.bbn.com] > Sent: Tuesday, April 10, 2001 4:36 PM > > In message > <Pine.BSF.4.21.0104101753540.98098-100000(a)overlord.e-gerbil.net>, "R > ichard A. Steenbergen" writes: > > >Don't be absurd, I can walk into fry's and pick up a motherboard with > >64bit/66mhz PCI, some Netgear GA620's, and all the other > >components for a 1GHz computer for under $1000. > > OK, so your bus has 4.2 Gb/s of bandwidth. But, alas, you're in a PC > so you have to copy each packet from the line card, into main memory, > examine it, and push it back out to a line card. So each > packet consumes > twice its size in bus bandwidth. So 2 1 Gb/s line cards will consume > 4 Gb/s backplane. Assuming you can run the PCI at full rate (which in > my experience is a big big if), you can connect two Ethernets. There are a few server-class motherboards that have dual PCI-66 buses. One on each bus and there's no problem. Incidently, those same MBs usually have dual or quad CPUs. > Incidentally, this isn't the full story either. You have to > do a route lookup on each of those packets. That's typically 5 to 10 memory > accesses... 5 memory access times 1 Mpps per gigabit times 2 gigabits > is 10 million lookups per second or 100 ns per lookup. Allowing for > time spent getting through the chip to the pins, you probably > need 60 or 70ns DRAM, which is doable. Except, oops!, that completely consumes > your memory bandwidth... where are you going to find the cycles to > get the packets in and out? Huh?! We haven't had the 60ns limitation for over three years. What time-vault have you been living in? PC100 RAM is error correcting at 10ns and PC133 runs at ~8ns. In fact, I challenge you to show me where you can even buy 60ns RAM these days. That's right up there with 3 GB HDDs, not available because they can't find customers for any thing that small/slow, except propriatary applications (they make you pay ... large). I just paid $104 for 256MB of ECC PC100 RAM, at the local computer store. The discount wasn't even worth the gas/hr to drive down to San Jose for (1989 Chevy Suburban, in San Jose rush hour). > PS: Side note, this illustrates where router vendors earn their bucks. Router vendors earn their bucks by building routing/switching appliances. The fact that they manage to get corps to cough up $200K for $15K worth of hardware (COGm, generous) is yet another issue. I expect to see some serious price drops in the next 6 months. I also expect to see commodity hardware start making some serious in-roads (cause of the price-drop). COGr = 1/2 COGm, manufacturers cost of raw material (chips, labor, copper, and such) COGm = Cost of Goods manufactured (fully burdened) 2*COGm = The resellers cost (including mfg's margins) 4*COGm = The distributors price 8*COGm = Retail price (What you pay, full retail) [yeah, that's right. This means that, said RAM, cost $13 to make. econ 101] > Find a way to move data over each bus only once (double your > bandwidth!). Dual PCI66 bus. > Design your memory subsystems to keep packets and routing > data separate (increase your memory bandwidth!). PC133 ECC RAM (8ns). > Find a processor that > doesn't waste cycles doing virtual memory (improve your memory access > times!). Dual/Quad 1Ghz PIIIs, anyone? > Oh yes, and then add hot board swap, How many routers actually do this? Even when they do, it is more prudent to find the time to shut it down for 5 minutes. It's not like solid-state devices die all the time...no moving parts. Keep them cool and they'll go obsolete before they fail. Unless it's a combat situation (where you don't have time to swap anyway) there isn't much that warrants this level of maintenance. You're much better off with a redundant hot fail-over configuration so that you can bring one down for PM and replacement/upgrade. > a working BGP implementation (quick, where's Tony Li working these days:-)), I actually like GateD. It ain't fancy, but it works. > a CLI, Linux is handy. RT Linux might be better (maybe). > and a power subsystem for a CO, If you must include that, then my choice is a Liebert GT3600. > and you're in business. With current commodity price drops, in less than 6 months, the cost of doing this will fall well below $1000, retail. Considering potential market volume. A 100% proprietary hardware solution may not be feasible, at that price-point. They will *have* to use commodity hardware, just to keep up the margins.

2 1

Re: Getting a "portable" /19 or /20
by smd＠clock.org 10 Apr '01

10 Apr '01

| > Perfectly aggregated networks are star-shaped. | | No. They are tree shaped. It seems pretty difficult to have all elements in a network except one have only a default route if you have a tree shape, assuming you don't mean a 3-node network... | > This is a result of the CIDR addressing architecture and is | > INDEPENDENT OF THE NUMBER OF BITS IN AN ADDRESS. | | I disagree, if insted we didn't aggregate into /19s or /20s but into /22s | and /23 there would be less unoptimum routing and larger (less scalable) | route tables. Yeah, and if you deaggregate from /[overhead]s into /[overhead+2 or 3] in any length CIDR routing system, you get 4 or 8 times the number of prefixes, and make some people happy that they get more optimal routing and make some people unhappy that they have to bear the extra dynamism. In the interest of obviousness, "overhead" is the number of bits necessary to identify a unicast address, and if you want to use a larger value (like 19 or 20) just for fun, you get the same number of potential prefixes whether your field is 32 bits or 128 bits or 2³² bits. Sean. (g'night)

1 0

Re: Getting a "portable" /19 or /20
by smd＠clock.org 10 Apr '01

10 Apr '01

Greg Maxwell <gmaxwell(a)martin.fl.us> writes: | > Aggregation buys time, that's it. Aggregation does not make the | > current routing methods any more scalable. | | In IPv4 yes, because you can't have perfect aggregation, too much network | multihoming and old prefixes and it's to painful to change address blocks. | | In IPv6, if implimented right aggregation provides for virtually limitless | scalability for unicast traffic. Perfectly aggregated networks are star-shaped. Any more complicated topology cannot be perfectly aggregated. In real networks, aggregation at best follows a "reasonable" trade-off between optimizing and stabilizing route selection. Not everyone will agree on what is a "reasonable" balance. Result: some people unhappy about suboptimal routing ("my packets to my neighbour across the street go through another country") and some people unhappy about too-great dynamicism ("damn, time to upgrade to a faster processor, more memory, faster memory, etc etc etc"). This is a result of the CIDR addressing architecture and is INDEPENDENT OF THE NUMBER OF BITS IN AN ADDRESS. Sean.

2 1