Hi Gert,
> "address first, VRF second".
Well no one sane would do that ;) I believe what Derick was asking was
why not have "incoming_interface/table_id -> prefix" lookup.
And while in software each VRF has separate RIB and FIB data structures
for reasons already discussed on L3VPN IETF mailing list in actual
hardware on a given line card however this may no longer be the case.
Also side note that most vendors still did not implement per
interface/per vrf MPLS labels (even in control plane) so all labels are
looked up in a global table with just additional essentially control
plane driven twicks to protect from malicious attacks in the case of
CSC/Inter-AS.
Cheers,
R.
Hi,
On Mon, Sep 26, 2011 at 01:18:05PM -0700, Derick Winkworth wrote:
I'm trying to find an archived discussion or presentation discussing
why exactly the industry generally settled on having a separate
FIB table for each VRF vs having one FIB table with a column that
identifies the VRF instance? I'm not finding it, but I'm guessing
its because of performance issues?
Lookup would fail for overlapping address space if you lookup
"address first, VRF second".
How do you find the right entry if you have
10.0.0.0/8 vrf red
10.0.0.0/16 vrf green
10.0.1.0/24 vrf blue
and try to look up 10.0.0.1 in vrf red? You'll find the /24 entry, which
is tagged "vrf blue".
Alternatively, you'd need to explode the /8 entry for vrf red if *another*
VRF adds a more specific for that /8.
gert
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
_______________________________________________
cisco-nsp mailing list [email protected]
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/
