[quagga-dev 11749] Re: [PATCH] Multiple VRF support in quagga
alain.ritoux at 6wind.com
Thu Nov 20 15:51:11 GMT 2014
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.
> 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.
More information about the Quagga-dev