For starters I would like to test that for example - Mikrotik router A should be getting only tagged VLAN packets for two Vlan's ID=1010 and 1020, then router B should be getting tagged VLAN packets for another two vlan's ID= 2010 and 2020 ?
First of all think about how the switching and bridging works. Once a frame from
a given unicast MAC has been received through any port of the bridge or switch, that MAC address associates with that port and until the association either times out or gets rewritten by arrival of a frame from the same MAC address through another port, all frames for
that MAC address are only send out via that port.
So to test for leaks, you have to make sure that you either send the test frames to a multicast MAC address or that you send them to a unicast MAC address which doesn't exist in your network, which always causes the frames to be sent out all ports., or that you have manually associated a destination address with a particular port on which you want to test, which may not be always possible (especially when a switch chip is involved) but if it is, it causes the frames to be sent through that single port only. So when I do things like this, I manually set arp records binding an unused IP address to an unused MAC address on an L3 interface which would be the /interface vlan
in your case and expect them to be broadcast via all switch/bridge ports.
The second thing is where to look for the leaked frames. Since there is often a switch chip between the CPU (where the sniffing actually takes place) and the wire, to be sure whether the frame has reached the wire or not you always have to look for the leaked frames at the other end of the wire. Also, if you use the switch chip for forwarding, make sure that you nject the frames you suspect to possibly leak also from other ingress ports, not just from the CPU. The switch chips normally take the decision what to do with the frame already at ingress.
And the third thing is how to detect leaked frames on the remote side. Of course the key is that the test receiver would neither filter by VLAN tag nor remove the tag (as most Windows drivers and reportedly also some Linux drivers do). If the test receiver is another Mikrotik, you can use /tool sniffer
to see what exactly is coming in, but you can also use /interface bridge filter
rules to just count frames matching the vlan ID you look for, e.g. chain=input action=accept in-interface=ether1 src-mac-address=34:CA:6D:00:00:00/FF:FF:FF:00:00:00 mac-protocol=vlan vlan-id=1020
, chain=forward action=accept in-interface=ether1 src-mac-address=34:CA:6D:00:00:00/FF:FF:FF:00:00:00 mac-protocol=vlan vlan-id=1020
. Of course, the ingress port you use for the test must be a member port of some bridge on the test receiver if you want to use /interface bridge filter
rules, and hw=no
must be set in the corresponding /interface bridge port
row; if you use the sniffer, it is better that the ingress port used as test receiver is not a member of any bridge and has no IP configuration attached.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.