Wireless Access

last person joined: yesterday 

Access network design for branch, remote, outdoor, and campus locations with HPE Aruba Networking access points and mobility controllers.
Back to discussions
Expand all | Collapse all

Enabled BC/MC vs denying same traffic via ACLs - Functionaly equivalent?

This thread has been viewed 6 times

  • 1.  Enabled BC/MC vs denying same traffic via ACLs - Functionaly equivalent?

    Posted Jan 16, 2013 10:11 AM

    Hi all,

     

    We have been dropping BC/MC (broadcast-filter all), along with enabling 'broadcast-filter arp', in the VAP to preserve network performance and as far as I know have had no complaints. I now have a manager request to allow a very small subset of devices to do L2 discovery within the same SSID.These devices are Android, Windows and Apple.

     

    Assuming I can identify all of the BC/MC traffic, can I go ahead and enable BC/MC in the VAP (no broadcast-filter all) and then essentially deny that same broadcast and multicast traffic with a series of policies (ACLs) instead? Is this "the same"?

    I plan to to nudge the targeted devices into a new role/vlan using RADIUS VSA. This role would not have the L2 ACLs. All other users on this SSID will get the default auth role which has the L2 ACLs in place. Would doing this be functionally equivalent - aside from the broadcast traffic between the devices in the "allow L2" role, or would doing this pollute the air more? Is this a good way to isolate broadcast multicast traffic to only this subset of devices or will it cause a BC/MC traffic to leak out for all?

     

    We have about 20k users connected during peak times on a school day. School reconvenes next week. I know that enabling BC/MC globally  is generally not a good idea with so many clients hunting for L2 peers..

    Below is an example of the ACLs I would put in place to "hopefully" "re-block" L2 protocols after enabling BC/MC in the VAP.

    ip access-list session deny_SSDP_and_UPnP_acl
     any host 239.255.255.250 any  deny
     any host 239.255.255.253 any  deny
    !
    ip access-list session deny_mDNS_acl_alt
     any host 224.0.0.251 udp 5353  deny log
    !
    ip access-list session deny_netbios_acl
     any any udp 137  deny
     any any udp 138  deny
    !

    We're running 6.1.3.2. As an aside, we just bought ClearPass and are exploring AirGroup but this is something folks want to do ASAP.

     

    Any advice would be appreciated.

    Thanks in advance,
    Mike



  • 2.  RE: Enabled BC/MC vs denying same traffic via ACLs - Functionaly equivalent?

    EMPLOYEE
    Posted Jan 29, 2013 07:31 PM

    BCMC Optimization  enabled on the SSID and its job is to send multicast and broadcasts at the highest rates possible.  It does not limit or drop broadcasts.

    BCMC Optimization enabled on a VLAN will drop broadcast and multicast traffic on that VLAN and will supersede dropping broadcasts and multicasts on a VAP.

    Drop Broadcast/Multicast on a VAP will drop all downstream multicasts broadcasts on a VAP.

     

    Once you are dropping broadcasts or multicasts on a VAP or VLAN, you cannot then enable it for a subset of users via an ACL.  You might have to run a version of Airgroup and use an ACL to remove visibility in any role for a user that you don't want to see bonjour traffic.  You can also do that via Airgroup's configuration.