[c-nsp] Quick question about redundant connections.

[David Coulson]

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