'SVI' IP not arping

RouterOS General
1

I have a Cloudcore CCR1016-12G connected to an Aruba 8360 switch with a tagged ethernet link. One of the VLANs on the link is 8. This vlan is then bridged to Ether2 (connecting to an unmanaged switch). We also have a VLAN interface for this network on the Cloudcore with an IP address, the intention being that this will present devices on another network via NAT. The following diagram summarises the configuration:

Config:

/interface bridge
add ingress-filtering=no name=Bridge vlan-filtering=yes
/interface vlan
add interface=Bridge name=Bridge-SVI-1 vlan-id=8
add interface=ether1 loop-protect=on name=VLAN9
vlan-id=9
/interface bridge port
add bridge=Bridge interface=ether1
add bridge=Bridge fast-leave=yes interface=ether2 pvid=
8
/interface bridge vlan
add bridge=Bridge tagged=ether1 untagged=ether2
vlan-ids=8
/ip address
add address=192.17.6.52/23 interface=Bridge-SVI-1 network=192.17.6.0
add address=192.23.0.18/30 interface=VLAN9 network=
192.23.0.16
add address=192.17.6.54/23 interface=Bridge-SVI-1 network=192.17.6.0
add address=192.17.6.55/23 interface=Bridge-SVI-1 network=192.17.6.0
add address=192.17.6.56/23 interface=Bridge-SVI-1 network=192.17.6.0
add address=192.17.6.57/23 interface=Bridge-SVI-1 network=192.17.6.0
add address=192.17.6.53/23 interface=Bridge-SVI-1 network=192.17.6.0

I’m eventually wanting the Cloudcore to NAT traffic on another network to the 192.17.6.0/23 VLAN 8 network, but at the moment I can’t even get that far. The Cloudcore will not arp the ‘SVI’ IP address attached to the bridge. I have tried attaching the IP address to the Bridge-SVI-1 vlan interface, the bridge itself and even the Ether2 port but it will not respond to arp requests from either a Windows laptop on a switch attached to the Ether2 interface, or off an access port on vlan 8 on the Aruba switch. If I put a static arp entry in on the laptop I’m testing from communications work fine (the IP responds to ping, the NATs work). At one point through disabling and re-enabling things I got it arping somehow yesterday, but this wouldn’t work for the secondary IP addresses and has stopped again. I’ve tried wiping the Cloudcore, setting the bridge up as a simple bridge with a vlan attached to eth1 and eth2 as members and the IP attached to the bridge etc but nothing seems to work. Also got rid of all the secondary IPs. The bridge is otherwise functioning - layer 2 traffic is flowing back and forth between the Aruba and upstream devices and devices downstream on the Unifi switch attached to Ether2.
Why would this interface not respond to arp requests?
Another observation - pinging out from the device with the correct source address set does not work unless I set the source interface as well as the source IP.
Incidentally if I do a capture on all interfaces the Cloudcore doesn’t show my arp requests at all, although I see them going out from the Aruba switch.
The other thing I note is there seems to be a bug where even with a static arp entry on an endpont device if I turn on a packet sniffer the vlan can’t be pinged. As soon as the packet sniffer is stopped the ping starts working again.

I should add I have tried 7.6, 7.8, 7.9.2 and now 7.10rc4 to no avail.

2

For the benefit of others, I finally found this section in the documentation that caused the scales to fall from my eyes:

https://help.mikrotik.com/docs/display/ROS/L3+Hardware+Offloading#L3HardwareOffloading-L3HWDeviceSupport:~:text=Below%20are%20typical%20user%20errors%20of%20configuring%20Layer%203%20Hardware%20Offloading.

I’d missed the memo about L3 hardware offloading and ignored this initially as the CCR1016 wasn’t on the list of models in the article, however adding the Bridge itself as a tagged interface on the VLAN in Bridge - VLANs sorted the issue.

3

Its a strange quirk indeed that you need to add the bridge to itself as tagged :slight_smile:

4

There are a few (mior) errors in the config shown. But I suggest you to go through this article, which explains different personalities of bridge entity in ROS. After understanding it, it becomes clear when bridge interface has to be member of certain VLAN (passing bridge switch-like entity) - it doesn’t have anything to do with L3HW offload at all.

One thing is that when you set some interface as bridge port, you should not use it elswehere as anchor for other config. In particular: ether1 is set as bridge port, yet you’re anchoring VLAN9 interface off it (this vlan interface should be anchored off bridge interface). Also beware of deault “native” VLAN … in MT it’s due to implicit of setting pvid=1 everywhere it might apply, but normal configuration export will not show it (in CLI, “export verbose” will show it though). Which is the reason for suggestions (expressed in numerous forum posts) to avoid using VID=1 explicitly.