Desired scenario:
Remote VRF-1 exports routes R1.
Remote VRF-2 exports routes R2.
Remote VRF-3 exports routes R3.
Central VRF-C imports only one from (R1, R2, R3),
without any preference. Once C selects Ri, it
stably sticks with Ri as long as Ri remains available.
Only if Ri becomes unavaiable, C would switch
to another Rj available and distinct from Ri;
afterwards, if Ri availability is ever restored,
C still stably keeps Rj as long as Rj remains available.
R1, R2 and R3 represent the same IPv4 prefix(es), but from different
VRFs?
Questions:
1) Is that possible to achieve by properly
configuring VRF's statements? If so, how?
Possibly not. VRF-C PE will compare all paths using the standard BGP
decision algorithm (http://www.cisco.com/warp/public/459/25.shtml) and
will import the best path into the VRF.
2) Would disabling "multipath ibgp" on the
VRF-C's PE, so that only the oldest active Ri
get installed on VRF-C's local forwarding table,
provide the behavior described above?
I don't think so. For eBGP paths, we don't compare the router-id and
stick with the "oldest" path. But for iBGP we can't do this and perform
a deterministic decision which will, given all other attributes like
localpref, as-path, igp-metric/etc. being equal, compare the router-id.
3) Can anyone point another way to achieve
the same behavior?
Why do you need this? Maybe there are alternatives?
oli
8 messages in net.nether.puck.cisco-nsp[c-nsp] VRF randomly, stably install ...
