Oliver Boehmer (oboehmer) wrote:
R1, R2 and R3 represent the same IPv4
prefix(es), but from different VRFs?
Yes. I forgot to make such note.
That's what I was afraid of, but hoped to find a
way to tell the central VRF-C to import routes
in that specific way.
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 eBGP to behave like iBGP
in that respect? Just out of curiosity.
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.
Thank you, Oliver.
8 messages in net.nether.puck.cisco-nsp[c-nsp] VRF randomly, stably install ...
