Hi Derick,
> I previously blogged that a (totally hypothetical) multi-tenant
> network built entirely with PBR or FBF would not pass audit because
> of a lack of separate RIB and separate FIB structures for each tenant
> in the network. Why wouldn't this pass audit? OpenFlow is similar.
Well I would like to observe that there may be an easy way to pass the
audit both in the FBF Junos case as well as OpenFlow.
- For FBF you may easily configure in the shipping boxes multiple VPLS
instances which are as separate as VRFs. Then FBF can be controlled per
instance basis (including even identical filters with different actions).
- For OpenFlow is the same thing. OpenFlow capable switch can support
multiple OpenFlow instances. In fact each such instance can belong to
different administrative domain and can be controlled by quite different
set of Openflow controllers. IMHO it is again no worse then VRF like
separation analogy.
Best,
R.
All:
I actually received quite a few responses off-list to this question.
We have to deal with many different audit/compliance agencies each
with their own guidelines. One of their guidelines is that security
zones should reside on physically separate switches. However, in an
MPLS based on environment they allow for VRF/VSI separation on the
same physical device. The reason is that each instance has its own
RIB and its own FIB structures. At least, this is what I've heard
now from multiple auditors over the last 6 or 7 years while working
for different companies.
I'm questioning this in general because we are looking at OpenFlow.
In particular, the question came up "Are separate structures really
necessary?" What if the FIB lookup was entirely hash-based
(source-port included) and each entry in the hash table had a
mask-structure associated with it (for src/dst mac and IPs?).
I previously blogged that a (totally hypothetical) multi-tenant
network built entirely with PBR or FBF would not pass audit because
of a lack of separate RIB and separate FIB structures for each tenant
in the network. Why wouldn't this pass audit? OpenFlow is similar.
In this potential OpenFlow design there would still be separate VRFs
on the controllers, but ultimately the forwarding would be compiled
into this single hash table structure.
So I'm questioning a basic assumption here: Are separate FIB
structures for each VPN required? What I am hearing is mainly
ASIC/NPU/FPGA design/performance concerns. Robert expressed some
concerns over one VPN potentially impacting other VPNs with something
like route instability or table corruption of some kind.. "crashing"
was the word he used :-).
I did spray a few lists with this question, but they are lists where
the right people generally lurk...
Derick Winkworth CCIE #15672 (RS, SP), JNCIE-M #721
http://packetpushers.net/author/dwinkworth
________________________________ From: Robert
Raszuk<[email protected]> To: Gert Doering<[email protected]> Cc:
Derick Winkworth<[email protected]>;
"[email protected]"<[email protected]>;
"[email protected]"<[email protected]> Sent: Tuesday,
September 27, 2011 3:58 AM Subject: Re: [c-nsp] general question on
VRFs and FIBs...
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/
