I have 2 dhcp interfaces and want to track an objects. IOS won't let me create 2?
ip local policy route-map ICMP-TRACK
access-list 103 remark ***** ICMP for Object Tracking out Fa0 *****
access-list 103 permit icmp any host xx.xx.41.19
access-list 104 remark ***** ICMP for Object Tracking out Fa1 *****
access-list 104 permit icmp any host xx.xx.72.92
route-map ICMP-TRACK permit 10
match ip address 103
match interface FastEthernet0
route-map ICMP-TRACK2 permit 10
match ip address 104
match interface FastEthernet1
It is not possible to use two route map in policy statement but generally you can feed more than one condition within single route-map itself. For example in above case instead of using second route-map, you can add another statement with different sequence number(route-map ICMP-TRACK permit 20
) on the first route-map itself.
I am considering general scenario so
perhaps you want to eleborate more on what exactly you are trying to achieve with this setup and we can help better.
Hi Yagnesh, Thanks for a response. I want to track 2 objects. I have a 1811 with 2 wan connections (2 ISP's). The primary ISP is cable and the secondary is a 3G wireless connection. We always want to have the wired connection to be the primary since the secondary link is wireless and they charge if you go beyond a certain amount of bandwidth. One issue we see is if both providers are dhcp, the AD ends of being 254 and it does not know how to route correctly (we have resolved this with EEM scripts and beta IOS). Second issue is we want to track when the unit is up on the secondary link and open a trouble ticket to confirm the primary is actually down so we can get the Primaries link issue resolved. So I track one object thru the primary path and one object thru the secondary path. I was originally using the policy statement to track both objects thru the primary path with a route map but wanted to track each object with a separate route map. It looks like you mention I could nest these. Please give me some examples :) THANKS!
"First of all you can change the AD of dhcproutes with a simple "ip route" command."
Sorry - doesn't work. Even if you append a route metric to the end of the ip route statement it is not recognized correctly.
"Then, you never need ip local policy to track objects. Just set the correct source address in the ping statement and router will take care of the rest."
Of course it is not needed but it was easier to do when I tracked both objects only thru the primary path. Why wouldn't IOS allow me to create 2 local policies? It lets me create multiple route maps.
is this the configuration in your two edge routers interface ?
ip address dhcp
just trying to figure out how could I help
Your scenario is bit tricky as you have multiple factors/conditions involved or perhaps I am thinking more than it requires. First I am trying to understand use of local policy and where these two tracking are attached. I understood that in order to track the status of the particular link, the pings must be routed only from that link. But isn't specifying source interface while defining ip sla can achieve the same result? This may not be option depending on who is end client of these two tracking. Sorry to ask more but could you share your complete configuration?
I have attached a sterilized version. Note the commands on the Fa0 and Fa1 interface to set the AD. They do not seem to "fully" work in this beta code. The code allows the commands but the routing table does not show it has set the AD correctly so the work around was to add the the metric to the end of the dhcp route statements. We want to track that both links are up so we can ticket but when the site is up on the secondary only, get the primary back online as quickly as possible. Original design was tracking both thru primary in combination with local policy. New design to is to track one object thru primary and other object thru secondary path. This way I can see when up on secondary and up on secondary only. I thought I could do this with the local policy but apparently not. I am sure I do not fully understand the ip policy process :).