[quagga-dev 13359] Re: VRF device integration in quagga

Vipin Kumar vipin at cumulusnetworks.com
Wed Oct 21 06:46:31 BST 2015

Hi Paul,

Firstly, thanks for starting the much needed conversation about how we 
make these talked/submitted (partial) models consumable (referring to 
the other thread). And also appreciate your effort to align future 
development so one doesn't conflict with the other.

Lot of great insights have already been given about whats more scalable, 
provides better fault-isolation, utilizes modern CPU architectures 
better. And during the last round of discussions on this topic months 
ago, many folks agreed that for scaling high number of VRFs, we may even 
need a mix approach that supports multiple of 
multiple-instances-per-daemon, referred to as [n + n] at that time.

As for this thread on VRF device integration using 
Mutliple-instances-per-daemon approach, we strongly believe that this is 
a step towards a complete and consumable VRF support, here are some more 

Already (merged) in quagga master:

     - Single zebra daemon VRF lib patch based on vrf-id config for 
static routes, show ip route, redistribution etc.
        (currently netns as the OS construct for needed separation)

     - Single BGP daemon has multi-instance support

     - OSPF code has 'struct ospf' top level instance containers but 
multiple of those are not supported yet.

Given that, finishing MI-per-daemon and use that for VRFs seems to be a 
realistic goal in near future.
Moreover, this will work with the current quagga configuration model and 
without changes in watchquagga.

Few responses inline..

On 10/20/15 5:09 AM, Paul Jakma wrote:
> On Mon, 19 Oct 2015, Vipin Kumar wrote:
>> We see this model better aligned to support traditional VRF semantics 
>> and modern VRF requirements for the following reasons:
>>        Management of VRFs/entities within a VRF is easier from a single
>> module on system.
>>        Resource usage wise, it can be argued that netns model is
>> relatively heavier.
>>        For route-leaking or any other feature (like BGP/MPLS based 
>> L3VPN)
>> that requires a component to work with multiple VRFs.
>> With that, to integrate with VRF devices, we would like to build upon 
>> the quagga community accepted VRF lib in zebra. We believe the 
>> implementation should be able to co-exist with the netns support 
>> (which currently gets triggered based on the 'vrf <vrf-id> netns 
>> <path>').
> The details of how it gets triggered are open to change at this point. 
> Including whether it lives in zebra or somewhere else.
Ack. We will keep an eye on the related development.

> You're going to have figure out how to make your proposal co-exist 
> with the other ways though (the semi-functional 'vrf...' commands in 
> there now, though see above; the ability to run daemons in namespaces; 
> etc).
Yes. One way to look at the proposed model/config is that if no 
configuration is present that MI-per-daemon, then daemons run with the 
default instances, and any *other ways* should be able to do what they 
intended to do.

>> We hope this approach is acceptable to quagga-dev, and useful to 
>> quagga-users.
> I'd suggest a design document, showing how everything will work in 
> terms of the UI, internal protocols, and architecture, to avoid 
> problems down the road.
> Big changes /can/ be easy to integrate, *if* contributors come to the 
> community first with design proposals, work out the details, and get 
> consensus. As you seem to be trying to do - bravo. :)
Will try our best. Thanks for the encouragement :)


> regards,

More information about the Quagga-dev mailing list