I have a Cisco L3 switch that I have configured route maps on to amend the next hop to be a firewall. The destination network for the traffic is also connected to the switch (therefore directly connected network), but my issue is this.
If the FW fails, then the traffic will still try to be sent to the down FW due to the route map amending the next hop. Is there a way that I can get the traffic to go via the connected network if the FW should fail? As far as I am aware, the route map will amend the next hop to the FW IP whether the FW is up or not, and therefore the traffic will be dropped.
Am I right on this or has anyone got another idea?
Thanks in advance,
Solved! Go to Solution.
I haven't labbed this up, but here's what the docs say:
The set ip next-hop command verifies the existence of the next hop specified, and…
if the next hop exists in the routing table, then the command policy routes the packet to the next hop.
if the next hop does not exist in the routing table, the command uses the normal routing table to forward the packet.
To configure policy routing to verify the reachability of the next hop of a route map before the router performs policy routing to that next hop, use the set ip next-hop verify-availability command in route-map configuration mode. To disable this function, use the no form of this command.
set ip next-hop verify-availability [next-hop-address sequence track object]
no set ip next-hop verify-availability [next-hop-address sequence track object]
If your IOS supports it, you could see if the verify-availability is available. Otherwise, how are you routing to the firewall? Can you post a quick diagram of how this is laid out?
thanks John but I did some research and this method uses CDp to discover if the next hop is available or not. Unfortunately, my next hop is an ASA and therefore doesnt run CDP .
It is one factor about setting a static route next hop or a Policy Based Routing next hop when the next hop is on an Ethernet interface that IOS will use the next hop as long as the router interface on that subnet is in the up state. So the next hop device (firewall in your case) could lose connectivity but the router will continue to try to use the next hop resulting in dropping traffic.
The alternative identified by John to use verify-availability in PBR is quite effective. I have implemented it a couple of times and it works quite well. I suggest that you give this a try.
 I am not sure where Dan did his research, but I have done the verify availability using ping to the next hop and not using CDP. I do not know if it is a specific version dependent thing. But I know that at least for some versions of IOS the verify-availability of PBR can use ping.
can you tell me how you did this Rick?
I am using a 3560G and the verify availability command does not give me the option to set the method of verifying.
If there are no odd requirements - only the traffic sourced from subnet x should go to the firewall - also the static route is an option, together with tracking option ( sla icmp ) which will solve both link or any other issues.
As Rick wrote , you will route as long as the interface will be up, but nowadays almost all firewalls are in cluster and connected to different access switches making this hard - even by loosing the link to the firewall - as a SVI to go down ( because of the link (trunk) between the switches ).
He is right Rick :
The set ip next-hop verify-availability command can be used in the following two ways:
•With policy-based routing (PBR) to verify next hop reachability using Cisco Discovery Protocol (CDP).
the ip sla monitor command is not an option on a 3560G (at least not on 12.2.58 SE2).
This is what I get...
set ip next-hop verify-availability 10.11.120.161 1 track 1
for ip sla I only get these options...no monitor
SL-Cisco-3560G-SW(config)#ip sla ?
<1-2147483647> Entry Number
enable Enable Event Notifications
group Group Configuration or Group Scheduling
key-chain Use MD5 Authentication for IP SLAs Control Messages
logging Enable Syslog
low-memory Configure Low Water Memory Mark
reaction-configuration IP SLAs Reaction-Configuration
reaction-trigger IP SLAs Trigger Assignment
read Read data for use with IP SLA
reset IP SLAs Reset
responder Enable IP SLAs Responder
restart Restart An Active Entry
schedule Entry Scheduling