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 3:14:05 pm
List:net.nether.puck.cisco-nsp

Oliver Boehmer (oboehmer) wrote:

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.

I have found this:

The import keyword allows the network operator to configure the VRF table to accept multiple redundant paths in addition to the best path. This feature should be used when there are multiple paths with identical next hops available to ensure optimal convergence times. A typical application of this configuration option is to configure redundant paths in a network that has multiple route reflectors for redundancy.

Would this work for equal prefixes exported from VRFs hosted at different PEs? I'm afraid here in our case we have mostly different next hops pointing to distinct PEs.

A difficulty ibgp-multipath-import option does not seem to address is the unstable routes R1 temporarily taking over stable routes R2 as the router PE1 oscillates between up and down.