December 1999 - Test - lists.nanog.org

more NSI whois changes
by Patrick Evans 14 Dec '99

14 Dec '99

I've not noticed any outcry over the latest set of changes to NSI's whois server yet, but some people might find these notes from our man at the NIC useful...the web interface, which doesn't currently make any mention of the changes (or didn't when I looked earlier), also needs careful use now... "The new Whois server requires additional qualifiers now be used: This affects both Whois on the NSI web site and Whois from domreg>. To ask WHOIS to search a certain field in the database, use the following three keywords (shown with their minimum abbreviation in all BLUECAPS): Examples: HOst [HO my.dotcomblues.com] or [HO 208.213.203.161] or [HO DCBLUES-HST] HAndle or '!' [!cxk9] or [HA cxk9] or [HA KC86-ORG] NAme or leading '.' [.kim, charles] or [NA Charles Kim] Mailbox or contains '@' ckim(a)netsol.com (no qualifier needed) (ho, hos, host, ha, han, hand, handle, na, nam, name in lower case work as well) Full details can be found by clicking 'Need Help? Click here' from the Whois web interface." -- Patrick Evans - Sysadmin, bran addict and couch potato pre at pre dot org www.pre.org/pre

1 0

Re: BGP Blowup?
by Tim Wolfe 14 Dec '99

14 Dec '99

So far the data is as follows: 1. My BGP session to Sprint (1239) exceeded 75000 routes at approx 5:39pm PST 2. Telestra seems to have had a similar surge from Uknown provider (or possibly on their own network) 3. Another individual reported that their GTEI (7176) session had a similar surge. 4. Yet another individual reported that their Digex session had a surge as well. I guess I'm confused. While 4 similar surges in table size at 3 distinct locations is not by any means conclusive evidence that the global table was experiencing wackiness, it certainly points a finger in the that direction. What perhaps bothers me more than the surge itself is that I have gotten very few (read 1) responses to indicate that there were NOT a problem similar to what I've reported. I get the feeling that many people are not tracking prefix counts so I'm am very nervous about future occurences. At what point does an event like this become a problem that gets noticed? Does it take a full meltdown of BGP speakers in a large providers network before this is worth looking at? I would think that a sudden random addition of 10,000 routes would be of concern to people who claim to be so worried about the size of the world's routing tables. Or is it only a concern if actually affects your network? I'm not attacking anyone, just concerned over the apparent lack of concern... It is interesting that all of the individuals that had direct UUNet sessions didn't see any of the surge on those sessions. Maybe they learned from the MCI experience awhile back? -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim(a)clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * --------------------------------------------------

2 1

Re: BBN issues
by Danny McPherson 13 Dec '99

13 Dec '99

