So, I have enabled VLAN filtering on both routers and the aggragate switch and trunked all ports including the LAN bridge, and now it appears to be working, but the connection to the routers doesnt seem as table as before. Also the DHCP table is still flodding. I dont think this is an issue with the VLANS, it appears to be some sort of discovery happening, maybe its a bug?
Thanks for indulging in the vlan-filtering=yes. I just know that works with VRRP, and if there was a bug/config-issue/etc here… I figured it block or change the issue. No such luck it seems.
Scanned your config again… I did notice one of the routers was using /ip/dhcp-server/alert & that might cause these entries in all VLANs. See https://help.mikrotik.com/docs/display/ROS/DHCP#DHCP-Alerts with the text:
As DHCP replies can be unicast, the rogue DHCP detector may not receive any offer to other DHCP clients at all. To deal with this, the rogue DHCP detector acts as a DHCP client as well - > it sends out DHCP discover requests once a minute> .
and other carefully worded text.
Perhaps just disable it for now*. And see if those entries come back.
- If that works, try re-enabling and picking the VRRP interface for /ip/dhcp-server/alert – although I don’t know how it interoperate with using VRRP – never used /ip/dhcp-server/alert myself, so not sure.
Its funny you say that, when I decided to hit it again lastnight, I noticed the alerts as well and thought to myself. I am actually going to try that next, I just want the stupid dynamic leases to stop popping up lol.
My man! That was it, I moved them to the VRRP interfaces and it has stopped the flood of DHCP entries. I still wonder why it was causing that, its kind of odd.
Good to hear! Lesson is posting the entire config is helpful… And even then I had to look /ip/dhcp-server/alert docs myself since I didn’t know HOW it worked. The yellow box in docs told the whole story however:
The docs make it clear that it SEND dhcp discovery requests, to deduce if the config’ed interface in running a dhcp-server on THAT interface. Since if the dhcp-server is on same router as alert, the local router hide/remove/ignore those requests, since it knows alert was enabled… BUT… the other router in VRRP have no clue a dhcp request was from another router’s /ip/dhcp-server/alert, so it’s just another client so it gets added as lease.
Essentially seems like /ip/dhcp-server/alert is the enterprise version of /interface/detect-internet – where there is hidden dhcp client lurking inside waiting to surprise you.
Additional Note: while I’ve always run dhcp-server on the VRRP interface, and this has long worked for me. It’s never been clear if that’s a “supported” configuration, since docs are silent on DHCP with in VRRP configurations. I do know that dhcp lease are NOT sync’d when using connection tracking. In my cases, I just don’t care what dhcp-server handled the lease, since client re-request same IP typically, and lease-time will eventually get them back on same router after failover. But adding the /ip/dhcp-server/alert on the VRRP, logically should be fine, but FWIW I didn’t test it.
I believe it may be due to that fact that I moved the DHCP servers over to the VRRP interfaces as well. This means all of the alerts we added were going to an interface not bein used the same way I guess. Personally, I didnt even realize that we did use dhcp alerts until I exported the whole dhcp server list to reimport them the way I wanted them. I changed them all to the vrrp interface, and they seem to be functioning properly now!
Thanks again man, I appreciate you sticking with me to find the cause, and for sure next time I will start with a full export!