Agreed. Andrew
Donald Sharp <sha...@cumulusnetworks.com> 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 <p...@jakma.org<mailto:p...@jakma.org>> 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 p...@jakma.org<mailto:p...@jakma.org> @pjakma Key ID: 64A2FF6A Fortune: Serfs up! -- Spartacus
_______________________________________________ Quagga-dev mailing list Quagga-dev@lists.quagga.net https://lists.quagga.net/mailman/listinfo/quagga-dev
