Start a Conversation

Unsolved

This post is more than 5 years old

33383

June 25th, 2008 07:00

LAG and (R/M)STP settings on PC 6224 and PC 5234 switches

Hi we have new backbone setup for testing and experience some unwanted behaviour.

 

new LAN is configured as:

PC6224   PC6224   PC6224 PC6224 PC5324 -> laptop connected on port for ping respons testing.

 

All ping tests are performed simultaniously to ALL switches and the remote laptop using ping commands.  For this a laptop was connected to the second switch in the series.

 

All firmware up to date as of end of may 2008. 

 

Issue 1:If we modify LAG settings on the PC6224 models the network goes down for appr. 30 seconds and returns to a stable state again which is acceptable.However if we remove the LAG setting “L” in the ports on the PC5324 switch all switches go down and stay that way. All forwarding appears to stop with only two solutions. Remove the PC5324 from the backboneOrRestore the LAG settings by enabling LACP via the console/serial port.

 

Question: How is it possible that such a change on a PC6224 brings down forwarding on ALL switches? (Same change on the PC 6224 switches is not causing the same behaviour.)  

 

Issue 2:

The connection between two switches is stable but if we remove the SFP modules one by one the behaviour is not consistent.In one LAG no packet loss appears if we remove either one of the SFP’s or enable it again. In most cases however a time-out of appr. 30 seconds appears in packets to ALL switches. Two different people have reviewed the LAG settings and concluded they are the same for all LAG’s but something is different or defect?

 

Your advise/comments would be very much appreciated.

In my opinion the PC5324 switch should not be able to bring the whole network down. Worst case it needs to be replaced by a PC6224 to prevent the situation from happening again. 

 

In both issues the appr. 30 seconds is likely to be the 28 seconds that STP needs to rebuild communicate the topology and STP-tree. I thought that RSTP should fix this but even with all switches set to RSTP the same behaviour occurs.

 

Thanks to Bruce Holmes info on LAG functionality in the PC5316M I understand that in my ping tests only one link is used and that if we remove a Fiber Optic it will need to fialover to another link. In my opinion this should still be within a second not 28-30!  Did we miss something on the STP settings for the switch port or LAG ? 

 

Gert-Wim 

June 25th, 2008 21:00

For clarity - are you really saying you backbone is a "chain" of switches, with Aggregated fibre optics links between each switch ?

 

Why do you think spanning tree (normal or RSTP) would be involved in such a topology - as you have no loop (until LAG is removed) ?

 

You might want to re-visit your chain, in favour of a more reliable & robust topology.

June 25th, 2008 22:00

I hope the 'drawing' below helps to show the setup.

GWS 

 

             PC-5324 (9)

                ||

             2xFO (3)-(9)

                ||
             
              PC-6224 (3)
                ||

                  ==== 2xFO (3)-(4)

                          ||

PC-6224 (2)              PC 6224 (4)

   ||                     ||

2xFO (0)-(2)             2xFO (0) - (4)

    ==========-   -=======
              || ||

            PC-6224 (0)


Current Test scenario with the issues
Speed for (3) and (9) should be 2 Gb
(0) being the server room and (9) remote backup/failover

June 25th, 2008 22:00

Sentinel-Master,

 

Indeed we have a chain of switches and using LAGS the (R)STP would not be necessary. Originally we started of with another topology where the first and last PC6224 were connected via single FO effectively creating a ring of PC6224 switches en with a double connection to the PC5324 switch in a remote building o n the side. 

 

This would result in only 1 Gb link to the remote building. In the current setup we would have two Gb everywhere. 

 

Reasons for building the chain are:

 

All our FO is 62.5 Multimode only allowing 1Gb up to distances of appr. 250 meters. The only way to get Gb speeds everywhere int he backbone is to chain switches. We used to have a star topology with 100Mb swtches since it was possible to reach everywhere without active components in between. New FO is not an option at the moment for budget reasons.

Since we have only 4 SFP's in every switch we ran out of connectors to make all connections FO DUAL in LAG's if we build the full circle.

Connecting one switch to 3 others would lead to the situation that RSTP is necessary because of the redundant paths AND that only one of the two paths would be used.

 

I hope this clearifies things a bit. In my opinion it is the best we could do with the current hardware. Optionally we would have to buy one other 6224 switch and create a stack or use an extra 6224F instead.

 

