- Test - lists.nanog.org

Re: Ascend GRF400
by Tony Li 26 Apr '97

26 Apr '97

> Correct me if I am wrong, but I thought the GRF-400 was an Ascend product > and the GRF-1600 is the NetStar GigaRouter, with some additional > developments. > > The GRF-400 is out there in networks like AGIS, NetRail, PSI, DOMINO and > Savvis. No word on any NetStar-cum-GRF1600 deployments. > > Am I right? My understanding is that the GRF-400 is just a 4 slot version of the GRF-1600, modulo cosmetic differences, branding etc. Certainly this is one of the easiest ways that one can take a crossbar switch and produce a cost reduced, bandwidth reduced midrange. Tony p.s. Do I hear a chainsaw in Minneapolis? ;-) ;-) ;-)

1 0

Now comes the news.
by Christian Nielsen 26 Apr '97

26 Apr '97

There are already 2 articles on the net about it http://www.news.com/News/Item/0,4,10083,00.html?latest http://www.wired.com/news/technology/story/3442.html and I am sure there are more to come. It seems too easy for one person/company to bring down the net. Yes, we all agree it was some kind of accident, one that wasn't supposed to happen BUT I have to ask, where were all the network people that should have caught this before it hit the internet full force. Yes, there is talk about having the RAs setup and to prevent this type of thing, but not much else. We put our stuff in the RA when we remember to but I don't think that many people look much at them anyways. Hopefully next time this can be stopped before long, like maybe within 10 - 20 mins. Maybe it is time for all companies, even the smaller ones, or those that use BGP to have and really USE a 24 hour noc. Where there are people there that really know about routers and BGP. Maybe as the internet grows, those making it grow need a more active role. Sorry, Voice mail doesn't cut it, or a busy number when the internet comes down.... Christian

1 0

RE: Wow, AS7007!
by Dave Van Allen 25 Apr '97

25 Apr '97

