On Fri, Oct 10, 2003 at 12:58:24PM -0700, Jonn Martell wrote:
> Hi Chris,
>
> That's an interesting concept: one of centrally managing a ton of
> different APs, firmware, etc. Gives me a headache just *thinking* about
> it! How many "managed" APs do you now have? How many FTEs do you
> expect to need to manage all these different types of APs?
See, that's the point. We don't manage the APs. We manage the
infrastructure. Once the APs are initially configured, they really don't
need to be touched much. Newer APs may need flash upgrades to fix bugs,
but that usually stabilizes after a while. The more features in the AP,
however, the more that could go wrong and need fixing.
Also, since the departments are buying these things anyway, we let the
departments manage the AP itself. Then we just handle infrastructure.
If the AP is stable and the infrastructure is solid, then the departments
are happy.
The exception is that we did just buy a pile of Cisco APs to put into
wiring closets. We chose the Cisco because of their increased signal
strength--the idea being that we could more easily penetrate the closet
walls. The amount we saved on conduit and installation more than made up
the difference in price.
Still, we won't be using many of the fancy features of the AP. We may
poll them for usage statistics and such, and there is some talk of setting
up a different SSID (with WEP) so that our field techs can be on a
separate vLAN.
> We almost went down that route and peppered the campus with cheap $100
> AP but when we looked at cost of ownership and reliability; it was a
> clear case of "pay now or pay later". And that was using a single
> vendor's cheap AP solution!
I have seen some differences in reliability, but those have to do with
individual brands. It doesn't seem to have anything to do with unit cost.
There was a discussion here on this list recently about Orinoco boxes
frying out, and we saw similar behavior with some of the older Apple APs
(the Orinoco 500 in an Apple case). There was also a magazine article a
couple of months ago about Microsoft using Cisco products, and all of the
problems they had. I think those were older Cisco boxes, though.
Another plus of the cheaper APs is that you're out less if you have to
replace them for other reasons. A lot depends on your deployment, of
course.
I popped the top on a Dell 1184 recently. The Dell costs $72 mail order.
Almost everything is on a single board (the exception being the indicator
lights) so it's well integrated and should be fairly stable hardware-wise.
It also runs Linux and has a built-in four-port etherswitch. I have one
of these units for home use and I plan on testing the heck out of it. I'm
not happy with the user interface and I'm still trying to get the Linux
sources from the vendor. Still, an interesting idea...
I mentioned above that we went with the Cisco's because of their signal
strength and receive sensitivity. They have, basically, better range and
they're also tunable. Those are nice features for the closet deployment.
The way I like to think about it, though, is like comparing a 250 watt
lightbulb against smaller 40 watt bulbs. There are some cases in which I
want to flood an area with light from a single source, and others in which
distributing the glow is nicer. We can fine-tune coverage in a similar
way.
> We now have over 1400 devices on our wireless network and I don't know
> how one would begin to manage these if they weren't nearly identical.
Again, the idea is that I don't want to manage the APs. I want to manage
the infrastructure behind the APs. The less the APs do the less I have to
manage them and the less I have to worry. If I think of the wLAN itself
as hostile territory (and express that to my users) then I have a workable
scenario. There are lots of different workable scenarios out there, this
one just matches my network.
> The way that we dealt with the rogue AP issue was by centrally funding
> the network and deploying very quickly. And we are done! The last
> remaining areas are student residences (wish me luck - I need it! :)
I started wireless planning four years ago or more, but we did not get
funding to push things out from the center. As a result, we have to pull
things in toward the center to make them work. Some colleges and
departments did their own deployments. In other cases, as mentioned,
people just went out and purchased APs on their own. Others asked us to
handle deployment for them.
One thing we have to deal with here is that we can't view "rogue" APs as
rogues unless they are on a centrally managed network. Departments that
run their own networks have to make their own policies and VPs or Profs
might just get to have their own APs. Ah, well...
> We are positioned for today's requirements and can scale up with campus
> wide VLANs with APs that support multiple VLANs/SSIDs. I have a CD from
> Silicon Chalk on my desk for example where the application uses
> broadcast/multicast - that's a perfect application for a special
> "learning" VLAN/SSID (we limit/manage broadcasts/multicast on our large
> campus-wide primary SSID/VLAN).
Broadcast and multicast can put a lot of pressure onto a wLAN, certainly.
We have people who want to use wireless for video applications. Ouch.
We are hoping that we can deploy 802.11a in high-density areas (lecture
halls, auditoria, etc.) to augment the bandwidth available in the 2.4GHz
range. That will offload the 802.11b/g spectrum, provide more channels,
etc. Many of the chipsets that have come out recently seem to be g/a
combos. I'm waiting for the radios to start appearing on campus.
> We just have to convince Cisco that multiple BSSIDs are absolutely
> required to provide true "virtual AP" functionality so we can support
> both a non-802.1x network (protected by wireless gateways and VPNs) and
> an 802.1x protected networks concurrently. Our secondary (802.1x
> protected) SSID/VLAN network can't be advertised which is a real problem
> with Windows. I agree that it's next to impossible to support a "802.1x
> only" network in a campus environment - you *have to* cater to the
> lowest common denominator to be a success.
That's an interesting approach toward moving into 802.1x. The Cisco's and
Symbol's can map different wireless network names to different vLANs,
which makes such an approach possible (assuming, of course, that you can
enable 802.1x on some SSIDs and not others). That might be an interesting
way to test 802.1x. It might also work with our plans to create separate
vLANs for our field techs--if we can find workable 802.1x client software.
Question: with the 802.1x-capable network, what do you use to encrypt the
data? As I understand it, 802.1x is used for access control
only. Am I missing something?
> In the near to long term, the 802.1x SSID/VLAN is absolutely strategic
> for us in providing a safe and scalable wireless network and we will
> push people as soon as it's fully deployable (hint: as soon as we get
> multiple BSSID support to make the 802.1x SSID/VLAN "plug and play" with
> Windows).We are reay to deploy it if our primary network comes under
> attack but with all the WPA and IEEE 802.11i delays, I prefer to wait a
> little bit more.
See, I'm just not convinced that 802.1x is a complete and practical
solution. You're only talking about Windows. I have a lot of other OSes
out there. Honestly, if I were to block a set of OSes from joining my
network, all of the recent attacks would make blocking Windows tempting.
That won't fly, of course, and neither will blocking PalmOS. I have had
people call me with AmigaOS support questions... (The scary thing was
that I was able to answer.)
> On a passing note: those preparing RFPs, please include "APs should have
> multiple BSSID support" Universities need "Virtual AP" capabilities.
>
> It's also hard to imagine operating a large wireless network without
> some level of filtering at the edge. We implemented DHCP anti-spoofing
> filters last year (to prevent all sorts of easy attacks) and quickly
> implemented RPC filters in July after the deadly vulnerability
> announcement. Wireless users, unlike ResNet users, were immune to the
> rash of worms that plagued most networks because of filtering at the edge.
If all of the data from the client came through our firewall box then
doing what you suggest would be easy for us. As it is, we can't easily
filter traffic that is local to the wLAN. Some APs offer such filtering
capabilities, but then I'm right back to having to tweak every AP. We
can, however, place filters at the VPN server and at the wireless LAN
firewall. That helps.
Going back to the "wireless transceiver", I would really prefer it if APs
would act as transceivers instead of hubs. If all AP traffic were sent up
the wire then the back-end device could handle all authentication and
authorization. It could also filter all flows, which would also be nifty.
The end product would also be less expensive.
Adding some extra processing power and memory to a transceiver style AP
would result in an AP like the ones we have today, so it would be a
no-brainer for a willing vendor. I am hoping that someone will do this
with the new Atheros chips.
> We also feel that segmentation by "campus wide" VLANs is the way to
> provide seamless campus wide roaming and the required longer term
> scalability. That means APs that properly understand VLANs.
With a transceiver-type AP, the back-end device could handle the vLANs.
:)
Okay, one feature that would be nice on a transceiver type AP would be GRE
tunneling. That way, it doesn't matter where you deploy the AP. It
would tunnel all packets to either an intermediate device or directly to a
central controller.
> One last note: I do agree that a policy manager is a neat concept but
> one that is very hard (or impossible) to implement in a full coverage
> environment where airwaves don't stay in a particular room (or
> building!). Doing it on a per-user level might work but that doesn't
> prevent users from borrowing someone else's ID. I just see support
> issues with this.
That's my gut feeling, but it is an interesting feature and worth
considering.
> PS We use the cheaper Colubris CN3500: Bluesocket didn't support Public
> CA SSL support when we evaluated it.
Thanks for the interesting conversation. I really enjoy seeing these
things with something other than my own eyes.
Chris -)-----
--
Christopher R. Hertel -)----- University of Minnesota
[EMAIL PROTECTED] Networking and Telecommunications Services
"Implementing CIFS - the Common Internet FileSystem" ISBN: 013047116X
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/cg/.
