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]> 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] > https://lists.quagga.net/mailman/listinfo/quagga-dev >
_______________________________________________ Quagga-dev mailing list [email protected] https://lists.quagga.net/mailman/listinfo/quagga-dev
