Other vendors are doing this too. I know from a recent presentation at Atmosphere 2015 that Aruba performs the RA Multicast to Unicast conversion. It's a known limitation in terms of how the 802.11 protocol works. Different vendors are implementing different features to overcome it, but it's an expected thing.
There is currently not support for Multicast to Unicast conversion for Flexconnect, they simply bridge broadcast/multicast traffic. On Wed, Mar 18, 2015 at 1:36 PM, Frans Panken <frans.pan...@surfnet.nl> wrote: > Breaking IPv6 is indeed undesirable ;-) Fortunately, other vendors do not > share your opinion. > Good news for the majority on this list: the bug is limited to Cisco's > FlexConnect. > -Frans > > > > Jake Snyder schreef op 18/03/15 om 20:19: > > It is expected from an 802.11 perspective. May not be desirable, but that > is how the wireless standard works. Unicasting RAs over the air fixes this. > > Sent from my iPhone > > On Mar 18, 2015, at 12:42 PM, Frans Panken <frans.pan...@surfnet.nl> > wrote: > > No, it is not. The result is that it breaks IPv6 on local VLANs: > clients receive multiple prefixes on local VLANs. > > Jake Snyder schreef op 18/03/15 om 17:51: > > Leaking of RAs between VLANS is expected behavior as RA are multicast. > Because the 802.11 protocol sends multicast traffic as broadcast over the > air and every device on a BSSID shares the same group key for encryption, > any client can decode any multicast packet, including RAs not on the same > VLAN. Again, this is expected behavior. The solution to this is to use > multicast to unicast conversion for the RA, however i've never done this in > a flexconnect deployment. > > This is also important in IPv4 deployments where you need to secure who > can gain access to a multicast stream. > > On Wed, Mar 18, 2015 at 10:32 AM, Frans Panken <frans.pan...@surfnet.nl> > wrote: > >> We use FlexConnect in both central and local switched mode (v 8.110.6). >> We use a single SSID and distinguish various user groups, differentiated >> by Radius and mapped on different VLANs. >> We observe that VLANs leak traffic to other VLANs. This is in particular >> very undesired with IPv6, where router adverstisements from one VLAN is >> broadcast to other VLANs (this also happens on IPv4, e.g., with ARP and >> other broadcast traffic). Even VLANs that are only centrally accessible >> leak traffic to local VLANs. >> >> This is a security issue that in my oppinion does not receive the >> desired attention. >> >> Frans >> >> >> >> Watters, John schreef op 18/03/15 om 07:29: >> > Please post any results you have if/when try expand FlexConnect to your >> entire campus. It looks like you are close to our size (we now have about >> 125 buildings & about 38K students plus about 4K faculty/staff). >> > >> > Thanks. >> > >> > Sent from my iPhone >> > >> >> On Mar 17, 2015, at 4:12 PM, Hector J Rios <hr...@lsu.edu> wrote: >> >> >> >> I've not performed tests to that scale yet. Plus we are only >> considering this for our ResHalls, of which we have 21 buildings only. >> >> >> >> -Hector >> >> >> >> >> >> -----Original Message----- >> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: >> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Watters, John >> >> Sent: Tuesday, March 17, 2015 11:55 AM >> >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >> >> Subject: Re: [WIRELESS-LAN] ResHall Wireless - FlexConnect >> >> >> >> We played with FlexConnect for a number of months but still could not >> get what we needed it to do on a consistent basis. Essentially we wanted >> FlexConnect to drop users into their building VLAN so they would be able to >> easily interact with the same devices that the wired connections in the >> buildings could see. As I'm sure you know, this also resolves many of the >> Apple, Chromecast, etc., problems. >> >> >> >> We did have one caveat though that we just couldn't get past -- we >> wanted to drop faculty/staff into one VLAN and students into another (we >> can easily return the proper VLAN for a particular client in a particular >> building from Radius server - FreeRadius with a call to our LDAP server for >> info) but we also need to send everything else back to the controller for >> central switching (e.g., police connections, special bar-code scanners that >> roam and serve to identify a user, but not being used for client traffic, >> for example, to give out free flu shots to eligible folks or let folks into >> a sporting event). We just couldn't get past having 95+% locally switched >> and the remainder centrally switched for over 200 buildings many with now >> over 100 APs each without using FlecConnect groups which are limited to >> numbers way too small for our campus. >> >> >> >> We can even live comfortably without roaming between buildings. MOst >> folks are not used to being able to roam between buildings downtown or many >> cannot roam between apartments off campus. >> >> >> >> How did you get around the FlexConnect group problem? >> >> >> >> >> >> >> >> >> >> ========================== >> >> -jcw >> >> ________________________________ >> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [ >> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] on behalf of Hector J Rios [ >> hr...@lsu.edu] >> >> Sent: Tuesday, March 17, 2015 9:27 AM >> >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >> >> Subject: Re: [WIRELESS-LAN] ResHall Wireless >> >> >> >> I tested FlexConnect on 8.0.110.0. Here are my observations: >> >> >> >> *Great alternative to switch data locally (obviously) *No AVC Support >> *When controller is down, AP goes into standalone more. Must make sure that >> AP is not able to reach any other controller you don't want. This was fixed >> with an ACL. >> >> *Client details page does not show client IPv6 address. Client still >> gets IPv6 address. (PRIME does show it if you run a report). >> >> *Client details page does not show VLAN ID. >> >> *Putting AP in FlexConnect mode does not require reboot (Cool!) *No >> IPv6 ACL support >> >> >> >> More testing to do, but so far so good. >> >> >> >> -Hector >> >> >> >> >> >> >> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: >> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Hector J Rios >> >> Sent: Thursday, March 12, 2015 11:13 PM >> >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >> >> Subject: Re: [WIRELESS-LAN] ResHall Wireless >> >> >> >> We use Cisco's wireless solution with WiSM2s and a variety of WAPs. We >> actually implemented the guest anchor controller solution last year with >> dual controllers (WLC2504) and we've been happy. >> >> >> >> I like Britton's idea of using FlexConnect at the dorms to switch the >> student data locally. However, I believe there are some limitations that >> would keep us from using it such as no support for AVC, and some >> limitations on IPv6. >> >> >> >> -Hector >> >> >> >> From: The EDUCAUSE Wireless Issues Constituent Group Listserv [mailto: >> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU] On Behalf Of Osborne, Bruce W >> (Network Services) >> >> Sent: Thursday, March 12, 2015 7:42 AM >> >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU<mailto: >> WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU> >> >> Subject: Re: [WIRELESS-LAN] ResHall Wireless >> >> >> >> Hector, >> >> >> >> You do not say what wireless solution you are using. Let me assume a >> Cisco or Aruba controller based solution. You can have vlans from your >> controller tunnel to an anchor controller in a DMZ. Use 802.1X >> authentication based on AD groups. >> >> >> >> This solution permits controlled internal access and, if you desire, >> unfiltered Internet access. Until recently, we did something similar with >> our open Guest wireless network on our Aruba system. We now use a different >> solution for this. >> >> >> >> The anchor controller idea was based on Cisco wireless training >> several years ago. At that time, it was their recommended guest solution. >> >> >> >> Bruce Osborne >> >> Wireless Engineer >> >> IT Infrastructure & Media Solutions >> >> >> >> (434) 592-4229 >> >> >> >> LIBERTY UNIVERSITY >> >> Training Champions for Christ since 1971 >> >> >> >> From: Hector J Rios [mailto:hr...@lsu.edu] >> >> Sent: Wednesday, March 11, 2015 9:48 AM >> >> Subject: ResHall Wireless >> >> >> >> I'm wondering how many of you treat the wireless in the ResHalls >> differently from the wireless on the rest of your campus. In terms of >> geography, we have 21 ResHalls that are in the perimeter of our campus. >> Some of these buildings are next to academic or administrative buildings. >> Eduroam is our main SSID. So, for the longest time it has only made sense >> to broadcast eduroam everywhere. Now, on the wired side of the house, our >> ResHalls have a dedicated connection that gives them direct, non-firewall >> access to the internet (for access to campus resources, a student must >> VPN). This came about as a request from the students to have more freedom >> in their residence. Makes sense. But wireless is different as it goes >> through our campus core, traverses our perimeter firewall, and goes out our >> main internet connection. >> >> >> >> I've struggled to find an alternative solution to this. We recognize >> that students in ResHalls are different in the sense that they pay for a >> place to live and should get an internet service that is similar to their >> home service. However, any alternatives that we have considered (separate >> SSID, dynamic VLAN assignment, user groups) just seem to complicate the >> setup. >> >> >> >> Any good ideas out there or creative ways in which you have tackled >> this challenge? >> >> >> >> Thanks, >> >> >> >> Hector Rios, CCNP, CCA >> >> Assistant Director, Network Engineering >> >> Dept. of Networking and Infrastructure >> >> Information Technology Services >> >> Louisiana State University >> >> >> >> ********** Participation and subscription information for this >> EDUCAUSE Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> >> ********** Participation and subscription information for this >> EDUCAUSE Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> >> ********** Participation and subscription information for this >> EDUCAUSE Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> >> ********** Participation and subscription information for this >> EDUCAUSE Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> >> >> >> ********** >> >> Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> >> >> >> ********** >> >> Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> > ********** >> > Participation and subscription information for this EDUCAUSE >> Constituent Group discussion list can be found at >> http://www.educause.edu/groups/. >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can be found at http://www.educause.edu/groups/. >> > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > > ********** Participation and subscription information for this EDUCAUSE > Constituent Group discussion list can be found at > http://www.educause.edu/groups/. > > ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/groups/.
