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

[Arie Vayner (avayner)]

Mundaugas,

OER, or the new name, PFR, would be a good option for this.

Do you control both sides? It would be easier to control the egress
policy on each side by just setting the local pref of the learned routes
according to your policy, and if it is a simple policy, a few EEM
scripts using IP SLA can also do it...

Arie

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Mindaugas
Kubilius
Sent: Thursday, October 28, 2010 19:47
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Change routing if path delay increases ( was Re:
Assurared BW to customer)

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/
>

_______________________________________________
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/