- NANOG - lists.nanog.org

Dead Line of APRICOT Fellow Application is Dec. 18 (fwd)
by Bill Manning 10 Dec '99

10 Dec '99

For you operational folk that have an interest, this might be useful. Sorry for duplicates and for pestering the rest of you. ----------------------------------------------------- % I'd like to let you know the dead line of APRICOT2000 Fellow Application % is Dec. 18. % % We are pleased to announce our Fellowship Program to support % participating in APRICOT2000 which will be held on 28 Feb. 2000 - % 2 Mar. 2000 in Seoul, Korea. The purpose of this program is to % encourage participation of network builders, top decision makers % in Government, Education, and Commercial Sectors who are not available % in fund. APRICOT2000 will cover registration of the conference and % tutorials in APRICOT2000 and US$250 equivalent Korean currency for % accomodation and food to the fellows. Clover hotel is the official hotel % for the fellows. % % Other related annoucement is in www.apricot2000.ne.kr. % % The Committee members select fellows according to following criteria % to % provide fairness, transparancy and necessity to come. % % 1) Network Builders. % 2) Top Decision Makers in Government, Education, and Commercial % Sectors. % 3) Developing Countries. % 4) No limit in geographical region. % % If you want to be a fellow in APRICOT2000, please fill in the attached % form and send to fellow-apply(a)nic.or.kr by 18 December 1999 . The % notification of accepltance will be on 21 December 21 1999. % % ================================================================= % Application Form % ================================================================= % % [Profile] % % (1) Name : % (2) Email : % (3) Address : % (4) Affliation and Position : % (5) Motivation to participate : % (6) One page A4 Biography (needed attached file - only text or word % file ) % % % ** The Motivation to participate is the most important to select % % % Best wishes, % % Sunyoung Han % syhan(a)cclab.konkuk.ac.kr % Fellowship Committee Chair of APRICOT2000 % -- --bill

1 0

Re: A call for the future. Was: Re: Verio Decides what parts ofthe internet to drop
by Dean Anderson 10 Dec '99

10 Dec '99

Around 07:22 AM 12/8/1999 -0800, rumor has it that Randy Bush said: > >> The phone system doesn't require anything close to millions of routes for >> LNP. Instead, at the time of call setup, there is a lookup that performs >> the translation between the portable number (which is the logical address) >> and the physical address (which to date is still mostly statically >> routed using a well-defined hierarchy based upon physical location). > >and here is where the anology breaks down. a second or two of call setup >may be acceptable for establishing a phone call. it would be a disaster >on a per-packet basis. > >ip is a connectionless protocol. before hitting the reply key, think about >that. I thought about it. It seems to me that a router is not presented with a stream of randomly addressed packets. In any time frame, there are going to be from 1 to many hundreds of packets between the same set of addresses. Cisco takes advantage of this to with a route cache. When I was a junior monkey, one of my first tickets involved the route cache ACL bug in IOS 8.0, where routes added to the route cache were no longer checked against the appropriate ACL's. Of course, I didn't know immediately that was the real problem. It just seemed to work after I pinged (permitted in the ACL), and would continue to work (for something denied in the acl) for a while afterward. So, while the first packet may result in a longer lookup, the successive packets hit the cached route. So now it becomes a problem to build an adequately sized route cache for the number of simultaneous 'connections' that one might expect to process in a given timeperiod. Which brings one back the terms and design rules that are not unlike those that apply to phone switches. The thing that is tough to grow is the access list size. The connectionless part of IP is just a matter of whether state is maintained in the protocol or at the endpoints. An ISDN connection has a state at the endpoints and all the processing points. All the switches along the path must maintain that state. An ISDN packet in the middle of stream does not carry enough information to recreate the state. If you miss the setup message, you can't figure out the state from the rest of the packets. By contrast, an IP packet traversing an IP network carries all the state it needs with it. However, that doesn't mean that you need to start from scratch each time you see the same src/dest pair. Methods which hold some additional state in the router for faster processing can be used to speed things up. The full route table could be very large. Much larger than 256Meg or even 4Gig. And even moving to disk backed storage (many gigs) most likely means that access would still be in tens or hundreds of milliseconds, not seconds. However, any given router doesn't really need to use very much of it at any given time. The problem, as I see it, is that Cisco sees everything as a router. And a typically low powered router, as compared to mid and high range unix servers. Consider the Cisco H323 (VOIP) product line. Clearly, the 5300 makes sense as a router. It processes 4 PRI or T1 CAS voice lines into h323 on IP, along with the consequent DSP chips. The 2600 & 3600 make sense for lower density DSP platforms. Clearly, tranlating G.711 to G.729 or others requires specialized hardware. However, the gatekeeper (call routing) software runs on a 3600. This is a grossly underpowered platform for gatekeeper functions, and underfeatured. Gatekeeper functions belong on a general purpose machine with modular (user replaceable) software and access to a database which can handle complex and quickly changing route policies (eg, time of day routing, followme routing). One desires a machine which can scale to handle hundreds or thousands of transactions per second (between a Sun ultra2 and an SGI Challenge w 64 processors). None of these functions are particularly suited to specialized routing hardware. Yet, Cisco insists that (nearly) everything must run on IOS. The best alternative right now runs on NT, with its lack of scalability and other PC problems. But the NT platform runs circles, triangles, squares, and other complex polyhedrons around the 3600. Policy based routing in either a voice or an IP network require flexibility which can't be found in a specialized hardware platform. The problem is the wrong software & hardware combination to do the job, not that the route table has grown too large, or that the job just can't be done. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

