1010 : You're denying UDP traffic, from source 224.0.0.552 (LLMNR), source port 5355, to any destination, and logging it.
I'm by no means, an ACL expert, but as far as multicast goes, the multicast IP address is not what the device (or network port) would see as the source in a packet capture. The unicast address would be in the packet header. Because of that, I don't think ACL lines 1010 and 1030 (or 15/25 in the example) actually do anything. From my perspective, they seem like useless lines in the ACL.
However, lines 10 and 20 from the example seem like what is needed. You block any protocol, from any unicast address, from sending to those two multicast addresses. If the port/SVI sees that traffic, it will drop it.
These two lines prevent UDP traffic, from that specific network, from sending to the multicast ip, matching port 5355 and logs it. Those two lines are effective, albeit very specific to the port. Why do you choose to specify port 5355? The example does not restrict the destination down to the UDP port.
-------------------------------------------
Original Message:
Sent: Dec 09, 2025 05:45 AM
From: parnassus
Subject: AOS-CX ACL Broadcast & Multicast threats mitigations
Hello Swarup! do you mean that (2nd and 4th ACEs) might not be effective (due to the way they are made [*])?
...
1010 comment Deny VLAN 2021 outgoing response to incoming LLMNR MLD query UDP/5355 to multicast 224.0.0.252
1010 deny udp 224.0.0.252 eq 5355 any log
...
1030 comment Deny VLAN 2021 outgoing response to incoming mDNS query UDP/5353 to multicast 224.0.0.251
1030 deny udp 224.0.0.251 eq 5353 any log
...
[*] Source is a multicast IP Address
The way I look at both the above ACEs is (take my assumptions like ones of as an uneducated guest): the router (VLAN SVI) will deny outgoing (as seen as incoming from the VLAN perspective) responses by those two multicast IP addresses (224.0.0.252 and 224.0.0.251) to requests coming from "any source" and destined to, respectively, UDP/5355 and UDP/5353 (note about "any source": to be honest, I imagine that here the "any source" means "coming from externals IP hitting the VLAN SVI = the router" because the switched traffic originating from within that very VLAN, as far as I know, should never hit the router for any destination which stay within that very same VLAN).
Could it make sense?
Original Message:
Sent: Dec 08, 2025 11:35 AM
From: HornAlum
Subject: AOS-CX ACL Broadcast & Multicast threats mitigations
Your 2nd and 4th ACL lines don't make sense to me. But neither does the original article. multicast should not be able to be the source address. AFAIK, it's always a unicast device that targets a multicast address as the destination. IGMP prunes the rest, if you're choosing to use it.
I have nearly 25k devices on my college campus, and every end user port has these two ACL lines, just like the source article
20 deny any 0.0.0.0/0.0.0.0 224.0.0.251
21 deny any 0.0.0.0/0.0.0.0 224.0.0.252
I could have probably made that easier and written it like the articcle, where it's "deny any any", but i was converting my ACL's from the Aruba-OS to Aruba-CX and this is how it came out. Don't fix what ain't broke. There's all sorts of crazy devices on campus, but this works and really tuned down the mDNS traffic
Original Message:
Sent: Nov 26, 2025 11:31 AM
From: parnassus
Subject: AOS-CX ACL Broadcast & Multicast threats mitigations
Hi all!
I'm trying to adapt the suggestions described into the "Ghost in the Network: The Persistent Threat of Multicast Name Resolution" article (Threat Labs section), especially the "Stopping it at the source" part where required ACEs are suggested (I report the IPv6 but I'm not going to implement that part on a IPv4 ACL):
IPv4 ACL:
access-list ip disable-multicast-namev4
10 deny any any 224.0.0.252
15 deny any 224.0.0.252 any
20 deny any any 224.0.0.251
25 deny any 224.0.0.251 any
30 deny tcp any eq 137 any
40 deny udp any eq 137 any
50 permit any any any
IPv6 ACL:
access-list ipv6 disable-multicast-namev6
10 deny any any ff02::1:3
15 deny any ff02::1:3 any
20 deny any any ff02::fb
25 deny any ff02::fb any
30 permit any any any
to fit into a draft ACL I'm writing for an AOS-CX Switch.
Below the outcome of my raw attempt (my VLAN id is 2021 and the network segment is 10.255.21.0 /24, this is just an example) to summarize the two sets above in just one set of ACEs for an ACL (to be applied on a VLAN in its incoming direction):
IPv4 mDNS + LLMNR (query and response):
1000 comment Deny VLAN 2021 outgoing LLMNR MLD query UDP/5355 to multicast 224.0.0.252
1000 deny udp 10.255.21.0/24 224.0.0.252 eq 5355 log
1010 comment Deny VLAN 2021 outgoing response to incoming LLMNR MLD query UDP/5355 to multicast 224.0.0.252
1010 deny udp 224.0.0.252 eq 5355 any log
1020 comment Deny VLAN 2021 outgoing mDNS query UDP/5353 to multicast 224.0.0.251
1020 deny udp 10.255.21.0/24 224.0.0.251 eq 5353 log
1030 comment Deny VLAN 2021 outgoing response to incoming mDNS query UDP/5353 to multicast 224.0.0.251
1030 deny udp 224.0.0.251 eq 5353 any log
IPv4 NetBIOS-NS (response):
1040 comment Deny VLAN 2021 outgoing response to incoming NetBIOS Name Service query TCP/137
1040 deny tcp 10.255.21.0/24 eq 137 any log
1050 comment Deny VLAN 2021 outgoing response to incoming NetBIOS Name Service query UDP/137
1050 deny udp 10.255.21.0/24 eq 137 any log
IPv6 mDNS + LLMNR (query and response):
comment Deny VLAN 2021 outgoing LLMNR MLD query UDP/5355 to multicast ff02::1:3
deny udp 10.255.21.0/24 ff02::1:3 eq 5355 log
comment Deny VLAN 2021 outgoing response to incoming LLMNR MLD query UDP/5355 to multicast ff02::1:3
deny udp ff02::1:3 eq 5355 any log
comment Deny VLAN 2021 outgoing mDNS query UDP/5353 to multicast ff02::fb
deny udp 10.255.21.0/24 ff02::fb eq 5353 log
comment Deny VLAN 2021 outgoing response to incoming mDNS query UDP/5353 to multicast ff02::fb
deny udp ff02::fb eq 5353 any log
and it would be nice if someone could chime in to say if the above make sense or not.
I admit just barely retyped what was suggested (hope to have not written wrong things about ports and protocols).
It would be interesting to understand if comments are correct (I know that writing that VLAN 2021 denies something when, de facto, the ACE refers to a multicast IP address...doesn't make sense but it was for keeping comments "aligned"...you know).
It's clear that I also dislike the usage of "any" (if I can avoid it) and I prefer to name a network segment explicitly instead (especially if this happens without invalidating the ACE's purpose).
Thank you for any suggestion!
-------------------------------------------