05-07-2023 06:14 AM
Hello colleagues! After googling about 30 min, I didn't find the answer, so I hope for your help. The simple question: there are 2 routers , let it be c8300 sd-wan as a VRRP pair , there is a WLC c9800-L and several APs 9100 connected to C9300 switches. Question is: why wireless clients can hear the VRRP mcast hello messages on the 224.0.0.18 group? Technically I understand why, but shouldn't it be blocked by default? It doesn't make a sense to sent this mcast messages over the air, it will utilize the airtime. Is there an elegant solution how to prevent it? Except the any kind of ACLs on switches ? Even more on another wifi vendor I can't see these messages.
If there is a topic about this problem, please point out by finger.
Thanks!
05-07-2023 06:55 AM
Hello,
The explanation could be this:
"When the multicast mode is enabled and the controller receives a multicast packet from the wired LAN, the controller encapsulates the packet using CAPWAP and forwards the packet to the CAPWAP multicast group address. The controller always uses the management VLAN for sending multicast packets. Access points in the multicast group receive the packet and forward it to all the BSSIDs mapped to the VLAN on which clients receive multicast traffic. "
This doc can be usefull to undestand the behavior and take action if required.
For example, the WLC have this possiblity:
Device(config)# wireless multicast
You could disable this with "no wireless multicast" but of course, you need to consider the impact first.
05-07-2023 08:08 AM
thanks mate! Yes , I understand how it works in general, but is there any elegant solution for filtering unuseless vrrp messages over the air? Or only ACLs can help ?
05-07-2023 08:36 AM - edited 05-07-2023 08:40 AM
I believe, never had to, you can disable the multcast option on the WLC ,as I said. This way you would change the WLC behavior related to multicast.
Another option could be use the commamd "switchport block multicast' on the switch.
A thirdy option would seggregate the broadcast domain but it may depend on the switch licensing.
ACL may note filter multicast as this traffic is usually sent to the Control plane and not to Data plane.
05-08-2023 06:09 AM
yep, I understand that we can disable multicast completely , but it's not our goal, we need some other groups. It seems like ACL toward the wlc is a possible way, but I am looking for a more clear solution. Do you have a prove that m-cast is in control plane? AFAIK it's simple packets , but with specific dst-IP.
05-08-2023 06:20 AM
Any kind of broadcast as far as I know is usually directed to control plane. But you can test it by adding an ACL on the switch or WLC.
05-08-2023 09:23 AM - edited 05-08-2023 09:23 AM
Multicast handling varies by platform and IOS so like @Flavio Miranda said I think best to just test with ACL on both switch and WLC to see whether either works and then use what's most convenient for you.
I agree that link-local multicast should not be forwarded by the WLC as per https://datatracker.ietf.org/doc/html/rfc5771#section-4
for protocol control traffic that is not forwarded off link.
so might be worth opening a TAC case and getting a bug raised for it.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide