11-25-2011 09:25 AM - edited 03-07-2019 03:36 AM
I understand that the track command is a compliment to HSRP in that it allows monitoring of a given interface to provide failover to a standby router. Isn't this what HSRP does, how is tracking differentiated from HSRP functionality....I've tried finding this answer on the web but as a novice I'm not finding any concrete differences.Can anyone provide me with a simple and definitive answer? Thanks
Solved! Go to Solution.
11-25-2011 11:41 AM
I am glad that my explanation helps you understand it better.
We do not have enough information about your particular situation to give you good advice about which interfaces should have the tracking. In my experience you generally want to use tracking in an HSRP interface when there is some other interface that impacts the efficiency of forwarding traffic. So for example you may have an interface serving a group of hosts and you run HSRP on that interface. If there is another interface which is the one that user traffic gets forwarded out, then it may make sense to track that other interface.
So - making some assumptions about your example - if Gig1/0/10 is where a group of users are connected (which would be a bit odd since it is a routed port and not part of a VLAN) and if Gig1/0/11 connects to the firewall where the user traffic gets forwarded, then it would make good sense to track Gig1/0/11 in the Gig1/0/10 interface. (if the connection to the firewall goes down then it is less efficient to have user traffic arrive on Gig1/0/10 since it can not forward directly to Gig1/0/11).
HTH
Rick
11-25-2011 09:33 AM
To provide a short answer: check the link below:
http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094e8c.shtml
regards,
Leo
11-25-2011 09:34 AM
There are two types tracking available with HSRP.
1. Tracking the interface which is directly connected to the router. If that interface goes down, you can lower down the priority and fail-over to the standby router. This is the normal HSRP tracking as you mentioned.
2. HSRP can also be configured to work with IP SLA object tracking known as enhanced object tracking. This would monitor any indirect failure to your network path from the HSRP router perspective and take the necessary action. For example of there is failure in ISP cloud, HSRP interface tracking would not be able to track that and you would black hole all the traffic at the active HSRP router. With HSRP + Object tracking, you can use IP SLA object to track the end-end availability to your remote site/network and if there is an indirect failure, inform the HSRP router which can take a necessary action to decrement the priority and switch over to the standby router.
http://www.cisco.com/en/US/docs/ios/12_2t/12_2t15/feature/guide/fthsrptk.html#wp1146585
HTH,
Please rate if it does.
-amit singh
11-25-2011 10:01 AM
Thanks guys,
so if i don't specify any object in my tracking command, it would amount to the same function as HSRP...see below;
interface GigabitEthernet1/0/10
description L3
no switchport
ip address 172.27.36.2 255.255.255.0
no ip redirects
no ip proxy-arp
standby 102 ip 172.27.36.1
standby 102 timers 2 6
standby 102 priority 200
standby 102 preempt delay minimum 90
standby 102 track GigabitEthernet1/0/11
standby 102 track GigabitEthernet1/0/12
standby 102 track GigabitEthernet1/0/1
!
interface GigabitEthernet1/0/11
description Firewall
no switchport
ip address 172.27.37.2 255.255.255.248
no ip redirects
no ip proxy-arp
standby 103 ip 172.27.37.1
standby 103 timers 2 6
standby 103 priority 200
standby 103 preempt delay minimum 90
standby 103 track GigabitEthernet1/0/10
standby 103 track GigabitEthernet1/0/12
standby 103 track GigabitEthernet1/0/1
!
interface GigabitEthernet1/0/12
description Physical crossover interface for routing path
no switchport
ip address 192.168.255.5 255.255.255.252
duplex full
!
11-25-2011 10:18 AM
This is the HSRP interface tracking configuration. Yes, if you do not define any Object tracking it will be normal interface tracking as you have configured.
11-25-2011 10:22 AM
Thanks Amit I appreciate the patience,
so if I didn't include the track commands as above, in the event of an interface failure the failover would not occur?
...or is my track command redundant?
11-25-2011 11:10 AM
Your track command is not redundant. Let me try to explain the issue in this way:
If you configure HSRP without specifying any tracking then failover from the HSRP primary to the standby will be based only on failure of the primary interface. (If the primary interface fails then failover will make the standby interface take over.) Whe you configure tracking in HSRP you introduce the possibility of having failover occur based on failure of some interface(s) other than the HSRP interface. So in your example you are configuring HSRP in interface Gig1/0/10. Without tracking failover to the standby would occur only if this interface fails. When you configure tracking then you introduce the possibility of failure on Gig1/0/11, Gig1/0/12, or Gig1/0/1 to decrease the priority of Gig1/0/10. And if the priority of Gig1/0/10 becomes lower than the priority of its standby router then the standby will take over as the active router (even though Gig1/0/10 is still operating it will no longer be the HSRP lead router).
HTH
Rick
11-25-2011 11:25 AM
That makes sense Rick, thanks
In the example I am tracking the hsrp gig1/0/10 and gig1/0/11 ports, I probably should be only tracking the non-hsrp ports.
11-25-2011 11:41 AM
I am glad that my explanation helps you understand it better.
We do not have enough information about your particular situation to give you good advice about which interfaces should have the tracking. In my experience you generally want to use tracking in an HSRP interface when there is some other interface that impacts the efficiency of forwarding traffic. So for example you may have an interface serving a group of hosts and you run HSRP on that interface. If there is another interface which is the one that user traffic gets forwarded out, then it may make sense to track that other interface.
So - making some assumptions about your example - if Gig1/0/10 is where a group of users are connected (which would be a bit odd since it is a routed port and not part of a VLAN) and if Gig1/0/11 connects to the firewall where the user traffic gets forwarded, then it would make good sense to track Gig1/0/11 in the Gig1/0/10 interface. (if the connection to the firewall goes down then it is less efficient to have user traffic arrive on Gig1/0/10 since it can not forward directly to Gig1/0/11).
HTH
Rick
11-25-2011 04:13 PM
I am glad that my explanations have helped you resolve your question. Thank you for using the rating system to mark this question as answered (and thanks for the points). It makes the forum more useful when people can read about an issue and can know that responses did lead to a solution. Your marking has contributed to this process.
HTH
Rick
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide