problem with 3750 switches in stack

[rlopez]

hi everybody,

I have netwrok problems with this four switches which are in a stack the models are  two WS-C3750-24PS-S, one WS-C3750G-48PS-S and one  WS-C3750G-24TS-S1U all of the have the same IOS version C3750-IPBASE-M 12.2(35)SE5. network starts having wierd behavior, sometimes one of the switches restarted (last one), some other times IP phones get their IP address fromo data DHCP instead of voice DHCP so, telephones don't register with call manager and users connected to those telephones don't have network access, other behavior is that ports are working ok and suddenly they just stop working. I saw this error message in the console of the stack

%PLATFORM_RPC-3-MSG_THROTTLED: RPC Msg Dropped by throttle mechanism: type 37, class 14, max_msg 32, total throttled 1205 (SW-SUSOC-GDL-1)

at this momment I unplugged the stack cables from the switches connected each them through an uplink using ethernet port. when I issue the "show switch" command I get this

Switch/Stack Mac Address : dc7b.942c.d880
                                           H/W   Current
Switch#  Role   Mac Address     Priority Version  State
----------------------------------------------------------
1       Member 0000.0000.0000     0      0       Provisioned
*2       Master dc7b.942c.d880     2      0       Ready
3       Member 0000.0000.0000     0      0       Provisioned
4       Member 0000.0000.0000     0      0       Provisioned

Although they don't have stack cable anymore and I restarted the swtiches after removing the cables.

sometimes I don't have connectivity to the servers.

Does anybody know if it is a bug? or I probably misconfigured something

Thank you in advance for helping me,

Alex

[andtoth]

Hi,

Do you have "snmp-server ifindex persist" configured on the 3750 stack? If so, please remove it as this can cause these kind of errors because it is not supported on 3750 switches.

Do you receive a Traceback as well? If yes, please share it together with the 'show version' output, so that we can decode it.

If you could attach the complete running configuration of the stack, that might be valueable as well.

Best regards,

Andras

[rlopez]

Hi Andras,

Thank you for your reply, the switch had the commands

snmp-server community private RW
snmp-server enable traps license

but I removed the last one and the behavior is the was the same. I tryied to get the traceback but it wasn't shown. Right now I don't have the stack since I thought it might cause the problems

I'm attaching show version of one of the switches and the show run of the stack

[andtoth]

Hi,

A few observations here.

"snmp-server community private RW" is not recommended because "private" is the default community name and RW means remote modifications to the switch (link shutdown, reload, etc) are allowed over SNMP.

When you remove the stack cables and use the switches as standalone, they will initially have the same configuration because while they were in stack they synchronized it. Therefore you might encounter problems later if you run them as standalone without making the necessary configuration modifications because they might have duplicate IP addresses on the Vlan interfaces.

I would suggest to connect the switches one by one to the stack and check when do you encounter the RPC error or if you start observing errors regarding the stack ports. If you start seeing it when a new switch is added to the stack it might indicate a hardware failure of the switch. Make sure that the stack cables are properly seated and tightened. If you have spare stack cables, also try swapping the cables to see if it solves the problem.

You can also check the 'show logging' and 'show switch' outputs to see which switch is not seen or which stack ports are down.

Please note that a switch add or remove to the stack needs to be powered down.

Best regards,

Andras

[rlopez]

Thank you Andras,

I'll remove the SNMP line and make the test you recommended me, as I have to power down the switches I think I'll have to do it on weekend. I'll let you know the results.

Regards,

Alex

[Julio Garcia]

I agree with Andras here , looks like you could of had a loose stack cable , which will lead to reboots and loss of connectivity as you have described

you should connect up the stack cables as below assuming switch 1 is on top and switch 4 is bottom..

switch1-to-switch2

switch2-to switch3

switch3-to-switch4

and then

switch 1-to switch4

do a .

#sh switch detail

to check all stack connections are okay

#sh switch stack-ring speed

should show 32G Full