We have Cisco WiSM1's and WiSM2's deployed in a very centralized manner.
While they are in physically separate datacenters, they connect to a
single distribution block. All WLC Mgmt interfaces are in the same
VLAN. Years ago, when we first turned up the multicast on wireless
(mainly to support Vocera Push-to-talk) we chose to use unique multicast
group addresses for each controller - thinking this would reduce the
amount of total mcast going to each AP. We are in multicast-multicast
mode, and use pim-sparse.
Over time, as I am sure many of you have seen - the multicast just keeps
growing. I have since discovered the ability to apply multicast ACL's
to controller interfaces, and WLAN's so that I can keep clients from
joining unnecessary multicast group addresses, and still allow Vocera's
group address or Airplay to our Apple-TV on our specific AAA override
subnet.
Unfortunately, there is still some multicast that I can't explain, and
hence don't know how to craft an ACL to stop it.
Example:
I use Airplay to mirror my screen to an Apple-TV. The laptop, and
Apple-TV are connected to AP's on WLC1 and point to VLAN 100. AP's from
WLC1 show they are joined only to WLC1's unique multicast group address
when I do a "sh ip mroute". WLC2 has it's own unique multicast group
address, it's own unique AP's, and *does not* have an interface for VLAN
100. Here is where it gets merky for me ...I do a packet capture on the
port-channel from WLC2 and I see MDNS traffic with my laptop and/or the
Apple-TV as Source and 224.0.0.251 as destination.
Three questions:
1) Why does WLC2 see this MDNS traffic at all?
2) Where would one place an ACL to keep WLC2 from seeing this traffic?
3) Is there some other way to solve the problem?
Any help is greatly appreciated.
Thanks,
Curtis
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
