[c-nsp] Change routing if path delay increases ( was Re: Assurared BW to customer)

Mindaugas Kubilius min.forums at gmail.com
Thu Oct 28 13:47:27 EDT 2010


Hello,
Although not identical but I feel like facing a similar problem in nature.

We have two sites connected over two providers SP_A and SP_B. Both can 
take a route which is geographically short (let's name it "short path"). 
SP_A also can take the alternative path which is considerably longer (a 
"long path"). The difference in latency between short and long paths is 
several hundreds milliseconds, so it has an impact.

Such setup is used for redundancy because there is a single points of 
failure in the "short path". We peer via BGP to both (it's a MPLS VPN 
services). In case the short path goes away, we still have a route over 
"long path". We need sometimes to prefer SP_A, and there is a problem. 
If SP_A decides to switch over to long path due to some problems in 
their core, the latency significantly increases BUT at the same time 
short path is still available and can be used via SP_B. BGP does not 
detect that because routes are perfectly valid learned over both 
providers, we do not have increased AS_PATH or whatever.

How to signal such event and direct traffic over SP_B if SP_A routes 
increase in latency while BGP attributes stay the same ? I am thinking 
of OER, but is this the only way to go ?

As usual there might be some clever knob to play with IPSLA+EEM, don't 
have much experience with EEM hence bit cautious will it handle such 
switchovers reliably. Any experiences would be helpful to hear.

Regards,
Mindaugas

On 2010.10.26 08:56, jack daniels wrote:
> Hi guys,
>
> I have a EOSDH as a primary link in which GE is mapped to 4 STM-1
>
> and backup path is another GE Link.
>
> In case 2 STM-1 out of 4 STM-1 in EOSDH fail my routing will not be
> aware of that and will not reroute the traffic to backup GE.
> This will lead to congestion on Primary link , while backup path not
> at all be used.
>   Is there any way to work out this issue.
> _______________________________________________
> 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