Strange switch behaviour in VLAN network

G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

Hi all,

I'm experiencing some weird problems in our switched network
and am really stuck there. Our configuration is the following:

We've got an Extreme Summit1i 8 x SX GBit basic layer 3 switch
(OS Version 7.2) working as "backbone switch", to which all our
other switches are connected. Our floor switches are stacked 3Com
3300s release 1 with current firmware, the servers are connected
via a Summit48i (also basic layer 3).

We have configured VLANs on all the 3Com switches and the Summits
and disabled STP (all VLANs are located on one floor switch only).
The two Summits exchange their VLAN information via the proprietary
EDP (extreme discovery protocol) and their VLAN tables look correct.
This configuration was working fine for two years until recently.

Suddenly all the switches started to drop packes for alternating
destinations without apparent reason. For debug reasons I connected
one of the servers directly to the backbone switch and saw that
from time to time the server wasn't able to ping the ip address
of the switch (i.e. its default gateway) and couldn't reach into
some floor networks, but at the same time a continuous ping from
a computer on the Summit48 to this server ran without any drops.

To illustrate that, here are some excerpts from the configurations:

------- Summit1 default VLAN ---------
VLAN Interface[0-200] with name "Default" created by user
Tagging: 802.1Q Tag 1
Priority: 802.1P Priority 7
IP: 192.168.0.1/255.255.240.0
STPD: s0(Disabled,Auto-bind)
Protocol: Match all unfiltered protocols.
Loopback: Disable
RateShape: Disable
QosProfile:QP1
QosIngress:None
Ports: 8. (Number of active ports=7)
Flags: (*) Active, (!) Disabled
(B) BcastDisabled, (R) RateLimited, (L) Loopback
(g) Load Share Group
Untag: *1 *2 *3 *4 *5 *6 7 *8
---------------------------------------

-------- Summit1 VLAN ITS -------------
VLAN Interface[10-20a] with name "ITS" created by user
Tagging: 802.1Q Tag 51
Priority: 802.1P Priority 7
IP: 192.168.51.254/255.255.255.0
STPD: s0(Disabled,Auto-bind)
Protocol: Match all unfiltered protocols.
Loopback: Disable
RateShape: Disable
QosProfile:QP1
QosIngress:None
Ports: 1. (Number of active ports=1)
Flags: (*) Active, (!) Disabled
(B) BcastDisabled, (R) RateLimited, (L) Loopback
(g) Load Share Group
Tagged: *2
----------------------------------------

The switch with the clients in ITS VLAN is indeed connected to
port 2 of the Summit1.

-- 3Com floor-switch 192.168.0.243 default VLAN ---------
VLAN ID: 1 Local ID: 1 Name: Default VLAN

Unit Ports
1 none
2 24, 25

Unicast Frames: 902 Octets: 4296726
Multicast Frames: 2796 Broadcast Frames: 55253
----------------------------------------------------------


----------- 3Com floor-switch 192.168.0.243 ITS VLAN ------------
VLAN ID: 51 Local ID: 6 Name: UHD4

Unit Ports
1 9, 10, 11, 12, 13, 14, 15, 16
2 25

Unicast Frames: 90195 Octets: 48910162
Multicast Frames: 0 Broadcast Frames: 253
-----------------------------------------------------------------

STPState on the 3Com is "disabled".

What really startles me is that both the Summits and the 3Coms show
the same behaviour, you can connect to them, ping them, and without
visible reason they become unavailable for some time, but they still
forward packets for other destinations.

I'd be really grateful for any hints where to look, and I thank
everyone in advance who reads through my rather lengthy description.

-Chris
 
G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

HI Chris,

I do not understand why you Disable STP states of SWITCH.
Usually PORT drops packets if it is in DISABLE state.
But CPU should runs STP protocol and gradually all port should be in
configured in FORWARING stage by CPU.

Please correct me if i am wrong.

Regards
Dilip.

