Why we have multiple wireless networks around here

November 7, 2016

I mentioned on Twitter that I wished my iPhone could be set to strongly prefer one configured wireless network over another in situations where more than one was available, to the point where it would switch from a lower-preference network to a higher-preference one. At this point, some of you may ask the obvious and perfectly sensible question of why we even have more than one wireless network available at once.

It is not, as you might first guess, because the various networks run over different wireless access points that were installed at different times by different groups within the university in only somewhat overlapping areas. That certainly used to be the case many years ago for reasons that made sense at the time, but a while back we were able to get out of the WAP business and now all of the various wireless networks involved all run over the same hardware (literally; the enterprise-grade WAPs the university uses handle multiple SSIDs at once). So these days, everywhere that has the departmental wireless network also has the university's wireless network and eduroam.

(The reverse is not true; for various reasons, the departmental wireless network is only available in the campus buildings that we're located in.)

Why keep having a departmental wireless, then? It comes down to network topologies and network access policies. Since we have our own wireless network at a logical network level, we can decide what weird devices can be on it, who does and doesn't get access to it, and how it can have bits of special access to our own internal networks. If researchers or the department has special needs for wireless devices, we can accommodate them. Does someone want to run a wireless robot that simply can't do special authentication and also be able to talk to it from our networks in order to control it? We can accommodate that, complete with holes poked through our wireless NAT firewall if necessary. This is not really possible with the university-wide wireless, or at least not without a lot of discussion and work by a bunch of people. And of course the university wireless can be used by anyone in the university, not just 'only people the department decides to give access to'.

(As a university wide thing, the university wireless group naturally has a tension between trying to accommodate narrow specialized needs for people and running their network in a scalable, manageable way, which in part means 'as few special cases as possible'. We run a much smaller network for a much smaller population, so we can afford more special cases and weirdness than they can and we don't need to be as scalable as they do. The overall university wireless usage is apparently scarily large; I've heard jaw-dropping numbers for how many concurrent active devices there are during peak times.)

As a wireless user in this environment, you have a relatively clear preference order for wireless networks but also a reason to have all three configured. If you're in campus buildings with the departmental wireless available, it's best to use that. If you're elsewhere on campus, you'll obviously want to use the general university wireless. And if you're off at another institution, you'll want to use eduroam to get more or less campus access (including access to resources that are restricted to University of Toronto people, such as certain online library resources and journals).

(I don't know if we'd still build a departmental wireless network if we were starting over from complete scratch today. There's some arguments for it, but our current wireless situation clearly benefited from inheriting a lot of existing firewalls, configuration, and so on from our old completely independent wireless network, and there are aspects of our departmental wireless network that we deliberately dropped support for when the university wireless became pervasive.)

Written on 07 November 2016.
« The other reason why I've wound up not interested in firewall managers
Security often involves not doing things »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Nov 7 22:25:31 2016
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.