EoIP not working as expected

RouterOS General
1

Hello everyone! Thanks for your interest in my problem!
I have multiple external IPs on side 1, and need to use this IPs on clients on side 2.
I have test setup in hyper-v, using free CHR license.
1 VM: ROS, 1 ethernet tagged with vlan 2(it is simulates side 1 router), has static IP 192.168.255.2, has EOIP tunnel with side 2 router, bridge between uplink port eth1 and eoip-tunnel, and DHCP server on this bridge that gives out external addressed to its clients.
2 VM: ROS, 2 ethernet tagged with vlan 2 and vlan 3(it is simulates “internet” between side 1 and side 2), has static IP 192.168.255.1 and 192.168.0.1
3 VM: ROS, 2 ethernet tagged with vlan 3, vlan 4(it is simulates side 2 router), has static IP 192.168.0.2, and bridge between eoip-tunnel and eth2(vlan 4, clients ethernet port)
4 VM: ROS, 1 ethernet tagged with vlan 4(it is simulates client of side 2), has no static ip, but configured dhcp client
So the problem is, that 4th VM, with vlan 4 that simulates client of side 2 does not acquiring address from dhcp-server of VM 1, side 1 router, but on Side 2 router, where DHCP server is, I’m seeing that it offers address to this VM.

Configs:

VM1:

/interface bridge
add name=bridge1
/interface eoip
add allow-fast-path=no ipsec-secret=1 mac-address=02:7D:9C:66:F1:F9 mtu=1500 name=eoip-tunnel1 remote-address=192.168.0.2 tunnel-id=0
/ip pool
add name=dhcp_pool1 ranges=192.168.255.4-192.168.255.20
/ip dhcp-server
add address-pool=dhcp_pool1 disabled=no interface=bridge1 name=dhcp1
/interface bridge port
add bridge=bridge1 interface=ether1
add bridge=bridge1 interface=eoip-tunnel1
/ip address
add address=192.168.255.2/24 interface=ether1 network=192.168.255.0
/ip dhcp-server network
add address=192.168.255.0/24 gateway=192.168.255.3 netmask=24
/ip route
add distance=1 gateway=192.168.255.1
/system identity
set name=vlan2-side1


VM2:

/ip address
add address=192.168.255.1/24 interface=ether1 network=192.168.255.0
add address=192.168.0.1/24 interface=ether2 network=192.168.0.0
/system identity
set name=vlan2-vlan3


VM3:

/interface bridge
add name=bridge1
/interface eoip
add allow-fast-path=no ipsec-secret=1 mac-address=02:CC:22:19:48:F0 mtu=\
    1500 name=eoip-tunnel1 remote-address=192.168.255.2 tunnel-id=0
/interface bridge port
add bridge=bridge1 interface=eoip-tunnel1
add bridge=bridge1 interface=ether2
/ip address
add address=192.168.0.2/24 interface=ether1 network=192.168.0.0
/ip route
add distance=2 gateway=192.168.0.1
/system identity
set name=vlan3-side2


VM4:

/ip dhcp-client
add disabled=no interface=ether1

https://imgur.com/a/MVyN6J0

2

On Hyper-V, like on other virtualization platforms, it is a common security measure that by default, the virtual switches only accept frames at ingress if their source MAC address matches the one of the connected virtual machine’s network interface. To get rid of this limitation, you have to change the NIC settings of the VM: hardware → network interface → advanced → permit MAC address spoofing.
In particular, the eth2 on VM3 needs to be set this way, so that the frames which come from the DHCP server at VM1 would be forwarded to VM4.

There used to be yet another issue, vlan-filtering on a bridge had to be set to yes so that the bridge worked when the CHR was running on Hyper-V (it was not the case on VMware). I don’t know whether it is still the case, but it was with 6.45.9.

3

What @sindy said is right. Firstly make sure that MAC spoofing (promiscuous mode) is enabled and that VLANs are allowed in the virtual switch.

the bug which @sindy mentioned is clearly related to my earlier investigation: http://forum.mikrotik.com/t/chr-does-not-transmit-frames-with-vlan-tags-from-bridge/127278/1
I will test further because so far, I didn’t know that I have to enable vlan filtering (even if i don’t want any VLAN filtering to occur)

4

Wow! Thank you, this really was the case. I though that i messed something with configs.

5

It’s funny as when reading your post some months ago after running into the same issue, from your wording there I’ve obtained a feeling that you’ve tried both ways, but you just didn’t want to use the vlan-filtering mode, not filtering of VLANs as such. Maybe back then I’ve even tried with vlan-filtering=yes only based on that post, I can’t remember :slight_smile:

Regarding the OP here, since this second issue only affects tagged frames, it is unrelated to this topic. But when responding yesterday, I just hazily remembered “something” else was wrong there and didn’t search for the details.