[c-nsp] general question on VRFs and FIBs...

Tue Sep 27 08:00:07 EDT 2011

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<robert at raszuk.net> To: Gert Doering<gert at greenie.muc.de> Cc:
> Derick Winkworth<dwinkworth at att.net>;
> "juniper-nsp at puck.nether.net"<juniper-nsp at puck.nether.net>;
> "cisco-nsp at puck.nether.net"<cisco-nsp at puck.nether.net> 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  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp archive at
>> http://puck.nether.net/pipermail/cisco-nsp/