BGP preferred outbound peer for given prefix when none of my peers directly announce the prefix (it's handled by the Default route)

Question

I'm connected to 2 BGP peers; They both give me a filtered table that includes a default + about 30K prefixes each (not a full table). For prefixes that I do receive, I simply let BGP use it's prefix-length algorithm to select the best route. For prefixes that I don't receive (ie: the "default" applies) I favor BGP peer 1. The problem is, for one particular prefix that I don't receive from either BGP peer (ie: the default would apply), I'd like to favor BGP peer 2, not the usual peer 1. I know I could easily do this using a static route, but that doesn't sound quite right, because if I add a static route towards peer 2's router and the route drops, the static route would "stick" and I will not be able to push any traffic to that prefix. If I can find a BGP mechanism to do the same, I can prefer a route to BGP peer 2, but if that route is not available, the route to BGP peer 1 would be used.

To manipulate my out-bound routes I'm using route-maps that set the an equal local-preference for outbound traffic towards received prefixes so BGP's default prefix-list-length algorithm is used, and I'm setting a higher preference for outbound traffic using the "default" route for BGP peer 1.

Unfortunately I have no idea how to use a route-map to do this for my special prefix, because no object with that prefix exists in the system: as far as both BGP peers are concerned, it is handled by the "default" route.

I'm using Quagga for my routing, so BGP is not the only available protocol. A Cisco-style solution wold be fine as well, since I suspect I'm lacking some basic knowledge and any nudge in the right direction would help me find my way.

Here's my bgpd.conf file, edited to remove personal information; Hopefully I didn't over do it:

router bgp 12345
 bgp router-id 10.0.0.1
 network 10.0.0.0/24
 redistribute connected
 !
 neighbor 10.0.1.1 remote-as 22222
 neighbor 10.0.1.1 ebgp-multihop 3
 neighbor 10.0.1.1 next-hop-self
 neighbor 10.0.1.1 distribute-list distrib-out out
 neighbor 10.0.1.1 route-map INBGP1 in
 !
 neighbor 10.0.2.1 remote-as 11111
 neighbor 10.0.2.1 ebgp-multihop 10
 neighbor 10.0.2.1 next-hop-self
 neighbor 10.0.2.1 distribute-list distrib-out out
 neighbor 10.0.2.1 route-map INBGP2 in
!
access-list distrib-out permit 10.0.0.0/24
!
access-list is-default permit 0.0.0.0/0 exact-match
!
route-map INBGP2 permit 10
 set metric 2
 set ip next-hop 89.121.231.73
 on-match next
!
route-map INBGP2 permit 20
 match ip address is-default
 set local-preference 101
 on-match goto 1000
!
route-map INRTC permit 30
 set local-preference 110
 set metric 1
!
route-map INBGP2 permit 10
 set metric 1
 on-match next
!
route-map INBGP1 permit 20
 match ip address is-default
 set local-preference 200
 on-match goto 1000
!
route-map INBGP1 permit 30
 set local-preference 110
 set metric 1

Answer 1

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.

Answer 2

There is a straight forward solution to your problem that doesn't involve static routes. Before delving into it, I want to touch on one semantic aspect in your description. The longest prefix match rule has nothing to do with BGP. You should be thinking about the BGP path selection algorithm. Every vendor has its own tweaks on this algorithm; however, most are very similar to Cisco's algorithm.

You have complete control over traffic in the direction from your site to the ISP. You can use local preference or Multi-Exit-Discriminators (MED) to influence routing in this direction. I recommend using one or the other for simplicity's sake. Implement this policy on prefixes the ISP sends to you (i.e., your inbound policy).

1) Local Preference - The highest local preference is preferred (default local preference is 100). Local preference is earlier in the BGP best path solution and is evaluated prior to AS_LENGTH. Your provider cannot send you prefixes with local preference; local preference does not cross AS boundaries.

2) MED - The lowest MED is preferred. Your provider may send MEDs on its prefixes. On Cisco routers, no MED is treated as MED = 0 unless you enable bgp bestpath med missing-as-worst. MEDs are evaluated after AS_LENGTH in the BGP path selection algorithm.

You may want to read Cisco's BGP case studies. I also highly recommend the book Internet Routing Architectures by Sam Halabi for detailed info on BGP and its usage.