[c-nsp] Quick question about redundant connections.

David Coulson david at davidcoulson.net
Fri Aug 10 11:28:29 EDT 2007


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  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>   


More information about the cisco-nsp mailing list