Last week, while we were exhibiting at the Connecticut Education Network conference, one particular subject came up with visitors to our booth a couple of times: network segmentation-the separation of school networks or VLANs according to their function. The topic was motivated partly by new requirements from insurance companies for increased internal network security.

You can picture a segmented network as one where the firewall is pulled into the core and sits between different internal network segments. In the case of a school district, segmentation could separate administrator VLANs from student VLANS, or separate the BoE from the high school, as examples.

Network segmentation isn't a new idea, but the appearance of a couple of technologies in equipment that school districts are likely to use, plus the performance of firewalls and processors, are making it easier to accomplish.

To explain these improvements, it might be good to start with what's wrong with trying to use last year's firewall and core switch to accomplish the job. Say that we have the following common configuration: a layer-3 core switch that interconnects traffic coming from each school, and possibly multiple VLANs from the schools, which is trunked back to the head-end of the network.

              :                    :
          --------             --------
          |  FW  |             |  FW  |
          --------             --------
             |                    |
         ----------    -or-       |     ----------     
         |        |               |     |        |
         |  core  |               |     |  core  |
         |        |               |     |        |
         ----------               |     ----------
              |                   |      |   |
              |                   +------+   |
          user VLAN                 user VLAN
              |                              |

A typical configuration is for the core switch to forward internal traffic internally and to forward Internet-bound traffic to the firewall. The two devices could be in series or sit side-by-side. If we wanted to to segment the internal network so that some VLANs were forced through the firewall, how would we do it? The problem is that the core switch has a layer-3 interface on each of the segments, and would usually route the traffic internally.

To force traffic to a firewall requires policy-based routing, including a collection of policy-based routing ACLs that say "if traffic is from VLANx and bound for VLANy, forward to firewall interface on the local VLAN." This overrides the core switch's IP routing. The firewall has a routing table as well, and it probably lists the switch as the correct next hop, so it would be inclined to send an ICMP redirect back to the switch that says "go forward it yourself." In short, we'd have to force the traffic to the firewall and have the firewall forward it back. It's doable, but not graceful.

Another alternative would be to have the firewall act as the core switch. In that case all traffic would have to traverse the firewall, including layer-2 traffic, multicast, everything. This would be ugly, if it were possible; not all firewalls will forward at layer-2. Those that can, can also filter at layer-2. We'll return to that in a moment.

Some of the switches that you might consider for a core switch today, including Aruba Networks' CX line of switches, feature multiple, separate Virtual Routing and Forwarding domains (VRFs). A VRF is a virtual switch instance with its own routing table and ARP cache. Two VRFs running inside one switch cannot see each other and cannot trade traffic unless explicitly forwarded. A core switch with multiple VRFs can seamlessly forward traffic to a firewall without policy-based routing. And, the firewall can forward it back from one VRF to another. This is a graceful way to ingest a firewall into the core--particularly at layer-3 boundaries.

What about performance? Commercial hardware-based firewalls often contain dedicated silicon for fast-path, stateful forwarding of packets. As long as you don't turn on UTM features between internal segments, including intrusion prevention, layer-7 inspection for viruses or content, a firewall in the core should be able to keep up. The UTM features slow a firewall down because the increase the involvement of the CPU. Perhaps these are features that you want between VRFs, in which case a more powerful firewall may be called-for.

So far, we have described a core and firewall combination that can separate internal layer-3 networks or groups of layer-3 networks that share a VRF. Firewall policies can be applied between VRFs--some traffic can pass and some can be denied. What happens when someone from the board of education goes to the middle school and wants to connect back to their desktop? Suddenly, the all-too-familiar swiss cheese of firewall special exceptions gets worse because the firewall is inside the core!

Again, talking about Aruba Networks, there is a capability called Dynamic Segmentation that makes it possible to extend a VLAN from one part of the organization to a switch port in another. The VLAN is encapsulated into a GRE tunnel and then presented as an access VLAN on the switch at the far end. Dynamic Segmentation uses an Aruba wireless controller to forward tunneled traffic to the remote switch in the same way that it dynamically selects and tunnels a VLAN for a wireless user. Combining Dynamic Segmentation with a segmented network makes it possible to secure a network against itself yet still allow for exceptions for administrators and staff.

I mentioned layer-2 filtering with a core firewall, above. Aruba (again) recently acquired a company called Pensando that makes custom silicon for securing flows deep in the core. It is now available in the Aruba CX 10000-series switch (that lists for over $50K...). We're going to have to wait for it to come to an affordable core switch in your district, but it will be possible some time in the future.