>-----Original Message----- >From: Stephen A Misel [SMTP:stevem@hway.net] >Sent: Friday, April 25, 1997 12:53 PM >To: nanog(a)merit.edu >Subject: Wow, AS7007! > >I happened to be in one of our 7505 routers this afternoon when POP -- all >of a sudden most of the internet disappeared! I immediately thought it was >me, but looked around and saw this AS7007 broadcasting MY routes! > >[...] > >Correct me if I'm wrong, but: > > (1) We're going to read about this in EVERY computer magazine, newspaper >and TV as "the end of the internet?" > >Probably. It's newsworthy in that it punctuates the statement "Nearly anyone >with a BGP router in hand can instantly core-dump the global routing tables" > > (2) Access lists by backbone providers *should* have prevented this. > >Mostly. An ISP, whether large or small that BGP's with customers can indeed >do distribute ACL's both on AS heard, and routes learned, including masks. >You can easily re-announce or announce only what you want, or not announce or >re-announce routes that are inconsistent with your policy or ACL's. > > (3) Does or does not the RADB and other routing registries (MCI's, etc) >prevent this? > >It helps, but all you need are a few ingress' that do not filter and you can >pollute enough of the core to hose it very nicely indeed. > >I bet this hole will be patched up real soon! > >I don't think so. I'm not sure that this is as much a "hole" as it is a >relationship and trust issue. Right now, when things go OK, the routing >policies on Net work pretty well. Unarguably, they need refining, but >all-in-all the Net still relies mostly on trust, as it has from the >beginning. If we simply take all trust away, then the current topology would >not work, and may not be able to be made to work quickly enough, without even >more disasters. > >This exact thing has happened before, and potentially will happen again >because all it can take is one typo under 'router bgp xxxxx' at the right >place, in the right network, and the Internet can go quickly to /dev/null. >This is the trust factor. We all rely on the fact that router-jocks won't >typo, will filter where appropriate, and will educate rookies prior to >whispering the enable passwd to them. > >A few things would help, IMO - All BGP should be authenticated, and all >neighbors should be ACL'd. > >Now after spending 4 hours announcing more specifics to cover the bogon >routes so we could play Internet today for a bit, it's time to be a >good-netcitizen and see if I can't re-CIDR myself. Then it's off to the >Scotch locker! :-) > > >Best regards, > >Dave Van Allen - You Tools Corporation/FASTNET(tm) >dave(a)fast.net (610)289-1100 http://www.fast.net >FASTNET - PA/NJ/DE Business Internet Solutions >

2 1

7007: FROM THE HORSE'S MOUTH
by Avi Freedman 25 Apr '97

25 Apr '97

MAI's view: Here's a status on what AS 7007 themselves saw and think happened. They're disconnected from the 'net now, so they can't post this themselves. 7007 is an ASN used by mai.net, MAI Network Services. They also use ASN 6082. Their topology at their new data center is: [asn 6082] Bay BLN [fddi] -> mae-east, where they peer with some and have mae-transit from Sprintlink [1239] [asn 7007] Bay BLN [t3] -> sprintlink [1239 1790] [t3] -> customer X And the two BLNs are connected to each other via 100bt. Customer X announced something like a full route table, according to MAI, and MAI was not filtering on either AS_PATH or by distribute_list (or whatever Bay calls them) on the routes. MAI apologizes for this, and acknowledges that if they had done this, the major problem could have been avoided. At about 11:30am (this is when we saw it), they started redistributing more specifics for many (thousands) of CIDR routes to Sprintlink [1239 1790] but the routes were announced - AND the routes were injected with an origin AS of 7007, hiding the AS_PATH the routes had (and the customer involved). MAI noticed this at about 11:45. MAI shut down the Sprintlink connection and the same thing happened again. 72,000 is the number of routes the Sprint router took before it melted, but the Bay might have been willing to generate even more than that. Anyway, Sprintlink saw the routes again from MAI (the de-aggregated specifics, with an AS_PATH of ^7007$). Then they rebooted the router and the 7007 router was not advertising the specifics or hiding AS_PATH info, but the damage was done, and the more specifics were still out there for some reason. At about 12:15 they shut off all of their routers; shortly after Sprintlink shut down the T3 for good measure. MAI does NOT think that they were distributing the BGP routes into an IGP and then readvertising them on that basis; they think there was/is a Bay BGP bug that caused this to happen. MAI's NOC # is 888 624 8700. Vincent Bono of MAI wishes to apologize for the trouble; a Bay tech is on the scene in DC working on the problem to make sure that when they come back up, nothing like this will happen again. An outside view of what happened: At 11:30, I noticed that we lost connectivity to the world. Some of our customers called our NOC - and our dual-homed customers said that they saw hundreds of routes from ASN 7007. One of the customers noticed that the ASN 7007 routes were stomping on their OSPF routes (because the BGP routes from _1239 1790 7007$ were more specific than some of their internal /23 OSPF routes). And ASN 7007 We saw about 60k routes in our core routers at the time, and saw thousands of routes from 7007 when we looked more carefully. We kept clearing sessions to filter 7007 but the routes kept popping back up: Sprint (of course), UUNET, and MCI all had them. Also, we had to advertise some of our customers more specifically because the dampened 7007 routes (because everyone else was clearing at the time) were screwing their connectivity. I know that some others did this, so tomorrow the tables will have a bunch of more specifics, I suppose. A note: If all more specific routes for a destination are dampened, exsting more general routes will not be looked at. If this behavior was changed, some of the blackholing that went on today would not have been possible. But this is a separate topic for discussion. I suppose that the immediate topic will be route filtering vs. AS_PATH filtering... Thanks, Avi Freedman (the original) Net Access (netaxs.net)

2 1

RE: Time frame..
by Wayne Bouchard 25 Apr '97

25 Apr '97

Based on my (now) mucked up traffic graphs, I'd say it started at about 8:30am PDT and I saw the last of it about 9:45. ---------------------------------------------------------------------- Wayne Bouchard GlobalCenter web(a)primenet.com Primenet Network Engineering Internet Solutions for (602) 416-6422 800-373-2499 x6422 Growing Businesses FAX: (602) 416-9422 http://www.primenet.com http://www.globalcenter.net ----------------------------------------------------------------------

2 1

RE: 7007: FROM THE HORSE'S MOUTH
by Dave Van Allen 25 Apr '97

25 Apr '97

>-----Original Message----- >From: Avi Freedman [SMTP:freedman@netaxs.com] >Sent: Friday, April 25, 1997 5:20 PM >To: freedman(a)access.netaxs.com; nanog(a)merit.edu >Subject: 7007: FROM THE HORSE'S MOUTH > > >MAI's view: > >Here's a status on what AS 7007 themselves saw and think happened. >They're disconnected from the 'net now, so they can't post this >themselves. >MAI does NOT think that they were distributing the BGP routes into an >IGP and then readvertising them on that basis; they think there was/is >a Bay BGP bug that caused this to happen. > >Or Bay unfamiliarity, to be fair. BCN's are all over the core participating >in BGP everyday in some very large networks as you know. If MIA is not >running the Bay ISP workspace code, then they need to get Bay to educate them >on what's available and appropriate for their environment. > >An outside view of what happened: > >And ASN 7007 > >We saw about 60k routes in our core routers at the time, and saw >thousands of routes from 7007 when we looked more carefully. > >When you and I were on the phone, we saw 70K at one time, and the Cisco's >were at 100% doing nothing but route calculations. > >We kept clearing sessions to filter 7007 but the routes kept popping >back up: Sprint (of course), UUNET, and MCI all had them. > >Which of course half of the Net was doing, so all routers running dampening, >had 3/4 of the prefixes on hold. > >Now a good 4 hours after the main-event, I still see MAE routers with a >couple thousand dampened paths. Most of the connectivity is stable now (from >my view), so some of you can clear ip bgp damp and make a few more customers >happy. > >I suppose that the immediate topic will be route filtering vs. >AS_PATH filtering... > >As it should of been a long time ago. > >Raw fish tonight, Avi? > >Best regards, > >Dave Van Allen - You Tools Corporation/FASTNET(tm) >dave(a)fast.net (610)289-1100 http://www.fast.net >FASTNET - PA/NJ/DE Business Internet Solutions >

1 0

Re: routes to hit 50,000 soon? or filter AS 7007....
by Danny McPherson 25 Apr '97

25 Apr '97

> > Agreed. I thought the same thing. Also, oldest servers are usually in > the beginning of the block, since we tend to start from the beginning and > work towards the end (well, perhaps I speak for myself). The servers > around longest are also probably more likely to have more information on > them and be more useful: Take webservers, for example. As time passes, > I've seen more and more activity to our oldest webservers simply because > there are more links on the web, more content (I think it was Einstein who > first figured out time and content are related) and more entries in search > engines. > > And let's not forget our routers, which are usually .1 in the first /24 :) > although you can't filter your entire block from other providers, i'd suggest that you filter the routes that won't be allocated to customers (backbone, internal, etc..) .. else you have even bigger problems when things like this happen. -danny

