Stan did a great job of explaining how it works with Aruba, and Cisco (Airespace line) and Trapeze work very similarly.
At first glance it might seem that with enough roaming events that tunnel establishment and maintenance might create a resource issue for the controller, but I haven't heard any complaints from customers or jabs from competing vendors about that, yet. It's my understanding that some of the vendors only create one tunnel between controllers, so that if 5 clients on controller A roam to APs on controller B, that there is only one tunnel, not five. It would be an interesting thing to test for. My assumption is that most locations don't install a wireless controller per wiring closet, but try to aggregate them per campus or building. If you have a few controllers in the campus data center then APs are likely to be allocated between them on some logical geographic mapping. If there is a controller per building, it's pretty clear that roaming events are a lot less likely to occur between buildings. Frank -----Original Message----- From: Stan Brooks [mailto:[EMAIL PROTECTED] Sent: Monday, September 11, 2006 11:51 AM To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU Subject: Re: [WIRELESS-LAN] Linksys APs as enterprise solution Ethan, I can't speak to how Meru handles L3 roaming, but I can tell you that Aruba's L3 roaming method works quite well, and without any software installed on the client. Aruba handles the L3 roaming internally using a technique similar (identical?) to Mobile IP - but with the "client" functionality handled on the central controller(s). That is, clients retain the IP address they were assigned (usually from a DHCP server) when they roam AP to AP. There are two basic scenarios - the first is roaming from AP to AP on the same controller. This is easy as the controller puts the client in the same VLAN they originated in, preserving their IP address and connectivity, as they roam AP to AP. The second scenario is a bit more difficult: when a client roams from an AP on one controller to another AP on a second controller. When the client roams, the second controller will tunnel the traffic back to the first controller. The client effectively remains in the same VLAN and has the same IP address as when it first connected to the wireless network. Emerson Parker, who lurks on the list, can probably give you a better and more technical explanation than I've done here. It works flawlessly; I can roam all over campus without losing or changing my IP address. Seamless roaming ROCKS! >>-> Stan Brooks - CWNA/CWSP Emory University Network Communications Division 404.727.0226 [EMAIL PROTECTED] AIM: WLANstan Yahoo!: WLANstan MSN: [EMAIL PROTECTED] -------- Original Message -------- From: Ethan Sommer Date: 9/10/2006 10:08 AM > Frank Bulk wrote: >> Ethan: >> >> Thanks for addressing my points so precisely and honestly. >> >> One of the things I forgot to mention on the list of shortcomings for >> consumer APs in enterprise settings was multi-BSSID and/or multi-SSID >> support. >> > The Linksys hardware is capable of doing multi-SSID but no multi-BSSID, > which apparently works OK if you only have one SSID advertised, as long > as the clients don't have certain (common) wireless cards which have > buggy drivers. (I believe the windows centrino drivers have this problem.) > > So at least at this point, I agree, that's a big downside. > >> Define flaky? Same as you, I meant the AP's software code. Perhaps the >> custom code you use doesn't make this an issue, but one only needs to >> peruse >> the linksysinfo forums to know that there are lots of issues with SOHO >> routers, and Linksys is not a vendor you can call and actually receive >> plausible enterprise support. >> > Yes, the custom firmware I'm running (dd-wrt) is significantly more > stable than the stock Linksys firmware. > > It is certainly true that I couldn't call Linksys up for help. And to be > honest, I've found only so-so knowledge on the forums when I've asked > anything. > > >> Putting all the APs in the same L2 domain has been done before, and I >> would >> only recommend it for the smallest deployments. Broadcast traffic, on >> the >> wireless and the wireline side, will absolutely ruin performance, as you >> pointed out, can cause AP issues. As you pointed out, the L3 roaming >> concern prevents you from segmenting the APs as you wish. >> >> > I know that Cisco has a L3 roaming solution which requires a client on > the client machine. How do Aruba and Meru, etc address this? Is there > anyway to do L3 roaming without the client having to install software? > >> If you put together a presentation in electronic form I'm sure we'd >> all love >> to see a link to it when you're done, perhaps after you've presented the >> material and had a chance to incorporate the response into the document. >> >> > I will post any presentation documents to the list when they exist. > > > Ethan > >> Kind regards, >> >> Frank >> >> -----Original Message----- >> From: Ethan Sommer [mailto:[EMAIL PROTECTED] Sent: Wednesday, September >> 06, 2006 2:08 PM >> To: WIRELESS-LAN@LISTSERV.EDUCAUSE.EDU >> Subject: Re: [WIRELESS-LAN] Linksys APs as enterprise solution >> >> We have just deployed over 120 Linksys WRT54GLs in our dorms. So far, >> everything has been working well. >> >> We used dd-wrt modified slightly (so that it acts as an AP and gets a >> dhcp address) and have each access point check in with a server every >> 2 minutes to report that they are up and who is connected to them. >> Where possible we are using PoE with linksys PoE adapters fed by a web >> enabled power switch (http://www.webpowerswitch.com/) which we can >> control using a perl script. (We can't do it in a few dorms which have >> "split jacks" running two jacks over one cat5 cable.) >> >> I believe we have addressed all of the conserns below, but we're very >> early in the project so time will tell. I'll detail how we have dealt >> with them below: >> >> Frank Bulk wrote: >> >>> I think this has been thrown out on the listserv before. The major >>> objections tend to be: >>> a) lack of external antenna connectors >>> >> Linksys WRT54G(L/S) have RP-TNC connectors. The other AP I'd consider >> is BuffaloTech's broadcom based APs which have SMA connectors. >> >> >>> b) lack of adjustable output power on some units (this may not apply to >>> >> the >> >>> Linksys in question) >>> >> The APs can be adjusted from something less than 28mw to 250mw. Some >> people on wrt related forums have expressed concerns about overheating >> and stability at higher than about 70mw, but we've been running over >> one hundred of them at 200mw all summer (many without AC) without any >> problem so I suspect that that's simply not a problem or that >> manufacturing has gotten better. >> >> >>> c) lack of management system for these APs, especially in regards to RF >>> planning and control >>> >> We have written our own management system. So far it monitors uptime, >> reboots APs if they are down or on demand, and monitors usage >> (including pretty graphs) of each ap, the system as a whole, or a >> subset of the aps. The ap reports what channel it is on, but doesn't >> have any smarts to suggest a better channel yet. >> >> We also use the APs to detect rogue aps. (we do a site survey every >> night and we get a nightly report by e-mail) >> >>> d) generally a more flaky radio in comparison to enterprise gear, but >>> this >>> is hard to quantify and I'm sure some objections would be raised. >>> >> Define flaky... What we have noticed to be flaky is the network stack >> of the OS. If there is a broadcast storm on the network several APs >> will stop checking in and need to be rebooted. I believe they are >> still "functioning" though. Right now we have three or four APs with >> 15-20 clients associated to them, and we aren't getting complains >> about it. We haven't had time to go see how well they are working >> since the students moved in though. >> >> >>> e) poor roaming experience: there's no pre-auth key caching as in >>> WPA2, so >>> every roam would require the full 8-way handshake. >>> >> We aren't using WPA2 so I can't speak there. I can say that we have >> been experimenting with wireless voip phones (specifically the linksys >> WIP300 and UTStarcom F3000) and we can walk around large buildings >> without audibly noticeable roaming drops. >> >>> f) all roaming would be L3 roaming: because each AP NATs the clients >>> (this >>> might be different in the OPENWRT build), every roam would likely >>> require >>> >> a >> >>> full DHCP cycle on the client, breaking any applications that require >>> session persistence. >>> >>> >> We set up the routers as APs, and all our wireless is on the same L2 >> broadcast domain, so that's not the case. We'd love to be able to >> subnet the wireless into more vlans but are afraid of the L3 roaming. >> As it is, we (3 days after upperclassmen could move in) are seeing >> about simultaneous 800 users at peek times, which is quite a bit of >> broadcast traffic. However, the APs seem to be handling it quite well. >> >> >> So, I'm not sure if I'd recommend it yet. I plan on preparing a talk >> for a local conference in January on the TCO of the system, so I'll be >> attempting to keep track of how much time it takes to maintain it. So >> far it seems relatively trouble free other than unrelated problems >> like students unplugging the routers (we put APs in RA's rooms in a >> few dorms which we couldn't install ethernet in public spaces this >> summer.) >> >> > > ********** > 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/.
