MAC Filtering not working - need assistance

[LesterClayton]

We have joined our L2 network with another one via a Cisco Catalyst 4500X switch, which has two egress ports in a port channel.  We use MSFT NLB technology, which is sent to every device which participates in the same VLAN.  We want to deny this traffic from being sent to the other network.

I have made the following configuration changes:

mac access-list extended msft-nlb
 deny   any 02bf.0000.0000 0000.ffff.ffff
 permit any any
interface Port-channel116
 mac access-group msft-nlb out

When I do capture on the connected network, I still see traffic being sent to a MAC address which should have been denied by the filter.

Is MAC filtering supposed to have prevented this packet from leaving the network?  Have I made a mistake in my configuration or have I misunderstood what MAC Filtering does?

[Georg Pauwen]

Hello,

the access list looks ok and should work. Try to apply it in instead of out:

interface Port-channel116
 mac access-group msft-nlb in

[LesterClayton]

Already tried that.  Also tried applying access-group to every interfaces which make up the port channel.

[Georg Pauwen]

Hello Lester,

I faintly remember there being an issue with mac access lists and wildcard masks. Can you try and match a couple of host mac addresses (exact matches, no wildcard bits) and see if those are blocked ?

[LesterClayton]

Tried that.  Also tried adding the filter to the ingress interface where the traffic comes in from (blocking it inbound rather than blocking it outbound)

Ingress Interface: Te1/16

Egress Interface: Te1/9, Te1/10 (Port Channel 116)

This is current config (snippets of):

mac access-list extended msft-nlb
 deny   any host 02bf.0a6e.b097
 permit any any
!
interface Port-channel116
 description Uplink to switch NDC-NDC02-SW-EXT10
 switchport
 switchport mode trunk
 mac access-group msft-nlb in
 mac access-group msft-nlb out
 spanning-tree bpdufilter enable
!
interface TenGigabitEthernet1/9
 description LACP-EXT-10
 switchport mode trunk
 channel-protocol lacp
 channel-group 116 mode active
!
interface TenGigabitEthernet1/10
 description LACP-EXT-10
 switchport mode trunk
 channel-protocol lacp
 channel-group 116 mode active
!
interface TenGigabitEthernet1/16
 description UPLINK-SKN-SW08
 switchport mode trunk
 load-interval 30
 mac access-group msft-nlb in
!

But the traffic still goes through to the other network

[Georg Pauwen]

Hello,

I'll do some more testing, in the meantime, there is a bug where 'spanning-tree bpdufilter enable' disables the ACL. For the sake of testing, can you remove that line ?

[LesterClayton]

My side of the network is MST. The other network is RSTP. Will removing the bpdufilter enable line cause any problems? This is a production environment. I do not have the ability to test this in an isolated environment.
Remember too that we have added this access list to the ingress port which has no bpdufilters enabled, and the traffic is still passing through this switch.

[LesterClayton]

I want to suggest a reason why this isn't working - and will never work.  It's a theory I have, but it would be helpful to know if it is correct.

Preamble: MAC Address 02:bf:0a:6e:b0:97 doesn't exist anywhere on the network,  It will never exist anywhere on any network.  If I type "show mac address-table | include 02bf.", it will always return no results.  It's a MAC Address used by Microsoft's NLB configured in a Multicast group.  The machine(s) which are members of that group will speak to the rest of the network using their properly-assigned MAC Address, but all members of the NLB group will receive the traffic merely because switches don't know where to send the traffic to and will therefore coincidentally send it to the virtual machine alongside everywhere else.

The theory I have is:

• Switch receives the traffic on its ingress port
• Switch looks up MAC table to see if MAC is on any of its ports.  No Result
• Switch sends traffic out to every port (trunk or access) which is in the same VLAN as the received traffic
• Access List is ignored due to the fact that it's unmapped MAC Address (no MAC to port mapping found)

Could this be the reason why it's not working?

[Georg Pauwen]

Hello,

makes sense I guess. So, what about just blocking all unknown multicast traffic on the port channel with the 'switchport block multicast' command ?

[LesterClayton]

The traffic itself is not seen as Multicast, but rather as Unicast :/

[amikat · Accepted solution]

Hi,

MAC ACLs are generally effective for non-IPv4 traffic only. While this is somewhat platform dependent it is also true for your box.

To cope with the MS NLB in the multicast mode you typically configure static arp and static mac address as per the document beneath:

https://www.cisco.com/c/en/us/support/docs/switches/catalyst-6500-series-switches/107995-configure-nlb-00.html

Best regards,

Antonin

[LesterClayton]

I like where this is going.  Thank you I'm going to play around with this.

Hopefully by telling the switch "This mac belongs on that port", it won't send it to any other port.  Will report back if it resolves my issue.

[LesterClayton · Accepted solution]

You have led me to a resolution.  I have placed the following command on the switch:

mac address-table static 02bf.0a6e.b097 vlan 41 drop

And now the traffic is not being forwarded to the new network.  Result!