1 0

Ingress Filtering
by Daniel Senie 25 Apr '97

25 Apr '97

I've been getting bombed for 3 days by someone who's using an RFC 1918 address as a source address and firing ICMP ECHO REPLY packets at a few addresses within our network. I've been trying to get some info on who is doing this, but haven't gotten anywhere yet. Seems a lot of folks are not yet doing any ingress filtering on their lines. This kind of stuff is easy to cure at the source, but a real pain at the target end... Please consider adding ingress filters if you don't already use them! Dan Daniel Senie mailto:dts@openroute.com Sr. Staff Engineer http://www.openroute.com/ OpenROUTE Networks, Inc. (a wholly owned subsidiary of Proteon, Inc.)

1 0

Re: routes to hit 50,000 soon? or filter AS 7007....
by Alex Rubenstein 25 Apr '97

25 Apr '97

out of 47000 routes from Agis, 7327 of them have 7007 in them. I spoke to them and they said that thier router broke.. They won't give us an answer, but when I said I was from Net Access, he said "nac.net?" like he knew me, and they were vague. They also claimed that they had 'turned thier router off', but the routes were still in for almost 25 minutes later. Not only that, it seemed mailcious to me, because the only announced the /24 of our name servers (207.99.0.0/24) and not our whole /17. VERY STRANGE. AND THEY WON'T ANSWER ANY QUESTIONS. [rs.internic.net] FL Internet Exchange (ASN-FLIX) 115 Walnut Avenue Revere, MA 02151-5125 US Autonomous System Name: FLIX Autonomous System Number: 7007 Coordinator: Bono, Vincent J. [1LT] (VB14) vbono(a)MAI.NET 703-734-8602 1-800-918-0524 (FAX) 1-703-506-1436 At 10:49 AM 4/25/97 -0600, Christian Nielsen wrote: > >sorry if someone thinks this is the wrong message for the group, but it does >effect us all... > >we are seeing lots of routes coming in > >sho ip bgp sum >BGP table version is 6699646, main routing table version 6699646 >49793 network entries (94886/99644 paths) using 8897576 bytes of memory >11894 BGP path attribute entries using 1541824 bytes of memory > >but the routes seem to be coming from AS 7007... They are advertising many >routes, even our own. Sorry, but email and phones to them isn't working. > >*> 156.5.0.0 137.39.167.29 50 701 701 701 1239 >1790 7007 ? >* 208.131.13.29 0 5650 6176 1239 1790 >7007 ? >*> 167.32.0.0 137.39.167.29 50 701 701 701 1239 >1790 7007 ? >* 208.131.13.29 50 5650 3561 3561 1239 >1790 7007 ? >*> 192.56.218.0 137.39.167.29 0 701 701 701 3561 >194 3909 1 1239 17 >90 7007 ? >*> 192.72.0.0 137.39.167.29 50 701 701 701 1239 >1790 7007 ? >* 208.131.13.29 50 5650 3561 3561 1239 >1790 7007 ? >*> 192.73.26.0 137.39.167.29 50 701 701 701 1239 >1790 7007 ? >* 208.131.13.29 50 5650 3561 3561 1239 >1790 7007 ? >*> 192.73.28.0 137.39.167.29 50 701 701 701 1239 >1790 7007 ? >* 208.131.13.29 50 5650 3561 3561 1239 >1790 7007 ? >*> 192.76.170.0 137.39.167.29 50 701 701 701 1239 >1790 7007 ? >* 208.131.13.29 0 5650 6176 1239 1790 >7007 ? >* 192.83.0.0 208.131.13.29 0 5650 6176 1239 1790 >7007 ? >*> 137.39.167.29 50 701 701 701 1239 >1790 7007 ? >* 192.83.64.0 208.131.13.29 0 5650 6176 1239 1790 >7007 ? > > > whois 156.5.0.0 >Unilever (NET-UNILEVER2) > Sprint International > > >Christian > >

5 4

Time Frame...
by Joseph C. Lappa 25 Apr '97

25 Apr '97

Hi, When did the BGP announcements from AS7007 start and end? Thanks Joe

2 1