- Test - lists.nanog.org

Re: OSPF Vs EIGRP
by Shaun S. Amini 08 Oct '97

08 Oct '97

Majority of Networks are running OSPF and a few larger ones like UUNET are running ISIS. For the most part, you will never need run ISIS. My recommendation would be to implement OSPF, it has a lot more knobs for tuning. If you are careful, you can even run OSPF and EIGRP together during the migration period and migrate one site at a time without any down time. At 04:50 PM 10/8/97 -0500, you wrote: >Dave do you know of any Global Corporations that are using EIGRP ? >IF so, what do they do when a major merger takes place and the corporation aquires a large amount of non Cisco routers throughout their newely aquired global network ? I have also been trying to locate a case study of the percentage of global IP networks currently using OSPF Vs EIGRP and any recent trends towards one or the other ? > With Regards, Shaun S. Amini samini(a)diginetusa.net www.diginetusa.net

1 0

OSPF Vs EIGRP
by Patrick O'Keefe 08 Oct '97

08 Oct '97

Dave do you know of any Global Corporations that are using EIGRP ? IF so, what do they do when a major merger takes place and the corporation aquires a large amount of non Cisco routers throughout their newely aquired global network ? I have also been trying to locate a case study of the percentage of global IP networks currently using OSPF Vs EIGRP and any recent trends towards one or the other ?

2 1

Re: UUNet Routing SNAFU
by Selina F. Priestley 08 Oct '97

08 Oct '97

> In message <v03110710b06160330f78(a)[209.104.193.33]>, Michael Dillon writes: > > > > Isn't this the kind of problems that the Doran filters are supposed to prevent? > > Proper PRDB based filters would have stemmed this too. Why isn't everyone > using them these days? > > -- > Harald Maybe you're thinking RADB, which is based on the distributed Internet Routing Registry, defined by the RIPE folks. Yes, if people define their routes, ASs, and routing preferences in the RADB (or a personal database which they create for their own ISP and make public), then other ISPs can use that information to generate prefix-based configs. The RADB is the database used in the US by providers who do not wish to maintain their own database. CAnet, MCI, and ANS have their own databases. The RIPE database is in use overseas. The PRDB is a years defunct database used by the NSFnet project to configure their routers. Selina P.S. Here's the blurb returned by 'whois -h whois.ra.net' when bogus info is requested: For an overview of the RADB and more information about creating and submitting Route objects, see: http://www.ra.net/RADB.tools.docs/.docs.html ftp://ftp.ra.net/routing.arbiter/radb/OVERVIEW ftp://ftp.ra.net/routing.arbiter/radb/doc/how_to_register ftp://ftp.ra.net/routing.arbiter/radb/doc/updating_maintainers You can obtain the full database files via anonymous ftp: ftp.ra.net:/routing.arbiter/radb/dbase URL: ftp://ftp.ra.net/routing.arbiter/radb/dbase/radb.db.gz

2 1

Re: UUNet Routing SNAFU
by Sean M. Doran 08 Oct '97

08 Oct '97

"Alec H. Peterson" <ahp(a)hilander.com> writes: > It might be a good idea for providers to put up web pages on their > policy for accepting external announcements, for reference purposes. At the same time you should augment your current filtering policies with a list of prices for punching holes through them. Sean.

1 0

multihome w/o BGP4
by Richard Welty 08 Oct '97

08 Oct '97

i recall that some months back, there was discussion of some software which would permit support of multihomed customers without BGP4. cann anyone give me a pointer to some information? thanks, richard welty -- Richard Welty welty(a)inet-solutions.net http://www.inet-solutions.net/~welty/ 888-311-INET

2 1

Denial of service attacks apparently from UUNET Netblocks
by Karl Denninger 08 Oct '97

08 Oct '97

