Re: [linux-vrf-core] First code release

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

Hello,

I agree with all of your suggestions.  I think we ca trim it down
to 3 big tasks (many details within task ;-).

-each process needs to be assigned to a vrf.  I was hoping to build on the
 "many virtual servers" by ja...@so...
-inter-vrf routing.  The current patch doesn't support this.  I think
 this is going to require a little re-working of the "next hop" code
 in the IP stack.  I already have to change this to support my mpls-linux
 work, so I will make sure linux-vrf benifits from it :-)
-aggregate VRF data structure.  Part of the purpose of this first patch was
 to identify all of the per VRF dependent structures.  I want to make sure
 we have found all of them (this will require digging into netfilter stuff
 a bit more).  Once they are all identified, then I would like to work on
 aggregating them into a common VRF structure.

On Sun, Mar 10, 2002 at 11:55:55PM -0500, Nick Eggleston wrote:
> Thanks Jim,
> 
> Here are my thoughts while reading the patch...
> 
> 1.  Processes need to have a vrf associated with them.  All
> sockets/packets generated by the process should by default be members of
> the vrf.  Special kernel calls (which you already created) should be
> needed to set particular sockets into particular vrfs.
> 
> We could then write a simple "chvrf" that works like chroot, allowing us
> to use "netstat" and suck without recoding them.
> 
> Once an interface is in a particular vrf, I think it (and member
> connections (via netstat)) should not be visible to processes from other
> vrfs.  At least, they shoud not be visible without special comands/perms.
> 
> 2.  Inter-vrf communication.  Once we get vrfs up and running, we need a
> way to selectivel allow traffic to pass between them.  Probably new route
> targets.  (maybe you did this already!)
> 
> 3.  Netfilter implications.  By default, we should probably virtualize the
> netfilter tables on a per-vrf basis, to continue the vision of having vrfs
> be transparent to most programs and systems.  Again, though, we might want
> to add some new code to make specific netfilter rules vrf-aware.
> 
> 
> 4.  Instead of var[vrf] (making fixed-size arrays out of single vars to
> support vrfs), I would strongly suggest moving to a a "struct vrf" model
> and dynamicaly allocating new ones upon vrf-creation.  That way, we
> collect all of the virtualized entities into a single struture.  Vrfs,
> then, would go from being "unsigned char" internally to "struct vrf *"
> 
> 5.  Once (if?) we move to dynamic structs, we could consider identifying
> vrfs by name instead of number.  This would be in keeping with the way
> that cisco defines and uses them.
> 
> Great work!!!
> 
> What do you think?
> 
> --nick
> 
> 
> On Wed, 6 Mar 2002, James R. Leu wrote:
> 
> > On Wed, Mar 06, 2002 at 04:16:43PM -0500, Nick Eggleston wrote:
> > > Jim,
> > >
> > > Could you take a few minutes and type up a note that describes from a
> > > system level the way you have implemented this?  How are you
> > > conceptualizing the kernel mods to support the vrfs?
> >
> > The base change of this implementation is make the fib_table array
> > a double index array.  Prior to this it was only indexed by the table id.
> > I added a vrf id.  So everywhere that create/gets/modifies a table had to
> > have an extra piece of info added to the call.
> >
> > The other change to the 'fib' is that the fib_rules are now index by vrf
> > as well.  fib_rules are the structuire behind maintaining the order in which
> > tables do route lookups.  (ie the local table alway is looked up before the
> > main table, whicb is before the default table).  By allowing VRFs to have
> > rules, policy routing and teh like still work within a VRF (I think
> > NAT will work as well!).
> >
> > The next large change is how the tcp/udp/raw sockets account for used port
> > numbers.  Every where a lookup or a comparison is made I add the vrf to
> > the mix.
> >
> > The other place where VRF show s up, the route cache, route messages,
> > link messages, rules messages, socket hash tables, skbs.
> >
> > This is a very quick overview.  I will try to come up with a better one
> > and add it to the README.  Maybe some of the questions you guys come back
> > with will hlep form this description.
> >
> > Jim
> >
> > > Thanks!
> > >
> > > Nick
> > >
> > > On Wed, 6 Mar 2002, James R. Leu wrote:
> > >
> > > > Hey guys,
> > > >
> > > > I know its been a LONG time since we talked about this, but I have been
> > > > thinking about it, and I've done some work.  I placed my first crack at a
> > > > VRF implementation for the kernel.  Take a look at the README inside it
> > > > then post questions :-)
> > > >
> > > > Jim
> > > >
> > >
> >
> >
> 
> -- 
> Nick Eggleston
> Consultant
> Data Communications Consulting, Inc.
> 6320 Rucker Road, Suite E
> Indianapolis, IN  46220
> 317/726-0295 x18
> 317/202-2445 (fax)
> 
> 
> 

-- 
James R. Leu