PowerConnect 6248 LAG and spanning tree protocol

A LAG is just like a port.  If STP is enabled on the switch, then it is enabled on the LAG by default.

For PowerConnect switches, when a port is in a LAG, its port specific configuration is not used.  The configuration of the LAG is applied to the member ports.

Whether or not to enable STP on any port or switch depends on the requirements of your network.  PROS: no loops, redundancy.  CONS: possible loops

What would be the benefits of using LACP in such setup and would you recommend it?

Thanks.

If the two ports LAG is the only interconnection between the two switches, is it safe to not enable STP?

We're going to use the two PowerConnect switches for connecting ESX servers and EqualLogic arrays: each server/array will have at least one connection to each switch for redundancy.

Would you still enable STP in such scenario?

What about the portfast option?

Thanks.

If there is no chance of a loop, you can disable STP.

Connecting multiple NICS from the servers and arrays to each of the switches will not create a loop since the NICS will not bridge traffic.

LACPs main benefit is to help prevent cabling mistakes.  It adds complexity to your simple set up, so I would not bother.

I have STP enabled as by default on the two PowerConnect 6248 switches interconnected with the LAG (2x1GbE) and I hit an issue while testing the redundancy of the network.

After rebooting root STP switch, when it comes back online, all the ports on the other switch will stop working for a few seconds (e.g. pinging the other switch management IP address from a server directly connected to it won't get any replies for a few seconds, then it will get back working as normal).

Since they are two separate switches connected with a LAG, I didn't expect that rebooting one of them could also affect the other!

(BTW, if I reboot the other switch, the ports on switch with is root for STP won't suffer any interruption)

I'm including the console logs from the switches in question below: switch2 is the root STP switch that I reload and switch1 is the other switch which suffers the issue when the first switch comes back online, LAG 3 is the interconnection.

Is this behavior normal? Any way to prevent the issue (besides completely disabling STP)?

What I'm looking is a way to completely manage the two switches separately for a fully redundant network (of course each server and SAN array will have a connection to one switch and another connection to the other switch) and rebooting one shouldn't bring down connectivity on the ports of the other.

Thanks.

I did some research, but I'm still not sure if what I'm seeing is the expected behavior or if it's a incorrect configuration ...

And besides completely disabling STP, I still didn't find a way to prevent the issue.

Any help would be appreciated.

Thanks.

Yes, this is fully expected behaviour. Look at these lines from your log:

<189> MAY 26 21:59:29 192.168.10.34-1 TRAPMGR[214618784]: traputil.c(906) 319 % Unit 1 Port 2 is transitioned from the Forwarding state to the Blocking state in instance 0

***PING REPLY STOPS AROUND HERE***

***PING REPLY STARTS WORKING AGAIN AROUND HERE***

<189> MAY 26 21:59:59 192.168.10.34-1 TRAPMGR[214618784]: traputil.c(906) 345 % Unit 1 Port 2 is transitioned from the Learning state to the Forwarding state in instance 0

Topology change puts by default all ports into blocking state and STP needs 30 seconds to move a port into forwarding state when no BPDUs are received.

For your configuration, there's no need for spanning tree. But if you still want to use it, observe these rules:

- use RSTP for fast convergence

- configure all end-station/server ports with "spanning-tree portfast" to ensure that topology changes don't affect them

- ports that interconnect switches must not be configured with "spanning-tree portfast"

We'll also have to connect a Juniper firewall to each switch and the two Juniper firewalls will be interconnect between them with an ethernet cable for HA (using NSRP).

Is it still safe to completely disable spanning tree on the two switches for our setup?

Also, for some further testing, we connected an older PC5324 switche to the PC6248 switches using a LAG (2 x 1GbE ports)  and we didn't experience any network disruption on it while rebooting the STP root PC6248 switch (while we still experienced the issue on the other PC6248 switch). The PC5324 appear to be using the default spanning tree settings. Any ideas why it doesn't seem to suffer the same issue of the newer switch?

Thanks.

After upgrading the two PowerConnect 6248 from firmware version 2.2.0.3 to 3.2.0.7, keeping the same config, it appears that there is an improvement with network downtime issue on the other switch when rebooting the STP root switch: the ping test from above loses about 7-8 replies, while it didn't get any reply for about 30 seconds with the previous firmware version.

We're still leaning towards completely disabling STP on the two switches.

Is that still safe even connecting the Juniper firewalls as outlined in my previous post?

Also, I still wonder why the older PowerConnect 5324 doesn't exhibit the same issue as the newer PowerConnect 6248 ...

Thanks.

1/20/2012 8:26:09 AM, 23, 5, 127.0.0.1, Jan 20 08:26:09
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:46 172.16.11.206-1
TRAPMGR[152288304]: traputil.c(611) 769 %% Link Up: 1/0/48

1/20/2012 8:26:09 AM, 23, 5, 127.0.0.1, Jan 20 08:26:09
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:46
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 768 %% 1/0/48 is transitioned
from the Learning state to the Forwarding state in instance 0

1/20/2012 8:26:09 AM, 23, 5, 127.0.0.1, Jan 20 08:26:09
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:46
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 767 %% 1/0/48 is transitioned
from the Forwarding state to the Blocking state in instance 0

1/20/2012 8:26:06 AM, 23, 5, 127.0.0.1, Jan 20 08:26:06
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:43
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 766 %% Link on 1/0/48 is
failed

1/20/2012 8:26:06 AM, 23, 5, 127.0.0.1, Jan 20 08:26:06
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:43
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 765 %% Link Down: 1/0/48

1/20/2012 8:26:06 AM, 23, 5, 127.0.0.1, Jan 20 08:26:06
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:43
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 764 %% 1/0/48 is
transitioned from the Forwarding state to the Blocking state in instance 0

1/20/2012 8:25:59 AM, 23, 5, 127.0.0.1, Jan 20 08:25:59
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:36
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 763 %% Link Up: 1/0/48

1/20/2012 8:25:59 AM, 23, 5, 127.0.0.1, Jan 20 08:25:59
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:36
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 762 %% 1/0/48 is
transitioned from the Learning state to the Forwarding state in instance 0

1/20/2012 8:25:59 AM, 23, 5, 127.0.0.1, Jan 20 08:25:59
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:36
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 761 %% 1/0/48 is
transitioned from the Forwarding state to the Blocking state in instance 0

1/20/2012 8:25:55 AM, 23, 5, 127.0.0.1, Jan 20 08:25:55
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:32
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 760 %% Link on 1/0/48 is
failed

1/20/2012 8:25:55 AM, 23, 5, 127.0.0.1, Jan 20 08:25:55
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:32
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 759 %% Link Down: 1/0/48

1/20/2012 8:25:55 AM, 23, 5, 127.0.0.1, Jan 20 08:25:55
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:32
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 758 %% 1/0/48 is
transitioned from the Forwarding state to the Blocking state in instance 0

1/20/2012 8:25:54 AM, 23, 5, 127.0.0.1, Jan 20 08:25:54
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:31
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 757 %% Link Up: 1/0/48

1/20/2012 8:25:54 AM, 23, 5, 127.0.0.1, Jan 20 08:25:54
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:31
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 756 %% 1/0/48 is
transitioned from the Learning state to the Forwarding state in instance 0

1/20/2012 8:25:54 AM, 23, 5, 127.0.0.1, Jan 20 08:25:54
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:31
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 755 %% 1/0/48 is
transitioned from the Forwarding state to the Blocking state in instance 0

1/20/2012 8:25:50 AM, 23, 5, 127.0.0.1, Jan 20 08:25:50
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:28
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 754 %% Link on 1/0/48 is
failed

1/20/2012 8:25:50 AM, 23, 5, 127.0.0.1, Jan 20 08:25:50
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:28
172.16.11.206-1 TRAPMGR[152288304]: traputil.c(611) 753 %% Link Down: 1/0/48

1/20/2012 8:25:50 AM, 23, 5, 127.0.0.1, Jan 20 08:25:50
172.16.11.206 RealSource:"172.16.11.206"  JUL 30 07:51:28 172.16.11.206-1
TRAPMGR[152288304]: traputil.c(611) 752 %% 1/0/48 is transitioned from the
Forwarding state to the Blocking state in instance 0

we have an issue regarding our switches as well that we loos the network suddenly for some minutes and then gets back to normwal please check our logs ?

Had a similar occurence - is this expected?

I have a 2-switch (Dell 6224) SAN network connected to a PS6000.   The two 6224's are uplinked on a 3-port LAG.  I was turning OFF STP for all ports on switch1 per EQ recommendations, but doing this one-by-one (port-by-port) to alleviate any network interruptions.  I got lazy and lost track of where I was, and turned off STP on port 22 (#1 member of LAG).  As soon as I hit APPLY, the entre network of VM's lost network connectivity.

After 30 to 60 seconds, I finally remembered which port I was on so I yanked the link cable out of port 22 on both switches.  The VM's started coming back on the network a few seconds later.

A).   Would changing this individual port setting cause this?
B).  If STP settings for a LAG are set by the LAG STP settings, why did the individual port setting (apparently) cause this?  STP is still on for the LAG.
C).  Did yanking the cable fromn the port fix the issue, or did the STP convergence coincidentally complete about the time I yanked the cable?

