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?
Edw
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
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
nux" 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"
&
ooked, 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
nal 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 base
t;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
t;
>
>
>
> - 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
>
>
>
t 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
PM
Subject: Re: Bird vs Quagga revisited
What's the state of MPLS on Linux these days?
~Seth
What's the state of MPLS on Linux these days?
~Seth
> > 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 int
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 ar
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
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
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 use
>
> > 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 duti
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
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 Op
> 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 Telecommunicatio
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.
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 ar
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 cou
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 ru
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
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/mee
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_fina
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
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 ro
> 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 w
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
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
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
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.
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 globa
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 actual
http://archive.psg.com/080918.plnog-complex.pdf
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
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 li
> 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
> 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
> 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 d
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...)
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 dem
> 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 pr
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 ca
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
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 L
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 wo
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
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 re
51 matches
Mail list logo
