Re: Bird vs Quagga revisited
The Linux Kernel itself may be GPL (which I wasn't debating), however I see no reason why MikroTik's MPLS stack couldn't work in a similar way to the closed source NVidia driers where my understanding is that a GPL stub loads a binary blob. Have you asked MikroTik for a copy of the source? Edward Dore Freethought Internet On 1 Sep 2012, at 09:12, Bjørn Mork wrote: Edward Dore edward.d...@freethought-internet.co.uk writes: They used to publish the source for their 2.4 kernel on routerboard.com (in fact, it's still available at http://routerboard.com/files/linux-2.4.31.zip), but I've not seen anything for the 2.6 kernel however and the routerboard.com site was redesigned a little while ago, seemingly without the links as far as I can tell. It might be a case of you need to ask them for it. Would be interesting to see which bits are GPL. There is no doubt that *all* bits of the Linux kernel are GPL. Whether vendors respect this is another question. But Mikrotik most certainly cannot distribute the Linux kernel, modified or not, without also providing the full source code. Bjørn
Re: Bird vs Quagga revisited
Seth Mattinen se...@rollernet.us writes: What's the state of MPLS on Linux these days? There was some renewed interest recently (i.e. last year). See the discussion starting at http://www.spinics.net/lists/netdev/msg180282.html But do note davem's replies in http://www.spinics.net/lists/netdev/msg180401.html http://www.spinics.net/lists/netdev/msg180646.html Don't put too much into the fringe facility comment. There have been similar comments on e.g. IPv6, and that went in some time ago :-) So in short: There is some interest and some people working on this in a direction which has some hope of mainline integration. Bjørn
Re: Bird vs Quagga revisited
Edward Dore edward.d...@freethought-internet.co.uk writes: They used to publish the source for their 2.4 kernel on routerboard.com (in fact, it's still available at http://routerboard.com/files/linux-2.4.31.zip), but I've not seen anything for the 2.6 kernel however and the routerboard.com site was redesigned a little while ago, seemingly without the links as far as I can tell. It might be a case of you need to ask them for it. Would be interesting to see which bits are GPL. There is no doubt that *all* bits of the Linux kernel are GPL. Whether vendors respect this is another question. But Mikrotik most certainly cannot distribute the Linux kernel, modified or not, without also providing the full source code. Bjørn
Re: Bird vs Quagga revisited
On Wed, 2012-08-29 at 16:39 +0100, Edward J. Dore wrote: MikroTik RouterOS is indeed based on Linux, however I believe they rolled their own MPLS stack. Hi, Does Mikrotik publish their modified Linux kernel source? Might be interesting to look at it. Laurent Last time I looked, the mpls-linux project over at SourceForge was incomplete and slow - I have no idea if this has changed at all recently however. Edward Dore Freethought Internet - Original Message - From: Walter Keen walter.k...@rainierconnect.net To: Seth Mattinen se...@rollernet.us Cc: nanog@nanog.org Sent: Wednesday, 29 August, 2012 2:00:52 AM Subject: Re: Bird vs Quagga revisited I'm fairly sure that Mikrotik software is based on linux, and supports MPLS. Not too sure which package they use, or if they rolled their own MPLS support... - Original Message - From: Seth Mattinen se...@rollernet.us To: nanog@nanog.org Sent: Tuesday, August 28, 2012 4:42:14 PM Subject: Re: Bird vs Quagga revisited What's the state of MPLS on Linux these days? ~Seth
Re: Bird vs Quagga revisited
Just for the records, OpenBSD got fully functional MPLS stack. HTH, Dan #13685 (RS/Sec/SP) The CCIE troubleshooting blog: http://dans-net.com Bring order to your Private VLAN network: http://marathon-networks.com On Fri, Aug 31, 2012 at 2:44 PM, Laurent GUERBY laur...@guerby.net wrote: On Wed, 2012-08-29 at 16:39 +0100, Edward J. Dore wrote: MikroTik RouterOS is indeed based on Linux, however I believe they rolled their own MPLS stack. Hi, Does Mikrotik publish their modified Linux kernel source? Might be interesting to look at it. Laurent Last time I looked, the mpls-linux project over at SourceForge was incomplete and slow - I have no idea if this has changed at all recently however. Edward Dore Freethought Internet - Original Message - From: Walter Keen walter.k...@rainierconnect.net To: Seth Mattinen se...@rollernet.us Cc: nanog@nanog.org Sent: Wednesday, 29 August, 2012 2:00:52 AM Subject: Re: Bird vs Quagga revisited I'm fairly sure that Mikrotik software is based on linux, and supports MPLS. Not too sure which package they use, or if they rolled their own MPLS support... - Original Message - From: Seth Mattinen se...@rollernet.us To: nanog@nanog.org Sent: Tuesday, August 28, 2012 4:42:14 PM Subject: Re: Bird vs Quagga revisited What's the state of MPLS on Linux these days? ~Seth
Re: Bird vs Quagga revisited
Seems that Netbsd have MPLS too, with the advantage to run in a jukebox. http://wiki.netbsd.org/users/kefren/mpls/ -- Eduardo Schoedler 2012/8/31 Dan Shechter dans...@gmail.com Just for the records, OpenBSD got fully functional MPLS stack. HTH, Dan #13685 (RS/Sec/SP) The CCIE troubleshooting blog: http://dans-net.com Bring order to your Private VLAN network: http://marathon-networks.com On Fri, Aug 31, 2012 at 2:44 PM, Laurent GUERBY laur...@guerby.net wrote: On Wed, 2012-08-29 at 16:39 +0100, Edward J. Dore wrote: MikroTik RouterOS is indeed based on Linux, however I believe they rolled their own MPLS stack. Hi, Does Mikrotik publish their modified Linux kernel source? Might be interesting to look at it. Laurent Last time I looked, the mpls-linux project over at SourceForge was incomplete and slow - I have no idea if this has changed at all recently however. Edward Dore Freethought Internet - Original Message - From: Walter Keen walter.k...@rainierconnect.net To: Seth Mattinen se...@rollernet.us Cc: nanog@nanog.org Sent: Wednesday, 29 August, 2012 2:00:52 AM Subject: Re: Bird vs Quagga revisited I'm fairly sure that Mikrotik software is based on linux, and supports MPLS. Not too sure which package they use, or if they rolled their own MPLS support... - Original Message - From: Seth Mattinen se...@rollernet.us To: nanog@nanog.org Sent: Tuesday, August 28, 2012 4:42:14 PM Subject: Re: Bird vs Quagga revisited What's the state of MPLS on Linux these days? ~Seth
Re: Bird vs Quagga revisited
They used to publish the source for their 2.4 kernel on routerboard.com (in fact, it's still available at http://routerboard.com/files/linux-2.4.31.zip), but I've not seen anything for the 2.6 kernel however and the routerboard.com site was redesigned a little while ago, seemingly without the links as far as I can tell. It might be a case of you need to ask them for it. Would be interesting to see which bits are GPL. Edward Dore Freethought Internet On 31 Aug 2012, at 12:44, Laurent GUERBY wrote: On Wed, 2012-08-29 at 16:39 +0100, Edward J. Dore wrote: MikroTik RouterOS is indeed based on Linux, however I believe they rolled their own MPLS stack. Hi, Does Mikrotik publish their modified Linux kernel source? Might be interesting to look at it. Laurent Last time I looked, the mpls-linux project over at SourceForge was incomplete and slow - I have no idea if this has changed at all recently however. Edward Dore Freethought Internet - Original Message - From: Walter Keen walter.k...@rainierconnect.net To: Seth Mattinen se...@rollernet.us Cc: nanog@nanog.org Sent: Wednesday, 29 August, 2012 2:00:52 AM Subject: Re: Bird vs Quagga revisited I'm fairly sure that Mikrotik software is based on linux, and supports MPLS. Not too sure which package they use, or if they rolled their own MPLS support... - Original Message - From: Seth Mattinen se...@rollernet.us To: nanog@nanog.org Sent: Tuesday, August 28, 2012 4:42:14 PM Subject: Re: Bird vs Quagga revisited What's the state of MPLS on Linux these days? ~Seth
Re: Bird vs Quagga revisited
MikroTik RouterOS is indeed based on Linux, however I believe they rolled their own MPLS stack. Last time I looked, the mpls-linux project over at SourceForge was incomplete and slow - I have no idea if this has changed at all recently however. Edward Dore Freethought Internet - Original Message - From: Walter Keen walter.k...@rainierconnect.net To: Seth Mattinen se...@rollernet.us Cc: nanog@nanog.org Sent: Wednesday, 29 August, 2012 2:00:52 AM Subject: Re: Bird vs Quagga revisited I'm fairly sure that Mikrotik software is based on linux, and supports MPLS. Not too sure which package they use, or if they rolled their own MPLS support... - Original Message - From: Seth Mattinen se...@rollernet.us To: nanog@nanog.org Sent: Tuesday, August 28, 2012 4:42:14 PM Subject: Re: Bird vs Quagga revisited What's the state of MPLS on Linux these days? ~Seth
Re: Bird vs Quagga revisited
MPLS and VPLS on RouterOS works very well. -- Eduardo Schoedler Em 29/08/2012, às 12:39, Edward J. Dore edward.d...@freethought-internet.co.uk escreveu: MikroTik RouterOS is indeed based on Linux, however I believe they rolled their own MPLS stack. Last time I looked, the mpls-linux project over at SourceForge was incomplete and slow - I have no idea if this has changed at all recently however. Edward Dore Freethought Internet - Original Message - From: Walter Keen walter.k...@rainierconnect.net To: Seth Mattinen se...@rollernet.us Cc: nanog@nanog.org Sent: Wednesday, 29 August, 2012 2:00:52 AM Subject: Re: Bird vs Quagga revisited I'm fairly sure that Mikrotik software is based on linux, and supports MPLS. Not too sure which package they use, or if they rolled their own MPLS support... - Original Message - From: Seth Mattinen se...@rollernet.us To: nanog@nanog.org Sent: Tuesday, August 28, 2012 4:42:14 PM Subject: Re: Bird vs Quagga revisited What's the state of MPLS on Linux these days? ~Seth
Re: Bird vs Quagga revisited
Personally I would like to see more work on all three opensource implementations, i.e. BIRD, OpenBGPd and Quagga. http://opensourcerouting.org/ to the rescue? Hi, I'm David Lamparter, employed at the OpenSourceRouting (OSR) project to maintain Quagga. I can tell you that the OSR's interest is in providing a stable open-source routing platform for actual switches/routers (with either a software or hardware forwarding plane). Quagga and BIRD were considered equally; Quagga's single-RIB design and existence of isisd were what tipped the scales. We primarily perform conformance and scale testing and fix/enhance in those areas; also we support 3rd parties in cleaning and submitting Quagga patches/features. OSPF and IS-IS are stronger targets currently since they need more work than BGP, and also Euro-IX already did much of the latter. Merging that is on the TODO, but it's a lot of work. Even as a Quagga maintainer, I must currently recommend against using mainline Quagga as a route server. Please use Euro-IX Quagga, and if you can/want, convince your decisionmakers to support Chris Hall on that -- I've been told future work on the Euro-IX Quagga branch is not certain. There's been a BoF on RIPE64 with OSR, BIRD and Quagga involvement. There'll be one at RIPE65 again I think. Either way if you have questions, feel free to ask. -David signature.asc Description: Digital signature
Re: Bird vs Quagga revisited
What's the state of MPLS on Linux these days? ~Seth
Re: Bird vs Quagga revisited
I'm fairly sure that Mikrotik software is based on linux, and supports MPLS. Not too sure which package they use, or if they rolled their own MPLS support... - Original Message - From: Seth Mattinen se...@rollernet.us To: nanog@nanog.org Sent: Tuesday, August 28, 2012 4:42:14 PM Subject: Re: Bird vs Quagga revisited What's the state of MPLS on Linux these days? ~Seth
Re: Bird vs Quagga revisited
Fell free to contact me if you have any questions about ExaBGP as I am painfully aware it's documentation is nowhere near what it should be. Thomas Sent from my iPad On 23 Aug 2012, at 08:52, Andy Davidson a...@nosignal.org wrote: On 22 Aug 2012, at 18:42, David Hubbard dhubb...@dino.hostasaurus.com wrote: Of those who have used Quagga or Bird, or anything else, would either of them be appropriate and/or well suited for use as an iBGP blackhole route server? You can use Quagga or Bird as a blackhole BGP injector, because the forwarding load is next to nothing and the number of prefixes in your blackhole RIB is likely to be small. You might - if you programatically get the blackhole criteria from your crm or some other database find ExaBGP to be easier to integrate with your data source. ExaBGP is a very lightweight BGP speaker that is perfectly suited for this purpose - http://code.google.com/p/exabgp/ Andy
Re: Bird vs Quagga revisited (MP-BGP RR)
On 23 Aug 2012, at 15:04, Raymond Burkholder r...@oneunified.net wrote: To expand the opinion set, how do Quagga, Bird, exaBGP, OpenBGPd hold up for handling Multi-Protocol BGP Route Reflector duties in a BGP/MPLS environment for a smaller ISP? I am using BIRD as a RR between a busy VRF and our core and will not change it until the PPS are over what the box can pass :) EuroIX members were presented on a comparison of RR : ASR 1001 / 1002, Bird 1.3.6 / 1.3.7 / OpenBGPd - Quagga is not in the list as they do not use it , they migrated away from it after too many issues AFAICR. They found that both cisco routers which are designed to be used as RR and BIRD were performing very well (even more when you look at what CPU is on those cisco routers). The talk made at Euro-IX was under the password protected section but I found it on their site : http://www.ams-ix.net/downloads/AMS-IX%20Route%20Server%20Implementations%20Performance.pdf They presented their second testing at RIPE : https://ripe64.ripe.net/presentations/49-Follow_Up_AMS-IX_route-server_test_Euro-IX_20th_RIPE64.pdf Thomas
Re: Bird vs Quagga revisited
Don't forget about XORP if you have any need for multicast routing ... On Wed, Aug 22, 2012 at 1:19 AM, Hank Nussbacher h...@efes.iucc.ac.il wrote: Sorry to disrupt the bad cabling thread, but I'd like to revisit a thread from 2 years ago. I have read over the NANOG presentations: http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final_N48.pdf as well as the NANOG thread: http://www.gossamer-threads.com/lists/nanog/users/123027 But have not found anything worthwhile on the matter over the past 2 years. Both Quagga and BIRD have developed since the comparison in 2010: http://savannah.nongnu.org/news/?group=quagga http://bird.network.cz/?o_news But has anyone performed a more recent comparsion? Does Quagga still suffer from performance issues vs BIRD? Has anyone performed an RFC conformance test to see who complies more strictly to all the various RFCs? If BIRD is so much better than Quagga why is there no instance at Oregon: http://www.routeviews.org/ I also notice that BSD Router Project supports both: http://bsdrp.net/bsdrp How well do the two coexist at the same time? Any migration issues going from Quagga to BIRD? Any feedback appreciated. We now take you back to cable wars :-) Thanks, Hank -- Ray Patrick Soucy Network Engineer University of Maine System T: 207-561-3526 F: 207-561-3531 MaineREN, Maine's Research and Education Network www.maineren.net
Re: Bird vs Quagga revisited
On Wed, Aug 22, 2012 at 1:42 PM, David Hubbard dhubb...@dino.hostasaurus.com wrote: Of those who have used Quagga or Bird, or anything else, would either of them be appropriate and/or well suited for use as an iBGP blackhole route server? We currently do blackholes via manual config on one of our real routers but are wanting to add a software-based (on linux) system where we could script a way for some of our tech support folks to add blackhole routes at the direction of a network person where they can just enter a command and the IP address. seems you want something like quagga on a secured host... that ought to be fine, you could even just make it an ebgp peer of 2-3 devices and use that with a route-map to reset the next-hop, there by not messing up your current nice ibgp mesh. Thanks, David
Re: Bird vs Quagga revisited
On 22 Aug 2012, at 18:42, David Hubbard dhubb...@dino.hostasaurus.com wrote: Of those who have used Quagga or Bird, or anything else, would either of them be appropriate and/or well suited for use as an iBGP blackhole route server? You can use Quagga or Bird as a blackhole BGP injector, because the forwarding load is next to nothing and the number of prefixes in your blackhole RIB is likely to be small. You might - if you programatically get the blackhole criteria from your crm or some other database find ExaBGP to be easier to integrate with your data source. ExaBGP is a very lightweight BGP speaker that is perfectly suited for this purpose - http://code.google.com/p/exabgp/ Andy
RE: Bird vs Quagga revisited (MP-BGP RR)
Of those who have used Quagga or Bird, or anything else, would either of them be appropriate and/or well suited for use as an iBGP blackhole route server? To expand the opinion set, how do Quagga, Bird, exaBGP, OpenBGPd hold up for handling Multi-Protocol BGP Route Reflector duties in a BGP/MPLS environment for a smaller ISP? Quagga's documentation indicates that is does handle the requirements. Any one able to offer up real life experiences? Or is it better to handle in a physical router? We being C based. Ray. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Bird vs Quagga revisited
On 22/08/12 06:19, Hank Nussbacher wrote: Sorry to disrupt the bad cabling thread, but I'd like to revisit a thread from 2 years ago. I have read over the NANOG presentations: http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final_N48.pdf Much of the Quagga pain discussed openly in 2010 was related to its performance as a route-server (which in a large instance might need to converge many millions of best paths, in a multiple table setup). A route-server is more like a database which uses bgp as its interface, than it is a router. The problems that we felt as exchange operators at this time were different to the ones that people using these packages as a router felt. Both Quagga and BIRD have developed since the comparison in 2010: http://savannah.nongnu.org/news/?group=quagga http://bird.network.cz/?o_news I'm not clear what you care about from a performance point of view - forwarding ? acting as a route-server ? collector ? BIRD is a great, super-fast route-server daemon - much better than typical competitors Quagga and OpenBGPd at this job. In a forwarding capacity, I do not know and I would really think that Operating system performance and environment tuning will have more to do with forwarding performance than the daemon used. I am hoping that forwarding best-practice information for Quagga eventually comes out of this project : http://opensourcerouting.org/ Andy
Re: Bird vs Quagga revisited
On 22/08/12 06:19, Hank Nussbacher wrote: ...Any feedback appreciated. I can't speak too highly of BIRD. Our use case is probably not completely typical, but our multilateral peering route servers have been hugely improved by switching to BIRD. Our two primary route servers, one for each LINX London LAN, use BIRD; the two secondaries use an enhanced version of Quagga. The BIRD route server scales better, gives much higher performance, is much more robust, and is much easier to restart - especially when there are lots of connected sessions. The development team are fantastic: very active and responsive, and especially responsive to the needs of the IXP community. Switching hats to Euro-IX, BIRD is now the most used route server amongst IXPs, as can be seen from our latest annual report: https://www.euro-ix.net/documents/1024-Euro-IX-IXP-Report-pdf?download=yes John -- John Souter, CEO, London Internet Exchange Ltd Trinity Court, Trinity Street, Peterborough PE1 1DA. Registered 3137929 in England. Mobile: +44-7711-492389 https://www.linx.net/ Working for the Internet sip:j...@linx.net
Re: Bird vs Quagga revisited
Hello, I came across this site a few weeks ago http://code.google.com/p/google-quagga/source/list Seems that Google (or at least some Googlers) are working on quagga, or worked as the last update is tagged July 2011. Main difference I see between Quagga and Bird, is that it is now possible to run ISIS on Quagga, but I did not perform a full comparaison of this two daemon. Guillaume 2012/8/22 Hank Nussbacher h...@efes.iucc.ac.il Sorry to disrupt the bad cabling thread, but I'd like to revisit a thread from 2 years ago. I have read over the NANOG presentations: http://www.nanog.org/meetings/**nanog48/presentations/Monday/** Jasinska_RouteServer_N48.pdfhttp://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf http://www.nanog.org/meetings/**nanog48/presentations/Monday/** Filip_BIRD_final_N48.pdfhttp://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final_N48.pdf as well as the NANOG thread: http://www.gossamer-threads.**com/lists/nanog/users/123027http://www.gossamer-threads.com/lists/nanog/users/123027 But have not found anything worthwhile on the matter over the past 2 years. Both Quagga and BIRD have developed since the comparison in 2010: http://savannah.nongnu.org/**news/?group=quaggahttp://savannah.nongnu.org/news/?group=quagga http://bird.network.cz/?o_news But has anyone performed a more recent comparsion? Does Quagga still suffer from performance issues vs BIRD? Has anyone performed an RFC conformance test to see who complies more strictly to all the various RFCs? If BIRD is so much better than Quagga why is there no instance at Oregon: http://www.routeviews.org/ I also notice that BSD Router Project supports both: http://bsdrp.net/bsdrp How well do the two coexist at the same time? Any migration issues going from Quagga to BIRD? Any feedback appreciated. We now take you back to cable wars :-) Thanks, Hank -- Cordialement, Guillaume BARROT
RE: Bird vs Quagga revisited
Of those who have used Quagga or Bird, or anything else, would either of them be appropriate and/or well suited for use as an iBGP blackhole route server? We currently do blackholes via manual config on one of our real routers but are wanting to add a software-based (on linux) system where we could script a way for some of our tech support folks to add blackhole routes at the direction of a network person where they can just enter a command and the IP address. Thanks, David
Re: Bird vs Quagga revisited
On Wed, Aug 22, 2012 at 1:42 PM, David Hubbard dhubb...@dino.hostasaurus.com wrote: Of those who have used Quagga or Bird, or anything else, would either of them be appropriate and/or well suited for use as an iBGP blackhole route server? We currently do blackholes via manual config on one of our real routers but are wanting to add a software-based (on linux) system where we could script a way for some of our tech support folks to add blackhole routes at the direction of a network person where they can just enter a command and the IP address. Thanks, David David Are you referring to the DROP[1] or BGPF[2] lists? If so there are various was to use that data. [1] http://www.spamhaus.org/drop/ [2] http://www.spamhaus.org/bgpf/ -- ~ Andrew lathama Latham lath...@gmail.com http://lathama.net ~
Re: Bird vs Quagga revisited
On 22.08.2012 11:22, John Souter wrote: On 22/08/12 06:19, Hank Nussbacher wrote: ...Any feedback appreciated. I can't speak too highly of BIRD. Our use case is probably not completely typical, but our multilateral peering route servers have been hugely improved by switching to BIRD. Our two primary route servers, one for each LINX London LAN, use BIRD; the two secondaries use an enhanced version of Quagga. The BIRD route server scales better, gives much higher performance, is much more robust, and is much easier to restart - especially when there are lots of connected sessions. The development team are fantastic: very active and responsive, and especially responsive to the needs of the IXP community. Switching hats to Euro-IX, BIRD is now the most used route server amongst IXPs, as can be seen from our latest annual report: https://www.euro-ix.net/documents/1024-Euro-IX-IXP-Report-pdf?download=yes +1 ... I guess we at DE-CIX perhaps run the largest routeserver setups with full as-path and prefix-list filtering. BIRD really was some magnitudes of perfomance improvement compared to Quagga. In the meantime some of us (LINX, INEX, DE-CIX) also supported development of Quagga as a routeserver. Biggest issue currently is to get this code into mainline Quagga to make it suitabke for further development and improvement. Personally I would like to see more work on all three opensource implementations, i.e. BIRD, OpenBGPd and Quagga. Arnold -- Arnold Nipper CTO/COO e-mail: arnold.nip...@de-cix.net DE-CIX Management GmbH mobile: +49 152 5371 7690 Lichtstr. 43i, 50825 Koeln phone: +49 69 1730 902 22 Geschaeftsfuehrer Harald A. Summa fax:+49 69 4056 2716 Registergericht AG Koeln HRB 51135 http://www.de-cix.net signature.asc Description: OpenPGP digital signature
Re: Bird vs Quagga revisited
Personally I would like to see more work on all three opensource implementations, i.e. BIRD, OpenBGPd and Quagga. http://opensourcerouting.org/ to the rescue? -- Christian Esteve Rothenberg, Ph.D. Converged Networks Business Unit CPqD - Center for Research and Development in Telecommunications Tel. (+55 19) 3705 4479 / Cel. (+55 19) 8193-7087 On Wed, Aug 22, 2012 at 4:43 PM, Arnold Nipper arn...@nipper.de wrote: On 22.08.2012 11:22, John Souter wrote: On 22/08/12 06:19, Hank Nussbacher wrote: ...Any feedback appreciated. I can't speak too highly of BIRD. Our use case is probably not completely typical, but our multilateral peering route servers have been hugely improved by switching to BIRD. Our two primary route servers, one for each LINX London LAN, use BIRD; the two secondaries use an enhanced version of Quagga. The BIRD route server scales better, gives much higher performance, is much more robust, and is much easier to restart - especially when there are lots of connected sessions. The development team are fantastic: very active and responsive, and especially responsive to the needs of the IXP community. Switching hats to Euro-IX, BIRD is now the most used route server amongst IXPs, as can be seen from our latest annual report: https://www.euro-ix.net/documents/1024-Euro-IX-IXP-Report-pdf?download=yes +1 ... I guess we at DE-CIX perhaps run the largest routeserver setups with full as-path and prefix-list filtering. BIRD really was some magnitudes of perfomance improvement compared to Quagga. In the meantime some of us (LINX, INEX, DE-CIX) also supported development of Quagga as a routeserver. Biggest issue currently is to get this code into mainline Quagga to make it suitabke for further development and improvement. Personally I would like to see more work on all three opensource implementations, i.e. BIRD, OpenBGPd and Quagga. Arnold -- Arnold Nipper CTO/COO e-mail: arnold.nip...@de-cix.net DE-CIX Management GmbH mobile: +49 152 5371 7690 Lichtstr. 43i, 50825 Koeln phone: +49 69 1730 902 22 Geschaeftsfuehrer Harald A. Summa fax:+49 69 4056 2716 Registergericht AG Koeln HRB 51135 http://www.de-cix.net -- Christian
Bird vs Quagga revisited
Sorry to disrupt the bad cabling thread, but I'd like to revisit a thread from 2 years ago. I have read over the NANOG presentations: http://www.nanog.org/meetings/nanog48/presentations/Monday/Jasinska_RouteServer_N48.pdf http://www.nanog.org/meetings/nanog48/presentations/Monday/Filip_BIRD_final_N48.pdf as well as the NANOG thread: http://www.gossamer-threads.com/lists/nanog/users/123027 But have not found anything worthwhile on the matter over the past 2 years. Both Quagga and BIRD have developed since the comparison in 2010: http://savannah.nongnu.org/news/?group=quagga http://bird.network.cz/?o_news But has anyone performed a more recent comparsion? Does Quagga still suffer from performance issues vs BIRD? Has anyone performed an RFC conformance test to see who complies more strictly to all the various RFCs? If BIRD is so much better than Quagga why is there no instance at Oregon: http://www.routeviews.org/ I also notice that BSD Router Project supports both: http://bsdrp.net/bsdrp How well do the two coexist at the same time? Any migration issues going from Quagga to BIRD? Any feedback appreciated. We now take you back to cable wars :-) Thanks, Hank
Re: BIRD vs Quagga
On 13 Feb 2010, at 01:01, Nathan Ward wrote: On 13/02/2010, at 11:51 AM, Steve Bertrand wrote: fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I haven't tried those either...zebra/Quagga just stuck. OpenBGPd would be great for a public route server at an IX. Nathan has made a good point. Deploying them in an IX environment, with features like per-peer RIBs, very complex filtering, and the numbers of peers you might expect on a route-server environment, is a very different beast to (and more complicated than) deploying them in a network edge/forwarding role. In a forwarding role, the underlying OS's features and the robustness of the daemon under load matters in different ways. So what's best ? I have used all three in a forwarding role and found BIRD on Debian a pretty solid combination. I found OpenBGPd on OpenBSD a pain to use - it converged really slowly and bgpctl seemed to lock up for a while after startup in an environment with *many* peers, and the behaviour with ospf3 used to change quite a lot. Quagga on Linux or FreeBSD seemed to work ok, and the interface will be quite familiar to Cisco users. Using all three as an injector for Anycast or similar leads to quite similar outcomes. However you might find ExaBGP more lightweight in this role - see http://bgp.exa.org.uk/ - do check it out. This has an interface which will feel extremely comfortable to Juniper users. You should still go to the IX Route-Servers panel to learn more about the software in question :-) And its really very good research being presented - but I am biased here. Best wishes Andy -- // www.netsumo.com // Professional network engineering consultancy // //uk ddi: +44(0)20 7993 1702// us ddi: (415) 520 3589//
Re: BIRD vs Quagga
During the discussion, a developers of Bird said that their filtering code _may_ still have bugs (when performing community based filtering). Someone rightly pointed to me that the commenter was not a BIRD developer .. my mistake sorry. I will recall my statement until I can watch to the webcast archive of the meeting. Thomas
Re: BIRD vs Quagga
On 17/02/2010 01:19, Randy Bush wrote: i would add decades of bad anecdotes where the data plane is not congruent with the control plane. in general, when plane N is not congruent with plane N+1, management and debugging are problematic. I've always maintained publicly and privately that route servers are not for everyone. A good rule of thumb is: using a route collector for peering is probably suitable for your network unless you know why it isn't. Interesting choice of wording: decades of bad anecdotes. Does that mean anecdata? Nick
Re: BIRD vs Quagga
Quagga does not really behave well with lots of peers (lots 200), but there will be an optimized route server version soon. This was discussed today at Linx 68. Linx is very pleased with Bird - they could not get Quagga working due to load issues. With large numbers of peers, the update processing can cause the program to hit his peer HoldTime Timer (with a domino's effect as well). EuroIX is sponsoring some work on Quagga to get the KeepAlive management moved into a separate Thread. During the discussion, a developers of Bird said that their filtering code _may_ still have bugs (when performing community based filtering). Thomas
Re: BIRD vs Quagga
On 16/02/2010 19:47, Thomas Mangin wrote: During the discussion, a developers of Bird said that their filtering code _may_ still have bugs (when performing community based filtering). medium-long term, community based route-server filtering has no future. There will be two reasons for its demise: it cannot easily accommodate asn32 and it does not allow predetermined filtering and hence sane loc-rib instance management. I touched on this briefly at my uknof talk recently, but long term, the writing is on the wall for this sort of filtering. Nick
Re: BIRD vs Quagga
On Tue, Feb 16, 2010 at 07:47:13PM +, Thomas Mangin wrote: (with a domino's effect as well). Your routes processed in 30 minutes or it's free? - Matt (Yeah, I know, back in my hole...)
Re: BIRD vs Quagga
medium-long term, community based route-server filtering has no future. There will be two reasons for its demise: it cannot easily accommodate asn32 and it does not allow predetermined filtering and hence sane loc-rib instance management. i would add decades of bad anecdotes where the data plane is not congruent with the control plane. in general, when plane N is not congruent with plane N+1, management and debugging are problematic. randy
RE: BIRD vs Quagga
As in SS7, which has successfully managed the phone system for decades, where the control and data plane are explicitly separated? There's significant theoretical work, backed up with lots of practical experience connecting a lot more nodes in real time in a lot more places than the Internet currently does, that posits that the control and forwarding plane should actually ALWAYS be separate, and control higher priority, so that state management converges faster than the dataflows. I'd like to see the countervailing, peer reviewed, references. -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Tuesday, February 16, 2010 5:19 PM To: Nick Hilliard Cc: NANOG list Subject: Re: BIRD vs Quagga medium-long term, community based route-server filtering has no future. There will be two reasons for its demise: it cannot easily accommodate asn32 and it does not allow predetermined filtering and hence sane loc-rib instance management. i would add decades of bad anecdotes where the data plane is not congruent with the control plane. in general, when plane N is not congruent with plane N+1, management and debugging are problematic. randy
Re: BIRD vs Quagga
As in SS7, which has successfully managed the phone system for decades, where the control and data plane are explicitly separated? and has such wonderful margins and, btw, separation is not necessarily non-congruence
RE: BIRD vs Quagga
Good point regarding non-congruence not necessarily meaning non-separation, and touché on margins (by which I presume you mean SS7 has massive overprovisionining for average traffic). However, the fact remains, it has proven itself to work for a lot longer, and a for much larger subscriber base, with far fewer systemic failures (especially on a per subscriber/expected availability basis), than the current Internet. I notice you didn't answer my request for the peer reviewed literature to support your assertion. To support mine I give (there are hundreds in the literature): Gopel (Nokia): HSN and Multimedia Apps, 5th Conf, IEEE, 2002: Print ISBN: 0-7803-7600-5 PP 161-166 Ramjee et al (Lucent Bell Labs): Comsware 2006: Print ISBN: 0-7803-9575-1 PP 1-10 Khalios et al (City College of NY): IEEE Globecom 2003: Print ISBN: 0-7803-7974-8 PP 3984-3989 Never mind all of Shannon's work and everything bell labs did in developing digital switching. You can always have control traffic follow the same path in a different channel, so you get the same effect of physical interruption, and therefore the topography alerting of an interrupted link, without the issues of pathological traffic in the bearer channel interrupting your control traffic (as with ISDN subscriber trunks). -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Tuesday, February 16, 2010 7:56 PM To: Tomas L. Byrnes Cc: Nick Hilliard; NANOG list Subject: Re: BIRD vs Quagga As in SS7, which has successfully managed the phone system for decades, where the control and data plane are explicitly separated? and has such wonderful margins and, btw, separation is not necessarily non-congruence
Re: BIRD vs Quagga
On Tue, Feb 16, 2010 at 10:55 PM, Randy Bush ra...@psg.com wrote: As in SS7, which has successfully managed the phone system for decades, where the control and data plane are explicitly separated? and has such wonderful margins and, btw, separation is not necessarily non-congruence cough decisions per second rate/cough cough path information per 'call' or 'decision'/cough ...these aren't like examples... (apples to oranges discussion, move along, nothing to see here)
Re: BIRD vs Quagga
http://archive.psg.com/080918.plnog-complex.pdf
Re: BIRD vs Quagga
On 2010-02-16, at 19:53, Tomas L. Byrnes wrote: There's significant theoretical work, backed up with lots of practical experience connecting a lot more nodes in real time in a lot more places than the Internet currently does, that posits that the control and forwarding plane should actually ALWAYS be separate, and control higher priority, so that state management converges faster than the dataflows. I'd like to see the countervailing, peer reviewed, references. I have no shortage of anecdotes where a non-trivial layer-2 topology at an exchange point has left my router and provider X's router both able to talk to a route server, but unable to talk to each other directly. Since the NEXT_HOP on routes we each learnt from the route server pointed at an address we couldn't talk to, the result was a black hole. So while your theoretical work might well have substantial merit, its application to the example at hand seems potentially lacking. I am somewhat intrigued at this network you mention with which people have practical experience that has more nodes than the Internet does, though. That'd be quite a network. Joe
Re: BIRD vs Quagga
On Wed, Feb 17, 2010 at 12:50 AM, Joe Abley jab...@hopcount.ca wrote: I am somewhat intrigued at this network you mention with which people have practical experience that has more nodes than the Internet does, though. That'd be quite a network. what's the current estimate on PSTN endpoints? 2-3B globally? is that more/less than the IP/Internet world? I bet it's, at this time, fairly close to the same number. Potential references: http://www.funtrivia.com/askft/Question25278.html thinks the ITU estimated ~33% of 1.4b devices were mobile phones (in 2002) http://en.wikipedia.org/wiki/List_of_countries_by_number_of_mobile_phones_in_use wikipedia thinks a total mobile phone market is ~4.1b phones with ~60% global penetration. http://en.wikipedia.org/wiki/List_of_countries_by_number_of_telephone_lines_in_use number of PSTN lines globally ~= 1.3b So a total across the wikipedia links says ~5.5b phone devices. That seems significantly more than IP devices. I did not, obviously, factor in phones which are also IP devices (your iPhone type thingy) -Chris
Re: BIRD vs Quagga
On 2010-02-16, at 22:00, Christopher Morrow wrote: On Wed, Feb 17, 2010 at 12:50 AM, Joe Abley jab...@hopcount.ca wrote: I am somewhat intrigued at this network you mention with which people have practical experience that has more nodes than the Internet does, though. That'd be quite a network. what's the current estimate on PSTN endpoints? 2-3B globally? True, I was thinking about packet-switched networks, since it always seems to me that a circuit-switched network is only as big at any time as the number of circuits that exist, not the number of possible termination points for circuits. Quite possibly I'm just smoking crack, however. Joe
Re: BIRD vs Quagga
On Wed, Feb 17, 2010 at 1:03 AM, Joe Abley jab...@hopcount.ca wrote: On 2010-02-16, at 22:00, Christopher Morrow wrote: On Wed, Feb 17, 2010 at 12:50 AM, Joe Abley jab...@hopcount.ca wrote: I am somewhat intrigued at this network you mention with which people have practical experience that has more nodes than the Internet does, though. That'd be quite a network. what's the current estimate on PSTN endpoints? 2-3B globally? True, I was thinking about packet-switched networks, since it always seems to me that a circuit-switched network is only as big at any time as the number of circuits that exist, I almost made a comment that the PSTN is really (as far as routing is concerned) lots of disparate networks with no 'global view' of the problem. It can be argued (and randy likely will, or bmanning even) that the Internet doesn't have a single view either... There's loop protection in the routing data, which the PSTN doesn't really have. (which is a side problem) not the number of possible termination points for circuits. Quite possibly I'm just smoking crack, however. doubtful... probably me missing a terminology collision :( It also depends on how Tomas was defining his problem. I still say the PSTN and Internet are apples/oranges in so many ways you can't use them in an comparision. -chris
Re: BIRD vs Quagga
On Tue, 2010-02-16 at 21:50 -0800, Joe Abley wrote: On 2010-02-16, at 19:53, Tomas L. Byrnes wrote: There's significant theoretical work, backed up with lots of practical experience connecting a lot more nodes in real time in a lot more places than the Internet currently does, that posits that the control and forwarding plane should actually ALWAYS be separate, and control higher priority, so that state management converges faster than the dataflows. I'd like to see the countervailing, peer reviewed, references. I have no shortage of anecdotes where a non-trivial layer-2 topology at an exchange point has left my router and provider X's router both able to talk to a route server, but unable to talk to each other directly. Since the NEXT_HOP on routes we each learnt from the route server pointed at an address we couldn't talk to, the result was a black hole. I have similar anecdotes... and I was on the side of running the route-servers. This gets to be a tough nut to crack especially if you happen to have multiple RSes on opposite ends of a layer2 failure (a case where intended redundancy resulted in unintended new failure modes). The best solution we came up with at the time was to add some control knobs to rsd in order to allow us to quickly take down the BGP session to the peer on the falsely advertising RS. Figuring out which third-party negotiated pairwise peering was being effected during a switch fabric breakage was done manually at the time and not all that accurate nor of course was it expedient. We attempted to automate that part without too much success. -- /*=[ Jake Khuon kh...@neebu.net ]=+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==*/
Re: BIRD vs Quagga
On Tue, 2010-02-16 at 23:03 -0800, Jake Khuon wrote: The best solution we came up with at the time was to add some control knobs to rsd in order to allow us to quickly take down the BGP session to the peer on the falsely advertising RS. Sorry... this was poorly worded. We did not actually tear down the BGP sessions. I should have placed quotes around BGP session. What we did was virtually nuked the view in the RS of the pairwise peering thus forcing a BGP withdrawal to the effected peers of the RS and hopefully leaving only valid third-party views intact. Again, the greatest problem was detection and modeling. -- /*=[ Jake Khuon kh...@neebu.net ]=+ | Packet Plumber, Network Engineers /| / [~ [~ |) | | | | for Effective Bandwidth Utilisation / |/ [_ [_ |) |_| NETWORKS | +==*/
Re: BIRD vs Quagga
On 13.02.2010 02:01 Nathan Ward wrote On 13/02/2010, at 11:51 AM, Steve Bertrand wrote: fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I haven't tried those either...zebra/Quagga just stuck. OpenBGPd would be great for a public route server at an IX. Be cautious when doing filtering. bgpctl will hang for minutes, even hours. Otherwise OpenBGPD seems to be very performant. Quagga does not really behave well with lots of peers (lots 200), but there will be an optimized route server version soon. BIRD seems to do fine. Best regards, Arnold -- Arnold Nipper / nIPper consulting, Sandhausen, Germany email: arn...@nipper.de phone: +49 6224 9259 299 mobile: +49 172 2650958 fax: +49 6224 9259 333 signature.asc Description: OpenPGP digital signature
BIRD vs Quagga
I was wondering what kind of experience the nanog userbase has had with these two packages. Thanks -- Jason Fried This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message. Any disclosure, copying, or distribution of this message, or the taking of any action based on it, is strictly prohibited. [v.E.1]
Re: BIRD vs Quagga
Fried, Jason (US - Hattiesburg) wrote: I was wondering what kind of experience the nanog userbase has had with these two packages. Quagga++. I've never tried the other. I use Quagga for OSPF, OSPFv3 and BGP (IPv4 and IPv6). With a bit of trickery, it fits in nicely with my RANCID setup, and what I like best is that it (mostly) follows Cisco's command convention. There are also very active developer and user mailing lists. For the most part, I wouldn't know if I was writing a config for a Cisco or for a Quagga box. fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I haven't tried those either...zebra/Quagga just stuck. Steve
Re: BIRD vs Quagga
http://www.uknof.org.uk/uknof15/ Has quite a few talk about Quagga/Bird as they are used as route servers in Europe. For a route server use, BGP under very high number of peers, it seems bird now behave better than anything else. so for normal use, it would seems that whatever you pick will work but quagga is surely the most deployed. Thomas On 12 Feb 2010, at 22:51, Steve Bertrand wrote: Fried, Jason (US - Hattiesburg) wrote: I was wondering what kind of experience the nanog userbase has had with these two packages. Quagga++. I've never tried the other. I use Quagga for OSPF, OSPFv3 and BGP (IPv4 and IPv6). With a bit of trickery, it fits in nicely with my RANCID setup, and what I like best is that it (mostly) follows Cisco's command convention. There are also very active developer and user mailing lists. For the most part, I wouldn't know if I was writing a config for a Cisco or for a Quagga box. fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I haven't tried those either...zebra/Quagga just stuck. Steve
Re: BIRD vs Quagga
On 13/02/2010, at 11:51 AM, Steve Bertrand wrote: fwiw, I've also heard good things about bgpd(8) and ospfd(8), but I haven't tried those either...zebra/Quagga just stuck. OpenBGPd would be great for a public route server at an IX. It's not so great for use in a network unless you run it on OpenBSD - FreeBSD has no metric attribute in it's routing tables, so next-hop IGP metric cannot be compared as the two daemons do not communicate directly at all. If you're on anything other than OpenBSD, I recommend Quagga. I can't comment on BIRD as I have no experience with it yet. XORP is also interesting, it's a more JunOS like interface. It's also some quite heavy C++, so running it on the tiny Soekris boxes that I had meant it wouldn't work for me. If you can spare the CPU and RAM then give XORP a go. -- Nathan Ward
