I have what I'm sure is a pretty simplistic question today on using custom route-maps. I have multiple upstream peers using BGP to balance traffic and handle failover. That works really well (thanks in no small part to these forums). I have a new question about forcing some traffic out one peer and other traffic out another peer. Let's say that I have the following configuration (relevant bits below):
access list 3 permit 192.168.1.0 0.0.0.255
interface GigabitEthernet 1.990
ip policy route-map Texas
route-map Texas permit 10
match ip address 3
set ip next-hop 192.168.77.2
What happens when the next-hop address that I've specified is down? Even though I have multiple default routes from multiple providers, I'm overriding them with this route map, right?
We have to be more precise about what it means for a next-hop to be "down".
If the next-hop specified in the route-map is reachable according to the routing table (i.e. you can find a route to that next-hop in your routing table) then the router considers the route-map valid and will try to send the corresponding packets via this next hop. If this next hop router is not working, packets will get lost. This is the same as having a static route towards a non-existent next hop address which lies on a directly connected network.
If the next-hop specified in the route-map is not reachable, i.e. there is no route to this next hop in your routing table, then the route-map is ignored and the packets will be routed according to the routing table, bypassing the PBR.
If my memory serves, the default route in the routing table will not be used to verify the reachability of next hops specified in route-maps.
The issue that you ask about is especially common when the link to the next hop is Ethernet/FastEther/GigEther. The basics of the isse are that it is common to lose connectivity to the next hop but the interface remains in the up/up state. And the route to the next hop is considered valid, even though you have lost connectivity to the next. hop. IP SLA (or Object Tracking) is an effective solution for this issue. In the PBR config you can use the optional parameter verify-availability to force tracking of connectivity to the next hop. I have used this approach and it worked quite well.
We are pleased to announce availability of Beta software for 16.6.3. 16.6.3 will be the second rebuild on the 16.6 release train targeted towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are looking for early feedback from custome...