September 1997 - Test - lists.nanog.org

Re: too many routes
by Sean M. Doran 11 Sep '97

11 Sep '97

"Jay R. Ashworth" <jra(a)scfn.thpl.lib.fl.us> writes: > Perhaps I misunderstood Sanjay, Sean, but I believe his concern was > that the addresses _not be the property of an upstream (ie: backbone) > provider_ to provide flexibility of connection choice. Welcome to the new Internet, which is being built. Two of the fundamental concepts that are important: -- IP addresses are not forever -- IP addresses are not end-to-end I think most people have bought into the concept of renumbering, and hopefully are realizing that the temporary nature of IP addresses could involve changes during the lifetime of a series of transactions at higher protocol levels. NAT and ALG demonstrate the second point right now, and are only crude to the extent that there are crufty protocols which were designed without any flexibility whatsoever in the two new fundamental concepts above, and a series of NAT and NAT-like gateways could conceivably already lead to changes in the IP addresses observed to be in use across segments of the path between two communicating endpoints. Combining the two concepts is very important, and this is essentially the next big step in the ongoing merge of routing equipment with address translating equipment. Ideally this will be done at a huge scale as well as at a small scale. So, to tackle the small-scale problem you refer to, the general idea is that you have multiple outward-facing addresses, one per provider, from each provider's PA address space. As providers come and go talking of Michaelangelo, you simply add or delete outward-facing addresses from the DNS advertisements your NAT generates. Your inward-facing port address of the NAT and all the behind-the-NAT addresses should never need to change, provided you do a decent job of assignment (or employ NATs internally :) ). The tricky part is the first fundamental part of the new Internet architecture, and that is changing addresses while conversations are in progress. Unfortunately IPv4/TCP both have poor facilities for supporting this without cooperation from higher-level protocols, and the current set of higher-level protocols are often wed to the idea of an end-to-end unchanging IP address. Sigh. However, NAT designers have some clever temporary hacks while a cleaner set of solutions are being looked into. These hacks generally involve tunnels, as I pointed out in a message I wrote just recently. > NAT will not solve this problem; it resides at too low a level of the > theoretical architecture, being used primarily to avoid renumbering of > internetworks. This isn't a network numbering problem, it's a routing > problem. The address at the transport layer (i.e., the IP address) is utterly and indivisibly wed to the local routing scheme at any point in any topology. Renumbering one endpoint of a connection on the fly when you have multiple outgoing addresses tho choose from (in the case of a multihomed endpoint with PA addresses from each upstream connection) directly influences how the rest of the world will route the other endpoint's traffic. This is a feature of NAT, not a side-effect. It is also a crucial feature in the new Internet. IPv4ever (well until we get proper endpoint identifiers and variable-length transport addresses so we don't have to emulate a decently scalable transport protocol using NAT). Sean.

1 0

IP b/w out of NA
by Hank Nussbacher 11 Sep '97

11 Sep '97

Is there any place I can find more info about the aggregate IP b/w out of North America? How many OC-3s to Europe and to Japan? Is there 600Mb/sec of b/w from NA to Europe? Any help and pointers appreciated. Thanks, Hank

1 0

Re: Flamed for off topic...
by Sean M. Doran 11 Sep '97

11 Sep '97

"Neil J. McRae" <neil(a)domino.org> writes: > What list is that then Michael? Shhh, Neil, you know it's not nice to undermine people's carefully crafted veneers of omniscience. Sean.

5 4

RE: too many routes
by Chris A. Icide 11 Sep '97

11 Sep '97

> L2 switches are available today that reliably receive OC-12 SONET > circuits. > > These can be disaggregated into OC3 ATM pipes that can be fed into > many routers with proven technology and reliability. Granted, the > disproportionality of the edge ckts to the backbone ckts provides > for interesting flow aggregation dynamics, but it does work. > > Your disdain for ATM does not stop its existence and use by the > larger NSPs. > Just think, there are people out there "throwing away" an oc-3 worth of bandwidth to IP over ATM overhead. Must be nice to live in a world of capitalization where one could do such a thing. We use ATM for two reasons, 1) it's still significantly cheaper than long-haul circuits of the same capacity, 2) it provides some interesting abilites that are only now beginning to show up in the mainstream IP hardware. -- additional commentary by yours truly removed by BS filter -- - Chris

1 0

Re: Network Diagramming Software
by Jim DeSorbo 11 Sep '97

11 Sep '97

