VLAN filtering on a sigle bridge problem

RouterOS General
1

Hi,
I have four switches: 2x CRS328-24P-4S+ as EDGE switches and 2x CRS317-1G-16S+ as CORE switches. On all switches I have only one bridge for HW Offloading. There is also enabled on Bridge VLAN Filtering and Ingress Filtering on all switches and the MSTP is set. Master bridge has 1st CRS328-24P-4S+.

Network topology is like that:
1st CRS328-24P-4S+ is connected with sfp+1 to 1st CRS317-1G-16S+ and with sfp+2 to 2nd CRS317-1G-16S+.
2nd CRS328-24P-4S+ is connected with sfp+1 to 2st CRS317-1G-16S+ and with sfp+2 to 1nd CRS317-1G-16S+.
1st CRS317-1G-16S+ and 2nd CRS317-1G-16S+ have bonded port each other.

The problem is that I see ARP requests from different VLANs on ALL interfaces and they are not in the same VLAN. For Example if I do TCPDUMP on a port which is only VLAN 2 untagged (my LAN) I see broadcast traffic from VLAN 100 (from my ISP):
15:55:51.195928 ARP, Request who-has cpe-168.static.xxx.net tell ip.ac.xxx.net, length 46
15:55:51.195934 ARP, Request who-has cpe-168.static.xxx.net tell ip.ac.xxx.net, length 46
15:55:51.195938 ARP, Request who-has cpe-213.static.xxx.net tell ip.ac.xxx.net, length 46
15:55:51.195940 ARP, Request who-has cpe-213.static.xxx.net tell ip.ac.xxx.net, length 46

Each of this packets above has in header 4 times VLAN ID 4095 and one VLAN 100.

Does anyone have any idea what would be wrong with the configuration?

2

Not without actually seeing the configuration.

3 
interface bridge
# MSTP bridge priority 12 lowest bits are ignored
add comment="all VLANs, Hardware Offload" ingress-filtering=yes \
    name=bridge.allVLAN priority=0x8192 protocol-mode=mstp region-name=\
    XXX region-revision=1 vlan-filtering=yes

/interface bridge filter
add action=drop chain=output dst-mac-address=\
    01:80:C2:00:00:00/FF:FF:FF:FF:FF:FF out-interface=sfp+4.ISP
add action=drop chain=forward in-interface=sfp+4.ISP mac-protocol=vlan \
    vlan-id=100
    
/interface bridge port
add bridge=bridge.allVLAN interface=sfp+1
add bridge=bridge.allVLAN interface=sfp+2
add bridge=bridge.allVLAN interface=sfp+3
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=sfp+4.ISP pvid=100
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth1 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth2 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth3 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth4 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth5 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth6 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth7 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth8 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth9 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth10 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth11 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth12 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth13 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth14 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth15 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth16 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth17 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth18 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged ingress-filtering=yes interface=eth19 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth20 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth21 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth22 pvid=2
add bridge=bridge.allVLAN frame-types=\
    admit-only-untagged-and-priority-tagged interface=eth23 pvid=3
add bridge=bridge.allVLAN interface=eth24


/interface bridge vlan
add bridge=bridge.allVLAN comment=LAN tagged=sfp+1,sfp+2 untagged="eth1\
    ,eth2,eth3,eth4,eth5,eth6,eth7,eth8,eth9,eth10,eth11,eth12,eth13,\
    eth14,eth15,eth16,eth17,eth18,eth19,eth20,eth21,eth22" vlan-ids=2
add bridge=bridge.allVLAN comment=ISP tagged=sfp+1,sfp+2 untagged=\
    sfp+4.ISP vlan-ids=100
add bridge=bridge.allVLAN comment=DMZ tagged=sfp+1,sfp+2 untagged=eth23 \
    vlan-ids=3
4

Ingress filtering is only enabled on eth19 (and bridge interface), the rest of ports don’t have it set.

I’ve no other idea, perhaps some smart guys will pop by …

5

That is a fragment of the configuration on one device, so impossible to tell what is happening elsewhere. Nothing should be generating VLAN ID 4095 as it is a reserved value.

