You want to debug an HSRP problem.
To debug all HSRP error events, use the following command:
Router2#debug standby errors
The events keyword will display information about HSRP events:
Router2#debug standby events
With the packets keyword, you can look at the contents of all HSRP packets:
Router2#debug standby packets
You can use the terse keyword to see a short form of all HSRP errors, events, and packets:
Router2#debug standby terse
HSRP is not a very complex protocol, and it is relatively simple to configure, so network engineers generally don't find that they need the sophisticated debugging tools that are available with other protocols. Consequently, HSRP debugging facilities were relatively limited until IOS level 12.1(0.2), when the enhanced debugging described here was introduced. However, these features can be useful when you are faced with strange HSRP problems such as general instability or multiple active routers.
We don't recommend starting with a packet-level debug for anything because it can easily overwhelm the router. In the case of HSRP, which should only send a hello packet every three seconds by default, this shouldn't be quite as dangerous as for many other protocols.
The debug standby terse command is probably the most useful option because it gives a short form output of all HSRP errors, events, and packets:
Router1#debug standby terse
HSRP:
HSRP Errors debugging is on
HSRP Events debugging is on
(protocol, redundancy, track)
HSRP Packets debugging is on
(Coup, Resign)
Router1#
From here, if you see a coup problem (for example), you might want to turn off the terse option and replace it with a full packet-level debug. Conversely, if you see that there is an issue with interface tracking, you might want to replace the terse option with the event option to get greater detail.
 |
|
|
| Top |