<html>
<head>
<meta http-equiv="Content-Type" content="text/html"/>
</head>
<body>
<div style="color: black;">
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;"></p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;">Le 21
avril 2017 9:35:38 PM Igor Ryzhov <iryzhov@nfware.com> a écrit :</p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;">>
Hello Philippe!<br>
><br>
> Do you see any advantages of netns-base VRF implementation besides
that it<br>
> can work on older kernels?</p>
<p style="margin: 0 0 1em 0; color: black;"></p>
<p style="margin: 0 0 1em 0; color: black;">There are some legacy systems
which are deployed with netns based VRF. </p>
<p style="margin: 0 0 1em 0; color: black; font-family: sans-serif;"><br>
><br>
> Best regards,<br>
> Igor<br>
><br>
> On Fri, Apr 21, 2017 at 4:37 PM, Philippe Guibert <<br>
> philippe.guibert@6wind.com> wrote:<br>
><br>
>> Hi all,<br>
>><br>
>> About VRF support of frrouting 2.0, regarding [0], the following
is<br>
>> 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">https://github.com/FRRouting/frr/wiki/Quagga-1.1-%E2%86%92-FRR-2.0</a><br>
>> [1] <a
href="https://www.kernel.org/doc/Documentation/networking/vrf.txt">https://www.kernel.org/doc/Documentation/networking/vrf.txt</a><br>
>> [2] <a
href="https://github.com/FRRouting/frr/commit/13460c44a2241">https://github.com/FRRouting/frr/commit/13460c44a2241</a><br>
>> [3] <a
href="https://github.com/FRRouting/frr/commit/216b18efe144b">https://github.com/FRRouting/frr/commit/216b18efe144b</a><br>
>> [4] <a
href="https://github.com/FRRouting/frr/issues/385">https://github.com/FRRouting/frr/issues/385</a><br>
>><br>
>> _______________________________________________<br>
>> dev mailing list<br>
>> dev@lists.frrouting.org<br>
>> <a
href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a><br>
>><br>
><br>
><br>
><br>
> ----------<br>
> _______________________________________________<br>
> dev mailing list<br>
> dev@lists.frrouting.org<br>
> <a
href="https://lists.frrouting.org/listinfo/dev">https://lists.frrouting.org/listinfo/dev</a><br>
</p>
</div>
</body>
</html>