The intention is that any device now plugged into ether5_lan of Router 2, will still only see untagged traffic from its own site (Site B) by default, but can now optionally be on Site A instead, using vlan1234. And that seems to work fine, as expected
However the problem comes in if I plug a Windows PC on ether5_lan @ Site B. For some reason, it can also “discover” all Mikrotik devices which are on Site A’s bridge_lan with winbox discovery (“Neighbors”) section.
So my question is, howcome is discovery of devices from Site A leaking through the VLAN @ Site B like this and how can I block/overcome this “cross-vlan” layer-2 traffic? I don’t want Site A devices to be visible on untagged LAN @ Site B which seems to be the case right now
Yeah.. I really suspected this was the case. That’s pretty crazy … I’ve spent the whole day debugging vlans and trying the different vlan implementations (software, bridged, etc) and couldn’t figure this one out (I’m also pretty new to working with vlan’s so I suspected it was just me doing something wrong).
Thanks. so I guess I’m going to have to find a more elegant way to pass the vlan over to another mikrotik switch on the lan at Site B then without other PC’s on the lan seeing that vlan traffic so openly, as the client won’t be too happy with this. I could run another tunnel between those, but the problem is I need wire-speed switching.. Hrm, If anyone has any ideas on this please let me know
Are you saying that a windows PC with “standard” settings is seeing the tagged vlans, or did you go into driver properties and set it to have an second interface for vlan 10?
The “normal way” to do this would be to decouple the vlans at site B. E.g. have an access lan for the Site A vlan (an untagged access port, say ether5) and then when you plugged into ether5, you would “be” on the remote LAN at site A. If you plugged into ether1 through ether4 you would be on the local LAN at site B.
This is intentionally mismatching vlans (connecting different vlans over an untagged link with different pvid values at each end of the eoip-router1 interface link). I assume if vlans are in use at site A, the main lan is not using vlan 1234, it may be using the default vlan 1, but as long as it is untagged over the link, it will be “cast” into the correct local vlan by the specification of the pvid.
By using the above config, will receive untagged on the eoip-router1 interface and bridge ot vlan 1234, and then also connect vlan 1234 to a local access port on ether5_lan. Then a device plugged into ether1-ether4 will be only on the local lan, and when plugged into ether5 only on the remote lan.
Since you have eoip-router1 interface (probably with an address too), you will need to have a firewall in place if you don’t want things routed between the two networks.
I found the links in this post helpful when I was learning the RouterOS bridge way of dealing with vlans.
As @tdw mentioned, some brain-dead windows drivers ignore VLAN tag. And since discovery announcements are broadcast, these can be then seen by PC connected to ether5@B. If that PC isn’t configured to talk to VLAN 1234, the connection between PC and MT gear @siteA can’t be established.
With your setup, ether5 being member of VLAN 1234, you can’t speak about VLAN leaking, port is member of that VLAN. Broadcasts are always transmitted through every port member of certain VLAN (multicasts as well if switch/bridge doesn’t run any kind of IGMP snooping / PIM). So if you can’t trust connected equipment to deal with VLANs properly (you can’t if you didn’t configure it yourself), then you have to do the job on switch/bridge port. Universal thing to do is to set port as access (untagged) port to single VLAN and nothing more.
… I’ve spent the whole day debugging vlans and trying the different vlan implementations (software, bridged, etc) and couldn’t figure this one out (I’m also pretty new to working with vlan’s so I suspected it was just me doing something wrong).