- NANOG - lists.nanog.org

Re: Mae-WEST
by Alex Rubenstein 12 Jul '97

12 Jul '97

According to nitrous.digex.net for its mae-west router: card inlet hotpoint exhaust RSP(4) 26C/78F 38C/100F 44C/111F Seems a little toasty to me. >Ironically, our temperature device is now broken in our Cisco. Has anyone >else had similar problems with them? We now have a number of 7000 series >routers which report off-the-wall readings. > >-Golan > > > --- "Don't go with a spineless ISP; we have more backbone." Alex Rubenstein -- alex(a)nac.net -- KC2BUO -- www.nac.net net @ccess corporation, 201-983-0725 -- 201-983-0725

3 2

Re: Mae-WEST
by Eric Kozowski 12 Jul '97

12 Jul '97

>Or, lets say, an automatic network monitor (ALA SNMP) that tells them >when UPS power is about to run down (before the lights go out) so they >can roll their generator into place. Shades of the massive AT&T failure of a few years ago. Lose external power, go to battery -- batteries run flat, cause nobody is paying attention. -- Eric Kozowski VP Internet Services eric(a)structured.net Structured Network Systems, Inc. (800)390-5945 Support A Verio Affiliate (800)881-0962 Sales/Info http://www.structured.net/ PGP Key fingerprint = 0A E4 91 B8 BD CB 3E 95 42 12 04 4E 14 DF 86 76 'They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.' -- Benjamin Franklin 1759

4 4

Re: weird BGP cisco-ism? [problem resolved]
by Danny McPherson 12 Jul '97

12 Jul '97

> You can build your customer BGP filters off data in the IRR. Make > it a requirement that BGP customers must keep that information up to date > (or do it for them). OK. So I apply an ingress filter (ideally built from the IRRs) to a customer peer. Then I have to add the cusomter's AS(s) prefixes to every eBGP peer's egress ACL (including customer peers) so that the networks will be permitted. The customer begins advertising a newly allocated netblock. Now virtually *every* BGP peers ACL has to be modified & deployed and the source AS will need to either flap the route or reset the session. If I had tagged the customer's prefixes with a BGP community when I picked up the routes ..and have filters in place that deny/permit predefined communities to all eBGP peers, all I would need to be concerned with is the customer's ingress ACL. IMO, ACLs alone won't scale. -danny

2 1

Re: weird BGP cisco-ism? [problem resolved]
by Barry A. Dykes 12 Jul '97

12 Jul '97

Why don't you just tag your exportable routes and let them through, while blocking everything else? You could then build a route-map that places that tag on all of your inbound BGP customers. This would allow you to export everything that they send you (allowing them to send the more specific as Dorian stated) and use a static tag for your aggregate routes. Then all the more specific routes on your backbone would be filtered, unless it originated from a BGP customer - who would need to send the more specific advertisements to each of it's providers and allow routing to work correctly. I know, that's what we do! If you don't have the right tag, you don't get off! And I don't have to mess with any filters after they are set up. Barry > > > >You can remove the specifics at the edges of your network either via community > >based filtering or prefix based filtering. The former is much more flexible > >and is the one I'd recommend. > > > >-dorian > > > > I'd think prefix based filters would be more likely to be correct. > Since you have to explicitly list what you think you should be announcing > you protect against having routes you don't expect in your tables and > against having interactions that cause unexpected routes to get tagged as > announceable. > > -- > > -Chris (cgarner(a)sni.net) >

1 0

Re: weird BGP cisco-ism? [problem resolved]
by Danny McPherson 12 Jul '97

12 Jul '97

> I'd think prefix based filters would be more likely to be correct. > Since you have to explicitly list what you think you should be announcing > you protect against having routes you don't expect in your tables and > against having interactions that cause unexpected routes to get tagged as > announceable. > OK, so then what do you do with BGP customers? Ideally, you'd be filtering the ingress advertisements from your customers. Now you have to add those prefixes to your egress filters as well. Using communities to accomplish this is much more efficient and "hands-off". -danny

2 1

MAE WEST
by Rodney Joffe 12 Jul '97

12 Jul '97

Good News.... Now we know :-) http://www.news.com/News/Item/0%2C4%2C12351%2C00.html?nd Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net

1 0

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

11 Jul '97

