July 1997 - Test - lists.nanog.org

MAE-WEST
by Matthew Pearson 11 Jul '97

11 Jul '97

We are still up... for the time being at least.... heh.... I guess the guy wielding the chainsaw missed our power cables! Or was it a Ryder Truck? But 75% of our peers are down...

1 0

RE: Mae-WEST
by Rodney Joffe 11 Jul '97

11 Jul '97

One of the benefits of being in the building is that if they don't answer their phone... we can kick down the door. Our guys are down there now. According to our guys, it is a power problem... but they are getting details... I will post as soon as I know.... Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net > -----Original Message----- > From: Todd R. Stroup [SMTP:tstroup@fibernet.net] > Sent: Friday, July 11, 1997 7:49 AM > To: nanog(a)merit.edu > Subject: Mae-WEST > > > > So did Mae-West fall into the ocean out there or what? Does anybody > know? > > > Todd R. Stroup > Fiber Network Solutions, Inc.

1 0

Re: Network Monitoring Tools
by William B. Norton 11 Jul '97

11 Jul '97

Hi David - Your question is well-timed. I just put up for anonymous FTP the Rover 4.0 code (beta). The previous versions of Internet Rover code has been in use since the NSFNET days and has been downloaded and put in production in many locations around the world. The original idea was to code a simple way to perform tests on network devices and create alerts when the tests failed. Many folks have added tests to the package and contributed them back for incorporation into the software. Current tests include: WWW, Named, SMTP, FTP, TELNET, PING, PORT, etc. Basically, if you can make a subroutine that returns a Pass/Fail, it can be incorporated into the code. These earlier versions of the code has scaled to about a thousand nodes in our NOC. This 4.0 version uses SNMP to externalize the list of alerts that Rover generates to centralized network management station(s) for consolidation into a single aggregate alert screen. This allows one to distribute the monitoring function as appropriate and only pull back the list of what is broken in the area. The cool thing is you can then build your hierarchy of management stations in a lego block approach. Currently the code has only been ported/tested on Solaris and SunOS systems. The real release is going out after some other folks verify that it works in their environment -- let me know your experiences with it... It shouldn't take long to install: edit a couple files and type ./configure;make The beta code and documentation is at: http://www.merit.edu/internet.tools/rover Hope this helps. Bill At 10:04 AM 7/11/97 -0400, David Hares - ADP Autonet wrote: > >I would like to solicit recommendations for network monitoring utilities. >We are attempting to monitor around a thousand nodes (and growing). We're >using SunNet Manager since we're primarily a Sun shop. The problem is >it's taking a full time programmer (me) to keep up with the changes in our >net. It doesn't seem like it ought to take that much effort. The >operations staff is competent and ought to be able to configure a >monitoring utility. Also, SunNet seems to be a cpu hog. At the rate it >uses up cpu, I'll need a giga-SPARC by next year. > >So, the question of the day is what's in use and really works ? I'm not >enamored of cute GUI interfaces, particularly ones that try to draw my >network out before giveing any useful information. Among other problems, >running these over a less than wonderful connection to my hotel room is >painful. Something that scales well into multipe thousands of nodes would >be nice. > >Thanks in advance. > -- >David L. Hares, Senior Staff Programmer >AutoNet Phone: (313) 995-6539 >175 Jackson Plaza FAX : (313) 995-6458 >Ann Arbor, MI 48106 (USA) Email: dhares(a)autonet.net > > > -------------------------------------------------------------- William B. Norton <wbn(a)merit.edu> (313) 764-9430

1 0

It's always fun
by Robert Bowman 11 Jul '97

11 Jul '97

It's always fun when the major West coast IXP goes down--Mae-West MFS. Every peer from our Mae-West NASA AMES router to MFS is down, as well as our MFS router. I'd suppose everyone else is seeing the same thing. And the MFS NOC isn't answering the phone, after being on hold for 15 mins. Anyone know what is going on? Rob Exodus

2 1

Mae-West
by Robert Bowman 11 Jul '97

11 Jul '97

Ticket 94946 is open at MFS. There is 80% down at Mae-West MFS side, according to the woman on the phone. Nobody is down at NASA-AMES, best I can see on our router.. but AMES is isolated from MFS, and our MFS router cannot hit anyone that I know of at Mae-West MFS. A fun Friday in the making. Robert Bowman Exodus Communications Inc. rob(a)exodus.net

1 0

RE: ATM vs. DS3
by Chris A. Icide 11 Jul '97

11 Jul '97

On Wednesday, July 09, 1997 9:34 PM, Josh Beck [SMTP:jbeck@connectnet.com] wrote: > Hello, > I just thought of something. We are in the process of purchasing a > 4 Mb CIR from another backbone. Now, we have the choice of ATM or standard > T3 delivery (over a DS3 either way). Now, if we get ATM, that 4 Mb CIR > turns into: > > [ (53-5)/53 ] * 4 Mb/s = 48/53 * 4 Mb/s = 3.62 Mb/s Emperical data shows that we are currently losing about 20.5% of capacity to IP over ATM overhead on fairly aggregated traffic. This means that *IF* your new connection is being measured as 4Mbps of cell bandwisth, you will only be getting 3.18Mbps. You may want to verify from the company providing this link what exactly are they limiting you to? btw, the extra overhead is lost in things like the last cell of a packet not being full, etc. Chris A. Icide Sr. Engineer Nap.Net, L.L.C.

8 7

Re: weird BGP cisco-ism?
by matthew＠scruz.net 11 Jul '97

