8 messages in net.nether.puck.cisco-nsp[c-nsp] VRF randomly, stably install ...
FromSent OnAttachments
Everton da Silva MarquesJan 7, 2005 11:26 am 
Oliver Boehmer (oboehmer)Jan 7, 2005 12:33 pm 
Everton da Silva MarquesJan 7, 2005 1:20 pm 
Everton da Silva MarquesJan 7, 2005 1:23 pm 
Oliver Boehmer (oboehmer)Jan 7, 2005 1:37 pm 
Oliver Boehmer (oboehmer)Jan 7, 2005 1:39 pm 
Everton da Silva MarquesJan 7, 2005 3:14 pm 
Oliver Boehmer (oboehmer)Jan 7, 2005 6:06 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[c-nsp] VRF randomly, stably install only one from multiple route setsActions...
From:Everton da Silva Marques (ever@lab.ipaccess.diveo.net.br)
Date:Jan 7, 2005 11:26:13 am
List:net.nether.puck.cisco-nsp

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.

Questions:

1) Is that possible to achieve by properly configuring VRF's statements? If so, how?

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?

3) Can anyone point another way to achieve the same behavior?

Please advise.