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

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

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)