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.
I see. Is it even technologically feasible?
I wonder whether Cisco could implement an
IOS option to make iBGP to behave like eBGP
in that respect? Just out of curiosity.
not sure, it sounds dangerous as path selection should be deterministic
within iBGP..
Why do you need this? Maybe there are
alternatives?
I now face a very similar scenario, where PE1
becomes unstable, stops exporting R1, central
VRF-C switches to R2. Then PE1 would flap, its
unstable routes R1 taking over R2. Then again,
PE2 may also become unstable. Fortunately,
both R1 and R2 (almost) never become unstable
at the same time. The definitive fix is to
stabilize those PE routers, and we've been
working on this with Cisco for months, without
an acceptable work-around. The scenario described
in the previous mail could provide an acceptable,
if temporary, stabilization method. Of course,
alternative suggestions are appreciated.
You might want to check the "import" option to ibgp-multipath. This way
we'll import more paths into the VRF and we can fail-over to alternate
paths without waiting for the periodic import-scan.
oli
8 messages in net.nether.puck.cisco-nsp[c-nsp] VRF randomly, stably install ...
