Agreed. Andrew
Donald Sharp <[email protected]> wrote: I think that a single daemon approach is the way to go. Code churn, memory pressure, more complicated startup/stop scenarios, and lots of work that can be done to improve daemon performance don't lead me to believe that I think it is a good idea at this time. donald On Fri, May 29, 2015 at 3:55 AM, Paul Jakma <[email protected]<mailto:[email protected]>> wrote: One of the key questions for me is whether the two approaches can live together. I have scripts semi-hacked together to run Quagga daemons in different VRFs^Wnamespaces - I use a number as the namespace name, so it's like a VRF id. The script configures namespaces and launches daemons with a ZServ path-name with the VRF ID in the path. You can then 'telnet $DAEMON $(($DAEMON_BASE+$VRF*10))' or somesuch to access the ui. I havn't gotten setting of inter-networking between the VRFs nicely scripted yet. At some point that really should become a proper VRF management daemon. That seems a sensible way forward for the daemon-set-per-VRF approach. (The mass of telnet UIs is not brilliant, vtysh doesn't do multi-instance. We should consider fixing that - I'm sure this has come up a few times over many years now, no one has been willing to grasp the nettle). Will this co-exist together with the single-set approach? If people run set-per-VRF, then they're going to have VRF related commands within the inside-VRF instances as things stand. Bit confusing UI wise. The zebra in the netns would say it supported VRFs in the netns (I think Linux namespaces are nestable that way, I thnk - but not sure we should do that for Quagga's VRF abstraction). I'm just very unclear on the big picture. How do we fit everything together in a way that doesn't end up a mess for the user? regards, -- Paul Jakma [email protected]<mailto:[email protected]> @pjakma Key ID: 64A2FF6A Fortune: Serfs up! -- Spartacus
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
