HSRP config on 2 x 3560X switches

highknees69 · ‎11-14-2012

We recently setup a new network in our Hong Kong office and we are seeing some intermittant issues on the LAN. I wanted to see if I could get some advice on the configs to see if I missed something.

Overview. 2 x 3560X switches are our "core" for this small office. They are trunked together, are both routing and both running OSPF (sharing routes with an upstream ASA firewall for outbound access). There is a 2960G data access switch and a 3560 PoE voice switch that are connected up to the core switches with 2 trunk ports (1 to each 3560X).

The issue we are seeing is when we ping the standby IP (10.168.1.1), we will sometimes get long ping times 2, 4, 8 11ms, and then occasionally it will time out. We see the issue when pinging between machines on this vlan as well. It will be fine for a while (<1ms), but then it will show abnormal times for a bit. Since this is the first remote site we have setup for HSRP, I'd like make sure we aren't missing something simple.

The core switches are WS-3560X-24T-E running 15.0(2)SE C3560E-IPBASEK9-M.

We have setup each of the VLAN interfaces for HSRP on the 3560X switches (call them core A [10.168.1.10] and core B [10.168.1.11]). Here is an example of the VLAN configurations:

Core A:

interface Vlan11

ip address 10.168.1.10 255.255.255.0

ip helper-address 10.168.1.14

standby version 2

standby 11 ip 10.168.1.1

standby 11 timers 5 15

standby 11 priority 150

standby 11 preempt

!

interface Vlan21

ip address 10.168.2.10 255.255.255.0

ip helper-address 10.168.1.14

standby version 2

standby 21 ip 10.168.2.1

standby 21 timers 5 15

standby 21 priority 150

standby 21 preempt

Core B:

interface Vlan11

ip address 10.168.1.11 255.255.255.0

ip helper-address 10.168.1.14

standby version 2

standby 11 ip 10.168.1.1

standby 11 timers 5 15

!

interface Vlan21

ip address 10.168.2.11 255.255.255.0

ip helper-address 10.168.1.14

standby version 2

standby 21 ip 10.168.2.1

standby 21 timers 5 15

When I do sh standby VLAN X, here are the results: (This appears correct)

Core A:

Vlan11 - Group 11 (version 2)

State is Active

5 state changes, last state change 2d00h

Virtual IP address is 10.168.1.1

Active virtual MAC address is 0000.0c9f.f00b

Local virtual MAC address is 0000.0c9f.f00b (v2 default)

Hello time 5 sec, hold time 15 sec

Next hello sent in 3.344 secs

Preemption enabled

Active router is local

Standby router is 10.168.1.11, priority 100 (expires in 15.456 sec)

Priority 150 (configured 150)

Group name is "hsrp-Vl11-11" (default)

Core B:

Vlan11 - Group 11 (version 2)
State is Standby
    4 state changes, last state change 2d00h
Virtual IP address is 10.168.1.1
Active virtual MAC address is 0000.0c9f.f00b
    Local virtual MAC address is 0000.0c9f.f00b (v2 default)
Hello time 5 sec, hold time 15 sec
    Next hello sent in 0.384 secs
Preemption disabled
Active router is 10.168.1.10, priority 150 (expires in 14.416 sec)
    MAC address is acf2.c54d.2c41
Standby router is local
Priority 100 (default 100)
Group name is "hsrp-Vl11-11" (default)

Any help or suggestions on how to better troubleshoot would be much appreciated.

Joseph W. Doherty · ‎11-14-2012

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

What you've posted looks okay, but with just the information you've there's multiple possible issues. On one hand you just might be seeing different hosts occasionally responding slowly to ping requests as it's generally considered a low priority task, especially on switches. (Some Cisco devices support router responder aka SLA to provide much more accurate/timely responses.)

On the other hand with two "core" L3 switches, you might be allowing unicast flooding which could create transient delays. Might any other traffic cause transient congestion?

I see core "A" is the hot gateway for the two posted VLANs. Is this also true for all VLAN interfaces? Is you spanning tree topology rooted on same device? What "flavor" of STP are you using? Using Portfast or any similar options?

highknees69 · ‎11-15-2012

Thanks for the response Joseph.

We were looking at STP as well to see if that might be the issue. Both switches were configured with the default settings and both were participating in STP, but with the sam priority. It did show that the uplinks were forwarding/blocking correctly, but we added a higher priority to the Core A switch in order to ensure it was the root. I haven't had to deal with the particulars of spanning-tree, so it's possible something is amiss there.

As for the STP options, below is a summary of what is running

#sh spannin summary
Switch is in pvst mode
Root bridge for: VLAN0250
EtherChannel misconfig guard is enabled
Extended system ID is enabled
Portfast Default is disabled
PortFast BPDU Guard Default is disabled
Portfast BPDU Filter Default is disabled
Loopguard Default is disabled
UplinkFast is disabled
BackboneFast is disabled
Configured Pathcost method used is short

Name                   Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001                     0         0        0          4          4
VLAN0011                     0         0        0         14         14
VLAN0021                     0         0        0          4          4
VLAN0044                     0         0        0          8          8
VLAN0050                     0         0        0          4          4
VLAN0100                     0         0        0          6          6
VLAN0150                     0         0        0          4          4
VLAN0172                     0         0        0          4          4
VLAN0200                     0         0        0          5          5
VLAN0250                     0         0        0          4          4
---------------------- -------- --------- -------- ---------- ----------
10 vlans                     0         0        0         57         57
#

As for your other question, Core A is the hot gateway for all of the VLANs (by design). I only provided the two examples to shorten the message.

I did some additional testing with another site that is using a similar config (albeit that site has dual 5548 switches running NX-OS). I noticed a similar issue when pinging the virtual IP gateway from a host on the network. I would get inconsistent response times (it was much better), but I would occasionally see a 4 or 5ms response to a ping.

Traffic between hosts that are on the switch seem to be fine with <1ms on nearly every ping. Maybe this is normal behavior for reponse time on a virtual IP using HSRP?

Joseph W. Doherty · ‎11-15-2012

Disclaimer

The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.

Liability Disclaimer

In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.

Posting

Traffic between hosts that are on the switch seem to be fine with <1ms on nearly every ping.  Maybe this is normal behavior for reponse time on a virtual IP using HSRP?

Well, again, Cisco devices often consider responding to ping requests a low priority. Good chance you'll see the same behavior if you ping the switch's real IP too.

PS:

You might want to consider using rapid-PVST, although I don't think related to what you're seeing.

alfonso garcia · ‎11-21-2013

Hello Michael, i think you need to writte this command in the Core B too : "standby 11 preempt" and "standby 21 preempt" to negotiate the priority between cores. Tell me if it works : alfonect@gmail.com