[quagga-dev 13359] Re: VRF device integration in quagga
vipin at cumulusnetworks.com
Wed Oct 21 06:46:31 BST 2015
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
>> 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
> 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;
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
> 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 :)
More information about the Quagga-dev