A Mikrotik CHR LAN/hotspot interface connect to a switch tagged access port. however, mikrotik can see dhcp requests and arp updates from other vlans too over that port, which fail/stale state. problem is mikrotik responds to dhcp requests from those devices on other networks too (ip conflict in log), failing to provision to required vlan as dhcp pool used up.
Any suggestion how CHR pool/hs-bridge could be set to avoid responding to dhcp request from unknown vlans, or stop such request at switchport where CHR VM connects to physical switch.
I don't have experience with CHR ... but other ROS devices handle ethernet broadcasts (such as ARP and DHCP packets) with VLAN headers just fine.
How's CHR's configured to deal with VLANs? If you're using interface towards switch as hybrid (one VLAN passing wire untagged ... I believe some vendors call this kind of setup "native VLAN") and have DHCP server bound directly to such interface (as opposed to having VLAN interface in between), then I guess that DHCP server might be able to "see" also tagged packets.
it says no difference in physical and chr as configuration wise. the setup is single LAN segment to use hotspot service for public users. however, the switch connected got few other network like corporate and others. Since CHR LAN segment connects to an access port for public internet vlan, was not expecting to see arps and dhcp request for other vlans. thanks
If the CHR is seeing other VLANs and the switch is supposedly configured as an access port for one VLAN that would point to a switch misconfiguration, nothing to do with the CHR
Yes, I would say a misconfiguration somewhere, but possibly in the CHR. DHCP works only on a single broadcast domain, which points to the SBD 'leaking' out via an interconnection.
Which to me tells that it's not CHR leaking VLANs (it's supposed to be connected to access port, so no VLAN tags should exist there), it's the switch (as @tdw already menitoned).
Absolutely. But it would be a grave error only to focus on CHR ...
The fact that CHR is connected to access port of a switch was only revealed in recent posts ... and port being configured as access should not pass any VLAN-tagged frames in the first place (now, it is possible that we're not talking about access port but about hybrid port ... which has a very different behaviour) ... so CHR seeing those frames IMO points directly at switch port configuration.