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/24 via 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/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)
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: [email protected]
[mailto:[email protected]] On Behalf Of Vincent Bernat
Sent: 24 September 2010 10:41
To: [email protected]
Subject: ECMP/multipath support
Hi!
BIRD does not support EMCP yet. Looking at the source code, BIRD seems to
be able to support ECMP routes internally by adding attaching several route
attributes to the same route entry. Is there already someone working on
this? ECMP is an important feature when dealing with redundancy.
Thanks.
________________________________
Monitor Computer Systems Limited
Company Registration Number: NI 17805
Registered Office: 3 Pine Crest, Holywood, North Down, Northern Ireland BT18 9ED
