> 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
[EMAIL PROTECTED] Boston-based Colocation & Bandwidth Services
cell: 1(978)-394-2867 web: http://www.towardex.com , noc: www.twdx.net
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
