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


Annual Conference
September 29–October 2
View Proceedings

Events for all Levels and Interests

Whether you're looking for a conference to attend face-to-face to connect with peers, or for an online event for team professional development, see what's upcoming.

Close

Digital Badges
Member recognition effort
Earn yours >

Career Center


Leadership and Management Programs

EDUCAUSE Institute
Project Management

 

 

Jump Start Your Career Growth

Explore EDUCAUSE professional development opportunities that match your career aspirations and desired level of time investment through our interactive online guide.

 

Close
EDUCAUSE organizes its efforts around three IT Focus Areas

 

 

Join These Programs If Your Focus Is

Close

Get on the Higher Ed IT Map

Employees of EDUCAUSE member institutions and organizations are invited to create individual profiles.
 

 

Close

2014 Strategic Priorities

  • Building the Profession
  • IT as a Game Changer
  • Foundations


Learn More >

Uncommon Thinking for the Common Good™

EDUCAUSE is the foremost community of higher education IT leaders and professionals.