cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2848
Views
0
Helpful
9
Replies

HSRP and Tracking

boondocker
Level 1
Level 1

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

1 Accepted Solution

Accepted Solutions

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

HTH

Rick

View solution in original post

9 Replies 9

lgijssel
Level 9
Level 9

To provide a short answer: check the link below:

http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094e8c.shtml

regards,

Leo

Amit Singh
Cisco Employee
Cisco Employee

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

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

!

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.

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?

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

HTH

Rick

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.

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

HTH

Rick

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

HTH

Rick
Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco