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/
