I actually did some digging and hopefully I narrowed it down to a simple statement:
receiving and transmitting untagged data between bridge and hypervisor's virtual ethernet interface work
receiving and transmitting VLAN tagged data between VLAN interface and hypervisor's virtual ethernet interface work
receiving and transmitting VLAN tagged data between bridge and hypervisor's virtual ethernet interface DOES NOT work
(there is no VLAN filtering on bridge enabled, even though it seems like obvious cause)
Now let me prove it.
In HyperV, I have properly configured vlan trunking:
Code: Select all
PS C:\WINDOWS\system32> Get-VMNetworkAdapterVlan
VMName VMNetworkAdapterName Mode VlanList
------ -------------------- ---- --------
dut eth1 Trunk 0,1-4094
tester eth1 Trunk 0,1-4094
Similarly, I have enabled MAC spoofing on both adapters.
Then I have CHR2 (dut) with following config:
Code: Select all
/interface bridge
add fast-forward=no name=bridge1
/interface ethernet
set [ find default-name=ether1 ] disable-running-check=no
set [ find default-name=ether2 ] disable-running-check=no name=ether2-management
/interface vlan
add interface=ether1 name=vlan1 vlan-id=98
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge1 hw=no interface=ether1 trusted=yes
/ip neighbor discovery-settings
set discover-interface-list=none
/ip address
add address=10.99.0.3/24 interface=ether1 network=10.99.0.0
add address=10.99.1.3/24 interface=bridge1 network=10.99.1.0
add address=10.99.98.3/24 interface=vlan1 network=10.99.98.0
/ip dhcp-client
add add-default-route=no dhcp-options=hostname,clientid disabled=no interface=ether2-management use-peer-dns=no use-peer-ntp=no
/system identity
set name=dut
With this config, I can easily ping any address. All of them are responding fine (even though ether1 shouldn't have address as it is slave...) I am actually using ARP ping to make sure that no ARP shenanigans will affect my test:
Code: Select all
[admin@tester] > ping 10.99.0.3 arp-ping=yes interface=ether1
SEQ HOST SIZE TTL TIME STATUS
0 00:15:5D:C9:30:0B 1ms
1 00:15:5D:C9:30:0B 0ms
2 00:15:5D:C9:30:0B 0ms
[admin@tester] > ping 10.99.1.3 arp-ping=yes interface=ether1
SEQ HOST SIZE TTL TIME STATUS
0 00:15:5D:C9:30:0B 0ms
1 00:15:5D:C9:30:0B 0ms
2 00:15:5D:C9:30:0B 2ms
[admin@tester] > ping 10.99.98.3 arp-ping=yes interface=vlan1
SEQ HOST SIZE TTL TIME STATUS
0 00:15:5D:C9:30:0B 0ms
1 00:15:5D:C9:30:0B 1ms
2 00:15:5D:C9:30:0B 3ms
Now, lets change config to create the bug:
Code: Select all
[admin@dut] > /interface vlan set vlan1 interface=bridge1
Anyway, lets look what results I get now:
Code: Select all
[admin@tester] > ping 10.99.0.3 arp-ping=yes interface=ether1
SEQ HOST SIZE TTL TIME STATUS
0 00:15:5D:C9:30:0B 4ms
1 00:15:5D:C9:30:0B 0ms
2 00:15:5D:C9:30:0B 4ms
[admin@tester] > ping 10.99.1.3 arp-ping=yes interface=ether1
SEQ HOST SIZE TTL TIME STATUS
0 00:15:5D:C9:30:0B 2ms
1 00:15:5D:C9:30:0B 7ms
2 00:15:5D:C9:30:0B 4ms
[admin@tester] > ping 10.99.98.3 arp-ping=yes interface=vlan1
SEQ HOST SIZE TTL TIME STATUS
0 10.99.98.3 timeout
1 10.99.98.3 timeout
2 10.99.98.3 timeout
Lets look at packet sniffers. We have 4 points of interest: vlan1 in dut, bridge1 in dut, ether1 in dut and finally ether1 in tester:
Code: Select all
[admin@dut] > tool sniffer quick interface=vlan1
INTERFACE TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
vlan1 10.71 1 <- 00:15:5D:C7:30:0D FF:FF:FF:FF:FF:FF 10.99.98.2: who has 10.99.98.3?
vlan1 10.71 2 -> 00:15:5D:C9:30:0B 00:15:5D:C7:30:0D 10.99.98.3: at 00:15:5D:C9:30:0B
[admin@dut] > tool sniffer quick interface=bridge1
INTERFACE TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
bridge1 7.237 1 <- 00:15:5D:C7:30:0D FF:FF:FF:FF:FF:FF 98 10.99.98.2: who has 10.99.98.3?
bridge1 7.237 2 -> 00:15:5D:C9:30:0B 00:15:5D:C7:30:0D 98 10.99.98.3: at 00:15:5D:C9:30:0B
[admin@dut] > tool sniffer quick interface=ether1
INTERFACE TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
ether1 5.187 4 <- 00:15:5D:C7:30:0D FF:FF:FF:FF:FF:FF 98 10.99.98.2: who has 10.99.98.3?
ether1 5.187 5 -> 00:15:5D:C9:30:0B 00:15:5D:C7:30:0D 98 10.99.98.3: at 00:15:5D:C9:30:0B
[admin@tester] > tool sniffer quick interface=ether1
INTERFACE TIME NUM DI SRC-MAC DST-MAC VLAN SRC-ADDRESS
eth2-jcw 0.991 1 -> 00:15:5D:C7:30:0D FF:FF:FF:FF:FF:FF 98 10.99.98.2: who has 10.99.98.3?
eth2-jcw 2.051 2 -> 00:15:5D:C7:30:0D FF:FF:FF:FF:FF:FF 98 10.99.98.2: who has 10.99.98.3?
eth2-jcw 3.081 3 -> 00:15:5D:C7:30:0D FF:FF:FF:FF:FF:FF 98 10.99.98.2: who has 10.99.98.3?
Now, why do I think it is fault of CHR? Elementary, my dear Watson - there is no difference in frame, whether it goes vlan1->ether1 or vlan1->bridge1->ether1. Due to that, anything else except dut (for example HyperV, tester, host OS...) can't possibly know, there was such change in topology.
Same thing happens when (instead of vlan1) communication flows for example through bridged EoIP from some remote device. As long as it is not tagged, it works. Once it gets tagged and goes through a bridge in CHR to virtual ethernet, it never leaves...
It also does not matter if the "tester" device is virtual or physical.
As always, when I find some reportable bug, I would like to ask you - clever members of this community - to look at it and point out any possible issue which I missed.
This time, situation is really simple and easily replicable - can anyone confirm/deny this bug?