- Test - lists.nanog.org

Y2K status list - apology/mail issue
by Sean Donelan 15 Dec '99

15 Dec '99

I found out Critical Path's mail system silently swallows e-mail with too many addresses. I don't know if this was spam prevention, or just a system limitation. In any case, it swallowed my messages for the last two weeks to the ISPs who asked to participate in the Y2K new year's rollover status list. I did get your mail, and I am now cutting and pasting your addresses to a different system. I will be sending individual messages to everyone today. If you don't receive a message by Friday December 17, do not hesitate to contact me. I guess its a good thing I tested it before the end of the year.

1 0

16 days and counting
by Jim Mercer 15 Dec '99

15 Dec '99

geez, nothing like cutting it to the wire. -- [ Jim Mercer jim(a)reptiles.org +1 416 506-0654 ] [ Reptilian Research -- Longer Life through Colder Blood ] [ Don't be fooled by cheap Finnish imitations; BSD is the One True Code. ] ----- Forwarded message from UUNET Canadian Support <support(a)uunet.ca> ----- Date: Tue, 14 Dec 1999 20:18:26 -0500 From: UUNET Canadian Support <support(a)uunet.ca> To: announce(a)uunet.ca Subject: UUNET Year 2000 Customer Premise Equipment Information Notification Dear Valued Customer: UUNET Year 2000 Customer Premise Equipment Information Notification UUNET is currently engaged in a project to evaluate its readiness for Year 2000. The UUNET Year 2000 Program Office manages program activities that encompass the customer global network and value-added services as well as internal systems. UUNET is taking this opportunity to communicate with its customers concerning their joint responsibilities for evaluating whether the Customer Premise Equipment (CPE) used in conjunction with UUNET services is Y2K compliant. This equipment includes routers, CSU/DSU's, firewalls, servers and desktops. Although UUNET does not make any claim or warranty as to the Year 2000 compliance of this third-party equipment, we are providing you with the sources of vendor compliance information in the web so that you can evaluate the CPE's Year 2000 status. We encourage you to contact the manufacturers of your CPE for information on their Year 2000 programs and the Year 2000 readiness of this equipment. The table on the next pages shows the type of equipment, the manufacturer and the URL through which you may be able to obtain more information. This list includes CPE that UUNET currently ships and supports. You may own other equipment that was not supplied by UUNET or that is not currently shipped and supported by UUNET. We hope that you will use this information to examine your CPE, assess its Year 2000 readiness, and upgrade any equipment that may require such action. Should you have questions concerning CPE, please call UUNET at 1-888 886 3865. If you have questions concerning UUNET's Year 2000 Program, we hope you will read our Year 2000 information at : http://www.wcom.com/about_the_company/year_2000_compliance/uunet_y2k/index.…. Direct inquiries to the Year 2000 Program Office can be made to year2000(a)uu.net. The information provided by UUNET in this letter constitutes a year 2000 readiness disclosure under the Year 2000 Information and Readiness Disclosure Act (October 19, 1998, 105 U.S. Public Law 271, 112 Stat. 2386). This Year 2000 readiness disclosure includes a republication of Year 2000 statements originally made by the third party manufacturers of the equipment listed below. UUNET is not the source of these republished statements, which have been supplied by another entity, which are based on information UUNET has not verified. Accordingly, UUNET is not responsible for the republished information's accuracy, completeness, or currency. "UUNET" as used herein and the references to various networks, services, and systems, refers only to UUNET and its networks, services, and systems, and should not be construed as applying to MCI WORLDCOM Inc. ("MCI WorldCom") in general or to any other WorldCom or MCI companies or their networks, services, or systems. We look forward to servicing you well into the new millenium! Sincerely, Andrew Ordin Y2K Project Coordinator Category Manufacturer and URL to Obtain Vendor's Model Number Recommendations Router Cisco 2501, 2514 www.cisco.com Cisco 2524 www.cisco.com Cisco 2610 www.cisco.com Cisco 3640 www.cisco.com Cisco 4500,4700 www.cisco.com Cisco 7200 series www.cisco.com OpenROUTE GTX1000 www.openroute.com Xedia AP 45 www.xedia.com Xedia AP ATM www.xedia.com Xedia AP T1/E1 www.xedia.com Ascend Pipeline 130 www.ascend.com Intel Express 8100 www.intel.com CSU/DSU Kentrox D-SERV 56k and T1 (78220, 78282 and 78222) www.adc.com Kentrox DataSmart D-SERV www.adc.com Verilink HDM2182 in the AS2000 CSU/DSU www.verilink.com Larscom Access T45 www.larscom.com Digital Link DL3100 www.dl.com Cisco POET serial port adaptor (1 &2 port) www.cisco.com Firewall Software Checkpoint Firewall-1 www.checkpoint.com Checkpoint SecuRemote www.checkpoint.com Axent Raptor Firewall www.axent.com Axent Raptor Mobile www.axent.com Gauntlet Firewall www.nai.com Ascend SecureConnect Firewall (SCF) 3.0 (in Ascend Pipeline products) www.ascend.com Firewall Platforms Sun Ultra or Sparc www.sun.com Patriot Black Box - Pentium II PC www.patriot.com Ascend Pipeline 85, Pipeline 75 www.ascend.com Firewall Operating Systems Sun Solaris www.sun.com Microsoft NT www.microsoft.com BSD www.bsdi.com Dial Access Ascend Pipeline 85, Pipeline 75 www.ascend.com Adtran ISU128 www.adtran.com 3COM Impact IQ Terminal Adaptor www.3com.com 3COM 56K Voice Fax modem Pro www.3com.com Cisco 1005 www.cisco.com Cisco 804 www.cisco.com Cisco 1604 (ISDN/T1) www.cisco.com Bay Instant Internet 100 www.nortelnetworks.com Hayes Accura 56K external data fax modem www.hayes.com US Robotics FX-BRI-U www.3com.com Whistle IJ100, IJ140 www.whistle.com -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= UUNET Canadian Technical Support / Support Technique Canadien support(a)uunet.ca / soutien(a)uunet.ca Phone: (888) 886 3865 fax: (416) 368-5473 ----- End forwarded message -----

1 0

Whois
by David Lesher 15 Dec '99

15 Dec '99

So where do we look up handles nowadaze? I tried a couple of obvious ways to no avail... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

2 2

Peering
by Alba, Victor 15 Dec '99

15 Dec '99

I hope this question belong to this list. I was wondering if there is a place where I could find peering information (public) among the different providers as well as the general description of each one of the major providers IP backbones (UUNet, C&W, Sprint, GTE, etc.) -Victor

3 2

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 14 Dec '99

14 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