> You don't see the NY -> Cali -> NY path? That is a bad thing (tm). In the first traceroute it did initially seem interesting, although my presumption was that Sprint likely wasn't leaking routes (or providing transit?) "everywhere", and probably only via that specific path, as demonstrated. Another observation to that regard is that the [leaked?] prefix was presumably a more specific, else [theoretically], Genuity would have selected the shorter AS path .. although BBN/GTEI may perhaps be providing that transit via there AS, which would even things out from a path vector perspective. (The reverse path seems somewhat reasonable considering BBN and Genuity are still separate ASs with distinct network and interconnection topologies. I do still see potential brokenness wrt route leakage and the like, so either Sprint is still leaking routes or GTEI is attempting to offload (via a psuedo transit connection) some of that Genuity hosting traffic elsewhere... Of course, I'd really suggest now that we avoid dicussing this specifically on the list and leave the problem resolution to the folks that can actually fix it/them, if they actually exist. -danny

1 0

Re: BBN issues
by Danny McPherson 13 Dec '99

13 Dec '99

Perhaps I'm confused, but the only potential brokenness demonstrated in your traceroute output is that Sprint is announcing Verio routes to AS3847/BBN (formerly Genuity). The latter of the two traceroute outputs seems quite reasonable. That is, BBN/GTEI providing transit to Genuity. I'm not sure exactly where BBN/Genuity or Verio would be at fault here, with the exception of BBN/Genuity accepting some random prefixes from Sprint. While NANOG posts will likely result in a "clueful person from BBN" promptly contacting you, usually, it doesn't take quite a entire week to reach them via their NOC. -danny > > Hello, > > I'm very sorry to use this list for this purpose, but I need a clueful > person at BBN who has dealings with the old Genuity network to contact me. > > We're seeing paths like this to nearly everywhere on BBN-announced space, > and we have not been able to get this fixed for over a week: > > (this is just one of many examples, but I thought the pure entertainment > value would keep Randy from browbeating me) > > This is to a recent verio partner. It is my understanding that verio > peers with bbn and that bbn does not buy transit from sprint for this > purpose. Traffic to uu, cw, you-name-it takes similar paths. We are in > NYC. > > Tracing the route to www.nyct.net (204.141.86.3) > (NYC to NYC) > > 1 fa10-0.nyccolo-border1.bbnplanet.net (207.240.48.45) [AS 3847] 4 msec > 0 msec 4 msec > 2 f6-0.nyccolo-core1.bbnplanet.net (207.240.1.81) [AS 3847] 4 msec 0 > msec 0 msec > 3 128.11.124.54 [AS 3847] 80 msec 84 msec 80 msec > 4 sl-gw11-ana-6-0-0.sprintlink.net (144.228.207.145) [AS 1239] 92 msec > 96 msec 88 msec > 5 sl-bb12-ana-0-3.sprintlink.net (144.232.1.61) [AS 1239] 88 msec 92 > msec 100 msec > 6 sl-gw7-ana-8-0-0.sprintlink.net (144.232.1.38) [AS 1239] 108 msec 92 > msec 88 msec > 7 sl-atmn-1-0-0.sprintlink.net (144.228.79.14) [AS 1239] 112 msec 112 > msec 108 msec > 8 lax00.nuq0.verio.net (129.250.2.197) [AS 2914] 104 msec 116 msec 104 > msec > 9 nuq0.pao5.verio.net (129.250.3.9) [AS 2914] 104 msec 100 msec 100 msec > 10 pao5.dca0.verio.net (129.250.2.246) [AS 2914] 172 msec 172 msec 176 > msec > 11 dca0.iad3.verio.net (129.250.2.61) [AS 2914] 168 msec 168 msec 168 > msec > 12 iad3.phl00.verio.net (129.250.3.106) [AS 2914] 184 msec 172 msec 176 > msec > 13 phl00.phl02.verio.net (129.250.3.154) [AS 2914] 172 msec 176 msec 176 > msec > 14 phl02.nyc1.verio.net (129.250.3.126) [AS 2914] 180 msec 176 msec 176 > msec > 15 nyc0.new-york.net (129.250.16.210) [AS 2914] 196 msec 196 msec 220 > msec > 16 nyc1.new-york.net (165.254.27.1) [AS 3384] 216 msec 216 msec 204 msec > 17 nyct-gw.new-york.net (204.141.247.202) [AS 3384] 204 msec 232 msec 204 > msec > 18 www.nyct.net (204.141.86.3) [AS 3384] 240 msec 220 msec 192 msec > > and a view from the other end: > > 1 gw1 (204.141.86.1) 1.716 ms 1.985 ms 1.647 ms > 2 nyc1.new-york.net (204.141.247.53) 6.680 ms nyc1.new-york.net (204.141.247.201) 45.256 ms nyc1.new-york.net (204.141.247.53) 4.348 ms > 3 nynet.nyc2.verio.net (129.250.16.253) 17.068 ms 15.114 ms 4.134 ms > 4 nyc2.ord2.verio.net (129.250.3.133) 80.155 ms 65.077 ms 105.167 ms > 5 ord2.bbn.verio.net (129.250.9.58) 83.454 ms 74.323 ms 48.674 ms > 6 p2-3.chicago1-nbr1.bbnplanet.net (4.0.1.205) 30.023 ms 28.376 ms 44.516 ms > 7 p2-1.paloalto-nbr2.bbnplanet.net (4.24.7.18) 94.908 ms 93.209 ms 100.024 ms > 8 p6-2.lsanca1-br2.bbnplanet.net (4.24.5.205) 108.497 ms 101.718 ms 102.779 ms > 9 p7-0.lsanca1-ba2.bbnplanet.net (4.24.4.37) 112.947 ms 102.288 ms 104.770 ms > 10 p1-0-0.lsanca1-bp1.bbnplanet.net (4.24.5.182) 137.716 ms 115.041 ms 105.331 ms > 11 s0-0-0.phnyaz2-cr1.bbnplanet.net (4.24.4.70) 137.202 ms 125.529 ms 120.528 ms > 12 fa8-1-0.phxcolo-core2.bbnplanet.net (4.1.110.238) 115.923 ms 126.025 ms 110.862 ms > 13 128.11.124.53 (128.11.124.53) 205.543 ms 198.474 ms 190.957 ms > 14 f12.border1.nyc1.genuity.net (207.240.1.82) 203.052 ms 254.448 ms 201.596 ms > 15 ptp-46.100fe10-0.nyc1.genuity.net (207.240.48.46) 242.274 ms 207.217 ms 233.641 ms > 16 covad-dsl-eth0.telehouse.inch.com (207.240.128.21) 210.980 ms 286.533 ms 259.133 ms > 17 sdsl-interface-130-208.dsl.inch.com (207.240.208.130) 274.182 ms 270.452 ms 264.278 ms > 18 zeus.7nt.com (207.240.214.2) 289.261 ms 265.979 ms * > > I am livid, is this any way to run a tier 1 network? More and more often, > I find myself (the customer who is supposed to know less) pointing out > gross errors to these folks. Sorry to vent. > > Charles > > -- > =-----------------= = > | Charles Sprickman Internet Channel | > | INCH System Administration Team (212)243-5200 | > | spork(a)inch.com access(a)inch.com | > = =----------------= > > >

3 2

BBN issues
by Charles Sprickman 13 Dec '99

13 Dec '99

Hello, I'm very sorry to use this list for this purpose, but I need a clueful person at BBN who has dealings with the old Genuity network to contact me. We're seeing paths like this to nearly everywhere on BBN-announced space, and we have not been able to get this fixed for over a week: (this is just one of many examples, but I thought the pure entertainment value would keep Randy from browbeating me) This is to a recent verio partner. It is my understanding that verio peers with bbn and that bbn does not buy transit from sprint for this purpose. Traffic to uu, cw, you-name-it takes similar paths. We are in NYC. Tracing the route to www.nyct.net (204.141.86.3) (NYC to NYC) 1 fa10-0.nyccolo-border1.bbnplanet.net (207.240.48.45) [AS 3847] 4 msec 0 msec 4 msec 2 f6-0.nyccolo-core1.bbnplanet.net (207.240.1.81) [AS 3847] 4 msec 0 msec 0 msec 3 128.11.124.54 [AS 3847] 80 msec 84 msec 80 msec 4 sl-gw11-ana-6-0-0.sprintlink.net (144.228.207.145) [AS 1239] 92 msec 96 msec 88 msec 5 sl-bb12-ana-0-3.sprintlink.net (144.232.1.61) [AS 1239] 88 msec 92 msec 100 msec 6 sl-gw7-ana-8-0-0.sprintlink.net (144.232.1.38) [AS 1239] 108 msec 92 msec 88 msec 7 sl-atmn-1-0-0.sprintlink.net (144.228.79.14) [AS 1239] 112 msec 112 msec 108 msec 8 lax00.nuq0.verio.net (129.250.2.197) [AS 2914] 104 msec 116 msec 104 msec 9 nuq0.pao5.verio.net (129.250.3.9) [AS 2914] 104 msec 100 msec 100 msec 10 pao5.dca0.verio.net (129.250.2.246) [AS 2914] 172 msec 172 msec 176 msec 11 dca0.iad3.verio.net (129.250.2.61) [AS 2914] 168 msec 168 msec 168 msec 12 iad3.phl00.verio.net (129.250.3.106) [AS 2914] 184 msec 172 msec 176 msec 13 phl00.phl02.verio.net (129.250.3.154) [AS 2914] 172 msec 176 msec 176 msec 14 phl02.nyc1.verio.net (129.250.3.126) [AS 2914] 180 msec 176 msec 176 msec 15 nyc0.new-york.net (129.250.16.210) [AS 2914] 196 msec 196 msec 220 msec 16 nyc1.new-york.net (165.254.27.1) [AS 3384] 216 msec 216 msec 204 msec 17 nyct-gw.new-york.net (204.141.247.202) [AS 3384] 204 msec 232 msec 204 msec 18 www.nyct.net (204.141.86.3) [AS 3384] 240 msec 220 msec 192 msec and a view from the other end: 1 gw1 (204.141.86.1) 1.716 ms 1.985 ms 1.647 ms 2 nyc1.new-york.net (204.141.247.53) 6.680 ms nyc1.new-york.net (204.141.247.201) 45.256 ms nyc1.new-york.net (204.141.247.53) 4.348 ms 3 nynet.nyc2.verio.net (129.250.16.253) 17.068 ms 15.114 ms 4.134 ms 4 nyc2.ord2.verio.net (129.250.3.133) 80.155 ms 65.077 ms 105.167 ms 5 ord2.bbn.verio.net (129.250.9.58) 83.454 ms 74.323 ms 48.674 ms 6 p2-3.chicago1-nbr1.bbnplanet.net (4.0.1.205) 30.023 ms 28.376 ms 44.516 ms 7 p2-1.paloalto-nbr2.bbnplanet.net (4.24.7.18) 94.908 ms 93.209 ms 100.024 ms 8 p6-2.lsanca1-br2.bbnplanet.net (4.24.5.205) 108.497 ms 101.718 ms 102.779 ms 9 p7-0.lsanca1-ba2.bbnplanet.net (4.24.4.37) 112.947 ms 102.288 ms 104.770 ms 10 p1-0-0.lsanca1-bp1.bbnplanet.net (4.24.5.182) 137.716 ms 115.041 ms 105.331 ms 11 s0-0-0.phnyaz2-cr1.bbnplanet.net (4.24.4.70) 137.202 ms 125.529 ms 120.528 ms 12 fa8-1-0.phxcolo-core2.bbnplanet.net (4.1.110.238) 115.923 ms 126.025 ms 110.862 ms 13 128.11.124.53 (128.11.124.53) 205.543 ms 198.474 ms 190.957 ms 14 f12.border1.nyc1.genuity.net (207.240.1.82) 203.052 ms 254.448 ms 201.596 ms 15 ptp-46.100fe10-0.nyc1.genuity.net (207.240.48.46) 242.274 ms 207.217 ms 233.641 ms 16 covad-dsl-eth0.telehouse.inch.com (207.240.128.21) 210.980 ms 286.533 ms 259.133 ms 17 sdsl-interface-130-208.dsl.inch.com (207.240.208.130) 274.182 ms 270.452 ms 264.278 ms 18 zeus.7nt.com (207.240.214.2) 289.261 ms 265.979 ms * I am livid, is this any way to run a tier 1 network? More and more often, I find myself (the customer who is supposed to know less) pointing out gross errors to these folks. Sorry to vent. Charles -- =-----------------= = | Charles Sprickman Internet Channel | | INCH System Administration Team (212)243-5200 | | spork(a)inch.com access(a)inch.com | = =----------------=

2 1

BGP Blowup?
by Tim Wolfe 13 Dec '99

13 Dec '99

Being somewhat of a paranoid body, I have all my BGP peers currently set for max-prefix of 75000. On Friday, my Sprint peer (usually around 67k) exceeded that number and we stopped the session. This in itself is not a big deal, but looking at http://www.telstra.net/ops/bgptable.html I notice that they suck a large influx in the table at a similar time.. Did anyone else see something similar? If so, what peers did you see this from? Here is the log for my incident in question.. Dec 10 15:03:54 No. of prefix received from SPRINTROUTER reaches 67117, max 75000 Dec 10 15:31:16 No. of prefix received from SPRINTROUTER reaches 67137, max 75000 Dec 10 15:50:50 No. of prefix received from SPRINTROUTER reaches 67133, max 75000 Dec 10 15:54:10 No. of prefix received from SPRINTROUTER reaches 67100, max 75000 Dec 10 15:54:40 No. of prefix received from SPRINTROUTER reaches 67102, max 75000 Dec 10 15:55:10 No. of prefix received from SPRINTROUTER reaches 67099, max 75000 Dec 10 16:27:34 No. of prefix received from SPRINTROUTER reaches 67024, max 75000 Dec 10 16:42:38 No. of prefix received from SPRINTROUTER reaches 67024, max 75000 Dec 10 16:45:53 No. of prefix received from SPRINTROUTER reaches 67068, max 75000 Dec 10 17:18:58 No. of prefix received from SPRINTROUTER reaches 67078, max 75000 Dec 10 17:39:35 No. of prefix received from SPRINTROUTER reaches 73712, max 75000 Dec 10 17:39:39 No. of prefix received from SPRINTROUTER: 75001 exceed limit 75000 My session was disabled so I'm not sure how much bigger their table got. The only reason I bring this up here instead of directly to Sprint is that the data on the Telestra page appears to point the finger at this being a multi-provider incident, and I haven't heard anything on this list or others regarding the situation.. TIA, -- Tim -------------------------------------------------- * Timothy M. Wolfe, Chief Network Engineer * * ClipperNet Corporation / It's a wireless world * * tim(a)clipper.net 800.338.2629 x 402 * * Sufficient for today = Inadequate for tomorrow * --------------------------------------------------

2 2

Re: [announce-all] NAC Maintenance this weekend (fwd)
by Dean Anderson 12 Dec '99

12 Dec '99

Around 12:36 PM 12/11/1999 -0500, rumor has it that Greg A. Woods said: > >[ On Saturday, December 11, 1999 at 03:02:07 (-0500), Steve Sobol wrote: ] >> Subject: Re: [announce-all] NAC Maintenance this weekend (fwd) >> >> The last time a transformer blew near my house, all that happened is >> that some of the neighbors lost power for a while. Well, some years ago, I called the building maintenance guy to tell him about a rattling transformer (about 2KAmp). He told me to get out of there fast. Turned out to be a broken cooling fan making noise. Another employer used to do some odd things with power, which eventually blew out their tranformer. Took 3 of those semi trailers with 1Megawatt generators running for a week while repairs were made. So, I don't doubt that a generator test, or rather the sudden interruption of load, could result in a tranformer failure and the damage as described. Its just that sort damage would make news that could be found. Maybe we are just bad searchers... --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean(a)av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

1 0

Re: St Louis Outage
by Sean Donelan 11 Dec '99

11 Dec '99

On Fri, 10 December 1999, Erik Montemer wrote: > We are currently experiencing an AT&T Outage in the St. Louis area. It > seems to be affect both data and voice services. No ETR at this time. There was a cable cut near Wentzville, MO yesterday, between Jefferson City and St. Louis. There was also a cable cut in New York.

1 0

Re: BGP dampening parameters
by Danny McPherson 10 Dec '99

10 Dec '99

Do many folks actually implement prefix-based dampening parameters? On customers or peers only? Seems like more gunk in the router configurations to confuse folks, although I suppose that it's potentially less confusing than having customers request that a given prefix be "unsuppressed". And, _if it wasn't obvious already, for all the folks suggesting that a globally routable /n (where n = some prefix length) was a requirement, you should have a look at section 1.5 "Aggregation versus damping". Even if you're multi-homed and your providers aren't performing any type of specifics suppression proxy-aggregation type stuff, an aggregate announcement from one of your upstreams *not* being suppressed could save some headaches. I don't completely agree with the "bgp fast-external-fallover" section (2.4), though I suppose it's up to the operator anyways :-) One useful addition to the document would be regarding BGP Route Refresh versus the soft-reconfiguration stuff. Along these lines, is asking why NANOG doesn't publish these types of BCP documents a silly thing? Given, the BCP from that perspective seems to suggest publishing an ID and submitting to some random IETF WG, but perhaps....? -danny > "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

St Louis Outage
by Erik Montemer 10 Dec '99

10 Dec '99

We are currently experiencing an AT&T Outage in the St. Louis area. It seems to be affect both data and voice services. No ETR at this time. -- Erik L. Montemer Missouri Research and Education Network -- MOREnet University of Missouri-Columbia (573) 884-7200 montemer(a)more.net http://www.more.net/

1 0