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

[James R. L. <jl...@mi...>]

On Thu, Oct 25, 2001 at 08:51:44AM -0500, Nick Eggleston wrote:
> 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).

This might be a good idea to work on so we can understand how a "virtual"
should work.  But for a long term solution it might not be a good idea
because the network performance on a UML is not the greatest.

I use UML quite extensivly to provide a test best for my MPLS work.  I start
3 UMLs up, network them together, then run my MPLS regression test on them.

> 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.

As far as the changing the routing/socket/process idea goes.  THis can be
broken into four parts:

-transit processing
-locally terminating traffic
-locally originating traffic
-populating VRF tables/rules

Transit processing it turns out will be pretty simple.  Right now all IP
routing goes through fib_lookup.  fib_lookup looks in it's rules list.
There exists default rules which say look in the default routing table
and if it's not there drop it on the floor.  Other rules that would show
up in the ruls list would be NAT, policy routing, etc.  If we create an 
array or rules lists, indexed by the VRF number.  Then each route lookup
just needs to know which VRF (or rules list) it needs to look in.
For transit processing the VRF number is stored on the interface
on which the packet arrived.  I may be over simplifing this a bit,
but it looks promising. (this requires an IOCTL to assign a VRF number
to an interface)

Locally originating traffic will be very similar as above, execpt the VRF
number will come from the socket the packet was generated on.
(this requires an IOCTL to assign a socket to an interface)

Locally terminating traffic might be a bit more work.  When a scoket is assigned
to a VRF it needs to be added to a list of sockets associated with the VRF.
When ip_local_route runs it needs to look in the VRFs list of sockets.
I'm not sure how to make this work yet.

Populating VRF table rules will require extending the 'ip' utility
and/or the ifconfig/route utilities.  The kernel side will just grab the
appropriate table/rules before doing any actions.

> What do you think?

I think the UML idea is a good sand box to figure out how this really should
work.  Ideally the results of this project should be that a single linux
box will behave like multiple linux boxes (from the routing and forwarding
standpoint).

Jim

> --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
> >
> 
> 
> _______________________________________________
> linux-vrf-core mailing list
> lin...@li...
> https://lists.sourceforge.net/lists/listinfo/linux-vrf-core

-- 
James R. Leu