Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

Does using Multicast Mode reduce network overhead of link-local multicast (e.g., mDNS/mDNS-SD or v6 ND)?


---------------------------------------------------------------------------------------------------------------------
Part I:  In theory, under the following conditions, one doesn't need to enable Multicast or mDNS features in the WLC:
---------------------------------------------------------------------------------------------------------------------

+ Single 2504 WLC
+ v7.4 code
+ Single client WLAN mapped to a single client VLAN (Trunked on LACP/LAG PortChannel, but untagged/VLAN1, routed), say, a /23 or /22 (or /64 v6) of Apple users.  Enough mDNS multicast traffic to choke a dozen donkeys.
+ WPA2-PSK Authentication
+ Single L2 (or L3 in L2 mode) POE switch (2950,2960,3750,3750E,3560E,3650-X)
+ Single L3 gateway (800,1800,1900,2800,2900 ISR Gateway) - No PIM or IGMP Support enabled/or any L3 MCast participation
+ Single AP CAPWAP VLAN (Trunked on LACP Port Channel, tagged) -- which is unrouted, directly connected to WLC
+ Single Management VLAN (Trunked on LACP Port Channel, tagged) -- Which is routed
+ Single AP group associated with a single WLAN

In theory, neither Multicast or mDNS features on WLC are needed in this scenario?

*) mDNS/mDNS-SD from LAN clients will, by default, be flooded on all wired VLAN Access ports and trunks; WLC will convert LAN->WLAN to a unicast CAPWAP packet toward each AP
*) mDNS/mDNS-SD from WLAN clients be recieved as a unicast CAPWAP packet from the AP the client is associated with, and flooded as unicast CAPWAP to all APs (including back to the original source AP), as well as the LACP/LAG trunk on the interface/VLAN associated with the WLAN

=================
Question:
=================

Am I correct in asserting that Multicast and mDNS snooping SHOULD NOT BE required in the attached/descriped topology (If I'm willing to live with the multicat->unicast CAPWAP overhead)
   -- I ask this because I recently had a client situation where AppleTV Bonjour/mDNS was not propagating without mDNS Snooping
      ( I didn't have a chance to debug this while on site )

---------------------------------------------------------------------------------------------------------------------
Part II:  Regarding CAPWAP bandwidth and WLC CPU overhead from duplicating CAPWAP unicast traffic for link-local Multicast
---------------------------------------------------------------------------------------------------------------------

If $N = (Access Point Count)

Then, to reduce the CPU overhead and CAPWAP switching bandwidth of impacts of the WLC needing to duplicate:
 
  1) [LAN multicast] -> [CAPWAP * $N]

    ... and ...

  2) [WLAN CAPWAP Unicast] -> [CAPWAP * ($N + 1)]
 
     ...packets ( for each mDNS/mDNS-SD packet recieved ):

    Wouldn't it be prudent for the WLC utilize the multicast groups when transmitting encapsulated link-local multicast (E.G .such as mDNS, IPv6 ND at reserved 224.0.0.0/24, ff02::/7, etc.) as CAPWAP?  

    E.g., to de-duplicate traffic on the switch backplane?

   On larger subnets (/22,/21), where end user workstations mixed Wired and Wireless, mDNS/mDND-SD volume can rise.

   (Maybe I'm over-thinking this on a L2/L3 switching platform rated 60gbps backplane bandwidth and 2GBps LAG ports with mDNS packets which are less than ~ 1KB)

--------
Questions:
--------


*) Will the WLC even consider converting link-local multicast into AP Multicast Group CAPWAP packets (as it would a non-link-local PIM/IGMP stream)?

*) It seems like any IGMP / PIM-learned Multicast traffic (encapsulated in CAPWAP to MGID destination) would be forced to be sourced/transmitted from the management interface (Quoting the Guide):

 'When the controller receives a multicast packet from any of the client VLANs on the first hop router, it transmits the packet to the LWAPP multicast group via the management interface at the lowest QoS level.'

  ...if I understand this correctly, this limitation/requirement defeats the purpose of having a directly-connected VLAN for AP Boot/CAPWAP connectivity; as that subnet will always be known to the WLC routing table as directly/connected and would be unreachable from the Management vLAN -- at least until a change was made to the attached topology.

 

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

