Re: BIRD vs Quagga

[Steve Bertrand]

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

[Thomas Mangin]

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

[Kevin Oberman]

There will be a presentation comparing BIRD with Quagga at NANOG week
after next in Austin. II believe it will be a part of the Route Servers
Track on Monday afternoon.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: ober...@es.net  Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

Re: BIRD vs Quagga

[Nathan Ward]

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

Re: BIRD vs Quagga

[Arnold Nipper]

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

Re: BIRD vs Quagga

[Thomas Mangin]

> 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

[Nick Hilliard]

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

[Matthew Palmer]

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

[Randy Bush]

> 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

[Tomas L. Byrnes]

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

[Randy Bush]

> 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

[Tomas L. Byrnes]

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

[Christopher Morrow]

On Tue, Feb 16, 2010 at 10:55 PM, Randy Bush  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

 decisions per second rate
 path information per 'call' or 'decision'

...these aren't like examples... (apples to oranges discussion, move
along, nothing to see here)

Re: BIRD vs Quagga

[Randy Bush]

http://archive.psg.com/080918.plnog-complex.pdf

Re: BIRD vs Quagga

[Joe Abley]

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

[Christopher Morrow]

On Wed, Feb 17, 2010 at 12:50 AM, Joe Abley  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:

thinks the ITU estimated ~33% of 1.4b devices were mobile phones (in 2002)


wikipedia thinks a total mobile phone market is ~4.1b phones with ~60%
global penetration.


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

[Joe Abley]

On 2010-02-16, at 22:00, Christopher Morrow wrote:

> On Wed, Feb 17, 2010 at 12:50 AM, Joe Abley  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

[Christopher Morrow]

On Wed, Feb 17, 2010 at 1:03 AM, Joe Abley  wrote:
>
> On 2010-02-16, at 22:00, Christopher Morrow wrote:
>
>> On Wed, Feb 17, 2010 at 12:50 AM, Joe Abley  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

[Jake Khuon]

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  ]=+
 | Packet Plumber, Network Engineers /| / [~ [~ |) | |  |
 | for Effective Bandwidth Utilisation  / |/  [_ [_ |) |_| NETWORKS |   
 +==*/

Re: BIRD vs Quagga

[Jake Khuon]

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  ]=+
 | Packet Plumber, Network Engineers /| / [~ [~ |) | |  |
 | for Effective Bandwidth Utilisation  / |/  [_ [_ |) |_| NETWORKS |   
 +==*/

Re: BIRD vs Quagga

[Thomas Mangin]

> 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

[Nick Hilliard]

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

[Andy Davidson]

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 revisited

[Andy Davidson]

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

[John Souter]

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

[Guillaume Barrot]

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 

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


-- 
Cordialement,

Guillaume BARROT

RE: Bird vs Quagga revisited

[David Hubbard]

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

[Andrew Latham]

On Wed, Aug 22, 2012 at 1:42 PM, David Hubbard
 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

[Arnold Nipper]

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

[Christian Esteve Rothenberg]

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

Re: Bird vs Quagga revisited

[Vlad Galu]

On Wednesday, August 22, 2012 at 11:38 AM, Andy Davidson wrote:

> 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.
> 
+1. FIB performance and RIB performance are two very different things, and the 
former depends on the OS. Besides (although I haven't checked this recently), 
Quagga still does not support multiple FIBs.
 
-- 
PacketDam: a cost-effective
software solution against DDoS

Re: Bird vs Quagga revisited

[Andy Davidson]

On 22 Aug 2012, at 18:42, David Hubbard  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

[Thomas Mangin]

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

> 
> On 22 Aug 2012, at 18:42, David Hubbard  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

[Ray Soucy]

Don't forget about XORP if you have any need for multicast routing ...

On Wed, Aug 22, 2012 at 1:19 AM, 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
> 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

[Christopher Morrow]

On Wed, Aug 22, 2012 at 1:42 PM, David Hubbard
 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

[David Lamparter]

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

[Seth Mattinen]

What's the state of MPLS on Linux these days?

~Seth

Re: Bird vs Quagga revisited

[Walter Keen]

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

[Edward J. Dore]

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" 
To: "Seth Mattinen" 
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"  
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

[Eduardo Schoedler]

MPLS and VPLS on RouterOS works very well.

--
Eduardo Schoedler


Em 29/08/2012, às 12:39, "Edward J. Dore" 
 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" 
> To: "Seth Mattinen" 
> 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"  
> 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

[Laurent GUERBY]

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" 
> To: "Seth Mattinen" 
> 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"  
> 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

[Dan Shechter]

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  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" 
> > To: "Seth Mattinen" 
> > 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" 
> > 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

[Eduardo Schoedler]

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 

> 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 
> 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" 
> > > To: "Seth Mattinen" 
> > > 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" 
> > > 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

[Edward Dore]

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" 
>> To: "Seth Mattinen" 
>> 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"  
>> 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

[Bjørn Mork]

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

[Bjørn Mork]

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

[Edward Dore]

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  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 (MP-BGP RR)

[Raymond Burkholder]

> 
> > 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 (MP-BGP RR)

[Thomas Mangin]

On 23 Aug 2012, at 15:04, Raymond Burkholder  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