Because the SAN network is isolated stricly for iSCSI traffic and one physical dual-homed management server, our intention is to disable STP for all switch ports - except the LAG (with no PORTFAST).

It is possible that simply making changes to the STP configuration on the switch set off a re-convergence of STP on the switch.  This would cause the a relearning of the redundant paths on the network.  Then at the same time you pulled the plug it completed the process and started communicating.

I would also recommend that you have the latest firmware installed.

v3.3.3.3

www.dell.com/.../DriverFileFormats

Hope this helps,

Keep us updated if you can.

Hi, my problem is similar, We have in test configuration one SW 6248 with 
ports 1 and 2 (LAG 1)
ports 3 and 4 (LAG 2)
ports 5 and 6 (LAG 3)

on the other side in
floor 1, 1 sw 3448 with port G3 and G4 (LAG 5)
floor 2, 1 sw 3448 with port G3 and G4 (LAG 5)
floor 3, 1 sw 3448 with port G3 and G4 (LAG 5)

connected as follows
LAG 1 (6248) to LAG 5 (floor 1 3448)
LAG 2 (6248) to LAG 5 (floor 2 3448)
LAG 3 (6248) to LAG 5 (floor 3 3448)

each LAG  port is configured as trunk, but the spanning tree protocol block ports !!!

please suggest me the best scenario.

Thank's

I would recommend updating the firmware to the latest version on all the switches.

PC6200v3.3.3.3

www.dell.com/.../DriverFileFormats

Dell PowerConnect 3448 fw2.0.0.34

www.dell.com/.../DriverDetails

Make sure you have the same or as close to the same configuration on either end of a particular LAG.  Whether it is Rapid Spanning or classic STP.  What is the reason for naming the lag on the 3448 LAG 5.  Can you not set up the LAG configuration like the example below.  Can you provide information as to why it is set up that way?

ports 1 and 2 (LAG 1)-- floor 1, 1 sw 3448 with port G3 and G4  (LAG 1)

ports 3 and 4 (LAG 2)-- floor 2, 1 sw 3448 with port G3 and G4  (LAG 2)

ports 5 and 6 (LAG 3)-- floor 3, 1 sw 3448 with port G3 and G4  (LAG 3)

Where are you seeing that the LAG has blocking ports?  Can you provide output of the spanning tree status on the LAG?

console(config)#show spanning-tree port-channel 1