My planned work on networking stack

[James]

> 	Do you have multiple connectivity to two separate metro area 
> exchanges, with multiple upstreams at each?  

	i dont know about europe, but here in the US, finding transits and
	filling up fib with 130K+ routes is easier than ever. welcome to equinix

> Most large cities are 
> lucky to have a single major metro area exchange, and the author of 
> bgpd for OpenBSD works at an ISP located in Hamburg which is lucky 
> enough to have two major NAPs, and he has multiple connectivity to 
> both.  He was the one ragging on zebra/quagga. 

	i don't know man, but we have a zebra box on our corporate network
	taking 4 full feeds and 5 partial feeds + downstream neighbors for more 
	than 6 months now? havent had any problems other than bgpd taking
	several seconds to lock up the CLI during session flaps caused by 
	maintenance work on our backbone router thats sending full transit
	(which isnt bgpd's fault btw)

>  Among other things, 
> he said he had real problems keeping sessions up with zebra/quagga 
> when neighbors were flapping.

	that's an interesting 'bug' most people including myself didnt
	have to deal with. perhaps more technical information should be gathered
	first before blaming zebra/quagga for not being able to keep 1w of bgp
	session uptime?

	oh for your amusement, telnet route-views2.oregon-ix.net and type
	sh ip bgp sum, then type sh ver

> 
> 	IIRC, he's also got some pretty big cisco equipment (75xx or 
> whatever), 

	sorry but 7500 isnt pretty big other than a size comparable to
	a fridge that acts as a good heater in my bedroom. </end flame>

[! multi snips !]
[! combining with another emails from you !]

>         My point is that zebra/quagga have significant limitations that
> restrict their usefulness, due to the design of the system.
> Moreover, the development on zebra has effectively stalled since the
> author got hired away to do that kind of work professionally, and
> development on quagga has apparently been sporadic and relatively
> limited, presumably due to the fact that they don't have replacement
> developers of the same caliber.

	have you even used zebra taking full routes? or quagga, whatever.
	or are you just talking out of whatever "YMMV Stories" you are
	hearing from other people?

	truth != lack of experience

>        If we want to get to the point where we can have a reasonable
> expectation of throwing away all cisco, juniper, Foundry, and other
> routing hardware and replace them with something that is easier to
> install, configure, monitor, and manage, then I think we need to be
> looking beyond zebra/quagga.

	if we want to get to the point where we can have a reasonable
	expectation of throwing away ciscos, (but sorry no, i am not throwing
	away my junipers), zebra/quagga isn't the place to focus our efforts at
	on this thread. quagga is doing fine in keeping up with defects of zebra
	as well

	what we need now is a FIB that is *better* at handling PPS, which is
	what andre is trying to do. the FreeBSD project is not a router company,
	but we do want a good *nix kernel and environment that provides the core
	api's and the environment needed for good pps forwarding performance
	and rib->fib interaction with the userlands

	remember, the point of the discussion on this thread is to update mainly
	the forwarding plane portion, not control

	forwarding != zebra/quagga, openbsd bgpd, or any bgpd of that matter



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