Hi, On Mo, 2015-06-08 at 11:35 -0700, Shrijeet Mukherjee wrote: > From: Shrijeet Mukherjee <s...@cumulusnetworks.com> > > This driver borrows heavily from IPvlan and teaming drivers. > > Routing domains (VRF-lite) are created by instantiating a device > and enslaving all routed interfaces that participate in the domain. > As part of the enslavement, all local routes pointing to enslaved > devices are re-pointed to the vrf device, thus forcing outgoing > sockets to bind to the vrf to function. > > Standard FIB rules can then bind the VRF device to tables and regular > fib rule processing is followed. > > Routed traffic through the box, is fwded by using the VRF device as > the IIF and following the IIF rule to a table which is mated with > the VRF. > > Locally originated traffic is directed at the VRF device using > SO_BINDTODEVICE or cmsg headers. This in turn drops the packet into > the xmit function of the vrf driver, which then completes the ip lookup > and output. > > This solution is completely orthogonal to namespaces and allow the L3 > equivalent of vlans to exist allowing the routing space to be > partitioned. > > Example use is > ip link add vrf0 type vrf table 5 > ip link set eth1 master vrf0 > ip link set vrf0 up > > ip rule add iif vrf0 table 5 > ip rule add oif vrf0 table 5 > > TODO: > This changeset is for IPv4 only > Connected route management can be made much better, but is deferred to > user space for now.
One thing that got lost is that we should prohibit user space applications to bind to devices which are vrf interfaces without having CAP_NET_ADMIN capability, so user space programs can be in future restricted to a specific VRF. Bye, Hannes -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