-Kevin Dowd

In 2016, the IEEE ratified a standard for pushing higher data rates over copper cabling. 802.3bz provides for 2.5 Gbit/S for 300 feet over Cat5e and 5 Gbit/S for 300 feet over Cat6. 802.3bz is available in commercial gear today. Cisco calls it mGig. Aruba calls it Smart Rate, and combines 802.3bz with optional 802.3bt, 60W Power-over-Ethernet.

Access points are really fast, now—particularly with 802.11ax. Even lower-end models are fast enough to outrun a gigabit connection. The problem can be addressed by running two, bonded 1-Gig connections to each AP. With 802.3bz, it may be possible to reuse the existing wiring and push it to 2.5 Gbit/S.

It works! We’ve been deploying a lot of it this past year. But, what about the cost? In order to push 2.5 Gbit/S (or 5 Gbit/S), you will need an access point that supports 802.2bz and a switch port that supports it, too. An 802.3bz deployment will save the cost of one network drop and one switch switch port for each AP, when compared with a bonded, 2 Gbit/S configuration. Assuming the same AP in either case, here are the relative costs:

What this says is that if you’re running two drops and using two switch ports, it will cost you just a little less to use 802.3bz. If you already have an existing network drop going to an access point, then it would be less expensive to run a second drop and consume another switch port. But who wants to do that! What a mess…

• Kevin Dowd

Aruba's OS-CX switches have the ability to profile devices connected to ports and dynamically assign roles and policies (ACLs) to those ports. The ACLs can include the usual stuff--filtering on source, destination and protocol. But, they can also include configuration parameters like VLAN assignment.

Here's a simple example that can be useful when deploying access points with bridged VLANs. In this example, the switch makes a profile of the connected device using LLDP (you can use CDP, too), parses the response and assigns a role to the port. The role has policies that assign VLANs.

To see how this would work, let’s say that we have an access point on port 1/1/10. Examining the LLDP query on the port, we get the following:

In our test for the presence of an AP, we will search the description for "IAP". To make the example a little more interesting, we will also skip any AP-305s we might find. The following are rules that will match our LLDP port access test. These are arranged like a sieve; the first pattern that matches wins.

 port-access lldp-group AP-lldp-group
      seq 10 ignore sys-desc 305
      seq 20 match sys-desc IAP

Next, we define the role and the policies that we want to associate with access points that match the above port-access tests. The block below says that the role is called "lldp-AP," and that the policies "create a trunk and allow VLANs 12,22,40 and 100, and make 100 be the native VLAN."

 port-access role lldp-AP                                                                                                                                                                   
     vlan trunk native 100                                                                                                                                                                  
     vlan trunk allowed 12,22,40,100               

This last section is the glue that pulls the port-access tests and the role assignment together. It says "if the device on port x matches AP-lldp-group tests then assign the role of lldp-AP."

 port-access device-profile AP-lldp-devprofile                                                                                                                                              
     enable                                                                                                                                                                                 
     associate role lldp-AP
     associate lldp-group AP-lldp-group

Dynamic profiling can be applied to other kinds of devices too, including printers, projectors and phones. When used in conjunction with Aruba Central or NetEdit, elements of the policies and port-access tests can be described using variables, such as this:

 port-access role lldp-AP                                                                                                                                                                   
     vlan trunk native %_native_VLAN%                                                                                                                                                                  
     vlan trunk allowed 
     %_wireless_VLANs%,%_native_VLAN%

When used in conjunction with ClearPass and controllers, the ports can implement enhanced profiling, role assignment and dynamic segmentation whereby VLANs that don’t even exist on the switch can be tunneled from other parts of the organization.

Network Infrastructure is Changing

Last year's switches are very appliance-like. They're a narrow mixture of layer-2, layer-3 and Power-over-Ethernet features--just as they have been for about fifteen years. Switches you might buy this year will behave like last year's when you need them to; you can still program them individually at layer-2 or layer-3 using the command line. But, they're different.

As with phones, cars, televisions, and other electronics, network switches (and access points) have benefited from great increases in computing power. New devices run general purpose operating systems in lieu of embedded firmware. They're built upon supercomputer-speed hardware. So, in addition to switching and routing, they can do general-purpose computer-like stuff, and they can be extended in their capabilities.

