Influencing Outbound Routes on Multi-Homed BGP Setup – How To

Just wanted to inform that I got some help from the Quagga-users mailing list in solving this and that this issue is resolved now.

For future reference I think that it's a good idea that I post the solution if anyone else encounters the same issue as I did.

The issue was with Ubuntu having net.ipv4.conf.all.rp_filter and net.ipv4.conf.default.rp_filter set to enabled by default. This was preventing packets from entering on one interface and leaving on another.

The suggestion in Ubuntu Bugs report (see link below) is that rp_filter is disabled when installed Quagga but this is not yet implemented.

Quagga-users mailinglist thread
Ubuntu Bugs report

Add a static route with a next hop that goes to peer 2 only because of a route to peer 2. That way, so long as you are receiving that route, the static route will point to peer 2. But the second you lose that route, your existing failover will flip it.

Pick any route that goes to peer 2 but that will go away if you cannot reach peer 2. Then add a static route for the traffic you want to cover with a next hop covered by the route you picked. That will cause traffic that matches the second route to track the first route.

For example, say the prefix you want to control traffic to is 216.152.32.0/24. You craft a static route to 216.152.32.0/24 and you choose its next hop. Since it's a static route, traffic to 216.152.32.0/24 will be routed towards that next hop (assuming there's no more-specific route, which there won't be). So that reduces the problem to choosing an appropriate next hop.

You want the traffic to go one way when the link to peer 2 is up and the other way when that link isn't working. So you need to pick a next hop that has that property. In principle, any IP inside a route you dynamically receive from peer 2 will work. That traffic will go to peer 2 when you have that route and will follow your default to peer 1 when you don't. (Assuming your default is properly set up to failover.)

Ideally, pick a route that's "core" to peer 2, but not too close to your point of connection. You want it to be "core" to peer 2 because you don't want it to flip over to peer 1 ever. You don't want it too close to you because if your node gets isolate, you want to fail over the peer 2. If you do a traceroute to a few random sites, you may be able to find a core router in a nearby city, on their backbone. That will do.