can you please explain me what is the difference between SLPP-Guard and SLPP enable on per interface? also, if i enable SLPP per interface (not globally) does it going to work? and what happened if i just enable SLPP globally (not per vlan or per interface )

You should use SLPP in combination with cp-limit.

Cheers!

Just an another information, the 2 “simple links” are trunking the same vlan to the two other switchs (8610)

I have Two switch 8610 and they have a MLT trunk between them in order to forward a VLAN for the voice. They ‘re connected each of them by a simple link to a third’s switch. I don’t have the rights on this switch but i want to be sure to avoid any switching loops. What is the best solution ? In this case , SLPP is it the best solution i have ?

Thanks for your help !

Hi Philippe,

You typically only run SLPP on your core switches – not on the edge switches.

You disable STP on the uplinks (on the edge) and the downlinks (on the core). You should still run STP on all the edge ports (user ports) to prevent any accidental loops between ports.

If you have additional questions I would suggest dropping by the forums;
http://forums.networkinfrastructure.info/nortel-ethernet-switching/

Cheers!

Great post.

I’m really new in the Avaya world.

I have some question about implementation of Slpp :

– SLPP must be enabled only on the Core Switches or also on access switches attached via smlt ?
– We must disable STP on the core switches ports only or also on the access switch port facing it ?

Cheers.

Philippe

I believe I replied to your thread in the forums.

http://forums.networkinfrastructure.info/nortel-ethernet-switching/slpp-brought-trunk-down/

Cheers!

Thanks for looking in to the issue.
While we polling the 8600 by SNMP the “show sys perf” command shows 100% for a long time (couple minutes)
Log file contains:

CPU5 [11/06/11 17:09:44] SNMP INFO Slpp port down(SlppRxPort = 82, SlppRxVlan =140, SlppIncomingVlanId = 140, SlppSrcMacAddress = 00:e0:7b:88:aa:0c)
CPU5 [11/06/11 17:09:44] SNMP INFO Port 1/19 is an access port
CPU5 [11/06/11 17:09:44] SNMP INFO Link Down(1/19) due to slpp
CPU5 [11/06/11 17:09:44] SW WARNING slppRx: SLPP packet received Rx-Vlan 140, Rx-Port 1/19, PDU-Vlan 140, SRC-Mac 00:e0:7b:88:aa:0c
CPU5 [11/06/11 17:07:03] SNMP INFO Port 1/19 is an access port
CPU5 [11/06/11 17:07:03] SNMP INFO Link Up(1/19)
CPU5 [11/06/11 16:59:33] SNMP INFO Slpp port down(SlppRxPort = 82, SlppRxVlan =140, SlppIncomingVlanId = 140, SlppSrcMacAddress = 00:e0:7b:88:aa:0c)
CPU5 [11/06/11 16:59:32] SNMP INFO Port 1/19 is an access port
CPU5 [11/06/11 16:59:32] SNMP INFO Link Down(1/19) due to slpp
CPU5 [11/06/11 16:59:32] SW WARNING slppRx: SLPP packet received Rx-Vlan 140, Rx-Port 1/19, PDU-Vlan 140, SRC-Mac 00:e0:7b:88:aa:0c
CPU5 [11/06/11 16:56:05] SW INFO user rwa connected from 129.2.70.53 via telnet
CPU5 [11/06/11 16:55:44] SW INFO Closed telnet connection from 129.2.70.53, user rw rcmd -2

It seems that a loop is creating in the network and it raises the cpu util high.
There is no SMLT created in the network but then also user has enabled SLPP on the ports.(not recommended).
Can you please suggest me what action should be taken to resolve the issue.

Regards

Ronit

Hi Ryan,

I’ve seen broadcast storms come and go without explanation. Sometimes it can be a user that creates the problem, and then when the network stops working they unplug and move on, clueless of the chaos they’ve left behind.

The reason I ask about Multicast is because there were a few known issues with 6.1.x were Multicast traffic get’s looped in the switch. I believe there is reference to a fix in 6.1.4 software similar to the following;