11 Jul '97

> add a default-metric under router bgp.. I think the source of the > route in the routing table is changing for some reason and the box is > conveying the metric as MED... > > --ravi Did that. It went from advertising it with an MED of 0 to an MED of 20 and back, to just readvertising it over and over with the fixed default MED I'd set (1). The sad thing is that until flap damping code was added, this sort of bug was masked... but now I have a few dozen customers totally offline. -matthew

2 1

weird BGP cisco-ism?
by matthew＠scruz.net 11 Jul '97

11 Jul '97

I have a Cisco 7505 which is advertising about 50 routes to about 40 peers at mae-west, and a few others. One set of customers has been complaining that their connectivity is going away right at that router, and then coming back. Narrowed the set of customers down to a single CIDR block, at 204.147.224.0/20. So, some of our peers are claiming that the route is flapping... that's weird, we have them all nailed up to static routes... especially the CIDR blocks. So I wrote a tool which you can peer a router with, and it watches the BGP traffic and prints anything it gets, formatted, to standard out. My Cisco is sending fresh advertisements every 10-30 minutes for that route, and not for any other of the routes it has, and it appeared to be all the same, but on careful examination, it appears that each advertisement reflects a change in the MULTI_EXIT_DISC from 0x00000000 to 0x00000014 and then back again in the next advertisement. What the heck am I seeing here? Is someone's flap damping code seeing the repeated advertisements and suppressing me? Is my Cisco going crazy? -matthew kaufman matthew(a)scruz.net

2 1

Re: weird BGP cisco-ism?
by Danny McPherson 11 Jul '97

11 Jul '97

if the primary route becomes unavailable and routing falls over to the "nailed up" route, a bgp update is still sent. (if dampening is enabled) this update is recorded by ebgp peers as a "flap". i'd guess from your message below that when this occurs your router(s) are also changing the med attached to the prefix, which seems normal to me... i'd suggest you have a look at the stability of the interface to which the primary route is attached (?carrier transitions, interface resets, etc...?). you might also consider breaking the primary route (/20) into 2 /21 blocks internally and allowing the longer "nailed up" route to be the permanent source of the /20 advertisement. for example: rather than: ip route 204.147.224.0 255.255.240.0 <interface> !"primary" route ip route 204.147.224.0 255.255.240.0 null0 254 !"nailed up" route ! router bgp <as> network 204.147.224.0 mask 255.255.240 try this: ip route 204.147.224.0 255.255.248.0 <interface> !"primary" route ip route 204.147.232.0 255.255.248.0 <interface> !"primary" route ip route 204.147.224.0 255.255.240.0 null0 <admin. distance> !"nailed up" route ! router bgp <as> network 204.147.224.0 mask 255.255.240 although correcting the stability problem is the correct solution. -danny > > I have a Cisco 7505 which is advertising about 50 routes to about 40 > peers at mae-west, and a few others. One set of customers has been complaining > that their connectivity is going away right at that router, and then coming > back. Narrowed the set of customers down to a single CIDR block, at > 204.147.224.0/20. > > So, some of our peers are claiming that the route is flapping... that's > weird, we have them all nailed up to static routes... especially the CIDR > blocks. So I wrote a tool which you can peer a router with, and it watches > the BGP traffic and prints anything it gets, formatted, to standard out. > > My Cisco is sending fresh advertisements every 10-30 minutes for that route, > and not for any other of the routes it has, and it appeared to be all the same, > but on careful examination, it appears that each advertisement reflects a > change in the MULTI_EXIT_DISC from 0x00000000 to 0x00000014 and then back > again in the next advertisement. > > What the heck am I seeing here? Is someone's flap damping code seeing the > repeated advertisements and suppressing me? Is my Cisco going crazy? > > -matthew kaufman > matthew(a)scruz.net

1 0

Re: weird BGP cisco-ism?
by matthew＠scruz.net 10 Jul '97

10 Jul '97

Original message <199707110721.HAA01250(a)ice.genuity.net> From: Danny McPherson <danny(a)genuity.net> Date: Jul 11, 0:21 Subject: Re: weird BGP cisco-ism? > > > if the primary route becomes unavailable and routing falls over to the "nailed > up" route, a bgp update is still sent. (if dampening is enabled) this update > is recorded by ebgp peers as a "flap". i'd guess from your message below that > when this occurs your router(s) are also changing the med attached to the > prefix, which seems normal to me... WHAT?!? This is ridiculous. There *must* be a way to have routes truly "nailed up" such that flaps do not occur. I have static routes in there precisely because I want to be friendly and reduce the number of routing announcements which occur when interfaces transition (I have dozens and dozens of people with class C networks attached via unreliable dialup lines) > i'd suggest you have a look at the stability of the interface to which the > primary route is attached (?carrier transitions, interface resets, etc...?). > you might also consider breaking the primary route (/20) into 2 /21 blocks > internally and allowing the longer "nailed up" route to be the permanent > source of the /20 advertisement. for example: However, in this case, I don't have *anything* as the "primary route". In fact, the very first /24 of the route is currently unused and goes nowhere... and the rest of the block goes as /24's, /29's and the like to various people who connect and disconnect all the time... just like I have on several other CIDR blocks I've got. But *this* one, and *only* this one, insists on sending a readvertisement. So, to readdress my first paragraph, apparently these static routes as I have them configured do just the trick, since if they didn't, I'd see lots of other things flapping on my BGP monitor software I just wrote, but instead I only see this one. Sounds like a real bug of some sort. -matthew

1 0