The above Topology will be configured in the bottom section for MHSRP / Load-Balancing, but first a quick review of the HSRP Active / Standby election, followed by Preemption and Interface tracking.
HSRP Election Overview
The election specifically for the “Active Router” only happens upon initial bootup of the Router Group, if the Active Router goes offline or is removed from the Router Group, or if another group member is assigned a higher Priority value with “Preemption” enabled.
Both during the initial bootup of the Router Group and upon Active Router change, all other group members will go into “Speak” state to participate in the election, as long as they have an IP address assigned to the L3 interface that HSRP is enabled on.
If preemption is enabled on a non-Active Router, and its value becomes greater than that of the Active Router, it will take over as the Active Router and an election will be held to determine the new Standby among all group members.
Highest IP Address value does come into play if all HSRP Priority Values are left at default or otherwise configured to be the same, however it will not work with preemption configured, only Priority value is considered with Preemption.
This means the highest IP Address will only come into play for the Active Router selection when the Router Group is booting up, or a Standby Router is being elected after a new Active Router takes over for the group.
Speaking of Preemption, a quick review of exactly what it is
Preemption is used for allowing non-Active routers to become the Active Router after the initial election has taken place, as once an Active Router is selected, it cannot be over-thrown by simply having a higher Priority value – Preemption must also be enabled:
SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#int vlan 10
SW2(config-if)#standby 10 priority 105
(30 seconds or so goes by)
SW2(config-if)#standby 10 preempt
SW2(config-if)#
*Mar 1 00:20:17.262: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Standby -> Active
*Mar 1 00:20:17.262: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Standby -> Active
SW2(config-if)#
Even though the Priority was configured to be a higher value, it did not make the change until preemption was configured with the “standby # preempt” command, which can be used to either immediately update the Active Router or for Interface Tracking to dynamically change the Active Router based on availability per the interface!
HSRP Interface Tracking / Active Router dynamic fail-over
Interface Tracking is configured to monitor a particular physical interface so that if it becomes unavailable, the Priority will drop by a configured amount, which will allow Group members with Preemption enabled to take over as the Active Router.
Note this CAN be used on a VLAN / SVI interface, however all ports in that VLAN would need to go down for the SVI interface to go down, so using a physical interface is best practice for Interface Tracking configuration.
To demonstrate this, consider the following Topology, same as above but with int #’s:
The default value that the Router Priority is decremented by is -10 Priority when a tracked interface goes down, and is incremented the same value it was decremented by when it becomes available again, and the Router will again become the Active Router IF PREEMPTION IS ENABLED upon the interface coming back up.
First a look at the configuration path for interface tracking, on the SVI interface:
SW2(config)#int vlan 10
SW2(config-if)#standby 10 ?
authentication Authentication
follow Name of HSRP group to follow
ip Enable HSRP IPv4 and set the virtual IP address
name Redundancy name string
preempt Overthrow lower priority Active routers
priority Priority level
timers Hello and hold timers
track Priority tracking
SW2(config-if)#standby 10 track ?
<1-1000> Tracked object number
Async Async interface
Auto-Template Auto-Template interface
BVI Bridge-Group Virtual Interface
CTunnel CTunnel interface
Dialer Dialer interface
FastEthernet FastEthernet IEEE 802.3
Filter Filter interface
Filtergroup Filter Group interface
GigabitEthernet GigabitEthernet IEEE 802.3z
GroupVI Group Virtual interface
Lex Lex interface
Loopback Loopback interface
Port-channel Ethernet Channel of interfaces
Portgroup Portgroup interface
Pos-channel POS Channel of interfaces
Tunnel Tunnel interface
Vif PGM Multicast Host interface
Virtual-TokenRing Virtual TokenRing
Vlan Catalyst Vlans
fcpa Fiber Channel
SW2(config-if)#standby 10 track fa1/0/2 ?
<1-255> Decrement value
<cr>
SW2(config-if)#standby 10 track fa1/0/2
SW2(config-if)#
Note that the tracking decrement value can be adjusted after the interface # is defined, and to verify in “sh standby” it is seen the default value is 10:
SW2(config-if)#do sh standby
Vlan10 – Group 10
State is Active
16 state changes, last state change 00:09:37
Virtual IP address is 10.0.10.254
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.064 secs
Preemption enabled
Active router is local
Standby router is 10.0.10.1, priority 100 (expires in 10.304 sec)
Priority 105 (configured 105)
Track interface FastEthernet1/0/2 state Up decrement 10
Group name is “hsrp-Vl10-10” (default)
SW2(config-if)#
This can also be verified with the User Exec level command “sh track” as seen here:
SW2#sh track
Track 1 (via HSRP)
Interface FastEthernet1/0/2 line-protocol
Line protocol is Up
1 change, last change 00:10:30
Tracked by:
HSRP Vlan10 10
SW2#
Given SW2 is only 5 above the Priority of SW1 which is default Priority 100, if the tracked interface facing the LAN goes down, in this scenario only having a single Trunk running back to SW3 it actually becomes stuck in “Init” state:
SW2(config)#int fa1/0/2
SW2(config-if)#shut
SW2(config-if)#
*Mar 1 00:50:43.261: %TRACKING-5-STATE: 1 interface Fa1/0/2 line-protocol Up->Down
*Mar 1 00:50:43.277: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to down
*Mar 1 00:50:43.277: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Active -> Init
*Mar 1 00:50:43.277: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Active -> Init
SW2(config-if)#
In this instance it became stuck in Init because its only interface in VLAN 10 (Trunk Fa1/0/2) went down, so VLAN 10 itself went down as seen in the output above, I removed the physical interface down output for clarity sake.
To verify:
SW2(config-if)#do sh standby
Vlan10 – Group 10
State is Init (interface down)
22 state changes, last state change 00:00:44
Virtual IP address is 10.0.10.254
Active virtual MAC address is unknown
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Preemption enabled
Active router is unknown
Standby router is unknown
Priority 95 (configured 105)
Track interface FastEthernet1/0/2 state Down decrement 10
Group name is “hsrp-Vl10-10” (default)
SW2(config-if)#
So “sh standby” output will tell you the interface is “Down” in general, with the decrement value, while “sh track” provides the actual interface Down state:
SW2#sh track
Track 1 (via HSRP)
Interface FastEthernet1/0/2 line-protocol
Line protocol is Down (hw admin-down)
4 changes, last change 00:04:24
Tracked by:
HSRP Vlan10 10
SW2#
This tells us the interface is administratively down, however it does not confirm that Preemption is enabled like “sh standby” output, so “sh track” output information is not enough to determine that this router will again become the Active Router upon bringing that tracked interface back up.
However, since Preemption is enabled on SW2, upon bringing the interface back Up:
SW2#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW2(config)#int fa1/0/2
SW2(config-if)#no shut
SW2(config-if)#
*Mar 1 00:57:59.141: %LINK-3-UPDOWN: Interface FastEthernet1/0/2, changed state to up
SW2(config-if)#
*Mar 1 00:58:02.723: %TRACKING-5-STATE: 1 interface Fa1/0/2 line-protocol Down->Up
*Mar 1 00:58:02.840: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/2, changed state to up
SW2(config-if)#
(About 30 seconds elapses)
*Mar 1 00:58:31.857: %LINEPROTO-5-UPDOWN: Line protocol on Interface Vlan10, changed state to up
SW2(config-if)#
*Mar 1 00:58:35.371: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Listen -> Active
*Mar 1 00:58:35.371: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Listen -> Active
SW2(config-if)#
This demonstrates that the router will not become the Active Router again UNTIL the VLAN SVI interface comes back up, which can be seen takes about 30 seconds from the time the “Interface Tracking” detected the physical interface coming back Up.
One other thing to note regarding interface tracking, if it is configured for an unused interface, it will immediately decrement the HSRP Standby Group Priority – So be careful to double check the physical interface being tracked and that it is not already down:
SW2(config-if)#standby 10 track fa1/0/1
SW2(config-if)#
*Mar 1 01:02:58.631: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Active -> Speak
*Mar 1 01:02:58.631: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Active -> Speak
SW2(config-if)#
Be sure to watch that on exam day and on the job!
I won’t go into a long winded lab about changing decrement values, its mostly important to know that only Router enabled with Preemption will over-throw Active Routers if there Priority is decremented enough to drop below another Routers Priority value, and that the Priority and decrement value can both be adjusted around the network to allow the network admin to control which Router Group members will step in as Active Router upon interface failure.
So with interface tracking, the following aspects are relevant to troubleshooting:
- The physical interface being tracked is not already “Down”
- The decrement value is high enough to allow it to decrement the Priority below the value of the planned Router to take over as Active Router
- That the SVI / L3 interface with HSRP configured is Up
- That Preemption is enabled on both devices, so the Backup Router can take over upon interface failure and the original Active Router can take back over when the interface comes back online and the Priority is incremented to its original value
Multiple HSRP (MHSRP) configuration for load-balancing
Multiple HSRP is literally just Multiple HSRP instances configured on a Router, which can provide load-balancing for the network, but with one gigantic catch:
Half of the hosts on the LAN segment must have their default gateways pointed at one Virtual Router IP, and the other half pointed at the other Virtual Router IP!
Configuring this on the Router Group members is not enough, the LAN hosts must be pointed at the different HSRP Instances for their default gateway for this to work.
To reference the Topology being created again (HSRP roles at top of switches in diagram):
I removed the Priority from the diagram as that has been reset to default Priority 100 on both SW1 and SW2, and tracking has been disabled.
This means SW2 by default is the Active Router for Standby Group 10, because it has the higher IP Address as the tie breaker, so first SW1 must be configured to be the Active Router for Router Group 10:
SW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
SW1(config)#int vlan 10
SW1(config-if)#standby 10 priority 105
SW1(config-if)#
*Mar 1 01:17:48.578: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Standby -> Active
*Mar 1 01:17:48.578: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Standby -> Active
SW1(config-if)#
I would probably use any value between 101-109 for the Priority to be changed to, as this way if Interface Tracking is configured with its default decrement value of 10, SW2 can take over as the Active Router for both Router Groups.
Speaking of both Router Groups, Multiple HSRP works by configuring a secondary (or more) HSRP instance on the same SVI / LAN segment as Standby Group 10:
SW1(config)#int vlan 10
SW1(config-if)#standby 20 ip 10.0.10.245
SW1(config-if)#
ASR#2
[Resuming connection 2 to sw2 … ]
SW2(config-if)#int vlan 10
SW2(config-if)#standby 20 ip 10.0.10.245
SW2(config-if)#
The two Routers will again go through the election states of “Init” first for Standby Group 20, then “Listen” / “Speak” / Etc.
Now given that Preemption is configured only for Standby Group 10 at this point, SW2 will win this election as though it were an initial bootup election of the group (which it basically is), being that it has the highest IP Address (the same SVI 10.0.10.2 for VLAN 10), and will automatically become the Active Router for Standby Group 20.
Verification on SW1
SW1#sh standby
Vlan10 – Group 10
State is Active
34 state changes, last state change 00:08:35
Virtual IP address is 10.0.10.254
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.728 secs
Preemption enabled
Active router is local
Standby router is 10.0.10.2, priority 100 (expires in 8.896 sec)
Priority 105 (configured 105)
Group name is “hsrp-Vl10-10” (default)
Vlan10 – Group 20
State is Standby
6 state changes, last state change 00:04:23
Virtual IP address is 10.0.10.245
Active virtual MAC address is 0000.0c07.ac14
Local virtual MAC address is 0000.0c07.ac14 (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.624 secs
Preemption disabled
Active router is 10.0.10.2, priority 100 (expires in 11.472 sec)
Standby router is local
Priority 100 (default 100)
Group name is “hsrp-Vl10-20” (default)
SW1#
SW1 is the Active Router for Standby Group 10, Virtual Router IP 10.0.10.254, and SW2 is the Active Router for Standby Group 20 with Virtual Router IP 10.0.10.245.
Now Hosts can be pointed at either Router for their default gateway, this means the load balancing is not perfect and will depend on Host configuration, but does allow for some type of load balancing using HSRP.
One important note for exam day mentioned previously, a Router can have a maximum of 64 HSRP instances running at one time, so you can only create 64 MHSRP instances!
HSRP Authentication for both key-string and key-chain configurations
Authentication is configured using key-string or key-chain configuration with the “standby # …” configuration on the L3 interface HSRP is enabled on, and for a basic configuration of a key-string only I’ll run through a quick setup on SW1:
SW1(config-if)#standby 10 auth ?
WORD Plain text authentication string (8 chars max)
md5 Use MD5 authentication
text Plain text authentication
SW1(config-if)#standby 10 auth md5 ?
key-chain Set key chain
key-string Set key string
SW1(config-if)#standby 10 auth md5 key-string ?
0 Specifies an UNENCRYPTED key string will follow
7 Specifies a HIDDEN key string will follow
WORD Key string (64 chars max)
SW1(config-if)#standby 10 auth md5 key-string 7 ?
WORD Key string (64 chars max)
SW1(config-if)#standby 10 auth md5 key-string 7 CCNP ?
timeout Set timeout
<cr>
SW1(config-if)#standby 10 auth md5 key-string 7 CCNP
Invalid encrypted keystring: CCNP
SW1(config-if)#standby 10 auth md5 key-string CCNP
SW1(config-if)#
*Mar 1 01:36:35.336: %HSRP-4-BADAUTH: Bad authentication from 10.0.10.2, group 10, remote state Standby
SW1(config-if)#
Highlighted in pink shows the Encrypted / 7 option is expecting an encrypted key-string, it will not take a plain text key-string and encrypt it, so on the “show run” output the password will be in plain text though it will be sent between devices with MD5 encryption.
For this reason, I switched to directly entering the password, then to encrypt the plain text in the show run I turn on the service for “password-encryption” shown here:
SW1(config)#service password-encryption
SW1(config)#do sh run
Building configuration…
(lots of output)
interface Vlan10
ip address 10.0.10.1 255.255.255.0
standby 10 ip 10.0.10.254
standby 10 priority 105
standby 10 preempt
standby 10 authentication md5 key-string 7 143431253C
standby 20 ip 10.0.10.245
Note that it does show “7” in the running configuration because the password-encryption service is enabled, however it was NOT configured with “7” in the actual key-string configuration.
Back to the configuration, immediately upon entering the authentication config, the console output present an error on SW1:
*Mar 1 01:36:35.336: %HSRP-4-BADAUTH: Bad authentication from 10.0.10.2, group 10, remote state Standby
This is indicating either SW2 is not configured for authentication, or the key-string has an incorrect WORD or password configured for it, the console will repeat this message until the member indicated by its IP Address is configured correctly or removed from the HSRP Group.
This authentication error also means that the local Router, and the remote router specified by IP Address will not agree on an Active / Standby Router between them:
SW1(config)#do sh standby
Vlan10 – Group 10
State is Active
34 state changes, last state change 00:29:41
Virtual IP address is 10.0.10.254
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 1.760 secs
Authentication MD5, key-string
Preemption enabled
Active router is local
Standby router is unknown
Priority 105 (configured 105)
Group name is “hsrp-Vl10-10” (default)
If the Router cannot Authenticate its group member, it will not consider it a group member, until the they are both configured to authenticate properly.
Key-Strings are pretty simple in the way they are basically like setting a single password and away we go, whereas with Key-Chains (as will be seen in ROUTE authentication if you have not yet had the pleasure), is a collection of key-strings grouped under the umbrella of the key-chain name.
One important note is that key-strings and key-chains configured with the same key-string (password) as the remote group member will not authenticate, this works in other configurations for OSPF or EIGRP, but with HSRP it will not work!
^That is a very important concept, so be sure to understand that for exam day!
One other piece of CLI output to note, when I jumped on SW2 for configuration:
SW2(config-if)#
*Mar 1 01:36:28.919: %HSRP-4-BADAUTH: Bad authentication from 10.0.10.1, group 10, remote state Active
SW2(config-if)#
Even though this output from SW2 has “remote state Active” in it, which might imply the remote group member is the Active Router, SW2 has the same “sh standby” output:
SW2(config-if)#do sh standby
Vlan10 – Group 10
State is Active
36 state changes, last state change 00:20:50
Virtual IP address is 10.0.10.254
Active virtual MAC address is 0000.0c07.ac0a
Local virtual MAC address is 0000.0c07.ac0a (v1 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 2.080 secs
Preemption enabled
Active router is local
Standby router is unknown
Priority 100 (default 100)
Group name is “hsrp-Vl10-10” (default)
The only difference in the output is, there is no authentication set YET, so lets take care of that on SW2:
SW2(config-if)#standby 10 auth md5 key-string CCNP
SW2(config-if)#
*Mar 1 02:03:46.417: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Active -> Speak
*Mar 1 02:03:46.417: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Active -> Speak
SW2(config-if)#
*Mar 1 02:03:57.633: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Speak -> Standby
*Mar 1 02:03:57.633: %HSRP-5-STATECHANGE: Vlan10 Grp 10 state Speak -> Standby
SW2(config-if)#
It goes into “Speak” State to participate in the election immediately, then is put into “Standby” state as SW1 has a Priority of 105.
I won’t put up the lab output and dig through it all, however Key-Chains are not flexible in the way that as long as a single key # matches another key # on the remote side, they will authenticate.
In fact even if “key 1” on the key-chain matches on both sides, but there are extra keys configured on the same key-chain that do not match, AUTHENTICATION WILL NOT HAPPEN FOR HSRP BETWEEN THE ROUTERS!
For exam day regarding HSRP Authentication, the key-chains must match each other exactly the same as a single key-string, or it will not authenticate!
First the key-chain must be configured at Global Exec level
SW2(config)#key chain ?
WORD Key-chain name
SW2(config)#key chain HSRP ?
<cr>
SW2(config)#key chain HSRP
This drop into key-chain config
SW2(config-keychain)#?
Key-chain configuration commands:
default Set a command to its defaults
exit Exit from key-chain configuration mode
key Configure a key
no Negate a command or set its defaults
SW2(config-keychain)#key ?
<0-2147483647> Key identifier
SW2(config-keychain)#key 10
SW2(config-keychain-key)#
This drops into Key-Chain Key configuration
SW2(config-keychain-key)#?
Key-chain key configuration commands:
accept-lifetime Set accept lifetime of key
default Set a command to its defaults
exit Exit from key-chain key configuration mode
key-string Set key string
no Negate a command or set its defaults
send-lifetime Set send lifetime of key
SW2(config-keychain-key)#key-string ?
0 Specifies an UNENCRYPTED password will follow
7 Specifies a HIDDEN password will follow
LINE The UNENCRYPTED (cleartext) user password
SW2(config-keychain-key)#key-string CCNP ?
LINE <cr>
SW2(config-keychain-key)#key-string CCNP
This key-chain is now configured with a password / key-string to be used to authenticate, again that key # / key-string must match EXACTLY on each side, without extra keys configured on the key-chain – I have labbed key-chains with HSRP and I’ve not gotten it to authenticate unless the key-chains match exactly down to the number of keys even if there is matching key #’s with matching key-strings configured!
Now to set the key-chain on a Standby Group
SW2(config-keychain-key)#int vlan 10
SW2(config-if)#
SW2(config-if)#
SW2(config-if)#standby 10 auth ?
WORD Plain text authentication string (8 chars max)
md5 Use MD5 authentication
text Plain text authentication
SW2(config-if)#standby 10 auth md5 ?
key-chain Set key chain
key-string Set key string
SW2(config-if)#standby 10 auth md5 key-chain ?
WORD Name of key-chain
SW2(config-if)#standby 10 auth md5 key-chain HSRP ?
<cr>
SW2(config-if)#standby 10 auth md5 key-chain HSRP
SW2(config-if)#
With either one of these, in the exam room or in the real world, I would just make absolute sure that ALL values match in either configuration scenario, or the members may not successfully authenticate.
That is it for HSRP related material!
Next FHRP covered will be VRRP which is extremely similar to HSRP, so that should be a fairly quick review, before finishing FHRP review with GBLP!
The DEVNET GRIND! 