Ladies and Gentlemen, This evening, at 11:45 PM CDT, a serious and severe denial of service attack was launched against MCSNet. This was a very well-coordinated effort which crippled us for over an hour. The individuals involved sourced traffic from 207.76.*.* towards *unicast* addresses within our network and to bogus addresses also in the same netblocks. The machines implicated individually as sources, so far, all appear to be MAX TNTs within UUNET's core. Examples are 207.76.40.175 and 207.76.57.161/164. Each of the source addresses hit several machines with essentially-identical packet and byte counts over a sustained period. The attack came from several different core blocks in 207.76, and was received on *both* of our primary DS-3 feeds, burying the core network segments inside our Chicago offices and rendering the network essentially unusable. We have taken measures to both capture repeat attempts and filter selected source locations in an attempt to prevent a reoccurance. We *did* get a good trace on the tail end of the attack; it clearly delineated the source of the data. Due to the highly-concentrated nature of this attack, its unicast destinations, the fact that we refuse source-routed traffic and further refuse directed broadcasts, I am at this point assuming that the source addresses which we saw are genuine. This might indicate that either someone inside UUNET was responsible, or that someone has penetrated UUNET's internal security and compromised the source devices. As TNTs are typically connected to very-high-speed egress pathways, they would be quite capable of sourcing the data flows we saw this evening. Again, this was *NOT* a smurf attack; it neither fit the profile nor would it have had the pattern of source and destination addresses which we captured. We are treating this as a criminal matter and referring it to the federal authorities in the morning. At this point our network status is nominal. Other operators may wish to be on the lookout for similar types of attacks, and extreme packet rates which are sourced from these address blocks. We have taken preventive measures against a repeat performance; this may inconvenience some legitimate users, but frankly, until we can figure out what's going on and UUNET decides to get on the phone with us relating to this incident we're going to act conservatively to preserve our operational status. Again, we're not casting aspersions on UUNET directly in this matter, other than the documented fact that the source addresses of the packets were all within the above listed netblock. However, it is worthy of note that of the various carriers we contacted during this incident, NONE were able to be reached with someone who knew what they were doing for over an *HOUR*. Folks, this is unacceptable. Our customers were in touch with me inside of 10 minutes into this thing, and I find it incredible that none of the other national providers involved think this kind of incident is important enough to have people on-call and available during off-hours to cover this. If someone of these people HAD been available, we might have caught the perpetrator(s) in the act. -- -- Karl Denninger (karl(a)MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/~karl | T1's from $600 monthly to FULL DS-3 Service | NEW! K56Flex modem support is now available Voice: [+1 312 803-MCS1 x219]| 56kbps DIGITAL ISDN DOV on analog lines! Fax: [+1 312 803-4929] | 2 FULL DS-3 Internet links; 400Mbps B/W Internal

22 39

Re: Denial of service attacks apparently from UUNET Netblocks
by Barney Wolff 08 Oct '97

08 Oct '97

> Date: Tue, 7 Oct 1997 12:04:27 -0400 (EDT) > From: Alex Przekupowski <oop(a)idt.net> > > On the MAX's that I have set up, I log that info to syslog (Local 7), and > can pull it up at will. If you need a hand, just let me know. By > combining the syslog output, and the RADIUS accounting logs, we can > definately prove at least the home address of the attacker. How are you providing source address assurance, on either a MAX or a TNT? My understanding, which may well be flawed, is that the only way is with a filter. I have heard claims, which may also be flawed, that filters have a severe performance impact on MAX and TNT. Without source address assurance, how do you know that the packets are actually coming from the user who was assigned that address at that time? Barney Wolff <barney(a)databus.com>

2 1

Re: 73K prefixes?
by John A. Tamplin 08 Oct '97

08 Oct '97

Well, at least we know our routers can handle an additional 30k prefixes out of this :). John Tamplin Traveller Information Services jat(a)Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801

2 1

Re: Denial of service attacks apparently from UUNET Netblocks
by Sean Donelan 08 Oct '97

08 Oct '97

>Security teams at ISPs should also obtain contact information for >their local and federal law enforcement offices. Such contacts >should be tested regularly, (eg; monthly) to ensure they are >accurate. You can also ask Law Enforcement to provide you with >a briefing on the types of computer investigations they are >working on and seeing, which may help you plan your method of attack or >compensation, or help you justify your continued existance with your >upper management. Since most of the top government computer & network security people are in Baltimore, MD this week, you might try again next week :-) Anyone want to have a BOF at the NSA/NIST conference for ISP security personnel? Once again, federal law enforcement made a public plea for companies and individuals to report attacks. Although they also said they may not be able to do anything due to lack of resources, they made the point they can't justify adding resources if no one reports crimes. Unfortunately law enforcement computer crime jurisdiction is still a hodge-podge of overlapping agencies. In the end you may be better off hiring a retired federal law enforcement person for your security department. Even if they know nothing about computers, they can talk the talk to get action out of the various law enforcement agencies. Robert Steele calls it "hacking the buearacracy." >Also, MCI has released a Denial Of Service "tracking" program >called DoStracker that helps to automate detection and tracing of >these types of attacks through large backbone networks. Nice program, thank you. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

4 3

Re: UUnet routes from hell..
by brett watson 08 Oct '97

08 Oct '97

> > Uhm, yeah. It seems they decided that they wanted 128.0.0.0/9 or so, and > decided that the easiest way to get it is announce it all as /24's. Spiffy. > > At least it was fixed relatively quickly. the question remains, was this a bug in some version of their code? or could someone have actually mis-configured something this drastically? -brett

1 0