Re: My planned work on networking stack

Gleb Smirnoff wrote:
> 
>   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...

No, Zebra/Quagga will not be integrated into FreeBSD but available from
Ports.  There is no reason why a routing daemon needs to be part of the
base system.  FreeBSD will provided the appropriate APIs to a routing
daemon to make full use of the kernel packet forwarding engine.

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

The AS path does not belong into the kernel or the FIB.

If you want to do per-AS accounting a much better solution is simply
to take a MRT dump and load it into a BPF/PCAP application which is
collecting statistics.

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

The routing message format needs to be redisigned.  That is nothing that
happens on short notice.

-- 
Andre