Uncheckng the MC

[highlands]

I found that the MC (Multicast) controls more than just the Multicast. It also stops the Broadcast that comes from a DHCP DISCOVER. there are very picky rules around what is a Multicast, Unicast and a Broadcast. They 'rule set' to catch and know the difference takes a good amount of research. I would request that additional research is done before that feature is considered working.

John

[sirhc]

I found that the MC (Multicast) controls more than just the Multicast. It also stops the Broadcast that comes from a DHCP DISCOVER. there are very picky rules around what is a Multicast, Unicast and a Broadcast. They 'rule set' to catch and know the difference takes a good amount of research. I would request that additional research is done before that feature is considered working.

John

I can tell you that checking or unchecking Multicast on a port does not block DHCP discovery, however make sure you do not have the check mark on the DS column which is DHCP snooping and will block DHCP Discovery from that port to any other port.

[highlands]

The DS is not and has not ever been used.

The graph is what happened after we removed the MC check mark on all ports. We did NOT notice the affect at the time. However when the leases ran out on the end users devices, and those devices did a DHCPREQUEST to reaffirm the current IP that traffic was blocked, however a device will keep its last known IP. If a end user did a reboot of their router then there would be NO IP and a DHCPDISCOVER would be blocked also. The net effect was no IP so no service.

The bottom line is we tailed the log and looked for traffic during those times from that location there were none, zero, nada. DHCPDISCOVER and DHCPREQUEST were unable to get to the DHCP server. At the end issue we did a wireshark capture to t-shoot the issue, we monitored the port that the WS connects to and did not see any DHCPDISCOVER and DHCPREQUEST come through. All we did to restore service was to place a check back in the MC and apply, then all the users grabbed a lease within a hour.

If you would like us to do some additional testing, but then you can do the same in your lab. This exact same thing happened on two separate units on two completely different locations separated by about 70 miles.


WS-12-250-DC




Firmware Version
1.3.9


Board Rev
D




WS-12-DC




Firmware Version
1.3.9


Board Rev
E




John

[Eric Stern]

I set up a test in my lab, turned of MC on all ports and plugged my laptop into it. It got a DHCP address and worked as expected.

So in general the MC option is not affecting DHCP. I don't know how this is affecting you. My only real guess is that if you are using DHCP multicast scopes, then obviously disabling MC is going to interfere with that.

Maybe send a copy of the wireshark capture when DHCP is working?

[adairw]

I just tested this myseld.
WS-8-AC with a mikrotik router plugged in to it.
disabled MC on all ports. cycled wifi on my phone, no problem grabbing DHCP via the Unifi AP plugged in to the switch.
Set my desktop computer to DHCP, no problem grabbing an address via DHCP with MC off.
Running 1.3.9 on the switch.

[seritsp]

I can verify that this problem stil exists, and it has to be a fimware bug, because this is not working as intended.

Tested setup 1:
DHCP-server feeding into an WS-12-400AC (Firmware 1.5.9rc1, Board rev. F) untagged.
Connecting to another untagged port on same vlan with mc unchecked gives me IP, and see packets both going out and coming in on Wireshark.

But, the plot thikens...
Tested setup 2:
DHCP-server feeding into an WS-12-400AC (Firmware 1.5.9rc1, Board rev. F) untagged, with uplink to another Netonix untagged
Uplink feeding into WS-6-Mini (Firmware 1.5.9rc1, Board rev. F)
When MC is disabled on uplink port from WS-12-400AC, DHCP works as expected when connecting to the WS-6-Mini.
When MC is disabled on uplink port from WS-6-Mini, DHCP is blocked when connecting to the WS-6-Mini.
When MC is disabled on both switches on the uplink port, DHCP is blocked (No difference)

It seems like the last switch is the culprit. Could try the other way around, with the dhcp-server connected to the WS-6-Mini, and Client connected to the WS-12-400-AC, but i suspect there would be no difference. This was labbed due to this exact issue happening when we were installing a new site, and the uplink on our WS-12-250-DC had this checkbox disabled. I didn't notice it being disabled since we never uncheck MC, but i suspect cold wet fingers may have caused an incidental push on this button when my touchpad was acting up. Caused me about three hours where I literally though I was going insane. Ping passes through with MC unchecked, but it takes a few pings until the arp table is up to date.
Also I have tried fully disabling MSTI/RSTP/STP without any further success. I haven't tried this setup without a management vlan also running, so there has always been a minimum of two vlans on the switches. The bug is also verified to be present in 1.5.8 firmware.

Let me know if I should do any further testing, and if any logs may be needed, but this problem should be easy to reproduce for someone working @ Netonix.

[seritsp]

Can also add that with MC enabled on EVERYTHING execpt the port connected to the DHCP-server also breaks DHCP.

[seritsp]

You don't actually need two switches to get this bug awakened. It seems DHCP is blocked on the first switch also, when disabling MC on the port the DHCP-server is connected to.
DHCP is definitely broadcast traffic, and should not be affected by MC(Multicast) enabling or disabling.