Christian Winter wrote:
> Hi all,
>
> I'm experiencing some weird problems in our switched network
> and am really stuck there. Our configuration is the following:
>
> We've got an Extreme Summit1i 8 x SX GBit basic layer 3 switch
> (OS Version 7.2) working as "backbone switch", to which all our
> other switches are connected. Our floor switches are stacked 3Com
> 3300s release 1 with current firmware, the servers are connected
> via a Summit48i (also basic layer 3).
>
> We have configured VLANs on all the 3Com switches and the Summits
> and disabled STP (all VLANs are located on one floor switch only).
> The two Summits exchange their VLAN information via the proprietary
> EDP (extreme discovery protocol) and their VLAN tables look correct.
> This configuration was working fine for two years until recently.
>
> Suddenly all the switches started to drop packes for alternating
> destinations without apparent reason. For debug reasons I connected
> one of the servers directly to the backbone switch and saw that
> from time to time the server wasn't able to ping the ip address
> of the switch (i.e. its default gateway) and couldn't reach into
> some floor networks, but at the same time a continuous ping from
> a computer on the Summit48 to this server ran without any drops.
>
> To illustrate that, here are some excerpts from the configurations:
>
> ------- Summit1 default VLAN ---------
> VLAN Interface[0-200] with name "Default" created by user
> Tagging: 802.1Q Tag 1
> Priority: 802.1P Priority 7
> IP: 192.168.0.1/255.255.240.0
> STPD: s0(Disabled,Auto-bind)
> Protocol: Match all unfiltered protocols.
> Loopback: Disable
> RateShape: Disable
> QosProfile:QP1
> QosIngress:None
> Ports: 8. (Number of active ports=7)
> Flags: (*) Active, (!) Disabled
> (B) BcastDisabled, (R) RateLimited, (L) Loopback
> (g) Load Share Group
> Untag: *1 *2 *3 *4 *5 *6 7 *8
> ---------------------------------------
>
> -------- Summit1 VLAN ITS -------------
> VLAN Interface[10-20a] with name "ITS" created by user
> Tagging: 802.1Q Tag 51
> Priority: 802.1P Priority 7
> IP: 192.168.51.254/255.255.255.0
> STPD: s0(Disabled,Auto-bind)
> Protocol: Match all unfiltered protocols.
> Loopback: Disable
> RateShape: Disable
> QosProfile:QP1
> QosIngress:None
> Ports: 1. (Number of active ports=1)
> Flags: (*) Active, (!) Disabled
> (B) BcastDisabled, (R) RateLimited, (L) Loopback
> (g) Load Share Group
> Tagged: *2
> ----------------------------------------
>
> The switch with the clients in ITS VLAN is indeed connected to
> port 2 of the Summit1.
>
> -- 3Com floor-switch 192.168.0.243 default VLAN ---------
> VLAN ID: 1 Local ID: 1 Name: Default VLAN
>
> Unit Ports
> 1 none
> 2 24, 25
>
> Unicast Frames: 902 Octets: 4296726
> Multicast Frames: 2796 Broadcast Frames: 55253
> ----------------------------------------------------------
>
>
> ----------- 3Com floor-switch 192.168.0.243 ITS VLAN ------------
> VLAN ID: 51 Local ID: 6 Name: UHD4
>
> Unit Ports
> 1 9, 10, 11, 12, 13, 14, 15, 16
> 2 25
>
> Unicast Frames: 90195 Octets: 48910162
> Multicast Frames: 0 Broadcast Frames: 253
> -----------------------------------------------------------------
>
> STPState on the 3Com is "disabled".
>
> What really startles me is that both the Summits and the 3Coms show
> the same behaviour, you can connect to them, ping them, and without
> visible reason they become unavailable for some time, but they still
> forward packets for other destinations.
>
> I'd be really grateful for any hints where to look, and I thank
> everyone in advance who reads through my rather lengthy description.
>
> -Chris
 
G

Guest

Guest
Archived from groups: comp.dcom.lans.ethernet (More info?)

dilip_1379@hotmail.com wrote:
> HI Chris,
>
> I do not understand why you Disable STP states of SWITCH.
> Usually PORT drops packets if it is in DISABLE state.
> But CPU should runs STP protocol and gradually all port should be in
> configured in FORWARING stage by CPU.
>
> Please correct me if i am wrong.

I may be wrong, but i thought STP is only neccessary if a
VLAN spans multiple switches. Besides, the configuration
was up and running like this for more than 3 years without
problems. But nonetheless i should propably really do
some reading on STP.

Today we found out that the Summit48 switch that is
connected to the Summit1 answers arp requests for some
VLAN devices with a wrong MAC address. The MAC address
it gives back belongs to our old Summit1 that has been
replaced due to a memory failure some weeks ago.

Tomorrow i'm going to restart the Summit48 and do some
sniffing to see if the ARP issue is resolved, then i'll
give a short status here. (Strangely, it reports back the
MAC but it doesn't even hold it in its ARP database, so
i'll simply take out the power plug for a minute or two
and see if some magical place in memory gets flushed).

Thanks very much
-Chris
 

TRENDING THREADS