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]> 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] @pjakma Key ID: 64A2FF6A > Fortune: > Serfs up! > -- Spartacus >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