wlc 2500 supports only ap

wlc 2500 supports only ap mode multicast. use flexconnect, if required.

from 7.5 code, WLC treats bonjour L2 multicast traffic as L2, on 7.4 and prior codes it was handled as L3 and would generate mgids.

for link local mcast traffic with ap mcast mode mcast, if wlc and ap on same vlan then pim not required on wired side, irrespective of client vlan. for non link local, pim needs to be enabled on wired network.

with mDNS snooping enabled, can't see bonjour response from wlc over the air due to snooping, only unicast tcp response seen based on the service.

if ap mode multicast configured, local mode AP would join the mcast group configured on wlc. all mcast received from wired/w.less will be forwarded by wlc to ap using the mcast group address configured on wlc.

6 REPLIES
Cisco Employee

wlc 2500 supports only ap

wlc 2500 supports only ap mode multicast. use flexconnect, if required.

from 7.5 code, WLC treats bonjour L2 multicast traffic as L2, on 7.4 and prior codes it was handled as L3 and would generate mgids.

for link local mcast traffic with ap mcast mode mcast, if wlc and ap on same vlan then pim not required on wired side, irrespective of client vlan. for non link local, pim needs to be enabled on wired network.

with mDNS snooping enabled, can't see bonjour response from wlc over the air due to snooping, only unicast tcp response seen based on the service.

if ap mode multicast configured, local mode AP would join the mcast group configured on wlc. all mcast received from wired/w.less will be forwarded by wlc to ap using the mcast group address configured on wlc.

VIP Purple

This is very useful

This is very useful information Saravanan..

Rasika

Cisco Employee

Thanks!!! Rasika

Thanks!!! Rasika

New Member

Re "if ap mode multicast

Re "if ap mode multicast configured, local mode AP would join the mcast group configured on wlc. all mcast received from wired/w.less will be forwarded by wlc to ap using the mcast group address configured on wlc."

 

- This feature refers to "local AP mode w/ 'AP Mode Multicast' enabled, and only in the v7.4, v7.6 code correct?

Cisco Employee

#1 Yes. on capwap, WLC's mgmt

#1 Yes. on capwap, WLC's mgmt as source and destination be the group address.

*that's why when the AP is on L3 vlan require Multicast routing on the wired side for the downlink path.

*The actual Multicast traffic that could be L2/L3 multicast application is encapsulated inside the capwap with respective source and application used Multicast address.

#2 Guess AP Multicast mode Multicast feature is supported from 4.2 or so, it should be like this starting that code.

*************

An Local and Flexconnect mode AP joined to the WLC.

On WLC, AP Multicast mode set to Multicast with address 239.1.1.20

 

How to verify the Local mode AP joined to the Multicast or not?

 

Local-2602i#show capwap mcast
CAPWAP MULTICAST
Multicast Group: 239.1.1.20, Source: 10.201.236.197
V1 Rpt Sent: 0; V2 Rpt Sent: 106
V3 Rpt Sent: 0; Leave Sent: 1
V1 Query Rcvd: 0; V2 Query Rcvd: 105
V3 Query Rcvd: 0; V1 Rpt Rcvd: 0
V2 Rpt Rcvd: 104; V3 Rpt Rcvd: 0

 

How to verify the Flexconnect mode AP did not join the Multicast group?

 

Flexconnect-1142#show capwap mcast
CAPWAP MULTICAST
No Multicast Group Configured

 

refer to these links and see it tries to help any.

https://supportforums.cisco.com/document/12050896/multicast-support-different-wlc-platform-when-using-local-and-flexconnect-ap-mode

https://supportforums.cisco.com/document/137196/rules-limitations-and-guidelines-when-using-multicasting-wireless-controller

https://supportforums.cisco.com/document/135546/legacy-bonjour-or-mdns-disabled-configuration-guidelines-all-possible-scenarios

New Member

Hi Saravanan,

Hi Saravanan,

thanks for the gret info. I would have a question regarding the overhead on the controller processor when using unicast mode.

When would be actually optimal to switch to multicast mode? How many APs would be needed to reach that overhead? How many clients? Any raw guidelines?

Thanks.

701
Views
10
Helpful
6
Replies