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; <ERR> 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.tjernlund@transmode.se] Sent: 26 April 2010 09:50 To: Andrew Lemin Cc: bird-users@trubka.network.cz; Ondrej Zajicek Subject: RE: OSPF performance/SPF calculations Andrew Lemin <andrew.lemin@monitorsoft.com> 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