7 6

Re: Re[2]: Portable IP space, isolated networks, BGP, etc... (fwd)
by Randy Bush 10 Dec '99

10 Dec '99

>>>>> First, it's my understanding that I can use a single ASN for the BGP >>>>> peering at each of these networks. Am I mistaken? >> if you don't care to reach one from the other. > Well, you _can_, if you want to put the time and effort into performing > the evil routing voodoo. I can think of a few ways of doing it, without > even bridging over a tunnel. I wouldn't advise it, however. i disagree strongly. i think it is a really great idea for our competitors to deploy. randy

2 1

Re: BGP dampening parameters
by Vadim Antonov 10 Dec '99

10 Dec '99

The problem with overly aggressive flap damping is pretty much fixed by the adaptive rate-based algorithm. Now, did anyone actually try it in the real networks? --vadim "Other" Sean: | Have people adjusted their dampening parameters or are they still using the | Cisco defaults? Please see http://www.ripe.net/docs/ripe-178.html Sean.

1 0

Re: BGP dampening parameters
by smd＠clock.org 10 Dec '99

10 Dec '99

"Other" Sean: | Have people adjusted their dampening parameters or are they still using the | Cisco defaults? Please see http://www.ripe.net/docs/ripe-178.html Sean.

1 0

BGP dampening parameters
by Sean Donelan 10 Dec '99

10 Dec '99

In the past when a large provider would do a rolling reboot of their routers, usually in the early morning, some routes would get dampened for a while. It usually cleared up before the morning business traffic hit. Although there were some complaints from our friends in Europe about rebooting routers in the middle of their business day. I haven't heard of BGP dampening issues for a while. Do they still happen? Have people adjusted their dampening parameters or are they still using the Cisco defaults? My concern is false reports due to the increasing number of sites who plan to bounce their networks overnight on New Year's. http://dailynews.yahoo.com/h/nm/19991209/wr/yk_usa_3.html The original BGP dampening parameters were very agressive. I don't know if all these sites are aware if they bounce their network more than a couple times in a short time, they will get dampened. And will start reporting Internet problems because their network was dampened. Has anyone in their lab testing done any work to see how well modern Cisco's react to large scale world-wide network reboots if lots of sites follow suit?

1 0

Need help from UUNet's routing specialist!
by Dmitry S. Esakov 10 Dec '99

10 Dec '99