I am just getting into this conversation. I apologize for any misinformation. If you are seeking an excellent Network Diagraming and design tool, I work for a company called NetSuite Development L.P.. We have created a fantastic Intelligent Network Design tool which allows you to design and maitain all Network Diagram Inventories, a series of softprobes, etc.. Check it out at www.netsuite.com There are many new and exciting features coming in our next version. If anyone would like a review or demo. let me know & I will see to it that you received it ASAP.... Jim D. ---Dave Curado <davec(a)zip1.ziplink.net> wrote: > > I don't think it does everything you want, > but a package called NetViz seems to be made > for network diagramming -- produces html and > imagemaps and interesting stuff like that. > I picked up this blurb at: > http://www5.zdnet.com/cshopper/content/9608/cshp0147.html > > _____________________________________________________________________ Sent by RocketMail. Get your free e-mail at http://www.rocketmail.com

1 0

Subject: AS path analysis tools
by Demetrius Christian 11 Sep '97

11 Sep '97

Hello, Does anybody know of some analysis tools I can make use of to justify peering with someone? My router is a CISCO running BGP ver 4. This could also be useful to decide where my traffic split will be amongst a few BGP peers. Many thanks Demetrius

2 1

Attn after mergers please update your contact information
by Sean Donelan 11 Sep '97

11 Sep '97

>I hate when contact numbers are disconnected. Does anyone have a good >contact for MAI.net? I'm shocked and amazed :-) When you buy, aquire, merge, swap, break-up, split, or leave providers, PLEASE update the contact information. This effects providers of all sizes (before and after the merger). P.S. just because you are a phone company doesn't mean everyone can dial your 'special' 811-xxxx or 1-800-xxx-xxxx phone number. Have a plain-old internationally diallable phone number for your NOC. This has been a recorded message.... -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

RE: Randy Bush et al
by Vincent J. Bono 11 Sep '97

11 Sep '97

Well. After getting back from a trip I find, what? That Mr. Bush has a bug up his ass. Bottom line: - We do default route. Into a Sprint T3 that we pay for. :-) - We do not pass no-next-hop-self routes - Check around, if someone was as bright as they think they are it would be obvious. - We only peered with Verio in the first place becuase someone other than Randy contacted us - We formerly sent a lot of traffic to Verio because it's customers love porn, and we have several rather large web farms downstream. The number listed in whois is bad, sorry, it happens. But the number on our web site is not. When there is a problem and we are involved, I say so. There was no problem here and we won't miss Verio peering one bit. Vinny vbono(a)comstor.com 888-624-8700 NOC 702-802-0222 ext 3148 voice BTW: Below is the "snotty" message that was sent to our NOC and it's reply. Who was snottier than who? ------- Forwarded Message Follows ------- Date: Thu, 11 Sep 1997 02:34:58 -0400 From: Matt Luebke <mluebke(a)mclean.mai.net> To: Randy Bush <randy(a)verio.net> Cc: noc(a)verio.net, noc(a)mai.net Subject: Re: you have been depeered Randy Bush wrote: > your peering at mae-east is very unacceptable. the phone number in whois is > answered by a modem. so you have been de-peered with 2914. > > randy Our peering at mae-east is very acceptable to us. However we find that Verio brings nothing to our table. Thank you and Goodbye. Matt

1 0

Re: too many routes
by Peter Lothberg 11 Sep '97

11 Sep '97

> Nathan Stratton <nathan(a)netrail.net> writes: > > > This is what I beleave sprint is doing. They are using the new Cisco 12000 > > GSR with external router servers. It is a smart way of patching the > > problem. If you need more CPU or memory you can just add a bigger box and > > more RAM. > > The GSRs are to move bits fast. They are not to act as > route servers. > > Sprint recently announced that they are deploying 622Mbps > POS cross-country links, and the GSRs are the only things > you can put on the ends of such beasts that are available > today. > > (Someone may point out that it may not be the only choice > for very long, however, it's the only one whose design I > know and have had any influence upon, and is therefore > frankly the only one I trust, although I don't expect the > people building the competing box will ship anything but a > good product even if they are now rather deeply in bed > with the cell-heads and about as transparent to most > observers as the Kremlin during the cold war... Well, Ericsson did spend around $1,250Mil trying to develop their own ATM switch as part of ther AXE family. A total fiasko.. --Peter

1 0

Re: too many routes
by Sean M. Doran 10 Sep '97

10 Sep '97

Peter Lothberg <roll(a)stupi.se> writes: > Sprintlink does not use route-servers today, the RP in the GSR is > probably enough for a while, right now it's not very busy. After convergence the CPU in any distributed switching framework should be a function of the routing algorithms and the amount of background noise. However, to close off the nit-pick, the RP in the GSR seems to perform spectacularly well even under unusually heavy routing load. This is great as long as there is no need to replace the RP before a replacement is technologically feasible... Sean.

1 0