Re: My planned work on networking stack

	hello -

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

	before FreeBSD can be a 'strong alternative against expensive commercial
	routers', there are several things that must be done

	rewriting of routing stack and implementing FIB-like structure as what andre
	proposed in this thread is very welcoming.

	there are still other things freebsd lacks. such as uRPF that _SERVICE_PROVIDER_
	can use. ipfw2 has verrevpath but all it does from what i know is strict uRPF
	only. service providers like myself, if we were to use freebsd boxen to run our
	network, i am not spending money on a router that doesn't do loose-check uRPF.
	this sounds like something linux does too but i refuse to use that :P

	implementation of policy routing similar to vrf's is something i wanted for a
	while as well. modern router deployments out in service provider core arena
	requires most people to start implementing "routing processes" using different
	routing instances. i.e. carrying mpls core routes in one routing instance, and
	carrying transit routes in the other to prevent core being affected by edge or
	outside routing failures, etc, etc


> Modern i386 PC
> can route/filter/shape much more traffic than expensive Cisco 36xx. I haven't
> yet compared with 7000 series...

	comparing a modern x86 box running freebsd against a 3600 is a piece of cake.

	comparing a modern x86 box running freebsd against a 7000 is a piece of cake.

	comparing an x86 box running freebsd against a 7500 with old vip's and RSP1 or
	RSP2 is also piece of cake. there must be something seriously wrong if any of
	these junk old crisco routers that were supposed to be in dumpster since Jan 1st
	2004, can beat modern freebsd box's performance.

	comparing a modern x86 box against a Cisco 7206VXR with NPE-G1 however is a 
	good challenge :)

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

	why inject as_path info from userland to kernel "fib"?  may be netflow turning
	into an api that quagga can take advantage of to gather accounting information
	is more feasible?



-- 
James Jun                                            TowardEX Technologies, Inc.
Technical Lead                        Network Design, Consulting, IT Outsourcing
james_at_towardex.com                  Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867           web: http://www.towardex.com , noc: www.twdx.net