Under certain conditions, broadcast traffic looped into the stack could generate a broadcast storm (Q02162104).

You might want to try upgrading the switches to 6.1.4 software and see if that resolves the problem.

Just so I understand your topology, you are using the ERS 5530 switches as distribution switches which feed your edge 470s? So your edge 470s are MLT connected to a single ERS 5530 or are you also running the Advanced License with an IST/SMLT configuration on the ERS 5530.

That’s definitely an odd problem… but a good think that CP-LIMIT is kicking in and isolating the affecting switches or else your entire network might go down. Perhaps you could perform a port mirror of one of the SMLT uplinks out to a desktop/laptop with a continuous packet trace running. Might help you being able to go back and look at the broadcast frames. Perhaps the source MAC might provide some clue to the problem.

Good Luck!

Thanks for the prompt and informative response to my query.

The 8600s are ERS-8610 (5.1.1.1) but we have not yet enabled VRFs, with the smlts connected to 5530-24FTD, (FW:6.0.0.6 SW:v6.1.0.006), with access switches being 470s, with STG enabled on all ports except for their uplinks.

I don’t believe it is a loop or malfunctioning device, as the broadcast storms should not stop once a disable/re-enable the SMLT ports, but should continue to swamp the network, unless the SMLT ports are the loop itself.

Please correct me on by above logic.

We do have Multicast traffic, but the log entry defines it as broadcast.

We run a (Management of a sort) VLAN between the 8600s and 5530s over the SMLT, which is unique to that device’s SMLT.

I could enable SLPP just on that VLAN, and not on all the user VLANs that are spanned over that SMLT.

I have checked the SMLT configuration, but that has been stable for over a year up until now that is.

My CP Limit is 10 000, but I am about to enable rate limiting for multi and broad traffic.

Thanks once again

Ryan

Hi Ryan,

It would appear that CP-LIMIT is kicking in and shutting down the links in question because they are flooding too many broadcast frames into the core network. Just to be upfront with you 11,201 pps is a LOT of broadcast traffic. The default value for CP-LIMIT is 10000, however, I personally use 5,000 in my network.

I haven’t used SLPP in more than 10 VLANs at any one site because I generally only enable it on a few larger VLANs. I’d recommend you review the design guidelines to see if there are any hard/soft limits.

With respect to your symptoms, there is definitely something wrong somewhere. Perhaps it’s an operational bug in the software or perhaps it’s mis-configuration or perhaps a cabling issue (loop) or a mis-behaving device.

I would start with the basics and make sure your edge switch has a good configuration. You should confirm that the MLT trunk on the edge switch is configured properly (and ENABLED). You should also enable rate-limiting and confirm that STP is enabled on all edge ports. Assuming your configuration is good we need to look at either a software issue or a potentially mis-behaving device on the network.

What model edge switches are you using?
What version of software are they running?
Are you doing any IGMP/Multicast?

I believe I remember reading a blurb in some release notes about an issue with a broadcast storm emanating from an edge switch although I believe it had something to-do with Multicast traffic.

Good Luck!

I have two 8600s connected via IST, and upon late I have ports shutdown from with the following Error code :

CPU WARNING Shutdown port 2/19 due to excessive control frames multicast 0, broadcast 11201 packet per second

We have 4 ports configured in a SMLT trunk, two links to each 8600, and all four ports are being closed with the above message.

I disable and reenable the ports, and all is well again. The ports get shutdown over random days long periods.

Now, I am considering implementing SLPP to assist in this issue. But reading an above entry of yours about VLANs, my network is subnetted to each switch stack, without a single management VLAN per se, and switch IPs are resident in their applicable subnet.

I have about 80 or so VLANs on site, and I am curious about the number of VLANs associated with SLPP, and is there any other limitiations, I should be aware of?

Thanks in advance.

Regards

Ryan

Hi Dan,

Let me ask and then answer a simple question that should help explain SLPP;

Q. How will SLPP (Simple Loop Protection Protocol) save your network?
A. It will save you if you have an edge switch that boots with a default factory configuration where there is no MLT configured (can you say loop).
It will save you if you configure the MLT but forget to enable the MLT (don’t laugh it’s been done too many times).