Even in that scenario we would have the same issue(s) and questions.

 

RSTP convergence appears to be slow (STP specs?) maybe wrongly configured?

Changing LAG settings on the PC5324 should not lead to blocking state everywhere permanently?

 

Just to make sure we are starting to rebuild from scratch and will see.

 

GWS

184 Posts

July 2nd, 2008 13:00

Can you post one of the configs for the switches? thats very odd indeed. The Lags should all act indepent of each other. Taking one down should not affect the next. This is a flat layer 2 network i assume ?

 

July 14th, 2008 10:00

Following up to the previous explanation of GWScheppink:

 

1. I unplugged all cables for all (5) switches.

 

2. Then removed the 5324 from the network (Leaving only the (4) 6224 Switches.)

 

3. Cleared the configurations of all switches. (using the serial cable on each of them.) 

 

4. After following the standard "Hyper Terminal" setup instructions and later on " adding our own settings" thru the web-interface , I saved the settings and then exported the configuration file.

 

5.  Then i changed the ip ,lag and asset information , saved it for that particulair switch ... and uploaded the previous made configuration to the next switch. (repeating this steps for the following switches)

 

6. I double checked if all settings where the same on all switches and all lags where configured as should be.

 

Strange problem:

 

When i unplug all cables from the main (ser0) switch and put back a random cable , i get "like 5 pings and then it goes timeout.

 

It doesn't matter if i have all cables or only 1 cable connected , i don't get a connection to "any" of the switches at all. ( witch exeption of the "5 pings when putting in a single cable)

 

Following up to this post i will add some picture of the lags and the configuration file of the main switch (note: all switches use the same settings with only the changed lag numbers according to the picture)

 

 

July 14th, 2008 11:00

Like promised the picture and configuration:

 

 

 

---------

 Config:

---------

 

!Current Configuration:
!System Description "Dell 24 Port Gigabit Ethernet, 2.1.0.13, VxWorks5.5.1"
!System Software Version 2.1.0.13
!
configure
hostname "SER 1"
stack
member 1 1
exit
ip address 10.0.250.1 255.255.0.0
username "swadmin" password cb551b27f479f58638b1c49aaa7193fc level 15 encrypted
spanning-tree bpdu-protection
spanning-tree mode mstp
!
interface ethernet 1/g1
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g2
spanning-tree cost 20000
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g3
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g4
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g5
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g6
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g7
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g8
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g9
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g10
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g11
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g12
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g13
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g14
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g15
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g16
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g17
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g18
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g19
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g20
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g21
channel-group 4 mode auto
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g22
channel-group 4 mode auto
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g23
channel-group 2 mode auto
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/g24
channel-group 2 mode auto
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/xg1
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/xg2
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/xg3
spanning-tree portfast
spanning-tree root-protection
exit
!
interface ethernet 1/xg4
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 1
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 2
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 3
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 4
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 5
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 6
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 7
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 8
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 9
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 10
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 11
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 12
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 13
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 14
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 15
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 16
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 17
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 18
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 19
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 20
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 21
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 22
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 23
spanning-tree portfast
spanning-tree root-protection
exit
!
interface port-channel 24
spanning-tree portfast
spanning-tree root-protection
exit
snmp-server user swadmin READ_noAuthNoPriv
exit
 
Message Edited by Daniel Bleumink on 07-14-2008 02:23 PM

108 Posts

May 26th, 2010 15:00

Did you ever find an explanation why the LAG settings change would bring down all switches and a fix for that?

Thanks.

909 Posts

May 27th, 2010 08:00

I believe the is expected behaviour.  It has to do with the STP TCNs.  When the root is rebooted, the spanning tree has to be recalculated. 

108 Posts

May 27th, 2010 10:00

Does that mean that if the STP root switch reboots, all the switches connected to it with STP enabled will suffer temporary connectivity downtime on all theirs ports?

Any ways to prevent that besides completely disabling STP?

Thanks.

22 Posts

May 27th, 2010 23:00

I believe his config is invalid. He uses spanning-tree portfast and spanning-tree root-protection on all ports together with spanning-tree bpdu-protection.

Spanning-tree portfast is for end-station ports, it must not be used for links between switches. The bpdu-protection is supposed to disable such port, if it ever sees a STP BPDU. And the root-protection configured on all switches will prevent any of them from becoming STP root.

No Events found!

Top