This topic has been marked solved and closed to new posts due to inactivity. We hope you'll join the conversation by posting to an open topic or starting a new one.
I am experiencing an issue where OSPF routers connectted m4300-series switches running IGMP Snooping are unable to form an adjacency. The m4300-series switches seem to be filtering OSPF multicast traffic (and possibly other traffic in 224.0.0.0/4 as well) which appears to be the cause of this issue.
I have a stack of 2x m4300-52g and 1x m4300-24x, a standalone m4300-24x, and a standalone m4300-12x12f that are all experiencing this issue.
I have observed this issue on firmware 12.0.11.10 and 12.0.11.8.
I do not recall observing this issue on older firmwares, but my network was much smaller and less complicated then.
Examining the routers, I can observe that they are all sending OSPF HELLO messages, but that they are not receiving messages from other routers.
Occasionally, I will see one router start to receive OSPF messages from other routers, but the other routers still do not see it's messages. This results in the router having a number of neighbors stuck in INIT, never forming a full or 2-way adjacency.
Examinging the MFDB Table on the switch, I can see a RSVD-MC STATIC entry for the important 01:00:5e:00:00:05 and 01:00:5e:00:00:06 groups. However, these entries only exist for VLAN 1. Examining the "forwarding interfaces" column of the MFDB Table, I observe that only ports participating in VLAN1 are in the list. For example, in the following table, ports 2/0/3 and 2/0/7 have OSPF routers which should be able to receive messages, but do not.
01:00:5e:00:00:05 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:00:06 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:00:09 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:00:12 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:00:6b 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:00:e6 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:00:e7 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:00:e8 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:00:e9 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:00:fb 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:00:fc 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:01:01 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:01:81 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:01:82 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:01:83 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:00:01:84 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:7f:ff:fa 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:7f:ff:fb 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:7f:ff:fc 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:7f:ff:fd 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:7f:ff:fe 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
01:00:5e:7f:ff:ff 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
91:e0:f0:01:00:00 1 RSVD-MC STATIC Network Assist 1/0/7, 1/0/9 - 1/0/11, 1/0/13 - 1/0/16, 1/0/18 - 1/0/19, 1/0/22, 1/0/24 - 1/0/30, 1/0/32, 1/0/36, 1/0/41, 1/0/43 - 1/0/44, 2/0/5, 3/0/1 - 3/0/21, lag 1 - lag 2, lag 5, lag 7 - lag 9, lag 11 - lag 128
Aside from not forwarding OSPF traffic, IGMP Snooping does appear to work correctly on other VLANs. The switches correctly add and remove interfaces in response to IGMP Group Membership reports, and correctly identify mrouter ports where the routers are running PIM. Routers running PIM are able to form OSPF adjacencies with other OSPF routers running PIM, but not with any OSPF routers that are not mrouters. The querier election proceeds correctly and the correct querier is elected. Etc. etc.
I am temporarily working around this by disabling IGMP Snooping on certain VLANs where I have OSPF routers that are no mrouters, but this is not ideal, as I have >800 multicast groups running >2Gbps constantly. I have not yet explored the possibility of disabling IGMP Snooping only on the ports where I have OSPF routers that are not mrouters, but this would not be an ideal workaround either, as it would significantly increase configuration and management overhead, as well as increase the opportunity for human error in configuration.
In summary, it appears that IGMP Snooping on the m4300 series is incorrectly filtering OSPF traffic on VLANs other than VLAN 1. As a result, IGMP Snooping is only working correctly on VLAN 1, even if it otherwise works to control the flow of groups to ports.
Is this a firmware bug, or is there a configuration setting I have missed that controls this and allows other VLANs/ports to receive the RSVD-MC static entries? Or is this just a red herring and something else is configured incorrectly?
Model: GSM4352S|M4300-52G - Stackable Managed Switch with 48x1G and 4x10G including 2x10GBASE-T and 2xSFP+ Layer 3, XSM4324CS|M4300-24X - Stackable Managed Switch with 24x10GBASE-T, XSM4324S|M4300-12X12F - Stackable Managed Switch with 24x10G including 12x10GBASE-T and 12xSFP+ Layer 3
I am sorry for your issue, let's go and fix it. Kindy export the Tech-Support file out, you can simply go the web GUI, Maintenance \ Export \ HTTP File Export \ and select Tech Support at the end of the drop down menu list.
You can use the private message here to let me know where I can get that file, and we'll be able to assess where is the problem.
I just tried a simple networking test to see how OSPF works except for vlan 1, It seems that OSPF neighbors can be set up normally on M4300 12.0.11.10.
I think I need more detailed information about your networking and configuration.
Could you please provide me with your topology and tech support file?
I'm going to try to replicate this issue.
Thank you.
(M4300-96X) #show ip ospf neighbor
Router ID Priority IP Address Neighbor State Dead Interface Time --------------- -------- --------------- ----------- ------------------ ---- 192.168.20.2 1 192.168.20.2 vlan 20 Full/BACKUP-DR 34
My configuration as follow:
Topo
M4300---M4300
Interface vlan and OSPF configuration:
router ospf router-id 192.168.20.2
interface vlan 20 routing ip address 192.168.20.1 255.255.255.0 ip ospf area 0 exit
!
router ospf router-id 192.168.20.1 interface vlan 20 routing ip address 192.168.20.2 255.255.255.0 ip ospf area 0 exit
VLAN ID........................................ 20 IGMP Snooping Admin Mode....................... Enabled Fast Leave Mode................................ Enabled Group Membership Interval (secs)............... 600 Max Response Time (secs)....................... 120 Multicast Router Expiry Time (secs)............ 300 Report Suppression Mode........................ Disabled Report Flood Mode.............................. Enabled Exclude Mrouter Interface Mode................. Enabled IGMP-Plus...................................... Enabled
(M4300-96X) #show mac-address-table multicast
Fwd VLAN ID MAC Address Source Type Description Interface Interface ------- ----------------- ------- ------- --------------- --------- --------- 20 01:00:5E:00:00:05 Rsvd-MC Static Network Assist Fwd: Fwd: ---- the ospf multicast address was in vlan 20 ALL ALL 20 01:00:5E:00:00:06 Rsvd-MC Static Network Assist Fwd: Fwd: ALL ALL
Model: GSM4352S|M4300-52G - Stackable Managed Switch with 48x1G and 4x10G including 2x10GBASE-T and 2xSFP+ Layer 3
A Linux machine running Quagga (old and new versions)
A Juniper device
An Extreme/Brodcade device
Whether a particular port is trunk or access, whether the vlan is tagged or not, doesn't seem to matter.
Some notable differences I see in our configuration:
We're not using IGMP-Plus mode. When I looked at it, it didn't appear to be appropriate for our configuration because we use any-source multicast and IGMPv2. IGMP Plus mode enables report flooding, which in theory should activate host report suppression and wouldn't work. Additionally, I have Exclude Mrouter Interface Mode disabled, and as nice as fast leave auto detection would be, I've disabled it because it doesn't seem to be reliable and I only need fast leave on a very small number of select reports.
Also, we are using the switches as switches. I'm pretty sure we don't have any layer 3 features turned on, save for one routing interface we use as a management and monitoring IP. It's possible that using OSPF on the switch itself works and doesn't trigger this problem; I don't know.
Thank you for your thoughts. Netgear support just said essentially the same thing to me: Getting these entries now requires igmp-plus mode.
As I mentioned earlier, I did not enable igmp-plus mode for our environment because it appears that it enables features that are undesirable. I have written back to Netgear support to clarify if turning it on will break my environment or not, and I'm working on the maintenance window to give it a try tonight either way.
In speaking with Netgear support, it sounds like I can disable the parts of igmp-plus mode that aren't appropriate for our environment after I turn it on. So it sounds like @sdesigowda has the right answer here.
I will test tonight and let everyone know.
Thanks everyone for the assistance so far. Much appreciated.
I can confirm that @sdesigowda solution combined with the advice from Netgear support that I could disable inappropriate features worked. On top of that, after firmware upgrades, packet loss on our network is down 70-80% across the board (not that it was very high to begin with), so I am pleased.
Thank you everyone for your assistance. I would like to humbly suggest that Netgear update the documentation regarding this new feature and the new requirements it imposes. While I realize many will not read the documentation carefully, my team did, and somehow we missed it, so either it's not there, or it's not as clear as it should be. Either way, now that we correctly understand what the feature does, thanks to excellent Netgear support, we are running in a configuration that seems correct to me and that seems initially to be working very well.