Like what? The best-hyped new capability in network equipment is AI. This is the ability to leverage observations taken in the past and apply them to your network in the present. Moreover, it is the ability to pool and organize observations across many organizations' networks to increase the network's resilience for everyone. This includes giving the network the power to recognize issues and heal itself.

Switches are smarter in non-AI ways, too. We've had NAC for a long time (and barely used it). Now, you can program the switches to recognize and classify a device, such as a printer or AP, and assign it the appropriate VLANs and permissions--all by itself. Switches can often apply ACLs and bandwidth restrictions without the help of a central authentication server.

Switches needn't be configured onesy-twosy any longer. Consistency in configuration, visibility, resiliency can be managed for the whole LAN or WAN, all at once. This is possible from the local or cloud-based managers. Software-defined networking--once the stuff of expensive data center switches--is right beneath the surface on many of these devices. The ability to create arbitrary logical network architectures, to safely extend encrypted VLANs from far-away cores and the ability to secure it are available, if you want to use it.

Wireless has advanced remarkably, too. Controller-based and hive (virtual controller) wireless is being supplanted by WiFi networks in which every AP is its own controller. Consider that if every access point has a 2.5 or 5 Gbit/S interface of its own, then centralized operation and switching will to become a liability for larger deployments. In the latest paradigm, AI and central configuration services manage and update the network, but the traffic is bridged onto the LAN at wire speeds by the access point, cooperating with neighbors, but acting on its own behalf.

Three features of WiFi6 are going to make today's wireless networks unrecognizably fast, tomorrow--especially in dense deployments. The first is modulation techniques, particularly QAM-1024, that push wireless into the gigbait+ range with a reasonable number of antenna chains. BSS Coloring greatly increases the efficient use of crowded radio space. OFDMA, which allows the sharing of transmissions between clients, can provide greatly improved transmission-cycle efficiency. If that's not all enough, WiFi6E is out with new spectrum in the 6GHz range, included very wide channels (up to 320 MHz) for huge performance. Look back at some of out earlier communications to learn more about these capabilities.

Problem we are trying to solve: repeat traffic over the same link, particularly broadcast storms. If a layer-2 network has a loop, the same traffic may be forwarded over the same physical network segment repeatedly until its time-to-live expires. Network loops can bring a network down by buying it in traffic.

A collection of switches can be organized into a spanning tree. A spanning tree is a concept from graph theory that describes paths to interconnect all nodes without creating cycles (or loops). So, for instance, nodes A, B,C and D can be interconnected in multiple ways, including:

The topology is a tree. Spanning tree protocols detect cycles (loops) by listening for Bridge Protocol Data Units (BPDUs), which are messages that start at a node designated as the root, and propagate through the tree. When a repeat BPDU is detected, a node makes a calculation about which is the best propagation link among the duplicates. The other, duplicate links are placed into a blocking state. By this mechanism, a spanning tree can be formed among arbitrarily interconnected nodes.

Spanning tree protocols have been used to create resiliency in networks; if one of multiple links goes down, spanning tree protocols may resurrect another. However, multi-path resilience built from link aggregation groups--multiple links cooperating as one--provide combined bandwidth and faster convergence, and are a better design.

Loop detection is a single-switch capability for detecting the interconnection of two or more ports through a another device that doesn't participate in spanning tree. Imagine, for example, two Ethernet ports in a classroom being looped through an unmanaged desktop switch; loop detection will shut down one of the ports.

-Kevin Dowd

What is EduRoam?

EduRoam or Education Roaming is a global wireless network access service developed for the international research and education community. It allows students, researchers and staff to obtain internet connectivity across campus. When visiting other participating institution, they can easily connect to the internet by opening their laptop and use their home institution credentials.

EduRoam uses the IEEE 802.1X protocol (WPA2-enterprise) and a system of interconnected RADIUS servers, with the main U.S. node operated by Internet2 in collaboration with the global Eduroam community.

Why do you need EduRoam?

We live in the world where WIFI access is a necessity in institutions, businesses or campuses. With Eduroam, this will make your venue more attractive for meetings or conferences as it allows participants to access network without assistance.

EduRoam is secured and can give an access to thousands of participating hotspots globally.

The cost of implementing and maintaining EduRoam is fair and acceptable. It can help reduce cost and workload for IT Department such as the need to supply temporary accounts to visiting users. Less work can mean less headaches for your IT or Administrative people.

The log-ins are secured which means that passwords are kept private at all times and misbehaving user can be always identified with the help of their home institution.