It won’t save you from someone mistakenly looping two ports in the closet, you’ll need to rely on other features (BPDU guard, STP) to save you there.

How do you handle IP telephony? Well there are literally dozens of articles on this blog for you to peruse. I would start with this one that details a best practice configuration when configuring an edge switch. The commands have only been tested on a 5520 series switch but they should probably work with the 4500 series and I believe ADAC/LLDP-MED is now supported on the 4500 series switches (the 5520 was the only switch for a long time that support ADAC/LLDP-MED).
http://blog.michaelfmcnamara.com/2007/10/nortel-ers-5520-pwr-switch/

Spanning Tree should be set to FastStart on all edge ports and disabled on any uplinks/downlinks. You still need Spanning Tree enabled even if the port is connecting to an IP phone because you can still get a loop from an IP phone with the built-in PC port on the back of the phone.
I won’t go on to far… I’ve gotten off-topic already with respect to SLPP. If you have any other questions please post in the forums and I’ll be sure to follow-up with you. http://forums.networkinfrastructure.info/nortel-ethernet-switching/

Cheers!

Hi Luis,

What version of software are you running? I’m assuming your using Ethernet Routing Switch 8600s and not the 5000 series?

Assuming that the software release is fine, no bugs or known issues I would suspect the possibility of a brief loop within the specific switch/stack that connects to the offending port.

Have you checked the configuration of every port and every device that connects to the switch/stack that is having issues? I would advise you make sure you have Spanning Tree enabled on all edge ports within that switch/stack. You might also want to enable BPDU guard to help keep any un-authorized switches from being connected downstream which could then cause a loop depending on the scenario. For those that are following the thread here’s a quick example of the SLPP messages that the ERS8600 switch will generate;

CPU6 [12/18/08 07:38:09] SW WARNING slppRx: SLPP packet received Rx-Vlan 12, Rx-Port 1/3, PDU-Vlan 12, SRC-Mac 00:15:e8:a8:00:0c
CPU6 [12/18/08 07:38:09] SNMP INFO Link Down(1/3) due to slpp
CPU6 [12/18/08 07:38:09] SNMP INFO Slpp port down(SlppRxPort = 66, SlppRxVlan =12, SlppIncomingVlanId = 12, SlppSrcMacAddress = 00:15:e8:a8:00:0c)

What do the logs from the edge switch indicate when you correlate the events in the core?

Please feel free to post the logs from both the core switch and the edge switch over in the forums and I’ll try to follow-up for you.
http://forums.networkinfrastructure.info/nortel-ethernet-switching/

Cheers!

I have a problem with slpp.

I have the same vlan for 3 different smlt, and i’m receiving slpp frames on one of the smlts with a 3 day interval.

What can be the problem?

Regards,

LR

Good Luck!

I am planning to implement SLPP only in the business critical VLANs (these are VLANs that cover many uplinks). For (s)MLT misconfiguration you need to send SLPP in only one VLAN. The reason why i want to deploy SLPP in business criticall VLANs is for loop prevention on access port, in case of misconfiguration or malfunction (STP not configured of not working properly).

I think that if SLPP wants to be a good alternative for Loop Detect, it should be possible to enable it on large amount of VLANs.

From Nortel we got the information that SLPP had been tested in 40 VLANs and that this was not a problem. Now the question is, what happens when you go to 100 VLANs or above?

Cheers,

Ata

In my opinion there’s no need to run SLPP in every VLAN.. it would be very inefficient to-do so and serve almost no purpose. You only need to run SLPP in the those VLANs that cover the majority of your closets switch (uplink). In my case I have a location that has 11 closets. I run SLPP in the management VLAN (the VLAN where the IP addresses of all the equipment resides) along with the closet VLANs (each closet has it’s own VLAN and IP network). There are probably about 30 VLANs in all at this location but I know that every closet has at least one VLAN that has SLPP running on it.

Here’s what Nortel has to say with respect to SLPP;

