Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 10 Aug 2005 13:16:11 +0200
From:      Andre Oppermann <andre@freebsd.org>
To:        Jeremie Le Hen <jeremie@le-hen.org>
Cc:        freebsd-net@freebsd.org, Marko Zec <zec@icir.org>
Subject:   Re: Stack virtualization (was: running out of mbufs?)
Message-ID:  <42F9E1FB.3ECF023E@freebsd.org>
References:  <1123040973.95445.TMDA@seddon.ca> <200508091104.06572.zec@icir.org> <42F8A487.67183CA6@freebsd.org> <200508091737.32391.zec@icir.org> <42F8D8ED.11A196FC@freebsd.org> <20050809211537.GX45385@obiwan.tataz.chchile.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Jeremie Le Hen wrote:
> 
> > I haven't fully explored all applications and possible tie-ins with
> > jails, virtual stacks etc. but it looks very interesting.
> >
> > For example I want to have multiple routing tables within the same
> > stack.  These routing tables can be opaque or fall-through and match
> > on the source and destination address (not at the same time though).
> > This way we get ultimate routing flexibility in using FreeBSD as
> > router.  An incoming packet on interface em0 with group priority
> > would first match into routing table X, and if no match fall-through
> > to the default routing table.  Or you could create a source matching
> > routing table Y sending matching packets further to table Z for
> > low priority routing.
> 
> What you are saying clearly reminds me the way Linux does it.
> Basically they have about 256 routing tables available, one of them
> being the default one (254 IIRC).  Once you have filled the those you
> want to use, you can assign a routing table to each packet with what
> they simply call "rules".  The routing criteria are classical, such as
> "from", "to", "tos", "iif" (incoming interface)...
> (See the manpage [1] for more informations, the IPRoute2 framework is
> quite powerful.)
> 
> One of the most powerful criteria it provides is "fwmark" which allows
> to match against a mark stamped on the skbuff (their mbuf) by the
> firewall.  This leads to the ability to route packets based on the
> whole capabilities of the firewall framework (NetFilter in this case) :
> TCP/UDP ports, ICMP types, and so on...

This is mostly the direction I'll go.  However any packet classification
other than on IP addresses is to be done by a packet filter (ipfw, pf,
ipfilter).

> This might appear a little bit hackish to networking guys, especially
> those ones that are working on backbone routers, but this flexibility
> is almost nothing to add (pf already has the ability to tag packets,
> IIRC) and it doesn't constrain the design at all, IMHO.  FYI, this has
> already been discussed in this subthread [2].

The biggest problem for more complex IP routing setups is wrapping ones
head around the endless possibilities.  The very concept of longest-
prefix match on a hop by hop basis is difficult to graps for too many
people unfortunatly.  I have things in (very large) enterprise environments
you wouldn't believe...

-- 
Andre


> I have to say that I was quite impressed by Linux networking
> capabilities (this was in the 2.4 days), and that's why I would really
> like to see FreeBSD to be able to do this.
> 
> > It's hard to describe this textually to its full extent.  That's why
> > my upcoming paper will have mostly graphics depicting the packet flow
> > and the processing options.
> 
> I'm in haste to read your paper.
> 
> [1] http://www.manpage.org/cgi-bin/man/man2html?8+ip
> [2] http://lists.freebsd.org/pipermail/freebsd-net/2005-June/007743.html
> 
> Regards,
> --
> Jeremie Le Hen
> < jeremie at le-hen dot org >< ttz at chchile dot org >



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42F9E1FB.3ECF023E>