cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
746
Views
0
Helpful
10
Replies

Problems with HSRP and 6000 series switches

mwitko
Level 1
Level 1

Is anyone aware of any problems with running HSRP and using 6000 series switches? I support multiple sites and we are starting to see problems with HSRP. On one site we are using two 7500 routers to do the routing and run HSRP. On a couple of others we have MSFC cards to do the routing and run HSRP. Some examples of errors that we are seeing when running HSRP. One site was having 80% packet loss. Anouther had a delayed connection to servers running HP Unix. Still another had the network going up and down and losing connetions between workstations and servers. The way we fixed these problems was to go and shutdown the interface on the router that was the backup for HSRP. All these problems had a simular fix. I was just wondering if anyone out there was seeing simular problems? We also have sites with 5000 series devices running HSRP and we have no issues.

10 Replies 10

mfaust
Level 1
Level 1

How are you configured? Is "preempt" configured? Have you set priority on the routers? Have you adjusted your timers? Have you assigned an HSRP IP address? I have not had any trouble with HSRP in any environmnet except with one AIX server (old code in server - could not clear the ARP cache) and this was not a problem with HSRP. As far as I can tell, HSRP works great.

here is an example of two interfaces. I have changedthe Ip address information.

Router 1.

interface FastEthernet2/0/0

description VLAN 11

ip address 8.1.5.2 255.255.248.0

ip helper-address 8.1.5.143

ip helper-address 8.1.5.52

no ip redirects

full-duplex

standby 11 priority 150

standby 11 preempt

standby 11 8.1.5.1

hold-queue 300 in

router 2

interface FastEthernet2/0/0

description vlan 11

ip address 8.1.5.3 255.255.248.0

ip helper-address 8.1.5.143

ip helper-address 8.1.5.52

no ip redirects

full-duplex

standby 11 priority 100

standby 11 preempt

standby 11 ip 8.1.5.1

hold-queue 300 in

!

That is what the configs look like for all the interfaces. When I do a show standby everything looks fine and I can ping the interfaces and HSRP addresses fine from almost anywhere. We just have these strange problems that crop up and cause us to have to shut down HSRP to fix them. It is almost as if the Servers and Workstation won't recognize the HSRP addresses.

Thanks

By anychance are the "endpoints" of the routers being bridged or on say a hub type device? I had a similar problem with Cisco 7000 routers where the end point was a FDDI hub; i.e. not switched or routed. The problem was the CDP packets were not propagating properly between the HSRP interfaces. I too had to shut one interface down to "force it" to the other.

A Spanning Tree loop or wiring loop will also cause strange HSRP functionality.

You may want to put a sniffer at some middle point and see what the routers are sending to each other and then force one interface down, etc.

http://www.cisco.com/warp/public/473/62.shtml

No bridges or hubs are present. The main problem that we are having is with servers directly plugged into the 6500 switches. I checked the networks for spanning tree loops and I don't see any. I also kept my eye on the loggs in the switches and the routers and they both look clean. I can even change priority on the HSRP interfaces or take one down and they do thier job by one taking over for the other with no delay. As far as the Cisco devices think HSRP is running fine. This mainly seems to be a problem on the workstations or servers not understaning HSRP. I have tried clearing the ARP cache on the routers, the workstations, and the servers but have had no luck. The only time the problem seems to fix itself is when I disable the interface on the secondary router which basically disables HSRP. My gut feeling that it has something to do with the arp tables either in the router or in the worksations and servers but I can't seem to pinpoint the error. The really wierd thing is that the workstations and servers respond to pings and traceroutes. They just don't seem to respond to application requests such as telnet without a long delay. We are running an older version of code on the 6500 5.5(3). I am planning an upgrade to 6.3(5) in the near future.

I tried to reply but it got lost - I'll try again. Your router config looks good - what about your servers and workstations? They should have their default gateway set to the HSRP address (8.1.5.1). Is HSRP stable? (debug hsrp) What is the layer two to layer three mapping in the workstations and servers? (arp -a)

Good comment. I have yet to compare the arp cache in the workstations and servers with that of the routers for the HSRP interface. I will give that a try and see if they match.

That IS strange. The servers and works stations shouldn't even be aware that

HSRP is running - it certainly sounds like the 6500 sw is doing something wrong.

Cisco does offer this caveat about HSRP:

" The use of vLAN encapsulations in conjunction with HSRP requires higher layers of software to be aware of MAC addresses embedded in the vLAN framing. Because of this IOS needed to be enhanced to deal with the MAC logic of HSRP in higher layers of software. Therefore, there are no issues with the use of the same MAC address on each several of the vLAN interfaces or on different interfaces in conjunction with the RSM or any other platform, since they are on logically separate interfaces with respect to the software. However, with the use of vLANs, there can exist network typologies, where the HSRP peers are separated by different media and devices, such that the takeover of routing responsibility by a standby router might not be immediately visible to all host devices. This can be the case because of different aging timers and cached entries in some switching devices and the existence of devices between the peers..."

If your force HSRP, what does your routing table look like immediately after?

"Show standby brief "looks ok?

You are right - the workstations and servers should not be aware that HSRP is running, but if they are not configured correctly , they will fail. For example; if a workstation has a default route to one of the routers ip address instead of the HSRP address, and the interface fails, the workstation will lose access to services off their local subnet.

The workstations and servers have the ip address of the HSRP interface for the default gateway. Standby brief looks fine after I force HSRP but the workstations still loose connectivity. It does sure seem like a software error with either the 6000 or the router. The one site that is using a 7000 has an old version of code 11.1(28)CA running on it. I think I am going to do a code upgrade first before I start going into desperate measures. My gut is just telling me that an upgrade will really help.

rfroom
Cisco Employee
Cisco Employee

HSRP uses multicast hello messages to work. Most HSRP problems are actually symptoms of a bigger problem like bad hardware or Spanning-tree problems, or DOS attacks, etc.

Are you seeing continuous HSRP standby states on the routers, broadcast storms on the network, or duplicate address messages.

Check out the following troubleshooting document for more details on troubleshooting HSRP.

http://www.cisco.com/warp/customer/473/62.shtml

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: