[quagga-dev 11749] Re: [PATCH] Multiple VRF support in quagga

Alain RITOUX alain.ritoux at 6wind.com
Thu Nov 20 15:51:11 GMT 2014

Hi Paul

I'll try to provide answer to the following question:

 > I can see a number of ways of doing this:
 > - 1 zebra, 1 protocol daemon, for all netns's. Call this "1+1" for 
 >   This is the approach the proposed patches take, right?
 > - 1 zebra, multiple protocol daemons, 1 daemon per netns. (Call this 
 > - dedicated set of zebra and protocol daemons for each netns. 
([1+1]:netns, say)
 > My question is, what are the pros and cons of each way, and what is 
the best approach to take?
 > Why is "1+1" the best way forward, over "1+1:netns" or "[1+1]:netns"?

First of all, those solutions are not exclusive. Assuming all is 
implemented, nothing prevent to run one set of zebra+daemons in 
different netns. Each one can be made of one zebra managing several 
VRFs, and having several ospfd daemons attached to it, one or some of 
the ospfd being able to manage several VRFs: this sounds a bit hellish, 
and I wouldn't recommend to go this way! My point is that none of the 
design 1+1 / 1+1:netns / [1+1]:netns  is a dead-end.

Having a lot of VRFs does not imply having a lot of routing and/or 
routing protocols. I mean, we can have one OSPF running for one or just 
a bunch of VRFs, and some static routes in all other VRFs. With that 
kind of usage, having a single zebra allows a much simpler way of 
managing the stuff, and allows to easily have a global view of RIB over 
all VRFs. It also avoids un-necessary daemons for a bunch of static 
routes. In case of small number of VRFs, then a single zebra still 
offers the simplicity of management. And if you want to go to cross-VRF 
based on routes (using inter-netns veth), this single zebra really makes 
it easier to handle.
This is why I think (1+1/1+1:netns) are somehow better than [1+1]:netns 
and it is what the current VRF patch offers.

As for 1+1 vs 1+1:netns, I agree, there could be some load issues with a 
single daemon. If load is not an issue, then a single ospfd makes it 
easier to manage, and removes the burden of many daemons running. Many 
daemons has also a cost ... so it's not all black and white. As for the 
risk of the burden being to heavy for the poor ospf daemon, I remember 
having tweaked the ospfd daemon quite a few years ago, so that it could 
run while injecting 1500 external routes and  having 350 active direct 
neighbors. The patches were not that big and ospfd did not collapse;  
this makes me feel pretty confident about what ospfd can support.
The other good point for 1+1 is that it will provide (inside ospfd) a 
framework for multi-instance; this can be used for running one opsf 
instance per VRF, but it can also be used (it won't be part of the 
proposed patch, but architecturally it should have covered a big part of 
it) to handle several instance of OSPFd inside a single VRF.
Once again these two approaches are not exclusive, and zebra can still 
be extended to support several OSPF daemons.

Best regards,

More information about the Quagga-dev mailing list