Hi Donald, Agreed. I just didn't want to bring Cisco name specific here by saying logical router instead.
As for the kernel change, let's discuss this in netdev shred, we'd like to work with netdev to get the change done Thanks Andrew Donald Sharp <[email protected]> wrote: Network namespaces align closely with Cisco's VDC concept and are orthogonal to some extent to an actual VRF implementation from my perspective. As pointed out elsewhere namespaces are heavy weight and having a large number of namespaces would present serious performance problems. I think that namespaces could( and should ) co-exist with VRF's. By definition (in RFC 4364), VRFs refer to multiple routing and forwarding tables with the ability to associate interfaces (attachment circuits) to a VRF and the ability to have overlapping address spaces. This can be implemented in Linux by leveraging the existing support for multiple routing tables, but some kernel enhancements are needed to facilitate overlapping IP addresses in different VRFs. Thanks! donald On Thu, May 21, 2015 at 1:32 AM, Nicolas Dichtel <[email protected]<mailto:[email protected]>> wrote: Le 20/05/2015 20:20, Andrew Qu a écrit : [snip] The way network namespace is configured and used is as I said earlier more like Virtual router or virtual switch that virtualizing a physical box into multiple Logical real network device, for example: OSPF/ISIS in NamespaceA and OSPF/ISIS in NamespaceB relationthip is network adjacency, A link in namespaceA and a link in namespaceB can be connected and form OSPF/ISIS Network adjacency. As you can't not call two different routers (even they have separate routing table) as VRF, Same way, you can't call namespace approach as VRF. They are just different routers. The routing table managed by namespace is more like routing table managed by physically Different routers, we can't call this as VRF. At least not the VRF term that has Been used by network operators. VRF approach is within ONE logical router/switch that via multiple routing instances or single instance To build multiple routing table which can fall back to one global routing table if Use configured. I had some discussions around this topic. A patch that allows to have a route in a netns that points to another netns make sense and will probably be accepted on netdev. I really think that the way to go for VRF is netns. And I agree that some improvements are still needed in the linux network stack for that purpose, but netdev community now agrees with the big picture, thus it's just a matter of writing the patches ;-) Namespaces are very flexible. You can build your virtual machine by using user namespaces. Then have a set of embbeded netns into this virtual machine for the VRF. And in each netns/VRF, you can do policy based routing. With this design, you can handle most of the scenarii without weird limitations. Regards, Nicolas _______________________________________________ Quagga-dev mailing list [email protected]<mailto:[email protected]> https://lists.quagga.net/mailman/listinfo/quagga-dev
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
