XS708T switch not passing Ethernet multicast packets

[paulmcg99]

I submitted this issue to Support a week ago and there's been no response. Perhaps someone here knows the answer. Here's what I sent to Support.

--------

We bought five XS708T switches and they are not passing some proprietary Ethernet multicast frames our products use for network control. We updated the firmware version to 7.0.0.20.

Using network analyzers, we found that these frames enter the switch but don't come out any port. Instead, the Unacceptable Frame Type for the port statistics keeps increasing. We are using unassigned IEEE 802.1d and 802.1q MAC addresses such as 01:80:c2:00:00:72
https://standards.ieee.org/products-services/regauth/grpmac/public.html

Here is an Ethernet frame captured with Wireshark that shows this problem.

0000 01 80 c2 00 00 72 00 1b 21 8f 5d de 00 18 42 42 .....r..!.]...BB
0010 03 00 00 00 de 81 0e 76 64 dc 00 1b 21 8f 5d de .......vd...!.].
0020 63 63 00 00 00 00 cc....

Frame 16: 38 bytes on wire (304 bits), 38 bytes captured (304 bits) on interface enp7s2, id 0
IEEE 802.3 Ethernet
Destination: Spanning-tree-(for-bridges)_72 (01:80:c2:00:00:72)
Address: Spanning-tree-(for-bridges)_72 (01:80:c2:00:00:72)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
Source: IntelCor_8f:5d:de (00:1b:21:8f:5d:de)
Address: IntelCor_8f:5d:de (00:1b:21:8f:5d:de)
.... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
.... ...0 .... .... .... .... = IG bit: Individual address (unicast)
Length: 24
Logical-Link Control
DSAP: Spanning Tree BPDU (0x42)
0100 001. = SAP: Spanning Tree BPDU
.... ...0 = IG Bit: Individual
SSAP: Spanning Tree BPDU (0x42)
0100 001. = SAP: Spanning Tree BPDU
.... ...0 = CR Bit: Command
Control field: U, func=UI (0x03)
000. 00.. = Command: Unnumbered Information (0x00)
.... ..11 = Frame type: Unnumbered frame (0x3)
Spanning Tree Protocol
Protocol Identifier: Spanning Tree Protocol (0x0000)
Protocol Version Identifier: Spanning Tree (0)
BPDU Type: Unknown (0xde)
[Expert Info (Warning/Protocol): Unknown BPDU type data]
[Unknown BPDU type data]
[Severity level: Warning]
[Group: Protocol]

We need to either be able to broadcast those frames to all ports or set up the ATU (address translation unit) to forward the multicasts to specific ports, like we do with the Marvell switch chips our products use. Here's an ATU example:

Marvell switch 6341 : ATU Table
ESA: 00:0D:2E:19:65:92, PRI:00, DB:00, ES:0E, MAP:[ 0| | | | | | ]
ESA: 00:1B:21:8F:5D:DE, PRI:00, DB:00, ES:06, MAP:[ | | 2| | | | ]
ESA: 01:80:C2:00:00:00, PRI:00, DB:00, ES:07, MAP:[ 0| | 2| | | | ]
ESA: 01:80:C2:00:00:01, PRI:00, DB:00, ES:07, MAP:[ 0| | | | | | ]
ESA: 01:80:C2:00:00:72, PRI:00, DB:00, ES:07, MAP:[ 0| | | | | | ]
ESA: 01:80:C2:00:00:78, PRI:00, DB:00, ES:07, MAP:[ 0| | | | | | ]
ESA: 01:80:C2:00:00:80, PRI:00, DB:00, ES:07, MAP:[ 0| | | | | | ]
ESA: 01:80:C2:00:00:F0, PRI:00, DB:00, ES:07, MAP:[ 0| | 2| | | | ]
ESA: 01:80:C2:00:00:FA, PRI:00, DB:00, ES:07, MAP:[ 0| | | | | | ]
ESA: 28:80:88:6D:E1:1E, PRI:00, DB:00, ES:07, MAP:[ | | 2| | | | ]

[paulmcg99 · Accepted solution]

I figured out the solution to my problem. You have to add the MAC multicast addresses to the ACL settings. An example is shown in the attached screen shot.

STEPS

1. Click on Security --> ACL --> ACL Wizard.
2. Choose "ACL Based  on Destination MAC" on the ACL Type pull-down menu.
3. Enter the Sequence Number. You can start at 1 if you have no ACL rules or use a unique positive integer if you have ACL rules.
4. Set the Action field to Permit.
5. Set the Match Every field to False.
6. Enter the Destination MAC address to forward. In the screen shot, this is 01:80:c2:00:00:72.
7. Set the Destination MAC MASK to ff:ff:ff:ff:ff:ff. The manual says use 00:00:00:ff:ff:ff for BPDUs like we're using, but I had problems saving using that mask and had to mask all 48 bits.
8. Set the VLAN ID to 1. By default, this is an untagged VLAN that goes to all egress ports.
9. In the Binding Configuration section, choose which ports are allowed to send the special frame.
10. For each unique MAC multicast address, you should add an additional sequence number.

[schumaku]

Look around in the Web UI on IGMP Multicast - there is a control for Block Unknown Multicast Address when I have it right.

[DaneA]

@paulmcg99,

Welcome to the community! 🙂 

I submitted this issue to Support a week ago and there's been no response. Perhaps someone here knows the answer.

May I know the case number so that I will send it to the NETGEAR Support Team for follow-up. 

Regards,

DaneA

NETGEAR Community Team

[paulmcg99]

Dane: I checked Support, and there is no case found, even though I did a submit.

I'll check the IGMP settings. Even though our frames are in the same MAC address range as STP, none of the STP settings worked.

[paulmcg99 · Accepted solution]

I figured out the solution to my problem. You have to add the MAC multicast addresses to the ACL settings. An example is shown in the attached screen shot.

STEPS

1. Click on Security --> ACL --> ACL Wizard.
2. Choose "ACL Based  on Destination MAC" on the ACL Type pull-down menu.
3. Enter the Sequence Number. You can start at 1 if you have no ACL rules or use a unique positive integer if you have ACL rules.
4. Set the Action field to Permit.
5. Set the Match Every field to False.
6. Enter the Destination MAC address to forward. In the screen shot, this is 01:80:c2:00:00:72.
7. Set the Destination MAC MASK to ff:ff:ff:ff:ff:ff. The manual says use 00:00:00:ff:ff:ff for BPDUs like we're using, but I had problems saving using that mask and had to mask all 48 bits.
8. Set the VLAN ID to 1. By default, this is an untagged VLAN that goes to all egress ports.
9. In the Binding Configuration section, choose which ports are allowed to send the special frame.
10. For each unique MAC multicast address, you should add an additional sequence number.