July 1998 - Test - lists.nanog.org

Re:Worldcom Fiber Cut
by Martin, Christian 22 Jul '98

22 Jul '98

600 DS3s affected. ETR 19:30-20:00. This is the second major cut in as many weeks. Whatver happened to SONET redundancy, hmmm???? -Chris

1 0

Smurfable Networks
by Brian Horvitz 22 Jul '98

22 Jul '98

Well, it's been an exhaustive evening. We've been the target of a pretty good smurt attack, which has had my network sucking down between 30 and 50 Meg for the last 10 hours or so. I'd appreciate it if you all could have a look at the following list of source blocks and let me know if you own them and preferably do something about it. Thanks. Brian Horvitz Shore.Net 12.127.131 12.68.136 12.68.160 128.109.34 128.135.2 128.135.253 128.135.91 128.193.6 128.195.23 128.2.203 128.213.4 128.241.3 128.252.221 128.252.233 128.252.5 129.107.1 129.11.11 129.11.12 129.11.13 129.11.14 129.11.152 129.11.159 129.11.16 129.11.20 129.11.22 129.11.8 129.11.9 129.110.10 129.110.13 129.110.14 129.110.15 129.110.4 129.110.5 129.110.6 129.110.7 129.110.8 129.110.9 129.111.2 129.115.4 129.115.6 129.115.8 129.117.1 129.117.10 129.117.11 129.117.12 129.117.14 129.117.17 129.117.20 129.117.22 129.117.24 129.117.36 129.117.41 129.117.5 129.117.8 129.122.16 129.122.20 129.122.46 129.125.1 129.125.13 129.125.136 129.125.14 129.125.16 129.125.17 129.125.19 129.125.20 129.125.5 129.125.8 129.128.1 129.128.15 129.131.1 129.131.12 129.131.15 129.133.1 129.133.10 129.133.12 129.133.13 129.133.15 129.133.16 129.133.18 129.133.19 129.133.2 129.133.20 129.133.21 129.139.10 129.139.128 129.139.14 129.139.2 129.139.20 129.139.22 129.139.23 129.139.8 129.139.9 129.141.120 129.141.20 129.141.22 129.141.5 129.142.6 129.142.7 129.161.16 129.173.13 129.173.249 129.180.1 129.180.11 129.180.16 129.180.9 129.182.13 129.182.14 129.182.15 129.182.16 129.182.17 129.182.18 129.182.21 129.182.22 129.182.3 129.182.5 129.182.9 129.183.1 129.183.16 129.183.19 129.183.20 129.183.4 129.189.1 129.189.10 129.189.180 129.189.2 129.189.9 129.191.1 129.207.10 129.210.11 129.210.12 129.210.13 129.210.15 129.210.16 129.210.17 129.210.18 129.210.19 129.210.20 129.210.21 129.210.4 129.210.5 129.210.8 129.212.11 129.213.12 129.214.251 129.214.3 129.215.162 129.215.2 129.215.3 129.219.16 129.223.1 129.223.10 129.223.14 129.223.2 129.223.20 129.223.8 129.223.9 129.231.10 129.231.17 129.234.16 129.234.8 129.238.12 129.238.13 129.238.14 129.238.28 129.242.10 129.244.1 129.244.14 129.244.17 129.244.18 129.244.20 129.244.22 129.244.41 129.244.5 129.244.6 129.244.8 129.246.101 129.246.13 129.246.20 129.246.22 129.246.229 129.246.25 129.250.20 129.250.255 129.253.0 129.253.16 129.253.18 129.253.19 129.253.31 129.253.64 129.254.10 129.254.11 129.254.143 129.254.2 129.254.20 129.254.21 129.254.224 129.254.3 129.254.5 129.254.6 129.254.7 129.254.9 129.255.128 129.255.14 129.255.22 129.255.230 129.255.246 129.3.254 129.32.0 129.32.25 129.32.4 129.32.6 129.32.8 129.37.0 129.40.16 129.40.3 129.40.4 129.46.49 129.47.10 129.47.180 129.5.176 129.52.251 129.52.7 129.52.9 129.61.21 129.66.1 129.66.12 129.66.2 129.66.20 129.66.3 129.66.4 129.7.18 129.74.10 129.78.1 129.78.22 129.78.23 129.79.2 129.79.5 129.80.22 129.81.10 129.81.153 129.81.174 129.81.186 129.81.241 129.84.2 129.84.3 129.84.4 129.89.18 129.93.1 129.93.11 129.93.116 129.93.12 129.93.120 129.93.13 129.93.14 129.93.16 129.93.17 129.93.18 129.93.19 129.93.21 129.93.22 129.93.3 129.93.4 129.93.56 129.93.6 129.93.66 129.93.8 129.94.1 129.94.12 129.94.129 129.94.17 129.94.177 129.94.18 129.94.19 129.94.2 129.94.20 129.94.22 129.94.4 129.94.66 129.94.8 129.96.201 130.244.194 131.151.7 132.178.181 132.241.60 134.222.200 134.24.32 134.24.42 135.206.251 136.176.5 136.176.80 137.145.202 137.52.129 138.171.6 139.130.5 140.142.12 140.247.210 141.198.1 144.224.23 144.228.134 144.232.139 144.92.233 146.97.254 149.171.204 150.252.40 150.252.47 152.163.194 152.163.201 152.163.204 152.163.205 152.166.26 152.205.20 153.37.94 157.130.192 165.166.8 166.48.23 166.48.234 166.48.92 169.130.112 169.130.73 172.19.59 192.12.10 192.132.65 192.160.127 192.225.17 192.234.72 192.65.88 193.107.188 193.54.185 193.54.238 198.174.96 198.182.76 198.185.178 198.252.208 198.79.72 199.164.151 199.179.169 2.0.0 200.0.227 203.15.123 203.251.18 204.202.169 204.233.137 204.27.123 204.49.9 204.62.245 204.70.181 204.70.227 204.70.29 204.70.40 204.70.43 204.71.52 205.173.178 205.240.124 205.252.130 206.111.144 206.127.8 206.13.28 206.150.138 206.162.64 206.165.113 206.173.136 206.175.105 206.245.156 207.158.78 207.170.53 207.171.46 207.21.136 207.214.13 207.217.208 207.227.71 207.235.31 207.25.201 207.69.200 207.79.35 207.8.5 207.90.198 208.135.168 208.16.152 208.23.202 209.1.169 209.216.44 209.30.66 209.42.128 209.45.240 209.51.160 209.54.110 24.112.115 32.101.8 38.2.195 38.2.99

