Isn't BFD supposed to help in these "brain-dead" cases ? (IGPs 'dead' timers should also kick-in, but usually BFD would be doing this much faster).
David Coulson wrote: > When the GSR stops routing, I'm guessing it doesn't drop IGP > adjacencies? That's usually what I rely on to figure out if a router is > useless, although maybe it won't help for you in this situation. > > I'd be more concerned as to why the GSR 'stops routing' than trying to > rebuild the network around it. Do you have multiple GSRs, and do they > all misbehave, or is it only a specific router or specific IOS/IOS XR > release? I'm not sure if a second GRP would help, since I'm sure the > active CPU doesn't notice anything bad is happening - It might be > something as simple as FIB table problems on the line cards or > something. Personally, I'd drop any IGP/EGP and then poke at it while > it's in it's non-routing state. Dropping interfaces will probably mess > with the CEF tables (I would think). > > Maybe you could track against something on the other side of the GSR via > icmp echo requests? Again, not sure if you can do something like modify > interface costs, or simply drop adjacencies based on the track state. > > Drew Weaver wrote: >> Hi there, I lurk here quite a bit and have even asked a few >> questions. I'm trying to figure out the best scheme for redundant >> connections on an ISP/provider network which is three tiered. The Internet >> Border, the aggregation layer, and the distribution layer (distribution >> layer is effectively the customer connection point). >> >> I have tried coming up with ways to make the connections from the >> aggregation layer to the Internet Border layer totally redundant. >> >> At the moment we're simply running multiple gig-e connections and using >> routes with hardware tags and the same priority to handle load >> sharing/redundancy. >> >> I suppose I should get to the question portion :D >> >> Anyway, we experienced an issue a few weeks back where one of our GSR12000s >> simply refused to do any IP routing, it was up, it was 'fine' for all >> intents and purposes but it simply wouldn't route traffic, none of the >> interfaces went down, so obviously the aggregation layer switches continued >> to attempt to send traffic 'through' this "dead" router. >> >> I've done a little research and so far the only redundancy methods I have >> seen all tend to rely on the interfaces going down, what if the interface >> doesn't go down? What if, to the switches/routers downstream everything >> "appears" to be working? >> >> Is there a particular scheme for downstream switches to verify that an >> upstream router is actually functioning "properly" on a periodic basis? >> >> Also, when routing 'fails' on a gsr12000 would it help if we had a secondary >> route processor installed in the box? (i.e., would it take over?) >> >> Sorry if this question is elementary, but we're doing a retrofit soon and I >> would like to nail down some different solutions. >> >> Thanks, >> Andrew >> >> >> _______________________________________________ >> cisco-nsp mailing list [email protected] >> https://puck.nether.net/mailman/listinfo/cisco-nsp >> archive at http://puck.nether.net/pipermail/cisco-nsp/ >> > _______________________________________________ > cisco-nsp mailing list [email protected] > https://puck.nether.net/mailman/listinfo/cisco-nsp > archive at http://puck.nether.net/pipermail/cisco-nsp/ _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
