RE: New release 1.3.0!
Hi Ondrej,
Thank you for your time considering this, it is greatly appreciated.
I understand how this works, very clever. This is indeed quite an inventive
hack :)
I will have a play and see if we can get it to work.
Our edge firewalls actually advertise around 80 RIP routes at the moment (we
have an awful lot of VPNs here in the head office) and so this would be a lot
to program but not unfeasible.
The limitation is that approximately once a month we have to add more VPNs as
we take on more remote locations and so I would need to continually update the
BIRD configuration every time we add more VPNs to gain multipath access for the
newly added tunnels etc.
I will definitely let you know how we get on. Please, please do consider
rewriting RIP with emcp. We would be in your debt and after all, whilst RIP is
archaic (I wish we could use a newer protocol) it is still the most widely used
routing protocol in SMB network devices. Obviously high end devices from Cisco,
Juniper etc support OSPF but Netgear, Draytek, Firebox etc etc only support RIP.
I would love to install some Cisco VPN concentrators however we like many other
SMB companies simply do not have the in-house skills to manage these properly,
and so we are forced to use basic kit which I can train others (non-networking
staff) to program/manage in my absence.
Thanks again for your time and kind help.
Andy.
-Original Message-
From: Ondrej Zajicek [mailto:santi...@crfreenet.org]
Sent: 31 March 2011 15:42
To: Andrew Lemin
Cc: Tony Vroon; Ondrej Filip; bird-us...@network.cz
Subject: Re: New release 1.3.0!
On Thu, Mar 31, 2011 at 11:09:54AM +0100, Andrew Lemin wrote:
>Great work to all involved J
>
>We have looked through the notes in the git repository etc however we are
>still confused as to whether multi-path support can be 'made to work' with
>RIP or not?
No, sorry. Current RIP was not ready for simple integrating multipath like in
OSPF. I will probaly rewrite it in a near future.
I thought about your case and i found a crazy hack, that should bring multipath
routes to your particular case (two RIP neighbors with a fixed number of
routes, just import from RIP):
table tn;
table te;
table t1;
table t2;
protocol static st_null
{
table tn;
export all;
preference 80; # lower than RIP
route 10.131.0.0/16 reject;
... (other routes)
}
protocol static st_ecmp
{
table te;
export all;
route 10.131.0.0/16 multipath via 192.168.214.1 via 192.168.215.1;
... (other routes)
}
protocol rip EDGE1RIP
{
table t1;
... (like in your config)
}
protocol rip EDGE2RIP
{
table t2;
... (like in your config)
}
protocol pipe pn1
{
table tn;
peer table t1;
export all;
import none;
}
protocol pipe pr1
{
table t1;
peer table master;
export where proto = "EDGE1RIP";
import none;
}
protocol pipe pg1
{
table t1;
peer table te;
mode opaque; # this is important
preference 300; # higher than static
export where proto = "st_null";
import none;
}
protocol pipe pn2
{
table tn;
peer table t2;
export all;
import none;
}
protocol pipe pr2
{
table t2;
peer table master;
export where proto = "EDGE2RIP";
import none;
}
protocol pipe pg2
{
table t2;
peer table te;
mode opaque; # this is important
preference 300; # higher than static
export where proto = "st_null";
import none;
}
protocol pipe pe
{
table te;
peer table master;
mode opaque; # this is important
preference 150; # higher than RIP
export where proto = "st_ecmp";
import none;
}
The idea is simple:
routes from RIP1 came to t1 together with reject route from st_null (through
pn1). if route from RIP1 exists, it will be preferred, because it has higher
priority than route from st_null. Pipe pg1 would push preferred route (opaque
pipe push just a preferred route) from t1 to te, but only if it is from st_null
(filter). If the preferred route is RIP1, nothing is pushed. such route in
table te would block ecmp route to be propagated to master (beacuse it has
higher priority, 300). So if there are routes from both RIPs, nothing is
propagated to table te and ecmp route will win. RIP routes are already pushed
to master through pr1, pr2.
So to use this, for each prefix from RIP you have to configuure one
(reject) static route in st_null and one ECMP route in st_ecmp.
You should see something like:
10.131.0.0/16 multipath [pe 16:35] * (150)
via 78.128.195.198 on eth0 weight 1
via 78.128.195.199 on eth0 weight 1
via 78.128.195.198 on eth0 [EDGE1RIP 16:35] (120)
RE: New release 1.3.0!
Great work to all involved :)
We have looked through the notes in the git repository etc however we are still
confused as to whether multi-path support can be 'made to work' with RIP or not?
Currently our BIRD configuration defines a unique RIP protocol instance on each
of our Linux routers edge interfaces to listen for RIP messages from our edge
firewalls (which host and advertise many IPSec VPN routes via RIP);
This means that birds internal route table contains many multipath routes.
bird> show route
10.131.0.0/16 via 192.168.214.1 on eth2 [EDGE1RIP 11:07] * (120/4)
via 192.168.215.1 on eth3 [EDGE2RIP 11:07] (120/4)
10.0.0.0/24via 192.168.214.1 on eth2 [EDGE1RIP 11:07] * (120/4)
10.1.20.0/24 via 192.168.214.1 on eth2 [EDGE1RIP 11:07] * (120/4)
via 192.168.215.1 on eth3 [EDGE2RIP 11:07] (120/4)
192.168.64.0/24via 192.168.215.1 on eth3 [EDGE2RIP 11:07] * (120/4)
via 192.168.214.1 on eth2 [EDGE1RIP 11:07] (120/4)
192.168.65.0/24via 192.168.215.1 on eth3 [EDGE2RIP 11:07] * (120/4)
via 192.168.214.1 on eth2 [EDGE1RIP 11:07] (120/4)
10.10.0.0/24 via 192.168.214.1 on eth2 [EDGE1RIP 11:07] * (120/4)
192.168.68.0/24via 192.168.215.1 on eth3 [EDGE2RIP 11:07] * (120/4)
via 192.168.214.1 on eth2 [EDGE1RIP 11:07] (120/4)
In version 1.3.0, will these multipath routes that we have in our bird routing
table now be exported to the kernel routing table? Please, please say yes :o/
Thank you for your help. Andy.
# cat /etc/bird.conf
#log syslog { error, fatal, bug };
protocol kernel { # Protocol pipe to kernel table
learn; # Learn static routes in main kernel table
scan time 10; # Scan kernel routing table every 20 seconds
import none; # Do Not import main kernel routing table into BIRD table
export filter {if net ~ [10.0.0.0/8+, 172.16.0.0/12+, 192.168.0.0/16+]
then { accept; } reject; };
}
protocol device { # Protocol pipe to network interfaces table
scan time 10; # Scan interfaces every 10 seconds
}
protocol rip EDGE2RIP { # Create RIP protocol instance called EDGE2RIP
timeout time 65; # specifies how old route has to be to be considered
unreachable. Default is 4*period (period default is 30)
garbage time 70; # specifies how old route has to be to be discarded.
Default is 10*period (period default is 30)
honor always;
export none;# Do not transmit BIRD table to RIP peers
import filter {if net ~ [10.0.0.0/8+, 172.16.0.0/12+, 192.168.0.0/16+]
then { accept; } reject; };
interface "eth3" { mode quiet; };
}
protocol rip EDGE1RIP { # Create RIP protocol instance called EDGE1RIP
timeout time 65; # specifies how old route has to be to be considered
unreachable. Default is 4*period (period default is 30)
garbage time 70; # specifies how old route has to be to be discarded.
Default is 10*period (period default is 30)
honor always;
export none;# Do not transmit BIRD table to RIP peers
import filter {if net ~ [10.0.0.0/8+, 172.16.0.0/12+, 192.168.0.0/16+]
then { accept; } reject; };
interface "eth2" { mode quiet; };
}
-Original Message-
From: owner-bird-us...@atrey.karlin.mff.cuni.cz
[mailto:owner-bird-us...@atrey.karlin.mff.cuni.cz] On Behalf Of Tony Vroon
Sent: 31 March 2011 10:53
To: Ondrej Filip
Cc: bird-us...@network.cz
Subject: Re: New release 1.3.0!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/31/11 10:27, Ondrej Filip wrote:
> New version is ready. This version includes many changes and bugfixes.
> We are working on packaging and other stuff.
In Gentoo now, thank you:
http://cia.vc/stats/author/chainsaw/.message/1e3992
My apologies for missing 1.2.5; it wasn't planned for production use in LINX.
Regards,
- --
Tony Vroon
UNIX systems administrator
London Internet Exchange Ltd, Trinity Court, Trinity Street, Peterborough, PE1
1DA Registered in England number 3137929
E-Mail: t...@linx.net
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk2UTuIACgkQp5vW4rUFj5qYpQCdF8i5lL+RTnOl9vp2oefIeWzn
bTYAniGuKTswJf0wnbJG58BA5VNMrWIz
=4zi0
-END PGP SIGNATURE-
Monitor Computer Systems Limited
Company Registration Number: NI 17805
Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
Next Release
Hi all, When is the next release of BIRD planned? We are desperately keen to test the multipath RIP routes functionality. :) Cheers, Andy. Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: ECMP/multipath support
Ah ok I understand. At least this is a good thing anyway as all the other protocols are decoupled from the core bird routing table, and so doing this work should only lead to a more stable system overall? PS; I agree that a community area for guides/manuals/configurations is a great idea :) -Original Message- From: Ondrej Zajicek [mailto:santi...@crfreenet.org] Sent: 15 December 2010 23:02 To: Andrew Lemin Cc: Vincent Bernat; bird-us...@trubka.network.cz Subject: Re: ECMP/multipath support On Wed, Dec 15, 2010 at 11:53:50AM +, Andrew Lemin wrote: > Wow, great news. > What has been the challenge with adding ECMP support in the RIP protocol? The problem is that RIP implementation currently maintains most of its state using the core routing table and it is closely tied with its routes in that table. Adding multipath routes would require some decoupling. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: ECMP/multipath support
Wow, great news. What has been the challenge with adding ECMP support in the RIP protocol? I understand you are making the changes on the protocols seeing as the bird table already supports multipath routes. Is there anything we could do to help to get the ECMP RIP working? Thank you for your time and hard work. Regards, Andy. -Original Message- From: Ondrej Zajicek [mailto:santi...@crfreenet.org] Sent: 15 December 2010 11:38 To: Andrew Lemin Cc: Vincent Bernat; bird-us...@trubka.network.cz Subject: Re: ECMP/multipath support On Wed, Dec 15, 2010 at 10:03:08AM +, Andrew Lemin wrote: > Hello. > > How is development coming along for adding multi-path route support into BIRD? We already have BIRD multipath support for OSPF, static and Linux kernel protocols in our Git repository [*]. RIP will probably come soon, although it is a bit tricky. [*] git://git.nic.cz/bird.git -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: ECMP/multipath support
Hello. How is development coming along for adding multi-path route support into BIRD? Please let me know if there is anything we can do to help or test ECMP in RIP as this is something we sorely need. Cheers, Andy. -Original Message- From: owner-bird-us...@atrey.karlin.mff.cuni.cz [mailto:owner-bird-us...@atrey.karlin.mff.cuni.cz] On Behalf Of Andrew Lemin Sent: 13 November 2010 20:22 To: Ondrej Zajicek Cc: Vincent Bernat; bird-us...@trubka.network.cz Subject: RE: ECMP/multipath support Hi Ondrej, That really is wonderful news. Thank you very much :) Please let me know if there is anything I can do to help. Regards, Andy. -Original Message- From: owner-bird-us...@atrey.karlin.mff.cuni.cz [mailto:owner-bird-us...@atrey.karlin.mff.cuni.cz] On Behalf Of Ondrej Zajicek Sent: 13 November 2010 00:21 To: Andrew Lemin Cc: Vincent Bernat; bird-us...@trubka.network.cz Subject: Re: ECMP/multipath support On Thu, Nov 11, 2010 at 10:38:55AM +, Andrew Lemin wrote: > Hi all, > > What does the BIRD dev team think? Is there anything more I can do to help > with adding this functionality. Hello, currently i am finalizing link state detection for OSPF. After that i would probably look at ECMP. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: ECMP/multipath support
Hi Ondrej, That really is wonderful news. Thank you very much :) Please let me know if there is anything I can do to help. Regards, Andy. -Original Message- From: owner-bird-us...@atrey.karlin.mff.cuni.cz [mailto:owner-bird-us...@atrey.karlin.mff.cuni.cz] On Behalf Of Ondrej Zajicek Sent: 13 November 2010 00:21 To: Andrew Lemin Cc: Vincent Bernat; bird-us...@trubka.network.cz Subject: Re: ECMP/multipath support On Thu, Nov 11, 2010 at 10:38:55AM +, Andrew Lemin wrote: > Hi all, > > What does the BIRD dev team think? Is there anything more I can do to help > with adding this functionality. Hello, currently i am finalizing link state detection for OSPF. After that i would probably look at ECMP. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: ECMP/multipath support
Hi all, I think all parties on the mailing list came to the conclusion that multipath support would be best implemented in the individual routing protocols instead of just in the kernel protocol. What does the BIRD dev team think? Is there anything more I can do to help with adding this functionality. We desperately need ECMP support in the RIP protocol. Thanks everyone :) Regards, Andy. -Original Message- From: Andrew Lemin Sent: 04 October 2010 16:55 To: 'Vincent Bernat'; Ondrej Zajicek Cc: bird-us...@trubka.network.cz Subject: RE: ECMP/multipath support Hi, >> I see two possibilities how to implement ECMP in BIRD: >> 1) adding special route type for a multipath route with multiple >> gw addresses. This wouldn't be hard, it is consistent with a way >> how Linux kernel handles multipath and works well with OSPF, but >> it will not allow to 'merge' routes from different protocols >> (a multipath route would have to be originated by one protocol). >I don't see this as a limitation. To the best of my knowledge, each >protocol having a different administrative distance, this is also how it >works with other routing solutions. A route from BGP and a route from >OSPF cannot be combined into a single ECMP route. I agree. I didn't want to get into the conversation because I know you guys are fully aware of all this. As you say, it is not really appropriate for routes provided by different routing protocols to have the same weight. It could be suggested that each protocol implementation could have a weight associated with it that is a function of the protocols administrative distance etc. >> 2) allow BIRD kernel protocol to scan all equal-best routes to >> one destination and 'merge' these to a multipath route for kernel. >> This would be harder to implement, esp. because BIRD would not >> allow more routes to the same destination from one protocol in >> one routing table. But it is probably more natural way for a user. >I don't know any use case for this. As long as multipath is implemented in the RIP protocol too, then go for the first method as it is the proper place for it. We NEED ECMP in RIP though. Please.. :) The point I was trying to make is by adding the functionality to the kernel protocol you only have to update one segment of code instead of having to update all the protocols. The vast majority of SMB firewalls and VPN concentrators etc only support RIP, hence our position.. >> What protocols are you thinking about with regard to ECMP? >> ECMP in OSPF would work OK, ECMP in BGP probably would not work either, >> i am not sure about RIP. >We use ECMP with OSPF here. Unlike Andrew, both routes are strictly the >same. We use this as layer 3 redundancy and aggregation. Aggregation is >pretty important too. With two routers, aggregation allows to handle >temporary bursts of traffic. You cannot rely on aggregation to handle >permanently more traffic because if one of them fails, you cannot handle >your original traffic. There is also the use case of three or more >routers. You can allow one to fail but you still need the traffic to be >load balanced on the two remaining ones. Agree :) >I have some knowledge on how ECMP routes work with netlink interface and >can offer to try to implement this in BIRD if we agree on what is the >best place to implement this. However, I have no knowledge on BIRD >internals and on how ECMP work with OS other than Linux. I am also happy to offer whatever I can to add multipath to BIRD. Thanks for all your thoughts and time. Cheers, Andy. Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: ECMP/multipath support
Hi, >> I see two possibilities how to implement ECMP in BIRD: >> 1) adding special route type for a multipath route with multiple >> gw addresses. This wouldn't be hard, it is consistent with a way >> how Linux kernel handles multipath and works well with OSPF, but >> it will not allow to 'merge' routes from different protocols >> (a multipath route would have to be originated by one protocol). >I don't see this as a limitation. To the best of my knowledge, each >protocol having a different administrative distance, this is also how it >works with other routing solutions. A route from BGP and a route from >OSPF cannot be combined into a single ECMP route. I agree. I didn't want to get into the conversation because I know you guys are fully aware of all this. As you say, it is not really appropriate for routes provided by different routing protocols to have the same weight. It could be suggested that each protocol implementation could have a weight associated with it that is a function of the protocols administrative distance etc. >> 2) allow BIRD kernel protocol to scan all equal-best routes to >> one destination and 'merge' these to a multipath route for kernel. >> This would be harder to implement, esp. because BIRD would not >> allow more routes to the same destination from one protocol in >> one routing table. But it is probably more natural way for a user. >I don't know any use case for this. As long as multipath is implemented in the RIP protocol too, then go for the first method as it is the proper place for it. We NEED ECMP in RIP though. Please.. :) The point I was trying to make is by adding the functionality to the kernel protocol you only have to update one segment of code instead of having to update all the protocols. The vast majority of SMB firewalls and VPN concentrators etc only support RIP, hence our position.. >> What protocols are you thinking about with regard to ECMP? >> ECMP in OSPF would work OK, ECMP in BGP probably would not work either, >> i am not sure about RIP. >We use ECMP with OSPF here. Unlike Andrew, both routes are strictly the >same. We use this as layer 3 redundancy and aggregation. Aggregation is >pretty important too. With two routers, aggregation allows to handle >temporary bursts of traffic. You cannot rely on aggregation to handle >permanently more traffic because if one of them fails, you cannot handle >your original traffic. There is also the use case of three or more >routers. You can allow one to fail but you still need the traffic to be >load balanced on the two remaining ones. Agree :) >I have some knowledge on how ECMP routes work with netlink interface and >can offer to try to implement this in BIRD if we agree on what is the >best place to implement this. However, I have no knowledge on BIRD >internals and on how ECMP work with OS other than Linux. I am also happy to offer whatever I can to add multipath to BIRD. Thanks for all your thoughts and time. Cheers, Andy. Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: ECMP/multipath support
Hi Martin, Yes you are quite right, we are aware that for it to work we need links of roughly equal latency and bandwidth etc, which they are. I.e. both slow and not much.. ;) Cheers, Andy. -Original Message- From: Martin Mares [mailto:m...@ucw.cz] Sent: 01 October 2010 16:15 To: Andrew Lemin Cc: Ondrej Zajicek; Vincent Bernat; bird-us...@trubka.network.cz Subject: Re: ECMP/multipath support Hello! > For us ECMP is important as we load balance connections to remote customer > sites across different ISPs for redundancy and performance. When doing that, please keep in mind that whenever the characteristics (delay and throughput) of the lines are different, TCP congestion control algorithms tend to fail miserably. This greatly limits the usefulness of any multipath routing. Have a nice fortnight -- Martin `MJ' Mares http://mj.ucw.cz/ Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth Even nostalgia isn't what it used to be. Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: ECMP/multipath support
Hi Ondrej, Thanks for your quick response. For us ECMP is important as we load balance connections to remote customer sites across different ISPs for redundancy and performance. In many parts of the world, including here, cheap high speed WAN connections are simply not available and so we have to aggregate the bandwidth of many small links to achieve the overall required capacities etc. Each of our edge firewalls, each hosting unique VPNs to all our customers, advertise their available VPNs to our core router performing multipath and running BIRD. We would not mind if ECMP routes were restricted to a single protocol type (as in my previous example you can see we run two RIP instances, one on each outside interface), however I do believe that for a complete solution ECMP should be supported for all routes regardless of source. > 1) adding special route type for a multipath route with multiple gw > addresses. This wouldn't be hard, it is consistent with a way how Linux > kernel >handles multipath and works well with OSPF, but it will not allow > to 'merge' routes from different protocols (a multipath route would have to > be originated by one protocol). This sounds simpler to implement, but will probably be far too restrictive. > 2) allow BIRD kernel protocol to scan all equal-best routes to one > destination and 'merge' these to a multipath route for kernel. > This would be harder to implement, esp. because BIRD would not allow > more routes to the same destination from one protocol in one routing table. > But it is probably more natural way for a user. This is a much better solution :) I am aware of the limitation that BIRD does not allow more routes to the same destination from one protocol 'instance' in one routing table, and it is for this reason that we run two instances of RIP on different interfaces instead of one instance on all outbound interfaces. If you had two nexthop gateways on a common interface could you not just run two protocol instances each set to only listen for routes from each of the IP's of each nexthop gateway? We are restricted to using RIP due to our edge firewalls being Draytek devices. With the exception of high end firewalls, most SMB firewall devices only support RIP. Thanks for your time. Regards, Andy. -Original Message- From: Ondrej Zajicek [mailto:santi...@crfreenet.org] Sent: 01 October 2010 13:19 To: Andrew Lemin Cc: Vincent Bernat; bird-us...@trubka.network.cz Subject: Re: ECMP/multipath support On Fri, Oct 01, 2010 at 10:40:58AM +0100, Andrew Lemin wrote: >Hi Vincent, > >This is something that we have also been after for some time too, and I >know that Securepoint (a company who implement BIRD in their >firewall/router product have also approached the bird team about), however >there does not seem to be any resources available in the BIRD team at the >moment willing to look into this despite how important it is. Is ECMP really much important? It seems to me that it is useful only in limited number of cases (like having two parallel lines with similar capacities in a network). I would expect that redundancy is usually solved by having generally denser network graph (where ECMP is more likey a random coincidence). But it seems that it is also a feature that is most often asked for. I see two possibilities how to implement ECMP in BIRD: 1) adding special route type for a multipath route with multiple gw addresses. This wouldn't be hard, it is consistent with a way how Linux kernel handles multipath and works well with OSPF, but it will not allow to 'merge' routes from different protocols (a multipath route would have to be originated by one protocol). 2) allow BIRD kernel protocol to scan all equal-best routes to one destination and 'merge' these to a multipath route for kernel. This would be harder to implement, esp. because BIRD would not allow more routes to the same destination from one protocol in one routing table. But it is probably more natural way for a user. What protocols are you thinking about with regard to ECMP? ECMP in OSPF would work OK, ECMP in BGP probably would not work either, i am not sure about RIP. -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so." Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: ECMP/multipath support
Hi Vincent,
This is something that we have also been after for some time too, and I know
that Securepoint (a company who implement BIRD in their firewall/router product
have also approached the bird team about), however there does not seem to be
any resources available in the BIRD team at the moment willing to look into
this despite how important it is.
Internally BIRD does support the ability to hold multiple routes for a single
common remote subnet in its routing tables.
I do not believe a single instance of a Dynamic Routing 'Protocol' can insert
multiple routes into the BIRD's routing tables, but multiple Protocol instances
can.
A simple example 'bird.conf' with two RIP Protocol instances listening on
different interfaces;
protocol rip EDGE2RIP { # Create RIP protocol instance called EDGE2RIP
debug all;
timeout time 65; # specifies how old route has to be to be considered
unreachable. Default is 4*period (period default is 30)
garbage time 70; # specifies how old route has to be to be discarded.
Default is 10*period (period default is 30)
export none;# Do not transmit BIRD table to RIP peers
import all; # Listen to RIP info from RIP peers and store in BIRD
table
interface "eth3";
}
protocol rip EDGE1RIP { # Create RIP protocol instance called EDGE1RIP
debug all;
timeout time 65; # specifies how old route has to be to be considered
unreachable. Default is 4*period (period default is 30)
garbage time 70; # specifies how old route has to be to be discarded.
Default is 10*period (period default is 30)
export none;# Do not transmit BIRD table to RIP peers
import all; # Listen to RIP info from RIP peers and store in BIRD
table
interface "eth2";
}
bird> show route
192.168.100.0/24 via 192.168.214.1 on eth2 [EDGE1RIP 09:57] * (120/4)
via 192.168.215.1 on eth3 [EDGE2RIP 09:57] (120/4)
10.131.0.0/16 via 192.168.214.1 on eth2 [EDGE1RIP 09:57] * (120/4)
via 192.168.215.1 on eth3 [EDGE2RIP 09:57] (120/4)
10.0.0.0/24via 192.168.215.1 on eth3 [EDGE2RIP 09:57] * (120/4)
via 192.168.214.1 on eth2 [EDGE1RIP 09:57] (120/4)
10.1.20.0/24 via 192.168.214.1 on eth2 [EDGE1RIP 09:57] * (120/4)
via 192.168.215.1 on eth3 [EDGE2RIP 09:57] (120/4)
10.1.19.0/24 via 192.168.214.1 on eth2 [EDGE1RIP 09:57] * (120/4)
via 192.168.215.1 on eth3 [EDGE2RIP 09:57] (120/4)
10.10.0.0/24 via 192.168.214.1 on eth2 [EDGE1RIP 09:57] * (120/4)
via 192.168.215.1 on eth3 [EDGE2RIP 09:57] (120/4)
192.168.68.0/24via 192.168.214.1 on eth2 [EDGE1RIP 09:57] * (120/4)
via 192.168.215.1 on eth3 [EDGE2RIP 09:57] (120/4)
You can see above that the internal routing table is capable of holding the
routes.
The problem is with the process (BIRD's Kernel Protocol) which exports these
routes into the Kernel routing tables.
To add an ECMP route using the 'ip' command set provided by the kernel package
iproute2 requires all the route options to be defined in a single statement.
For example to export the first ECMP route shown in the example above requires
the following statement;
ip route add 192.168.100.0/24 nexthop via 192.168.214.1 weight 1 nexthop via
192.168.215.1 weight 1
However the Kernel Protocol is currently not capable of scanning the BIRD
routing table for all route 'options' and forming a single statement, instead
the 'Kernel Protocol' just recursively works its way through the BIRD routing
table exporting each entry in single statements. E.g;
ip route add 192.168.100.0/24 via 192.168.214.1
ip route add 192.168.100.0/24 via 192.168.215.1
.
The first command will work fine. But the second command will NOT work and will
be rejected (with error; 'RTNETLINK answers: File exists') resulting in only a
single route in the kernel routing tables for 192.168.100.0/24 via
192.168.214.1 in my example.
The solution could be provided in two places.
1) Support could be added in iproute2 for the 'ip route add' command to update
the existing route into an ECMP route if a second route add statement is
provided for an existing subnet etc.
2) Or support could be added in BIRD for the 'Kernel Protocol' to scan the
BIRD routing tables for all the route 'options' and form a single 'ip route add
.. nexthop' statement etc.
I believe support needs to be added to BIRD's 'Kernel Protocol' to scan BIRD's
internal routing table for all route options.
Hope this helps provide some insight.
Regards, Andy.
-Original Message-
From: owner-bird-us...@atrey.karlin.mff.cuni.cz
[mailto:owner-bird-us...@atrey.karlin.mff.cuni.cz] On Behalf Of Vincent Bernat
Sent: 24 September 2010 10:41
To: bird-us...@trubka.network.cz
Subject: ECMP/multipath support
Hi!
BIRD does not support EMC
RE: OSPF performance/SPF calculations
Hello. Yes it quite possible that bird does use netlink directly. Regardless I think the issue is still related to the fact that a multipath route needs to be added with a single statement and not by adding separate single route statements. Regarding the error. I cannot say why it is not there, it is not a problem however. I am not a developer. Thanks again. Andy. -Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: 26 April 2010 13:32 To: Andrew Lemin Cc: bird-us...@trubka.network.cz; Ondrej Zajicek Subject: RE: OSPF performance/SPF calculations Andrew Lemin wrote on 2010/04/26 12:14:52: > > Hello. > Yes, I believe the changes should not be that difficult. > > For example, by simply creating two separate 'RIP protocol' instances which > listen on different external interfaces, I can get bird's internal core > routing table to show all the multiple routing 'options' for common remote > subnets etc. > > I imagine the initial fix would be quite simple as it appears to just require > a change to the 'kernel protocol' export filter; > Instead of updating the kernel routing table by iteratively running individual > 'ip route add ' commands for each of the bird route table entries, the > kernel protocol filter should read each route entry from its bird routing > table, then search for any other matching routes before finally running a > single 'ip route add nexthop ' command which includes each of the > routeing options. BIRD is using "ip route" to configure routes? I figured BIRD used netlink directly. > > Extract of 'ip route' from our Securepoint firewall; > # ip route > . > . > . > 192.168.230.0/24 via 192.168.214.1 dev eth2 proto bird > 192.168.35.0/24 via 192.168.214.1 dev eth2 proto bird > 192.168.32.0/24 via 192.168.215.1 dev eth3 proto bird > 10.44.50.0/24 via 192.168.215.1 dev eth3 proto bird > 10.44.51.0/24 via 192.168.215.1 dev eth3 proto bird > 192.168.55.0/24 via 192.168.214.1 dev eth2 proto bird > 10.46.55.0/24 via 192.168.214.1 dev eth2 proto bird > 192.168.56.0/24 via 192.168.215.1 dev eth3 proto bird > 62.6.40.0/24 via 192.168.214.1 dev eth2 > 10.36.20.0/23 via 192.168.215.1 dev eth3 proto bird > 192.168.48.0/22 via 192.168.175.2 dev eth1 > default > nexthop via 192.168.214.1 dev eth2 weight 1 > nexthop via 192.168.215.1 dev eth3 weight 2 > # > > causes the following error; > KRT: Mysterious route with no OIF (0.0.0.0/0) I can't even find that error msg in BIRD sources. Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: OSPF performance/SPF calculations
Hello. Yes, I believe the changes should not be that difficult. For example, by simply creating two separate 'RIP protocol' instances which listen on different external interfaces, I can get bird's internal core routing table to show all the multiple routing 'options' for common remote subnets etc. I imagine the initial fix would be quite simple as it appears to just require a change to the 'kernel protocol' export filter; Instead of updating the kernel routing table by iteratively running individual 'ip route add ' commands for each of the bird route table entries, the kernel protocol filter should read each route entry from its bird routing table, then search for any other matching routes before finally running a single 'ip route add nexthop ' command which includes each of the routeing options. Also the kernel option to enable multipath should be checked. If not enabled then no change. E.g; #birdc bird>show routing 192.168.230.0/24 via 192.168.214.1 on eth2 [EDGE1RIP 11:47] (120/4) via 192.168.215.1 on eth3 [EDGE2RIP 11:47] (120/4) Both of these two route options can be added to a multipath enabled kernel with; '# ip route add 192.168.230.0/24 nexthop via 192.168.214.1 dev eth2 weight 1 nexthop via 192.168.215.1 dev eth3 weight 1'. There is also a minor bug that I believe needs looking at and is probably associated with this subject; A kernel routing table with a multipath default route causes errors in bird. Extract of 'ip route' from our Securepoint firewall; # ip route . . . 192.168.230.0/24 via 192.168.214.1 dev eth2 proto bird 192.168.35.0/24 via 192.168.214.1 dev eth2 proto bird 192.168.32.0/24 via 192.168.215.1 dev eth3 proto bird 10.44.50.0/24 via 192.168.215.1 dev eth3 proto bird 10.44.51.0/24 via 192.168.215.1 dev eth3 proto bird 192.168.55.0/24 via 192.168.214.1 dev eth2 proto bird 10.46.55.0/24 via 192.168.214.1 dev eth2 proto bird 192.168.56.0/24 via 192.168.215.1 dev eth3 proto bird 62.6.40.0/24 via 192.168.214.1 dev eth2 10.36.20.0/23 via 192.168.215.1 dev eth3 proto bird 192.168.48.0/22 via 192.168.175.2 dev eth1 default nexthop via 192.168.214.1 dev eth2 weight 1 nexthop via 192.168.215.1 dev eth3 weight 2 # causes the following error; KRT: Mysterious route with no OIF (0.0.0.0/0) I believe that Securepoint themselves have also indicated a commercial interest in contributing to the development of multipath support in BIRD. Thanks for your time. Andy. -Original Message- From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se] Sent: 26 April 2010 09:50 To: Andrew Lemin Cc: bird-us...@trubka.network.cz; Ondrej Zajicek Subject: RE: OSPF performance/SPF calculations Andrew Lemin wrote on 2010/04/26 10:46:36: > > Hello. > There are users out there who do desperately want multipath routing support > in Bird. > Please don't just ignore the need for multipath. The SPF work to support that should not be very hard I think, but I have no idea what other parts that need work too. Jocke Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: OSPF performance/SPF calculations
Hello. There are users out there who do desperately want multipath routing support in Bird. Please don't just ignore the need for multipath. Regards, Andy. Securepoint user. -Original Message- From: owner-bird-us...@atrey.karlin.mff.cuni.cz [mailto:owner-bird-us...@atrey.karlin.mff.cuni.cz] On Behalf Of Joakim Tjernlund Sent: 26 April 2010 00:05 To: Ondrej Zajicek Cc: bird-us...@trubka.network.cz Subject: Re: OSPF performance/SPF calculations Ondrej Zajicek wrote on 2010/04/25 23:20:33: > > On Sun, Apr 25, 2010 at 06:08:04PM +0200, Joakim Tjernlund wrote: > > > This is not a problem because both SPF and calc_next_hop() chooses the > > > cheapest (full) ptp link. They both uses the same (local) metrics. > > > > Our ptp links typically have the same cost between the same two routers so > > it is not unlikely that the link will be asymentric I think. However I > > don't think that will be a problem anymore as BIRD don't use/support > > equal cost multipath, right? > > Yes. > > > Right, how about these statements from RFC 2328: > ... > > These talk about inheriting ALL next hops from the parent and I don't > > see the BIRD does that. Looks like BIRD just selects one next hop > > from its parent? > > Assuming it is, does that impose any restricts? > > Yes, BIRD chooses one next hop. Because BIRD does not implement equal > cost multipath, this is not a problem. > > > Some other random questions: > > > > One think I always wanted is the possibility to add an host IP address to > > all areas, in my case I like to export the routers primary IP address > > to all areas so the router can always be reached. Is that possible with > > BIRD? > > You can use 'stubnet' option to add 'virtual' stub network (in that case > /32 stub) to the router-LSA. You can add this option to each area > config to get this in each area. That sounds exactly as what I need, thanks. > > Or add /32 stub network to one area, other areas get a summary-LSA > with that address. > > > If you pull the cable to an ethernet I/F that is currently in a OSPF > > domain, do BIRD delete the whole subnet from the R-LSA or do you > > leave a host route with the I/F's IP address in the R-LSA? > > BIRD does not use link availability information, therefore if you pull > the cable, BIRD keeps the whole subnet in the router-LSA (if it is > a stub network). If you do(any plans?), my vote is to leave a host stub in the R-LSA as it may very well be possible to reach that IP address over another link. Jocke Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
RE: another bug: system time change
Hello, This is my first time so sorry if I have not done this right. I have seen this problem before. I have seen this in Linux when the BIOS synchronises its time with the OS. The Linux OS could have been fine and have had a valid NTP source, but periodically there is some form of synchronisation that occurs between the BIOS and the OS and weird things can happen. This is probably nothing to do with bird. PS; A Virtual BIOS does exactly the same thing. Ie. the real BIOS time gets synchronised with all the Virtual BIOS clocks (one for each VM), which each in turn synchronise with their respective guest. Check all your BIOS times (physical BIOS and virtual Guest BIOS'). Hope this helps. Andy. -Original Message- From: owner-bird-us...@atrey.karlin.mff.cuni.cz [mailto:owner-bird-us...@atrey.karlin.mff.cuni.cz] On Behalf Of Wolfgang Hennerbichler Sent: 09 April 2010 09:49 To: Ondrej Zajicek Cc: Bird Users Subject: Re: another bug: system time change On Apr 9, 2010, at 10:49 , Ondrej Zajicek wrote: > On Fri, Apr 09, 2010 at 10:22:05AM +0200, Wolfgang Hennerbichler wrote: >> Hi Ondrejs, >> >> I think I found another bug. For some mysterious reason our system time >> jumped forward (more than 30.000 seconds) on one of our route-servers. I >> don't know why this happened, but I suspect a broken ntp server could have >> caused this. Nevetheless, this was reason enough for BIRD to drop the BGP >> peerings: >> > >> You see the log-entries from the wtachdog, which is run every minute, >> all of a sudden the time jumps to 10:08 UTC, and BIRD brings down BGP >> sessions. Are the session hold timers dependent on the system time? > > That is really strange. On Linux 2.6, we use monotonic timers, which > shouldn't be affected by system time change. If monotonic timers are not > available (on Linux 2.4), we use system time but we detect time jumps > and ignore them. Hm. Now this is strange indeed. I run linux 2.6.33.1 (amd64) - but it is a virtualized host (with xen). Maybe it was xen's fault, but the logs don't reveal much as you see. Hm. this sucks. > > -- > Elen sila lumenn' omentielvo > > Ondrej 'SanTiago' Zajicek (email: santi...@crfreenet.org) > OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) > "To err is human -- to blame it on a computer is even more so." -- www.vix.at | www.aco.net w...@univie.ac.at | WH844-RIPE Vienna University Computer Center Tel: +43 1 4277-14031 | Fax: -9140 Monitor Computer Systems Limited Company Registration Number: NI 17805 Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
