The trunk port is carrying two tagged VLANs (10, 50) and 1 untagged VLAN (1) and is connected to a CISCO WS-C2960, which itself is connected via a trunk to a CISCO WS-C3650 aggregation switch.
The problem is that I found a lot of clients of both VLANs 10 and 50 in the “host table” (Bridge menu) that are not locally connected to the MT CRS switch. The were all marked as “DE” (Dynamic, External). Above that I had MAC address-flapping on the Cisco WS-C2960 because he had the same MAC addresses both on its aggregation switch and on the MT CRS.
Why has the CRS all these hosts in it’s host table? I believe every switch in a broadcast domain has its own MAC Address Table (CAM Table), they are not shared. And is this the reason I keep getting MAC address-flapping on the WS-C2960 switch?
First: in L2 domain (switched ethernet) every switch will have MAC address of (almost) every active device in its switching table and it doesn’t matter if it’s directly connected or behind a couple of switches. The purpose of switching table is that each and every switch forwards packet only through port which (eventually) connects the destination. If the destination is behind another switch, then this switch still needs to know the local egress port that should carry the frame. In case another switch is connected to local port, switching table will have many MACs paired with same port.
When topology changes, MAC entries in switching table is partially invalid for a while. Things get sorted out by two mechanisms: 1) switch sees a frame with src MAC arriving through different port and changes the switching table 2) entries in switch table have some timeout values and when they expire, they are purged from switch table. If a frame arrives at switch and switch doesn’t have corresponding entry in switch table, it’ll forward the frame to all ports (except the ingress port) …
But it’s slightly unclear to me what exactly you’re referring to with “MAC address-flapping” …
What device does the flapping MAC address belong to?
You have RSTP enabled on the CRS, do you have any spanning tree configured on the Cisco devices? IIRC the default is PVST+ which doesn’t necessarily play nicely with RSTP.
The device is some HUAWEI tablet from our data VLAN. But I see A LOT of clients “MAC flapping” that way on the WS-C2960. But this switch is just my desktop switch with three devices connected to it, one of them beeing the MT CRS. And the MAC flapping comes and goes.
Are you thinking of a problems in regards to a Spanning Tree topology change? Wouldn’t that explain the “randomness” of MAC address flapping?
The WS-C2960 has RPVST+ configured and the MT CRS is default in terms of STP (so RSTP). The MT CRS shows up as a p2p link and Fa 0/7 is a (Cisco)-Trunk, so it accepts BPDUs.
show spanning-tree vlan 10
VLAN0010
Spanning tree enabled protocol rstp
Root ID Priority 4106
Address 00xx.5axx.b6xx
Cost 22
Port 9 (GigabitEthernet0/1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32778 (priority 32768 sys-id-ext 10)
Address 00xx.50xx.20xx
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Fa0/1 Desg FWD 19 128.1 P2p Edge
Fa0/7 Desg FWD 19 128.7 P2p
Gi0/1 Root FWD 19 128.9 P2p
I was thinking of spanning tree topology changes, but that looks to be fine.
What are you expecting the /interface ethernet switch acl rule to do ? My reading of those options is that any packets destined for the standard DHCP server port will be redirected to ether1 - likely including any received on ether1, such as the initial client DHCPDISCOVER broadcast across the entire layer2 network.
Bridge DHCP Snooping on CRS1xx/2xx feature will not work properly in VLAN switching setups, unless you make sure that required packets are sent out with the correct VLAN tag using ACL rules. The ACL rule was given to me by the MikroTik support when asked for an example.
On ether8 of the MT CRS there is a MT hEX PoE attached that hands out IP addresses for testing purposes, and I don’t want it to be a rogue DHCP server on our production network. That’s why I enabled DHCP snooping (on the bridge) and configured this ACL.
Elsewhere the wiki states “For CRS1xx and CRS2xx series switches it is possible to use DHCP Snooping along with VLAN switching, but then you must make sure that DHCP packets are sent out with the correct VLAN tag using egress ACL rules” - my emphasis added. The rule they provided is for ingress traffic so may not have the desired effect.
As a test get a client device to perform a broadcast DHCPDISCOVER (probably have to release existing address first as renews are unicast) and see if that corresponds with the port flap messages. If that is the trigger then try disabling that rule (with the test DHCP server disconnected for safety) and repeating.
Yes, I will give it a try. For the moment I have switched to the “normal” post-6.41 ROS bridge way of configuring MT switches with VLANs (abandonning the HW offloading, I know) and have not seen any MAC address flapping as of yet. I will update the thread if I find the time to dig any further.
I have also contacted support to inquire for the proposed ACL that would make DHCP snooping with option 82 to work in CRS1xx/CRS2xx switches (also using VLANs).
The ACL they gave my is: