Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Community Member

SG300 - possible Bug regarding Vlan-Interfaces in Release 1.3.7.18

Hi,

 

Today we had a strange problem at one of our customers productive environments. They have 6 SMB Switches, of which 3 were suddenly unreachable. All 3 (B, C, D) are daisy-chained behind switch (A). The trunk from A to B was up and ok, vlans active, L2-status ok. 

"show cdp neigh det" showed the correct output, also with the management IP of B, but it was unreachable. After reboot of B same issue. Rebooted switch A, after reboot it had the same issue. Trunk from our core to A ok, vlans up and active, cdp ok - but not reachable. 

 

Established connection to A via console, all status ok, but still not working. After 2 more reboots, switch A came up again. 

 

Console to B -> ping to it's own interface not working (sh ip int vlan shows UP/UP). Reboot doesn't help. Shut/noShut -> Switch working again. 

Same procedure on C and D, both showing interface as UP/UP, but only reachable after a shut/no shut. 

 

The topology is plain - only one VLAN in use for Mgmt and Clients.

I can't really explain why a reboot of the whole switch didn't have any impact, but a reset of the interface had. 

 

Any ideas?

 

BR,

Amir

2 REPLIES
Cisco Employee

Hi Amir,first of all I assume

Hi Amir,

first of all I assume that all switches use different IP addresses.

Since the topology is flat we might need to look at the following:

1. physical layer - if the duplex are speed are negotiated correctly, test even with static settings

2. check the cabling 

3. you may also look at the mac address table and entries for corresponding uplink ports 

4. if all above would not indicate any issue I would check for arp response - packet capture on uplink ports when trying to initiate ping

I hope this would give you some idea what is happening.

Aleksandra

 

 

Community Member

Hi Aleksandra, Thanks for

Hi Aleksandra, 

Thanks for your time and advice. Regarding your points:

- Yes, switches use of course different IP-addresses (192.168.0.x). Everything was working properly.

- Physical Layer - from my point of view impossible, because L2 seemed completely ok. I could see the cdp neighbour, uplinks, traversing vlans, spanningtree - everything ok. 

- Cabling - same as above.

- Regarding MAC address table, seemed also ok. On Switch A I could see MAC-addresses on the downlink to B.

- Since Monday, when the problem was solved the network is stable without any problems. So a packet-capture won't have any effect now, until it happens again. But if it happens again, we will get some serious troubles with the customer, because it's a production environment. :)

 

P.S.: Dot1x is running also on the switches. Since the ip-interfaces of the switches made problems, also the connection to the RADIUS failed. I think this was the reason for the failed-user-connectivity. Otherwise the users wouldn't have any problems, only the switches would have been unmanagable.

 

But the main question remains - why did the VLAN-interfaces went down - but were shown as up?

As mentioned, they weren't even pingable by themselves before the shut/noshut. 

 

In the first step I think of upgrading all devices to 1.4.0.88 this weekend. Any recommendations?

BR
Amir

247
Views
0
Helpful
2
Replies
CreatePlease to create content