Andrew,
Nice work and a well written design document. I skimmed through the
document and here are a couple of quick comments/questions:
The VRF implementation in this case takes a different approach than
that of 6wind's.
6wind's VRFs are bound to different network namespaces, but in your
case VRFs are bound to different kernel routing table
within the same network namespace (normally the global one). Is that
correct?
Section 7.1.1 describes how to create a new vrf table by using the
command
Router(config)# ip vrf /NAME/
% bind table name /NAME/ with id /ID/.
I don't see ID in the command, was it supposed to be ip vrf NAME ID?
Does the ID refer to a kernel routing tabel id that is already
created outside Quagga, or does the command actually creates a new
kernel routing table?
Thanks again for sharing this,
Jafar
On 5/18/2015 8:40 PM, Andrew Qu wrote:
Hi Jafar, and Martin
We have finished coding to support VRF-lite (user CLIs, static ip route with
vrf support, and
Zebra VRF support).
Enclosed is our design and user CLI etc
We plan to commit them back to quagga.
We didn't change IGP routing to support VRF yet. But we plan to do it as well
But our goal is to have one OSPF instance to support multiple VRF so it can
Scale.
But with this support, if you are going to develop OSPFd to support VRF, it
will
be less work.
Attach our VRF support design spec.
Thanks,
Andrew
-----Original Message-----
From: Jafar Al-Gharaibeh [mailto:[email protected]]
Sent: Monday, May 18, 2015 7:10 AM
To: [email protected]; [email protected]
Subject: [quagga-dev 12336] Re: VRF and Multiple-Instance OSPF
On 5/17/2015 3:04 PM, Nicolas Dichtel wrote:
Le 15/05/2015 01:28, Jafar Al-Gharaibeh a écrit :
Hi Nicolas,
Thank you for the email. I looked at the comments/details in the
attachment of the following email:
https://lists.quagga.net/pipermail/quagga-dev/2014-November/011795.html
Attachment link:
https://lists.quagga.net/pipermail/quagga-dev/attachments/20141105/84
0508c9/attachment.txt
It states that the VRF support is only limited to zebra, and that
all protocols are not VRF-aware yet, but it also hints that VRF-aware
protocols is something that is probably already done at 6WIND and
they are/were planing to contribute new patched with such support
back to Quagga. That email came in October last year and I haven't
seen any new source code with VRF-aware protocols unless I've been
looking in the wrong place. I'm currently interested to get that to
work with OSPF.
Is there a VRF-aware ospfd contributed by 6WIND that I don't know
of?
Yes, but currently, we need to get VRF first since some comments on
the list can require some reworks.
If there is at least a partial implementation I'd be interested
to work on and try to get it to work instead of starting from
scratch.
A better option: help us to get this VRF patch into quagga ;-)
I'm ready to help, what can I do to make this happen?
Is it possible to run multiple OSPF daemons, one for each VRF
defined in zebra and have them all talk to zebra? I know that this
still requires some tweaking to ospfd/zebra code to let them know
which VRF they are talking about at the daemon level - from ospfd at
least.
This solution allows both:
a/ one OSPF daemons for ALL VRFs -> 1 single zebra daemon
b/ many OSPF daemons for a set of VRF (down to 1 VRF per daemon) ->
1 single
zebra daemon
Currently, our plan is to upstream a/, but it remains compatible with b/.
Do you have a timeline on how soon this might happen?
Regards
Jafar
Regards,
Nicolas
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
************* Email Confidentiality Notice ********************
The information contained in this e-mail message (including any
attachments) may be confidential, proprietary, privileged, or otherwise
exempt from disclosure under applicable laws. It is intended to be
conveyed only to the designated recipient(s). Any use, dissemination,
distribution, printing, retaining or copying of this e-mail (including its
attachments) by unintended recipient(s) is strictly prohibited and may
be unlawful. If you are not an intended recipient of this e-mail, or believe
that you have received this e-mail in error, please notify the sender
immediately (by replying to this e-mail), delete any and all copies of
this e-mail (including any attachments) from your system, and do not
disclose the content of this e-mail to any other person. Thank you!
_______________________________________________
Quagga-dev mailing list
[email protected]
https://lists.quagga.net/mailman/listinfo/quagga-dev