Overall, EduRoam makes it possible for visiting students, staff and researchers use their EduRoam credentials to access secured WIFI quickly and easily without (or at the most minimum) assistance and support.

How do you deploy EduRoam?

The basic process to set up EduRoam is as follows:

• The school or school district registers with EduRoam and verifies identity and domain control.

• Once registered they are given credentials to an administration page which allows them to associate their domain with an IP address for their RADIUS server. They are also given a pre-shared secret for their RADIUS server to authenticate to the EduRoam RADIUS servers.

• The internal RADIUS server needs to handle three scenarios of clients authenticating on the EduRoam SSID. o A local user is attempting to authenticate - no need to involve EduRoam's RADIUS' servers.

  o An external EduRoam visitor is on-campus attempting to authenticate. Authentication is sent to EduRoam's RADIUS servers, expect return response.

  o A local user is visiting or "roaming" off-campus. Authentication attempt is received from EduRoam's RADIUS servers, need to authenticate and return response.

Who ya gonna call?

When there's something bad and it doesn't look good. Who ya gonna call? You contact the manufacturer. Nothing gets resolved. This blog entry is about ten WiFi puzzles we've been invited into over the last year or so. I leave the names out. A few of them aren't even our regular customers.

Case 1: School A, no address disclosed, has a problem with Chromebooks using a shared PSK SSID. Some of the kids can get on. Some can't. All other devices seem to be fine. Diagnosis: the manufacturer's wireless intrusion prevention saw many different devices logging in with the same ID and password and shut them down, thinking that they were massing an attack. Resolution: Disable WIP for this case.

Case 2: School B, no certain address, most kids can't Zoom, can't stream. But some are fine. Diagnosis: school had installed a new LED lighting system over the summer. Non-802.11 communications or noise (makes no difference to the WiFi clients) spiked across the upper part of the 5 GHz spectrum at arbitrary times. Resolution: enable DFS channels and move 5 GHz traffic away from the lighting system.

Case 3: School C, address withheld, can't stream reliably, can't Zoom reliably--all devices affected. Short sessions 'appeared' to be okay. Diagnosis: another vendor had increased the basic WiFi rates and minimum negotiated rates too high. This caused clients to hang onto sessions that were unsustainable and led to high frame loss. Resolution: relax the basic and negotiated rates to make the network useful again. Raising rates is just voodoo, anyway; clients roam when RSSI gets low, not when there's no lower rate choice available.

Case 4: School D, location unknown, WiFi was no good on the second floor. Diagnosis: this was a small school with two floors in a crowded city environment. Resolution: enable band-steering for the 5GHz band and disable 2.4 GHz upstairs.

Case 5: School E, name changed for security, lost WiFi connectivity in some areas of the school every day at the same time. Diagnosis: a manufacturer update had enabled DFS channels. This school was on the glide path to a large airport. One particular 5 GHz channel was re-abandoned every day at the same time as a daily flight came in. Resolution: Disable DFS channels.

Case 6: School F, not the same address as the last one, lost WiFi connectivity every day at the same time. Diagnosis: inspection of AP logs showed that access points lost contact with their controller two or three times a day. Resolution: we found a loop in an MDF that caused a broadcast storm on the wired network. This caused the APs to lose contact with the controller. Not sure why nobody noticed everything else grinding to a halt...

Case 7: School G, address confidential, had 'spinning' WiFi in certain parts of the building. Diagnosis: during a renovation, builders were to remove all of the old access points (and pretty much everything else). They missed a few. When the renovations were complete, and the new switching was installed, the old APs found the controller and began advertising SSIDs. The problem was that these APs weren't supposed to exist, and the networks they were offering weren't trunked to them (these were bridged SSIDs; not tunneled). Students could connect at Layer-2, but that was it. Resolution: shutdown the old APs.

Case 8: School H, address also withheld, had student WiFi that was unable to reach the Internet for some, not all, students. Diagnosis: This was a small school. The wired LAN was bridged to the WiFi network (by design). One day, a teacher had plugged a consumer-grade WiFi router into the wired network. This router began handing out 192.168.0.x DHCP assignments to students as they joined the 10.x WiFi network. Resolution: Unplug the router.

Case 9: School J, address unknown, had bad WiFi in the auditorium. Diagnosis: the auditorium had an impossible number of interfering access points, all with omni-directional antennas. Resolution: shut some of them off and think about partitioning the space with directed coverage for wireless access.

