Date: Tue, 2 Mar 2004 11:26:25 +0300 From: Gleb Smirnoff <glebius@cell.sick.ru> To: Wes Peters <wes@softweyr.com>, Andre Oppermann <andre@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: My planned work on networking stack Message-ID: <20040302082625.GE22985@cell.sick.ru> In-Reply-To: <20040302042957.GH3841@saboteur.dek.spc.org> References: <4043B6BA.B847F081@freebsd.org> <200403011507.52238.wes@softweyr.com> <20040302031625.GA4061@scylla.towardex.com> <20040302042957.GH3841@saboteur.dek.spc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear sirs,
On Tue, Mar 02, 2004 at 04:29:57AM +0000, Bruce M Simpson wrote:
B> > > > add multi-path and policy-routing options. (planned)
B> >
B> > would the policy-routing optioned table sort of similar to VRF's or
B> > different routing instances that could potentially be tied to userlands
B> > like Quagga?
B>
B> That's the plan, I believe, anyway... It would be nice if Quagga could be
B> taught about how to add TCP-MD5 keys to both FreeBSD and OpenBSD SADBs.
Is there any plans about integration of BGP routing daemon (Zebra or Quagga)
into FreeBSD? With BGP routing daemon onboard, FreeBSD will be a strong
alternative against expensive commercial routers. I have successfull experience
of running FreeBSD STABLE with 2 full BGP views for half a year. Modern i386 PC
can route/filter/shape much more traffic than expensive Cisco 36xx. I haven't
yet compared with 7000 series...
Currently I'm working on my Netflow implementation, and I have faced the
following problem: I've already got global routing in my routing table, but it
lacks AS (Autonomous System) information. The routing daemon (zebra in my case)
already knows ASes, but this informations is lost when routing information is
injected into kernel. It'll be nice to add AS path to struct rtentry.
Seems like there is no problem with extending struct rtentry, but injecting
this info from userland requires changes to routing API. I see two ways of
implementing it:
1) Simply add new field into struct rt_msghdr, and bump RTM_VERSION. I have
done this, it works. But I don't like it, since RTM_VERSION has changed.
2) Create new sockaddr, called sockaddr_aspath. Define RTAX_ASPATH, increase
RTAX_MAX. Pass this sockaddr_aspath in rti_info[] array of a routing message
into kernel. Unparse it in the kernel, fill in new field of struct rtentry.
While I haven't yet started working on 2), I'd be very glad to hear comments
from FreeBSD developers. Thanks in advance.
--
Totus tuus, Glebius.
GLEBIUS-RIPN GLEB-RIPE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040302082625.GE22985>