This functionality provides active protection against network loops by sending out test packets and detecting self originated packets. It can be used in Spanning Tree networks as well as SMLT networks. Beginning with Software Release 4.1 Nortel recommends using SLPP to protect the network against L2 loops. In addition, the extended CP-limit functionality can be put into place to protect against DOS attacks where required. For earlier releases please refer to the corresponding release notes.

Loops can be introduced into the network in many ways. One way is through the loss of an MLT configuration caused by user error or malfunctioning as shown in Figure 32. This scenario does not introduce a broadcast storm, but because all MAC addresses are learned through the looping ports, does significantly impacts L2 MAC learning. Spanning Tree would not in all cases be able to detect such a configuration issue, whereas SLPP reacts and disables the malfunctioning links, limiting network impact to a minimum.

It’s really designed to protect you against a misconfigured or malfunctioning MultiLink trunk on the edge switch.

Cheers!

We have implemented SLPP in approx. 10 VLANs. We are very positive about this mechanism and therefore want to deploy SLPP over more VLANs (60 at this moment). You are saying not to deploy SLPP over too many VLANs since it uses CPU resources. Can you tell me in how many VLANs you are using SLPP? Would SLPP behave well when deployed in 100 to 200 VLANs?

Thanks,

Ata

I would advise that you look at the following measures to help protect your network;

– Spanning Tree Protocol with FastStart on all edge ports (you could also run MSTP or RSTP if you prefer that)
– If you are using Nortel edge switches configure rate limiting to help keep the loop from crushing your network
– If you are using rate limiting adjust your CP-LIMIT values down so CP-LIMIT can detect the problem and isolate the offending closet.

After you’ve setup all that you should also enable SLPP to protect against a problem with the edge MultiLink Trunk (MLT) configuration.

In all honesty we’ve found that Spanning Tree will help isolate 99% of the problems that involve end users and/or field engineers. Although you don’t want to run Spanning Tree on your uplink ports… make sure those ports are disabled. The rate limiting feature helps to keep a loop from initially bringing down your entire network, although you’ll still experience ARP/FDB corruption issues but you’ll at least get some time to locate the problem and resolve it before everything comes crashing to a halt.

If you are using Nortel for your edge switches you might be interested in looking at this article;
http://blog.michaelfmcnamara.com/2007/10/nortel-ers-5520-pwr-switch/

Good Luck!

I have a customer expericing loops in their network due to student and staff intervention. We have CP-limit turned on so that when the ports see a broadcast storm the ports are shutdown. I would like to know what do i gain, if anything by turning SLPP and cp-limit at the same time.

I’m not sure I’ll get to all your points tonight but let me take a first stab.

I’m not completely understanding why you want to “protect” the edge. In my environments if the edge switches get disconnected from the core backbone the network is useless to those folks. Yes the local edge switch might be up but all the applications including voice and data are only reachable through the core backbone.

If STP is disabled on your core uplinks but enabled on the edge downlinks I don’t think you’ll protect your edge switch like you think. With STP enabled globally on the core but disabled on the uplinks it will not forward BPDUs that come from your edge switch. Have you tested your approach? I think you’ll find that it doesn’t work and you think it should and probably doesn’t buy you anything.

Assuming there is a mis-configuration at the core or someone wires the fiber uplinks to the wrong ports CP-LIMIT will still protect your core backbone from too much traffic flooding in the event of a loop. CP-LIMIT is a last ditch effort to protect the core backbone. SLPP helps by trying to isolate an uplink should the SMLT/MLT connection itself be creating the loop (edge switch gets set to factory defaults – yes we’ve had it happen).

We actually have found that rate-limiting on the edge switches helps to keep the network from entirely collapsing. As a standard we now set all edge switches to rate-limit all Multicast and Broadcast traffic at 5% of the link speed.

The idea behind all of this is to protect the core backbone even if you have to sacrifice an edge switch.

With regard to your question about running SLPP in a square/full mesh configuration I will ask the powers that be and let you know. I’m only running SLPP at one campus right now but I am running it in all my closet VLANs and in my management VLAN.

Thanks for your comment!