6 5

Re: Worldcom cut?!?
by Adam Rothschild 22 Jul '98

22 Jul '98

Uhmm, the BENGI list sez: There is a huge worldcom fibercut between Stanton and Foyshill penn.. there is no ETA, worldcom has dispatched. Strange. On Wed, Jul 22, 1998 at 02:02:11PM -0600, Hui-Hui Hu wrote: > > I donno, but I got a message about a fibre cut by Worldcom in > Stanton, CT that is affecting much northeast traffic. > What's in PA? > > : Anyone have any information about the extent of this Worldcom phiber cut in P > : A, est. repair time, etc? > : > : Thanks in advance, > : -Adam > :

1 0

Re: Smurfable Networks
by Richard Thomas 22 Jul '98

22 Jul '98

-----Original Message----- From: Yung-Chao Yu <yy(a)qsun.ho.att.com> To: Brian Horvitz <horvitz(a)shore.net> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Wednesday, July 22, 1998 2:05 PM Subject: Re: Smurfable Networks >It is not clear to me how you got net 12 entries in your list. >They are not smurfable and I don't think they have even been. >Please remove them from your list. >Thanks. I don't see a single entry in that list which is a broadcast. I would say someone is being taken here. Perhaps you were flooded with straight spoofed echo replies, as most of these networks seem to be the EXTRA-responsible ones.

2 1

Re: Weird BGP Issue
by Sean M. Doran 22 Jul '98

22 Jul '98

Say, whatever happened to the wonderful patent pending tool from Priori (see below) which will fix all the horrible problems with BGP with its broken blahs and prepending traffic to places and obviously very difficult to use terminology? I'm sure many people are interested in such an operational tool, and it's now even topical, given the discussion revolves around BGP's path selection as it relates to operators. Sean. - -- | So, in many cases shortcuts are | taken such as prepend all of so and so's traffic through connection A, or, | perhaps in your case, prefer connection A for /16 blocks or larger, and B | for smaller... ... | What you really need is a cut and paste of a few sho ip bgp blahs and sho | ip route blahs.... - -- > From: "Robert L. Shearing" <robert(a)priori.net> > Subject: Re: hmm..wierd shit at priori > Message-Id: <3.0.32.19980202191654.00bf3e88(a)local.mail.priori.net> > Date: Mon, 02 Feb 1998 19:16:56 -0800 > ... > Subsequently Priori hired a CTO, Chris Icide, who invented a routing > technology that allow Priori to blow out the competition in routing > performance. ... - -- > From: "Robert L. Shearing" <robert(a)priori.net> > Subject: Re: hmm..wierd shit at priori > Date: Sun, 01 Feb 1998 22:51:01 -0800 > Message-Id: <3.0.32.19980201225100.00be2980(a)local.mail.priori.net> > ... > Second, > we agreed that the way BGP-4 determines path selection is primitive almost > to the point of stupidity. > > Chris invented a dynamic and robust new routing technology, not yet > officially announced, that is far smarter than BGP-4. We believe this > technology will give Priori a substantial performance edge over all other > National Internet Backbones, including Savvis, by June, 1998. Indeed, we > believe this technology will all but eliminate 404 (Cannot reach that > destination) errors for customers of the Company. This technology is now > patent pending. ... > There you have it. The Special Report on how Priori ran into some > technical glitches early on, overcame them and then became the industry > performance leader in a period of eight months. ... > Robert L. Shearing voice: +1-650-482-2840 > President/CEO fax: +1-650-482-2844 > PRIORI NETWORKS, INC. http://www.priori.net