As @mkx said ingress-filtering=yes is only set on a couple of ports, without it frame-types= has no effect. Also /interface bridge filter has no effect on traffic between hardware accelerated ports, you have to use switch ACLs.

6

Thank you for the answers. The 2nd EDGE switch has exactly the same configuration except SFP+4 port is not connected.

Configuration on both CRS317-1G-16S+ is like this:

/interface bridge port
add bridge=bridge.allVLAN frame-types=admit-only-vlan-tagged interface=\
    sfp+9
add bridge=bridge.allVLAN frame-types=admit-only-vlan-tagged interface=\
    sfp+11
add bridge=bridge.allVLAN frame-types=admit-only-vlan-tagged interface=\
    sfp+13
add bridge=bridge.allVLAN frame-types=admit-only-vlan-tagged interface=\
    sfp+14
add bridge=bridge.allVLAN frame-types=admit-only-vlan-tagged interface=\
    sfp+15
add bridge=bridge.allVLAN frame-types=admit-only-vlan-tagged interface=\
    sfp+16
add bridge=bridge.allVLAN frame-types=admit-only-vlan-tagged interface=\
    sfp+10
add bridge=bridge.allVLAN frame-types=admit-only-vlan-tagged interface=\
    sfp+12
add bridge=bridge.allVLAN frame-types=admit-only-vlan-tagged interface=\
    bonding.CoreSwitch


/interface bridge vlan
add bridge=bridge.allVLAN comment=LAN tagged="sfp+9,sfp+11,sfp+13,sfp+14,sfp\
    +15,sfp+16,sfp+10,sfp+12,bonding.CoreSwitch,sfp+7,sfp+8" vlan-ids=\
    2,3,4,5,6,7,8
add bridge=bridge.allVLAN comment=ISP tagged=\
    bonding.CoreSwitch,sfp+7,sfp+8,sfp+11,sfp+12 vlan-ids=101

About ingress filtering MikroTik says on Wiki: Enables or disables VLAN ingress filtering, which checks if the ingress port is a member of the received VLAN ID in the bridge VLAN table. By default, VLANs that don’t exist in the bridge VLAN table are dropped before they are sent out (egress), but this property allows you to drop the packets when they are received (ingress).

I’m wondering from where VLAN 4095 comes from? Maybe from ISP? XX.XX.XX.XXX and XX.XX.XX.1 are WAN IPs from the ISP.

When I put Wireshark on eth19 which has ingress-filtering=yes I still se this:

Cisco_5a:53:XX	Broadcast  ARP	72	Who has XX.XX.XX.XXX? Tell XX.XX.XX.1
Cisco_5a:53:XX	Broadcast  ARP	72	Who has XX.XX.XX.XXX? Tell XX.XX.XX.1
Cisco_5a:53:XX	Broadcast  ARP	72	Who has XX.XX.XX.XXX? Tell XX.XX.XX.1
Cisco_5a:53:XX	Broadcast  ARP	72	Who has XX.XX.XX.XXX? Tell XX.XX.XX.1

BTW: We do not have any Cisco in our network.

And if I analyze one if this packet i see:

Frame 12: 76 bytes on wire (608 bits), 72 bytes captured (576 bits) on interface 2
Ethernet II, Src: Cisco_5a:53:XX (00:af:1f:5a:53:XX), Dst: Broadcast (ff:ff:ff:ff:ff:ff)
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 4095
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 4095
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 4095
802.1Q Virtual LAN, PRI: 0, DEI: 0, ID: 101
Address Resolution Protocol (request)

So where does the VLAN 4095 comes from? Because I can’t even set VLAN 4095 on bridge… What I found about VLAN 4095 on internet is that VLAN 4095 is used internally within a switch,…

7

If ether19 is your uplink to the ISP, then yes, these funny frames come from the ISP.

Next, as @tdw has pointed out, the ingress-filtering=yes only has any effect on frames which are processed by the software bridge. Frames which are forwarded by the switch chip alone (which is the very substance of “hardware-accelerated bridging”) are not affected, and you have to use the switch chip rule table to do ingress filtering of these frames. So the rule should look somehow like the following (not tested, I don’t have any CRS3xx):

/interface ethernet switch rule
add ports=ether19 vlan-header=present vlan-id=4095 new-dst-ports=“”