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