I currently have the following two static routes:
ip route 10.185.165.0 255.255.255.0 192.168.52.33
ip route 10.185.165.0 255.255.255.0 22.214.171.124 100
The first route goes over an Ethernet link that our switch connects to. If that link goes down, there is no way of us knowing so the second route will only work manually (i.e. if we either remove the first route or shutdown the interface connecting to the ethernet link).
I am thinking of implementing route-map with next-hop verify-availability. Does this option only work with CDP?
Below is our setup:
I basically want to check the availibility of "farendswitch"
Have a look at Reliable Static route with object tracking
Thanks much for the quick reply. What do you think of this config?
type echo protocol ipicmpecho 192.168.52.33
rtr schedule 1 life forever start-time now
track 192 rtr 1 reachability
ip policy route-map vlan14
set ip next-hop verify-availability 192.168.52.33 10 track 192
ip route 10.185.165.0 255.255.255.0 192.168.52.33 track 192
ip route 10.185.165.0 255.255.255.0 126.96.36.199 254
Yes looks good.
What switch are you using... some switches like the 3750 would require you to chnage the SDM template to support PBR
Cisco IOS Software, C3750 Software (C3750-ADVIPSERVICESK9-M), Version 12.2(25)SED1, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2005 by Cisco Systems, Inc.
Compiled Tue 22-Nov-05 23:37 by yenanh
Image text-base: 0x00003000, data-base: 0x0119A6B0
ROM: Bootstrap program is C3750 boot loader
BOOTLDR: C3750 Boot Loader (C3750-HBOOT-M) Version 12.2(25r)SE1, RELEASE SOFTWARE (fc)
NY45B3SEZ00 uptime is 2 years, 9 weeks, 5 days, 19 hours, 51 minutes
System returned to ROM by power-on
System restarted at 14:48:44 EST Tue Jan 31 2006
System image file is "flash:c3750-advipservicesk9-mz.122-25.SED1.bin
Do a show sdm prefer and see what template the switch is running
you need to change the template to routing for PBR to work
I tried to setup PBR but could not add the route using track:
ip route x.x.x.x x.x.x.x. track x.x.x
it seems that the switch will not take that command but it took all other commands.
Will changing the template affects my current configuation?
Im just thinking out loud....
Im wondering what the benefit is of using PBR and object tracking in this particular case.
What's wrong with the static/floating static approach? The primary static goes down because the next hop fails, so the floating becomes the primary. What qualitative difference does object tracking really offer?
They seem to achieve the same thing, but PBR takes a lot more to get to work.
Am I missing something?
The problem is that if the Provider circuit goes down, we have no way of knowing it. We only can know it if the ping times out. Our provider uses Ethernet Link so our switch connects to their switch.
So -- correct me if Im wrong -- it's not the next hop in your static route that you are afraid of losing and not being aware of, it's the Metro Ethernet link between the service provider's switches that you do not have visibility to. And that's why you want to do some object tracking. Correct?
I will further assume that the next hop address for your primary static route (192.168.52.33) is also a directly connected interface. IOW, its L2 adjacent to an interface on your own switch. You don't have to depend on any recursive routing to take you to that next hop, right?
If all that is the case, why are you PINGing the next hop address in your static route (192.168.52.33) as part of your RTR test? If you lose that next hop, since it is directly connected, your router will know about it and install the floating static in the routing table and use it as the primary route. You don't need object tracking to track a directly connected interface.
Isn't it an address beyond that provider's first hop that you want to be PINGing as part of your RTR test?
This is my mental picture of your network:
You<->SP_edge_switch (192.168.52.33)<--METRO ETHERNET FIBER-->SP-edge_switch<->clients
1. Yes, it is the Metro Ethernet link that I have no visibility to.
2. No, the next hop is located at the client site over the Metro Ethernet.
3. The address beyond the provider's Metro E is 192.168.52.33.
ME(VLAN14: 192.168.52.34)<->SP_Edge_Switch)<-MetroE->SP_Edge_Switch<->(192.168.52.33 int x)Clients
No worries Victor, I am here to find a solution so I welcome the questions.
Indeed it shows it as directly connected since they share the same subnet. But the problem is really because of the Metro E. Because the service provider does not give us a way of knowing when that circuit goes down, we have to ping the far end.
Yes, I realized the answers to my own questions as soon as I submitted them to you. :-) thats why I deleted them and did an "[EDIT]"
The fact that 52.44 is several L2 hops away, your 52.33 interface will always remain "up,up" and never expunge the routes from the routing table that point to it. Basic stuff, actually. Had a brain fart.
Have you ever been able to get this thing working?
Not yet...my switch is not taking the command
ip route destination_address 255.255.255.0 track 192
I need to do some more homeworks....