Header Only - DO NOT REMOVE - Extreme Networks

MSM-A: Notify-threshold for L3 Protect packet count of 3500 reached


if I try to connect a new access switch (Summit X440-48) to the core switch (BD8006) I read after some minutes the following entry in the log file:

MSM-A: Notify-threshold for L3 Protect packet count of 3500 reached
MSM-A: Added an ACL to port 4:1, srcIP 0.0.0.0 to destIP 10.72.50.100, protocol udp

After that several servers are not reachable (but the new access switch is reachable via ping). If I disconnect the new switch everything is fine.

So what is wrong?

8 replies

Userlevel 7
https://gtacknowledge.extremenetworks.com/articles/Q_A/DOS-protect-log-message
Userlevel 6
Hi Matthias, that means you have DoS Protect enabled on BD8k to apply an ACL if more than 3500 pps reaches the switch CPU.

For some reason this might be caused by X440 side that's connected to BD8k port 4:1 (based on the log provided).

Is there anything connected to the new switch like other switches, PCs, phones, etc?
Did you change the switch configuration or it's using default configuration?
Hello Henrique,

after a reset (unconfigure switch all) the new access switch got only an IP Adr. and a sharing port.

configure vlan Default ipaddress 172.........
configure iproute add default 172.........
enable sharing 47 grouping 47-48 algorithm address-based L2
configure vlan "Default" add ports 47 tagged

A configuration like the rest of the available switches.

The new switch is connected to the core switch port 3:4
Port 4:1 on the core switch is the ISC for MLAG.

On the new switch I have only one SFP port used for the uplink. No PCs ore anything else.

You wrote "For some reason this might be caused by X440". I think also because if I disconnect the new switch everything is fine.

But what can I do?
Userlevel 6
Hi Matthias.

If you are using MLAG between 2 Core switches, please confirm if the information below is correct:
  • Port 4:1 is the ISC port/link between Core1 and Core2 switches. Core1(4:1) ------ (4:1)Core2
  • New_SW port 47 connects to Core1 port 3:4. New_SW(47) ------ (3:4)Core1
  • New_SW port 48 connects to Core2 port 3:4. New_SW(48) ------ (3:4)Core2
  • LAG enabled on the New_SW to ports 47 and 48 (static mode)
  • MLAG enabled to port 3:4 on both Core1 and Core2 switches
Please provide more details about the New_SW connection with both Core switches (including ports, LAG and MLAG configuration).

Thanks.
Hi,

yes, that is corect.

Config Core1:
****************
create mlag peer "CORE2"
configure mlag peer "CORE2" ipaddress 1.1.1.2 vr VR-Default
enable mlag port 3:1 peer "CORE2" id 1
enable mlag port 3:2 peer "CORE2" id 2
enable mlag port 3:3 peer "CORE2" id 3
enable mlag port 3:4 peer "CORE2" id 4
enable mlag port 3:5 peer "CORE2" id 5
enable mlag port 3:7 peer "CORE2" id 7
enable mlag port 3:8 peer "CORE2" id 8
enable mlag port 3:10 peer "CORE2" id 10
enable mlag port 3:11 peer "CORE2" id 11
enable mlag port 3:13 peer "CORE2" id 13
enable mlag port 3:17 peer "CORE2" id 17
enable mlag port 3:18 peer "CORE2" id 18
enable mlag port 3:19 peer "CORE2" id 19
enable mlag port 3:20 peer "CORE2" id 20
enable mlag port 3:21 peer "CORE2" id 21
enable mlag port 3:23 peer "CORE2" id 23
enable mlag port 3:24 peer "CORE2" id 24
enable mlag port 4:2 peer "CORE2" id 42
enable mlag port 7:2 peer "CORE2" id 72

enable sharing 4:1 grouping 4:1, 7:1 algorithm address-based L2

Config Core2:
****************
create mlag peer "CORE1"
configure mlag peer "CORE1" ipaddress 1.1.1.1 vr VR-Default
enable mlag port 3:1 peer "CORE1" id 1
enable mlag port 3:2 peer "CORE1" id 2
enable mlag port 3:3 peer "CORE1" id 3
enable mlag port 3:4 peer "CORE1" id 4
enable mlag port 3:5 peer "CORE1" id 5
enable mlag port 3:7 peer "CORE1" id 7
enable mlag port 3:8 peer "CORE1" id 8
enable mlag port 3:10 peer "CORE1" id 10
enable mlag port 3:11 peer "CORE1" id 11
enable mlag port 3:13 peer "CORE1" id 13
enable mlag port 3:15 peer "CORE1" id 15
enable mlag port 3:17 peer "CORE1" id 17
enable mlag port 3:18 peer "CORE1" id 18
enable mlag port 3:19 peer "CORE1" id 19
enable mlag port 3:20 peer "CORE1" id 20
enable mlag port 3:21 peer "CORE1" id 21
enable mlag port 3:23 peer "CORE1" id 23
enable mlag port 3:24 peer "CORE1" id 24
enable mlag port 4:2 peer "CORE1" id 42
enable mlag port 7:2 peer "CORE1" id 72

enable sharing 4:1 grouping 4:1, 7:1 algorithm address-based L2

All other access switch are working without any issue.
Userlevel 6
Hi Matthias, thank you for the outputs. I don't see any config issue.

What's the configuration for DosProtect? Could you please share the output for "show configuration dosprotect" for both Core switches?

When you see this issue, are you connecting just the uplink to Core1 or both?

I would try to connect to both Core switches with only sharing configuration on the New_SW, without any vlan/IP configuration to the uplink ports. Also, you could try to connect to Core2 only and see the results.

I'm wondering if that could be just a burst and not a constant high traffic rate from the New_SW. If that's true, than you could try adding the New_SW port as a trusted_port to the Core switch using the following command:

"config dos-protect trusted-ports add-ports 3:4"

You can monitor the switch CPU with "top" command.
Hi Henrique,

show configuration "dosprotect"
#
# Module dosprotect configuration.
#
enable dos-protect

Everytime I had only one active uplink. Ether connected to Core1 or Core2. Each time withthe same result.

What happend if I configure the port as a trusted port? The "bad" packets are still enter the core and CPU is busy?

Meanwhile I have opend a case perhaps there is a broken hardware.
They told me I shoud to following steps:
disable dos-protect
enable elrp-client
configure elrp-client one-shot ports all log

And/or I should capture the packets on port 3:4.

But I don't know where a loop should be because the whole network is working without the new switch.

BR,
Matthias
Userlevel 6
Hi Matthias,

"trusted-port" won't block the packets from the new switch to reach the Core CPU. That's a little bit risky and should be tried in a MW or non-critical period. Since you have already opened a case, please hold this action and follow GTAC instructions.

Regarding the ELRP, I believe the GTAC suspects that could be any loop related to the new switch. Even something with bad HW or wrong LAG HW programming.

Please share the solution provided when you get the GTAC case closed.

Thank you.

Reply