Depends what is meant by 'not routing' - I would imagine there are situations where you can hit the router directly, but not actually route *across* it. That's why I suggested tracking, since it will work across multiple hops.
Or maybe I'm just missing the point. Julio Arruda wrote: > 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/ > _______________________________________________ cisco-nsp mailing list [email protected] https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/
