<div dir="ltr">Hello Philippe!<div><br></div><div>Do you see any advantages of netns-base VRF implementation besides that it can work on older kernels?</div><div><br></div><div>Best regards,</div><div>Igor</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 21, 2017 at 4:37 PM, Philippe Guibert <span dir="ltr"><<a href="mailto:philippe.guibert@6wind.com" target="_blank">philippe.guibert@6wind.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
About VRF support of frrouting 2.0, regarding [0], the following is indicated:<br>
- VRF Lite (Linux VRF device support, Zebra and BGP) Instructions ([1])<br>
<br>
This is good information that VRF lite is now supported in frrouting.<br>
However, I would like to draw your attention to the following:<br>
* the VRF feature in frrouting is lost for kernels not supporting [1],<br>
whereas it was working on Quagga.<br>
* it is not possible to rely on kernel netns, whereas in Quagga the<br>
netns solution was used.<br>
An issue has been created for that in [4].<br>
<br>
On behalf of 6WIND, we want to fix those two issues, but would like to<br>
ensure that the proposed solution is aligned, and does not conflict<br>
with frrouting/other roadmap.<br>
<br>
Code investigation in frrouting showed the following :<br>
- The netns support has been moved to a lib/netns libary ( see commit<br>
illustration in [2]). This change made useless the ns support )<br>
- The VRF support has been mapped to vrf kernel feature ( as<br>
illustrated in [3], file lib/vrf.h)<br>
<br>
The most obvious solution is the following.<br>
It consists in configuring at runtime frrouting, so that the frrouting<br>
VRF mecanism will rely either on VRF or on Netns feature.<br>
<br>
The fact is the clients that have a quagga based solution, would like<br>
to benefit for frrouting, without having to change their<br>
configuration. Either because the kernel is not yet up to date, or<br>
because this is not part of their plan to move to vrf kernel<br>
implementation. Like that, the user will be able to choose with a<br>
minimum configuration change to be on VRF mode or on Netns mode.<br>
<br>
Any remarks about the proposal to solve [4] ?<br>
<br>
Best Regards,<br>
<br>
Philippe<br>
<br>
[0] <a href="https://github.com/FRRouting/frr/wiki/Quagga-1.1-%E2%86%92-FRR-2.0" rel="noreferrer" target="_blank">https://github.com/FRRouting/<wbr>frr/wiki/Quagga-1.1-%E2%86%92-<wbr>FRR-2.0</a><br>
[1] <a href="https://www.kernel.org/doc/Documentation/networking/vrf.txt" rel="noreferrer" target="_blank">https://www.kernel.org/doc/<wbr>Documentation/networking/vrf.<wbr>txt</a><br>
[2] <a href="https://github.com/FRRouting/frr/commit/13460c44a2241" rel="noreferrer" target="_blank">https://github.com/FRRouting/<wbr>frr/commit/13460c44a2241</a><br>
[3] <a href="https://github.com/FRRouting/frr/commit/216b18efe144b" rel="noreferrer" target="_blank">https://github.com/FRRouting/<wbr>frr/commit/216b18efe144b</a><br>
[4] <a href="https://github.com/FRRouting/frr/issues/385" rel="noreferrer" target="_blank">https://github.com/FRRouting/<wbr>frr/issues/385</a><br>
<br>
______________________________<wbr>_________________<br>
dev mailing list<br>
<a href="mailto:dev@lists.frrouting.org">dev@lists.frrouting.org</a><br>
<a href="https://lists.frrouting.org/listinfo/dev" rel="noreferrer" target="_blank">https://lists.frrouting.org/<wbr>listinfo/dev</a><br>
</blockquote></div><br></div>