Re: [linux-vrf-core] VRF for Linux (MPLS IP VPNs)

[Nick E. <ni...@dc...>]

I've been doing more thinking about this.

I think the first thing we should tackle is the UML approach.  It provides
a while virtual router interface, and shoud be fairly easy to set up.  I
am not too familiar with it, so I will definately need help
interconnecting the UMLs for networking with VLANs (and MPLS, for you).

The other design will involve changes to the routing, user/process socket
layers to support VRF separation in the kernel, which is going to take a
while to implement.  I still think it would be useful to implement such a
system, but let's get things working with UML, first.

What do you think?

--Nick

On Thu, 11 Oct 2001, James R. Leu wrote:

> On Wed, Oct 10, 2001 at 09:35:47AM -0500, Nick Eggleston wrote:
> <snip>
> > Please read the attached references.  Here are some very sketchy ideas on
> > potential implemenations approaches for Linux:
> >
> >
> > 1. minimal changes - keep existing rules and tables, use fwmarks to
> > distinguish traffic internally.  This CAN work for non-local traffic,
> > and it is even possible with the OWNER netfilter target to set the
> > fwmark for localally GENERATED traffic.  However, how to handle
> > local reception is not understood.  I particular, how RIP, OSPF, BGP
> > and the user process subsystem need to be modified is incomplete, and
> > these would need to be modified to push their routes into specific tables.
>
> Interesting.  I hadn't thought about using fwmark.  I will look around
> about how that would work.
>
> > How do we fix up local subsystem to mark sockets (so gated, zebra, routed)
> > work right.  What about ping, traceroute, telnet, etc?  /etc/hosts, dns?
>
> I think if we provide a means for a socket to say which VRF it wishes
> to use we cover all of the cases. By default a socket would be in the default
> VRF.  Any application that would need to take advantage of VFRs would have to
> be modified (alternativly by hacking libc to recognize a environment varible
> no application would HAVE to be changed)
>
> > 2. separate, virtual netfilters, rt, rules, with extensions to break out
> > of the virtual spaces for particular routing magic.  Process subsystem
> > would be modified to set it into a default VRF context (a'la chroot).
> > Special mechanisms should be included so VRF-aware processes can change
> > VRF membership for particular sockets.
>
> If I understand correctly you want to make sure that existing rules and
> netwfilters continue to work, but have the notion of which VFR they belong to
> so that a VRF A cannot create a rule which forwards traffic to a table owned
> by VRF B.
>
> > 3. virtual linux "machines".  I know there is a project to virtualize the
> > whole linux system running atop linux (name?).  The issue them would be
> > how to interconnect the routing, how to manage the system as a while, and
> > how to handle PVCs (Frame, ATM) and VLANs.
>
> user-mode-linux.  It works pretty good, I use it for a lot of my MPLS testing.
> They already have a scheme to network between the "UMLs".  This is a very
> interesting point.  We need to have the ability to route traffic between
> VRFs as well.  In particular the "Internet VRF" (the VRF that knows how
> to get the real world (non VPN), needs to be reachbale via other VPNs.  Can
> a rule be created to handle this?
>
> So I think we've agreed (maybe implicitly) on the following:
> -sockets need to be VRF aware
> -interfaces need to be VRF aware
> -exiting functionality should not be limited just becuase a VRF is being used
>
> Jim
>