Main Nav

Message from curtis.k.larsen@utah.edu

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/.

Comments

Message from curtis.k.larsen@utah.edu

Nevermind. I think I just figured out my own problem. WLC2 *did* have the same client vlan added to the port-channel. It just didn't have the vlan interface on the controller. I think that was my problem. Thanks, Curtis On 10/26/2012 05:16 PM, Curtis K. Larsen wrote: > 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/.