Hi,
(Note: for emails to make it through to quagga-dev you need to subscribe
to it via http://lists.quagga.net - if you don't want to receive list
email, you can set your subscription to not deliver list mail to you).
On Mon, 24 Aug 2015, Baptiste Daroussin wrote:
Add support for FreeBSD distinct kernel FIBs
https://bugzilla.quagga.net/show_bug.cgi?id=839
VRF integration? Should this be integrated with the VRF ID already being
kept somehow?
I think there is a need for 2 differents implementations: The one I
proposed which is make quagga run in a FIB and respect that FIB. The
second would be make quagga handle the fib and in that case yes it would
need a VRF implementation.
For my use case I did only need the first and it was quite easy to implement.
The second would take more time, but I agree in most cases, it would be more
interesting for users than the first.
I can work later on implementing the second once the first is in.
So, one thing I don't quite understand is, if this is appropriate without
VRF support, does that mean FreeBSD is sending /all/ interfaces in
response to the sysctl, regardless of whether they are appropriate for the
FIB the process is running in? If so, isn't that a FreeBSD kernel bug?
A kernel network interface virtualisation solution should /not/ require
any patches or changes to software to run as it did before, surely?
I'm confused why this patch is necessary. If it isn't tying into multi-RIB
support, then it shouldn't need a patch - and if a patch is needed,
perhaps it should be to fix the FreeBSD kernel? Otherwise, it needs to
tie in with the 'front end' VRF state we keep that connects (or will do in
some way) to the user UI.
Can you explain what's going on a bit more? Is it that the setfib utility,
having called 'setfib()' has changed the behaviour of the kernel? So the
kernel is using new multi-FIB semantics with 'zebra'?
Further review comments:
- HAVE_FIB is a bit too generic. HAVE_FREEBSD_FIB?
- You described usage to me before (e.g. that setfib utility), that'd be
good in the commit message.
- The rtread_sysctl.c::route_read change presumably is there to tell the
kernel to restrict the read to the given FIB ID. Why doesn't a similar
approach work for if_sysctl.c::interface_list? It'd be much nicer to
have the sysctl restrict itself to a given FIB ID in constructing the
returned interface list, than to then have to issue an ioctl() as every
message is parsed, or not?
Some comments in the code about how this kernel interface works would be
good on this.
regards,
--
Paul Jakma [email protected] @pjakma Key ID: 64A2FF6A
Fortune:
Q: What's the difference betweeen USL and the Graf Zeppelin?
A: The Graf Zeppelin represented cutting edge technology for its time.
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