1 0

roamabout/wavelan and macs
by Robert E. Seastrom 22 Jul '98

22 Jul '98

Is anyone using Roamabout cards successfully with a G3 "Wallstreet" powerbook? If so, could you please drop me a line? I have a couple of questions (mainly having to do with what drivers you're using...) ---Rob

1 0

Re: Weird BGP Issue
by Chris A. Icide 22 Jul '98

22 Jul '98

In many cases, one finds that people who manage thier bandwidth closely to limit the amount they buy sometimes do strange things (I'm not saying invalid or wrong things under whatever circumstances, it may be perfectly valid) to optimize the use of thier current bandwidth. For example, take a customer who has two T1 circuits from different providers. In many cases if there is a major difference between the two upstreams, (i.e. a tier one provider versus a regional ISP), BGP will tend to select one for most of the traffic. So, in many cases shortcuts are taken such as prepend all of so and so's traffic through connection A, or, perhaps in your case, prefer connection A for /16 blocks or larger, and B for smaller... I'm not commenting one way or another on the validity of this, as in many cases it's a business decision versus a technical decision. I'm just commenting that I've seen this many times. What you really need is a cut and paste of a few sho ip bgp blahs and sho ip route blahs.... -Chris At 12:02 AM 7/22/98 -0700, Jason L. Weisberger wrote: > >Y's routing policy should effect both blocks in the same way however, and >not be an issue - so long as they haven't decided to specifically route >the block strangely. > <snip>

1 0

Re: OPERATIONAL : MCI - Kansas City hosed?
by sully＠mail.usinternet.com 22 Jul '98

22 Jul '98

I've noticed some major problems at MCI's core in Kansas City as well. I've called MCI and they say there is no problems. I emailel trouble(a)mci.net and here is thier response. I've have seen almost no improvement since I have recieved this email. Return-Path: <gbrown(a)cary.mci.net> Date: Mon, 13 Jul 1998 15:42:50 -0400 (EDT) Sender: gbrown(a)cary.mci.net From: Greg Brown <gbrown(a)cary.mci.net> To: sully(a)mail.usinternet.com Subject: RE: routing problems at MCI level Cc: trouble(a)mci.net Tim, We currently have a core router shut down in willowsprings due to an interface problem. The new card is due on site at 7pm EDT and will be replaced at that time. Once the router is restarted your routes should return to normal. greg iMCI/iNOC At 11:20 PM 7/21/98 -0500, you wrote: >For the past 12 or so hours, we have been experiencing mediocre response >times through MCI's core in Kansas City... has anyone heard of any problems >there? I haven't been able to find out anything....(now...where's my >multi-homed link request form again???) > >Danke > >Kevin Brown >Huber & Associates, Inc. >Networking Technologies >kbrown(a)primelink.com > > >

1 0

Re: OPERATIONAL : MCI - Kansas City hosed?
by Sean Donelan 22 Jul '98

22 Jul '98

>For the past 12 or so hours, we have been experiencing mediocre response >times through MCI's core in Kansas City... has anyone heard of any problems >there? I haven't been able to find out anything....(now...where's my >multi-homed link request form again???) MCI hasn't posted anything to their customer list, but if you go to their traffic monitoring site http://traffic.mci.com/ you'll find Independence isn't listed on the front page with the rest of the "green" sites. Go down a level to the "other cities" page and query various various destinations. Independence to several other cities on MCI's network reports a "red" and "yellow" delay statistic. Before a reporter takes this date point and turns it into a gory story, remember MCI is about the only major NSP making any data public about their network performance. If everything was always "green," people might wonder if it was rigged. I'm sure several other folks will also post the inevitable question, have you asked MCI's NOC about this? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Weird BGP Issue
by Jason L. Weisberger 22 Jul '98

22 Jul '98

Lets say ISP X is peering with Tier One's A and B, as well as buying transit from them. ISP Y also peers with A and B, in another geographic region. While all routes for Y are best through A for X, it seems that 75% of X's routes have a return path of A for Y to reach X and the other 25%, although annouced in the EXACT SAME MANNER, use B for the return. ISPs A and B both claim they are distributing all of the routes in the exact same manner, there is no difference between a route for one of my /17's and there is for one of my /19's - yet some of my traffic is taking a different return path than the rest of it. Assymetry is cool and all, but this boggles the mind. Basically: I announce 207.155.0.0/17 and 209.151.224.0/19 to A and B. ISP A and B annouce them to both to Y, making no discrimination between the two routes. ISP Y takes A for 207.155.0.0/17 and B for 209.151.224.0/19 Why doesn't take the route from A as best is 207.155.0.0/17 is best from A or why doesn't it choose B over A, as the 209.151.224.0/19 route appears better. I'd like to understand this c.p. and not just find an answer that is "prepend your routes to A and B will always be preferred." Any ideas? -- Jason Weisberger Chief Technology Officer SoftAware, Inc. - 310/305-0275 ...but the wicked shall do wickedly... --Daniel 12:10

2 3