RE: Getting a BGP table in to a lab
Quagga is great for smaller implementations, but it doesn't scale very well. It eats up a lot of CPU, so once you hit a certain number of BGP peers, it may start intermittently flapping BGP sessions, or even just crash the bgpd process entirely. Although, I don't recall whether or not the newer versions support multi-threading for dual processors now... -Rob -----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Frotzler, Florian Sent: Thursday, April 21, 2005 4:35 AM To: nanog@merit.edu Subject: RE: Getting a BGP table in to a lab Hi, Zebra is outdated, the successor is called quagga (at least on debian) and is capable of providing most of the vendor C BGP features, though MD5 autentication is still experimental I think. We used to push a handful of BGP full feeds on our quagga router and it didn't stumble a bit. OSPF also works quite well, btw. Florian
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Scott Morris Sent: Donnerstag, 21. April 2005 02:50 To: swm@emanon.com; 'Nathan Ward'; nanog@merit.edu Subject: RE: Getting a BGP table in to a lab
Forget part of my reply here... I thought someone was posting from the CCIE forum stuff I do.
So disregard the lack-of-caffeine-induced, retarded command about no router being able to support a full feed. :)
My apologies....
Zebra is still a good idea though!
Scott
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Scott Morris Sent: Wednesday, April 20, 2005 8:42 PM To: 'Nathan Ward'; nanog@merit.edu Subject: RE: Getting a BGP table in to a lab
None of the routers that are tested in the lab are capable of supporting a full BGP feed....
If you just want to play with BGP stuff, you can use Zebra (unix) or go to www.nantech.com and get their BGP4WIN program.
That may help you a bit more.
Scott
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Nathan Ward Sent: Wednesday, April 20, 2005 8:35 PM To: nanog@merit.edu Subject: Getting a BGP table in to a lab
I'm trying to come up with a way to get a full BGP routing table in to my lab. I'm not really fussed about keeping it up to date, so a snapshot is fine. At the moment, I'm thinking about spending a few hours hacking together a BGP daemon in perl to peer with and record a table from a production router, disconnect, and then start peering with lab routers.
Am I reinventing a wheel here?
-- Nathan Ward
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Nathan Ward Sent: Wednesday, April 20, 2005 8:35 PM To: nanog@merit.edu Subject: Getting a BGP table in to a lab
I'm trying to come up with a way to get a full BGP routing table in to my lab. I'm not really fussed about keeping it up to date, so a snapshot is fine. At the moment, I'm thinking about spending a few hours hacking together a BGP daemon in perl to peer with and record a table from a production router, disconnect, and then start peering with lab routers.
Am I reinventing a wheel here?
may i suggest OpenBSD/OpenBGPD -- Okan Demirmen <okan@demirmen.com> PGP-Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xB3670934 PGP-Fingerprint: 226D B4AE 78A9 7F4E CD2B 1B44 C281 AF18 B367 0934
On 21.04.2005 17:17 Reeves, Rob wrote
Quagga is great for smaller implementations, but it doesn't scale very well. It eats up a lot of CPU, so once you hit a certain number of BGP peers, it may start intermittently flapping BGP sessions, or even just crash the bgpd process entirely.
For what numbers? I've two quaggas, ~150 peers each, doing as-path and *full* prefix filtering for each peer (Config is around 9MB). CPU is idle 99.x% mostly ... Arnold -- Arnold Nipper, AN45
Arnold Nipper wrote:
On 21.04.2005 17:17 Reeves, Rob wrote
Quagga is great for smaller implementations, but it doesn't scale very well. It eats up a lot of CPU, so once you hit a certain number of BGP peers, it may start intermittently flapping BGP sessions, or even just crash the bgpd process entirely.
For what numbers? I've two quaggas, ~150 peers each, doing as-path and *full* prefix filtering for each peer (Config is around 9MB). CPU is idle 99.x% mostly ...
Yea, but not 150 full feeds. With some full feeds flapping Quagga has a hard time. This is mostly due to poor scheduling of its poor internal multithred scheduler. Fortunatly the root cause has been identified and fixes are currently being discussed on the Quagga lists. Nontheless I prefer OpenBGPd because its internal design is made for many full feeds and it's parts run asynchonously from each other. The only missing thing there is full filtering capabilities which are under development currently. And of course that I pay the time for one of the OpenBGPd developers employed at my company. ;-) If you want to tip the jar too you are most welcome. -- Andre [Oppermann] [aka andre@FreeBSD.ORG] ( http://www.networx.ch )
On Thu, Apr 21, 2005 at 11:36:03PM +0200, Andre Oppermann wrote:
The only missing thing there [in OpenBGPD] is full filtering capabilities which are under development currently.
Oh, and other very basic things like IPv4-multicast, IPv6-unicast and IPv6-multicast AFI/SAFI support. Regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
participants (5)
-
Andre Oppermann -
Arnold Nipper -
Daniel Roesen -
Okan Demirmen -
Reeves, Rob