3750 stachwise configuration issue

[kokhong.chew]

I got 2 x 3750 switched stackwise configured, the master unit failover work fine but not the secondary unit in which connectivity is lost to the other end of the WAN link with similar 3750 setup. EIGRP is configured as the routing on both sides of the WAN link.

Till i clear the mac-address-table, then i am able to ping the other side of the WAN link and connectivity seem to restored back.

Please advise, thanks

[Giuseppe Larosa]

Hello Kok,

a possible hint is the following:

Enabling Persistent MAC Address

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_46_se/configuration/guide/swstack.html#wp1206500

Hope to help

Giuseppe

[kokhong.chew]

Hi Giuslar

             It is disabled . . .

CORE_SPRING#1#sh switch
Switch/Stack Mac Address : 0022.9061.1580
                                           H/W   Current
Switch#  Role   Mac Address     Priority Version  State
---------------------------------------------------------
*1       Master 0022.9061.1580     1      0       Ready
2       Member 0022.907e.6680     1      0       Ready

[Reza Sharifi]

Hello Kok,

*1       Master 0022.9061.1580     1      0       Ready
2       Member 0022.907e.6680     1      0       Ready

Why do both switches have priority 1? Your master should have a higher priority.

HTH

Reza

[kokhong.chew]

set the master to higher priority, is it necessary ?

I have another 3750 stackwise with the same configuration over the other end of the WAN link and they are working fine.

[Reza Sharifi]

The switch you chose as a master, should have higher priority, so you always know which switch is the master.

From the config guide for Cisco 3750 switches:

We recommend assigning the highest priority value to the switch that you prefer to be the stack master. This ensures that the switch is re-elected as stack master if a re-election occurs.

Please refer to this document for more info:

http://www.cisco.or.at/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_se/configuration/guide/swstack.html#wp1153255

HTH

Reza

[Giuseppe Larosa]

Hello Kok,

the note from Reza is meaningful you should declare what switch should be the master by rising its priority.

the measure about MAC address persistent can be of help in case of switchover: without it the standby switch when becomes master uses its own set of MAC addresses for STP and also for SVI vlan interfaces.

As a result of this neighbors cannot contact it until they clear the ARP entry.

So I see some relationship with your issue. it's not clear if you have cleared the ARP table on the stack or on the neighbor devices

if we look at your show we see:

CORE_SPRING#1#sh switch
Switch/Stack Mac Address : 0022.9061.1580
                                           H/W   Current
Switch#  Role   Mac Address     Priority Version  State
---------------------------------------------------------
*1       Master 0022.9061.1580     1      0       Ready
2       Member 0022.907e.6680     1      0       Ready

as you can see the second switch has a different own MAC address enabling persistency would cause it to use the same MAC in case of switchover making it transparent for neighbors

Hope to help

Giuseppe

[kokhong.chew]

Hi Giuseppe

I clear the arp first, but still cannot ping the other end of the WAN link

Next, i clear the mac-address-table and able to access the other side of the WAN link thereafer.

Note that i have no problem pinging all the local subnets during the failover of both switches.

[davy.timmermans]

About switch priority,

Just want to add that being master: it's not preemptive. So if your master has a higher priority, and you boot the master, the other switch will become master and remain master as long it's up. Even if it has a lower priority.

[Giuseppe Larosa]

Hello Kok,

what if you clear the ARP table on the remote end of the WAN link?

the fact that clearing the CAM table, the MAC address table helps appears strange.

your WAN link is probably a L2 bundle including one link from switch1 and one link from switch2 and connecting to a remote stack.

I wonder if clearing the MAC address table leads to some MAC flooding and in a indirect way to update the ARP table of remote device.

Hope to help

Giuseppe

[kokhong.chew]

Hi Giuseppe

                   Well, we didnt try to clear arp on the remote end because its stackwise 3750 configured similar have no problem during the failover test. May i know why the need to clear arp on the remote end.

                   You are right that the WAN link is L2 bundled.

[Giuseppe Larosa]

Hello Kok,

the change of switch master without MAC address persistency should cause a change of MAC address used by SVI interfaces on the local stack, this should result in incorrect ARP entries on neighbors like when we change a NIC in a PC.

Hope to help

Giuseppe

[kokhong.chew]

Hi Giuseppe

            Since the stack-mac persistent is set to 0, shouldn't the stack MAC address of the previous stack master is still used until you enter the no stack-mac persistent timer command, which immediately changes the stack MAC address to that of the current stack master. If you do not enter the no stack-mac persistent timer command, the stack MAC address does not change as per Cisco's?

[Giuseppe Larosa]

Hello Kok,

I agree on this.

if your stack has this MAC address persistency enabled with 0 timer, the reasons of your issue are different but should be in the ARP anyway, or related to STP.

I guess your test uses switching off old stack master switch and seeing the results.

Are the devices directly connected on the WAN bundle? Can the remote site detect that one link is down on the  local stack?.

Are you using LACP on the etherchannel bundle?

I wonder if the remote site can stay stucked thinking it can still use the link to the switch that has been powered off.

Hope to help

Giuseppe

[kokhong.chew]

Hi Giuseppe

I too think it is arp or stp issue here since they connect to the WAN bundle via a L2 switch C2960

No etherchannel configured.

I still can reach the the remote WAN during the failover but not the the remote 3750 stackwise.

This remote 3750 stackwise have no problem with the failover and both stackwise are configured similarly.