Well, that was a week-long disruption in routing that shouldn't have been able to happen. This is an explaination of the problem I described last night... We have a handful of CIDR blocks that we announce, but one of them was getting flap-damped. By writing a tool to monitor the BGP announcements, we discovered that a reannouncement was happening every few minutes, for no apparent cause. What was happening is that, about a week ago, another provider got a request from a customer to route them a single /24 from the middle of our (non-portable) block. Because there was no IGP route for that customer, but a network line was in place, the other provider was, every 5-20 minutes, announcing the route for about 30 seconds, and then withdrawing it. We peer with that provider directly, and can also see them via our transit provider, and we have "summary-only" set in our BGP configuration. Every time the /24 appeared, our router would send *four* repeated announcements of the /20 block... once when it appeared via the direct session, again when it appeared via our transit provider, and then twice more, once for each withdrawl. This then triggered the flap damping code at our peers, causing them to ignore the /20 route altogether. Problem took forever to find because the only way to catch it was to know exactly when the flaps were happening and then, at that very moment, look for any longer prefixes in the table. Any suggestion as to how to prevent my Cisco from saying *anything* when someone else decides to briefly present a more specific route would be appreciated, and yet again, we'd be better off with some sort of authentication as to who can advertise what to whom. -matthew kaufman matthew(a)scruz.net

4 3

Re: weird BGP cisco-ism? [problem resolved]
by Danny McPherson 11 Jul '97

11 Jul '97

> > Try it w/o the summary-only stuff. > > Didn't help at all. > > > > > I don't use summary-only, or aggregate-address, or network XXX at > > all. I redis my connected & static routes into bgp and arrange > > for my global routes to make it beyond my AS. I also use pull up > > static routes to null0 for all of my blocks. > > I redistribute in a similar way, and have the statics to null0 as well. > > Still insisted on flapping at least twice every time it got the brief > hit on the /24 subnet coming from the outside world. > > At this point what needs to happen is for this to be recreated in > a lab somewhere and some config changes tried... I can't blow away > my customers one more time just to play with it. > > Some day we'll have routers that can tell you what they're doing, right? Because you're redistributing the route into BGP, when the "true" route becomes unavailable and the "nailed up" route kicks in, the route will flap. As Ravi mentioned: [snip] To avoid readvertising the same prefix, you might want to check if there is any other dynamic protocol that is installing that prefix in the routing table and removing it (could be a OSPF subnet...) ------- You could do a couple of things. 1.) Stop redistributing the more specifics into BGP and allow the "nailed up" routes to source the "aggregate" BGP advertisements. Something like I mentioned previously should suffice. Besides, there's really no need to inject the more specifics into BGP if you don't plan to advertise them to external peers .. per they're probably already being redistributed into your IGP. 2.) Configure a Loopback interface addressed out of the /20 network on the router which the summary-only statement exists so that a more specific of the network will always be available. I prefer sourcing advertisments via "Null 0" and "network" statments and don't like redistrbuting anything into BGP. -danny

1 0

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

11 Jul '97

Original message <199707112126.RAA11467(a)home.partan.com> From: Andrew Partan <asp(a)partan.com> Date: Jul 11, 17:26 Subject: Re: weird BGP cisco-ism? [problem resolved] > > > provider, and we have "summary-only" set in our BGP configuration. Every > > Try it w/o the summary-only stuff. Didn't help at all. > > I don't use summary-only, or aggregate-address, or network XXX at > all. I redis my connected & static routes into bgp and arrange > for my global routes to make it beyond my AS. I also use pull up > static routes to null0 for all of my blocks. I redistribute in a similar way, and have the statics to null0 as well. Still insisted on flapping at least twice every time it got the brief hit on the /24 subnet coming from the outside world. At this point what needs to happen is for this to be recreated in a lab somewhere and some config changes tried... I can't blow away my customers one more time just to play with it. Some day we'll have routers that can tell you what they're doing, right? -matthew

3 2

Re: Mae-WEST
by Philip Steffora 11 Jul '97

11 Jul '97

I have a cage in the MFS Co-Lo and insisted on having a separate UPS from the main. While I never lost power today, my FDDI did go down. This gets me thinking about the backup generator that is supposed to be online. Why didn't the generator kick-in before the UPS went down? Perhaps the better question is if they have a functioning generator ... Anyone from MFS listening? -ps At 09:15 AM 7/11/97 -0700, you wrote: > > I would guess that power to the colo cages is down. > >Mike.

4 3