Case 10: School K, wouldn't want me to disclose their address, had "bad WiFi". People "had to reboot," etc. Diagnosis: school had multiple, uncoordinated DHCP servers handing out overlapping network addresses from the same scope. Resolution: Really?! C'mon! Who ya gonna call?

What is Outdoor WiFi or Long-Range WiFi Network?

Outdoor WiFi are low-cost setups that can help improve your internet connection throughout your property; This set up gives you the ability to access a network from miles away - whether it’s to share the internet connection with another building or simply extend the WiFi signal outside.

To provide outdoor WIFI to an area adjacent a building, there are two approaches:

1) exterior, weatherproof, purpose-built access points, mounted on the outside of the building.

2) interior access points mated with exterior antennas. The AP is inside the building; the antenna is outside.

Often, you will choose an AP or antenna with a sector radiation pattern that directs coverage away from the building and out into an open space.

The AP or sector antenna might create a 30, 45, 60, 90, or 120 degree horizontal wedge. The narrower the antenna pattern, more concentrated the power from the transmitter. This concentration is expressed as the antenna's gain factor. An antenna with a narrow sector pattern can provide service for many miles over a smaller coverage area.

In the US, the effective radiated power output is limited to 100 milliwatts, by law. When you pair an antenna with an access point, you will have to program a gain factor for the antenna. This will be provided by the antenna manufacturer. The gain value tells the transmitter to reduce output power to remain within the law.

Antenna extension cables and connectors can cause losses between the transmitter and the antenna. With long antenna cables, you may have to reduce the programmable gain to make up for the losses. It is better to extend the Cat5e or Cat6 data cable that provides data and power to the access point than to extend the antenna leads.

When choosing a location for an exterior antenna or AP, it is best that there be line-of-sight between the antenna and the area to be covered. Trees and other structures will attenuate radio signals, particularly for the 5 GHz bands.

It is also very important that the near-field of the signal be unobstructed. Roof edges, building overhangs and corners can interfere with the radiation pattern.

Picture a pebble dropped into the water. Ripples will radiate evenly in all directions. Now, picture the same pebble dropped into water with rocks. The ripple pattern will be disturbed by the reflections from the obstructions. We want to avoid the same kind of reflections with WiFi.

To cover an open space with many access points, such as a quadrangle, it is better to mount the antennas high and aim them downward, toward the ground. This is the same approach that one would take if installing outdoor lighting, careful to light each area independently.

To provide WiFi to locations far away, a wireless bridge or mesh may be desired. An access point located on a building can create a back-haul link to a distant access point or access points.

When there is one access point at the far end of the back-haul link, we call this a point-to-point connection or bridge. When there are several, we call this point-to-multipoint or mesh. The distant access points may provide local service as if they were wired.

Often, with a dual-radio access point, one radio is used for the back-haul network. The other is used to provide WiFi access. Sometimes, you will use a high gain antenna for the back-haul radio and an omni-directional antenna for user WIFI. You may also let down a wired connection for a camera or switch.

There must be electrical power available at the far end of the link. This can be hard-wired AC power or provided by a power injector depending on the AP and the application. A typical access point plus camera installation will include two power injectors--one for the AP and one for the camera.

In an WiFi infrastructure, APs that form the bridge or mesh are managed by a wireless controller or cloud just as the campus APs are. Sometimes, instead, an inexpensive third-party bridge can be used to extend the campus network. Devices located at the far end, including access points, will not be aware of the third-party wireless bridge.

A typical bridge or mesh configuration will use a 5 GHz link for back-haul and 2.4 GHz for local service. The expected speed in a nearby, line-of-sight application is often just over 100 mbit/S.

Bridge and mesh products that use 24 GHz or 60 GHz radios are also available. These feature back-haul speeds that in the 1 gbit/S range. The wavelength of a 60 GHz signal is just 5mm, which is less than the width of a large raindrop or a snowflake. Because of this, 24 GHz and 60 GHz transmissions are subject to 'fade' or failure in rain, snow or fog. For this reason, 60 and 24 GHz bridges are often packaged with 5 GHz fall-back radios.

A bridge built from 900 MHz radios can penetrate trees and weather much better than a 5 GHz radio, but with much narrower channel width, measured in 100s of kbits/S.

Local outdoor coverage, bridges or meshed links--Atlantic has been providing commercial WiFi for 15 years. Call us for your next project. - Kevin Dowd