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
