04-18-2012 09:02 AM - edited 03-07-2019 06:12 AM
Hi Everyone,
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,
Dan
Solved! Go to Solution.
04-19-2012 01:57 AM
04-18-2012 12:05 PM
any thoughts anyone?
Dan
04-18-2012 12:17 PM
Daniel,
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.
OR
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?
John
04-18-2012 01:22 PM
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 .
Thanks anyway,
Dan
04-18-2012 01:26 PM
Hi Dan,
As far as I know - and also from John's post - the set ip next-hop verify has a tracking option
Dan
04-18-2012 01:27 PM
Dan
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.
HTH
Rick
[edit] 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.
04-18-2012 01:40 PM
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.
Thanks,
Dan
04-18-2012 01:45 PM
Hi,
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).
http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtpbrtrk.html
Dan
04-18-2012 01:44 PM
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
04-18-2012 01:46 PM
ip sla 1 monitor
Dan
04-18-2012 01:49 PM
ah brilliant, thanks Dan .
Now I need to go about setting it to use ICMP - not sure how to do this yet.
Dan
04-18-2012 01:56 PM
ip sla 1
icmp-echo 10.11.120.161
timeout 300
threshold 300
freq 2
ip sla sched 1 lif fo start no
track 1 ip sla 1
show track
Dan
04-18-2012 01:59 PM
I think that we have different IOS versions :
ip sla monitor 1
type echo protocol ipicmpecho 10.11.120.161
ip sla sched 1 lif fo start no
track 1 ip sla 1
show track
Dan
04-18-2012 01:47 PM
my route map says this....
route-map NMS-RM, permit, sequence 10
Match clauses:
ip address (access-lists): 2550
Set clauses:
ip next-hop verify-availability 10.11.120.161 1 track 1 [undefined]
ip next-hop 10.11.120.161
04-18-2012 02:07 PM
Hi Dan,
Did what you suggested in the first reply and I get the following:
Not sure why it says tracked by Route Map 0 - not sure where I have the option to point it at NMS-RM route map.
SL-Cisco-3560G-SW#sh track
Track 1
IP SLA 1 state
State is Down
1 change, last change 00:00:04
Latest operation return code: Unknown
Tracked by:
ROUTE-MAP 0
SL-Cisco-3560G-SW#sh route-map NMS-RM
route-map NMS-RM, permit, sequence 10
Match clauses:
ip address (access-lists): 2550
Set clauses:
ip next-hop verify-availability 10.11.120.161 1 track 1 [down]
ip next-hop 10.11.120.161
Policy routing matches: 18619 packets, 1578776 bytes
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: