Solved: Usage of Route Maps for Next Hop - Page 5

danbowencisco · ‎04-18-2012

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

mukremin13 · ‎04-20-2012

yes same story. because verify-availability is not supported in this switch. configuration guide says.

But i need this also. What will we do i dont know.

danbowencisco · ‎04-20-2012

if I replace the set ip next hop ver avail and try it, it works and lets me add it to the interface. So it must be that the command is not supported at the interface level (even though it doesnt error).

mukremin13 · ‎04-20-2012

vlan interface level also.

danbowencisco · ‎04-20-2012

yeah I meant VLAN interface, SVI level.

annoying thing is, it is supported!

SL-Cisco-3560G-SW(config-route-map)#set ip next-hop ?

A.B.C.D IP address of next hop

dynamic application dynamically sets next hop

encapsulate Encapsulation profile for VPN nexthop

peer-address Use peer address (for BGP only)

recursive Recursive next-hop

self Use self address (for BGP only)

verify-availability Verify if nexthop is reachable

danbowencisco · ‎04-20-2012

my only other possible solution would be a vrf for every vlan, that way the destination wouldnt be seen as a directly connected network and therefore it would route via the firewall. I could then control the routing with a preferred static to the firewall and a backup static to the switch interface.

Not sure if this would work, but its either that or running HSRP between the FW and switch, with the FW as the active member.

Dan

mukremin13 · ‎04-20-2012

Configuration guide says:

This appendix lists some of the command-line interface (CLI) commands that appear when you enter the question mark (?) at the 3560 switch prompt but are not supported in this release, either because they are not tested or because of switch hardware limitations. This is not a complete list. These unsupported commands are listed by software feature and command mode:

and set ip next-hop cerify-availability is in the list.

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_58_se/configuration/guide/swuncli.html

This is very frustrating because if it is not supported why it is shown in the ? option.

Finally i dont know whether any other solution exist or not.

Dan-Ciprian Cicioiu · ‎04-20-2012

Daniel , Mukermin,

Sadly yes , 'next-hop + verify-availability , is not supported on 3560. I think that the fact that you have a 3560G, Daniel , I missed.

Now the interesting thing is that , from what I understand you can use at maximum 1 set ip next-hop verify-availabilty per route-map, because the setup worked for Daniel when the route-map contain just one entry.

Daniel , just to be clear that this multi entry route-map you paste :

show ip policy route-map

And also tell me how did you performed test ?

Dan

danbowencisco · ‎04-20-2012

Hi Dan.

No, even when I only have one verify entry per map it still doesnt work, its only when I remove the verify and replace with set ip next-hop that it works. Cisco have screwed us in the fact they support verify-availability, but not at an interface level. So the verify comes up and shows as active, but you can apply the route map to the interface (so it never matches any traffic).

Just for reference though, this is the output.

SL-Cisco-3560G-SW#sh route-map PBR-Management
route-map PBR-Management, permit, sequence 10
Match clauses:
    ip address (access-lists): Route-Map-ACL-Management-Process1
Set clauses:
    ip next-hop verify-availability 10.11.120.161 1 track 610 [up]
Policy routing matches: 0 packets, 0 bytes
route-map PBR-Management, permit, sequence 20
Match clauses:
    ip address (access-lists): Route-Map-ACL-Management-Process2
Set clauses:
    ip next-hop verify-availability 10.11.120.161 1 track 620 [up]
Policy routing matches: 0 packets, 0 bytes
route-map PBR-Management, permit, sequence 30
Match clauses:
    ip address (access-lists): Route-Map-ACL-Management-Process3
Set clauses:
    ip next-hop verify-availability 10.11.120.161 1 track 630 [up]
Policy routing matches: 0 packets, 0 bytes
route-map PBR-Management, permit, sequence 40
Match clauses:
    ip address (access-lists): Route-Map-ACL-Management-Information
Set clauses:
    ip next-hop verify-availability 10.11.120.161 1 track 640 [up]

Track 160
IP SLA 160 state
State is Up
2 changes, last change 00:02:20
Latest operation return code: OK
Latest RTT (millisecs) 1

Dan-Ciprian Cicioiu · ‎04-20-2012

Daniel ,

Yes, then this is the case. I'm very sorry that I missed this detail.

Dan

danbowencisco · ‎04-20-2012

not a problem Dan, sorry I wasted your time.

I have another possible solution tho...

Florin Barhala · ‎10-29-2012

Hi guys,

I enter here a small question I have about IP SLA:

- I have two ISP in a failover scenario; I need to use a track object on ISP 1.

- I configured it and use icmp packets sent from ISP1_connected_interface to the ISP_GW

The trouble I enconter is that if I plug out the cable from ISP1_connected_interface my tracking object it's maintaing its state because I can reach that IP using the 2nd ISP connection.

How can I prevent this?

Here is the config (classy one):

ip sla monitor 10

type echo protocol ipIcmpEcho 193.aa.bb.201 source-ipaddr 89.xx.yy.18

timeout 1000

frequency 4

ip sla monitor schedule 10 life forever start-time now

track 10 rtr 10 reachability

delay down 10 up 30

ip route 0.0.0.0 0.0.0.0 89.238.226.17 track 10