Hi Jafar and Andrew, I think that both development are complementary. The point that bother me is to call this 'vrf-lite', it seems to be more policy based routing. As you said, we can easily imagine a scenario with netns + multiple routing table. Calling it vrf will confuse the user. With only multiple tables, you cannot assign the same address multiple times for example. VRF is usally more complete. On netdev mailing list (linux networking kernel), several people already report that, with multiple table, some corner case cannot be solved when they tried to implement VRF.
Note also that there are develomement in the linux kernel to ease VRF usage and scalability. For example, Eric Biederman has recently post a patch to lighten the size of a netns. I've also post some patches to be able to assign an id to peer netns and ease netlink management. Regards, Nicolas Le 19/05/2015 19:48, Andrew Qu a écrit :
Hi Jafar, We noticed 6wind’s VRF implementation, but from networking perspective, namespace approach Is more like virtual-router approach rather than vrf-lite, it is too heavy and does not scale to say 4000 VRF or more in a data center switch. Logically it should be more like this: a physical switch/router may have multiple-virtual router/switch (which is by namespace), then within each namespace, there are still needs of VRF within each Namespace. With our approach, user now has choice to use namespace to create virtual router/switch as Independent administrative domain, and then within each namespace (administrative domain) you can then support VRF within that domain. As far ID part question, it is more to co-work with Linux the way VRF is implementing. Linux have name-id pair, hence if user using our created CLI to create a VRF, internally We will allocate a unique ID which will be taken by Linux kernel to create VRF table. You don’t need to “input” ID, but you will see what ID is bind to the name using “show” cli. Thanks, Andrew From: Jafar Al-Gharaibeh [mailto:[email protected]] Sent: Tuesday, May 19, 2015 7:26 AM To: Andrew Qu; [email protected] Cc: [email protected] Subject: Re: [quagga-dev 12336] Re: VRF and Multiple-Instance OSPF 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
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