Hello! We (as8470) are Teleglobe customer. And we experience terrible delays on Teleglobe to UUNet interconnect points. Teleglobe's customer support engineers insist, that the problem caused by UUNet's routes prioritization. But I belive that this assymetric routing initiated by Teleglobe, not UUNet. Could you please send me 'sh ip bgp 195.128.65.33' performed at Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89). I am expecting to see communities or MEDs set at TG router that lowres route priority and makes traffic to go back via _Seattle_Denver_Chicago_NY_. Any help is _greatly_ appreciated! --------------------- Example of delays: --------------------- nyy-1#trace Protocol [ip]: Target IP address: www.uu.net Translating "www.uu.net"...domain server (195.128.64.3) [OK] Source address: 195.128.65.33 Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to www.uu.net (208.243.117.123) 1 if-0-1-0.bb6.NewYork.Teleglobe.net (207.45.205.13) [AS 6453] 0 msec 0 msec 0 msec 2 if-3-0.core2.nqt.Teleglobe.net (207.45.221.98) [AS 6453] 4 msec 0 msec 0 msec 3 if-1-0.core1.Washington.Teleglobe.net (207.45.223.170) [AS 6453] 8 msec 4 msec 8 msec 4 if-2-0-0.bb1.Washington.Teleglobe.net (207.45.221.228) [AS 6453] 8 msec 4 msec 8 msec 5 Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89) [AS 701] 1356 msec 1152 msec 1180 msec ^^^^^^^^^^^^^^^^^^ !!!!!!!!!!! 6 110.ATM3-0.XR1.DCA1.ALTER.NET (146.188.161.54) [AS 701] 1048 msec 1144 msec 1136 msec 7 195.ATM8-0-0.GW1.DCA1.ALTER.NET (146.188.161.17) [AS 701] 1172 msec 1036 msec 1244 msec 8 260.GW1.TCO3.customer.ALTER.NET (157.130.33.222) [AS 701] 876 msec 788 msec 812 msec 9 prod-334a.tco3.web.uu.net (208.243.113.236) [AS 11486] 1112 msec [cut] Serial3-1-1.GW1.DCA3.ALTER.NET (157.130.39.89) ---------------- Have a nice day! Esakov Dmitriy, Macomnet Internet Dpt.

3 2

OPERATIONAL: NSI.Registery died yesterday. Updates lost
by John M. Brown 09 Dec '99

09 Dec '99

According to several NSI.Registrar techs (first and second level) that I spoke with today The SRS died yesterday. Updates made yesterday may not have made it to the real world. Further comments stated that updates today may also be problematic. Just a heads up on the REGISTERY

1 0

Event sites: Mars polar lander
by Sean Donelan 09 Dec '99

09 Dec '99

NASA engineer's made some public comments about the performance of the network and web sites during the Mars Polar Lander event. Even without any data from the lander, NASA used up much of its public bandwidth. http://www.fcw.com/pubs/fcw/1999/1206/web-mars-12-08-99.html I also heard from a couple of people about the problems I experienced accessing the mars polar lander cache pages. Apparently there was an operator error loading some of the information, leading to missing pages. It was quickly corrected, but not before the bad links got out to the mirrors.

1 0

Re: A call for the future. Was: Re: Verio Decides what parts of the internet to drop
by Andrew Bender 09 Dec '99

09 Dec '99

In the design of contemporary core routers, table maintenance and packet processing are discrete functions. The maintenance of comprehensive routing information that includes a superset of best paths is common practice, with proven benefits. However, it is neither necessary nor desirable to consult this database for a forwarding decision. Instead, the fastpath need only have knowledge of the best next hop matching a DA prefix. Whatever changes we believe to be in store for the table population, this is unlikely to affect the typical number of adjacencies for a core router. Assuming also that we continue to use IPv4 for a while, the "input length" of composite information for the FIB could be less than 7 bytes for unicast routes. For the 2.5E5 best paths discussed, this equates to approximately 1.4MB. Also, since the matching (ideally) yields a singular, exclusive result, this matching operation is easily "parallelized" , in hardware or otherwise; observed work need not even be linear with FIB size. In short, the technical obstacles presented by high table / route population are no greater for forwarding logic than for the control plane. Regards, Andrew Bender Total Network Solutions, Inc. > Date: Mon, 06 Dec 1999 18:27:07 -0800 > From: George Herbert <gherbert(a)crl.com> > > The issue isn't in storing hundreds of thousands, millions, > or tens of millions of routes. This is, all things considered, > a piece of cake. > > The issue is getting the route out of storage, for each packet coming > through the router, at a rate of millions of packets per second for > each core router. Each IP core router is doing about the same > lookup work as the whole combined PSTN network is for all of its > freely routed numbers. It is, or should be, quite viable... but not > easy, as we've all found. > > - -george william herbert > gherbert(a)crl.com >

1 0