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?
Solved! Go to Solution.
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:
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!
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 ?
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
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 ?
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:
Could this be the reason why it's not working?
makes sense I guess. So, what about just blocking all unknown multicast traffic on the port channel with the 'switchport block multicast' command ?