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: [email protected]
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/.
