Deployment Info

Domain

VT’s deployment of the Aruba Mobility system uses the domain mobility.nis.vt.edu. All hostnames are relative to this domain. For example, the hostname foo has the FQDN foo.mobility.nis.vt.edu and the hostname foo.dev has the FQDN foo.dev.mobility.nis.vt.edu.

Configuration Hierarchy

Design

/
├── mm
│   └── mynode
└── md
    └── [org]
        └── [region]
            └── [cluster]
                └── [device]

• /, /mm, /md, and /mm/mynode are created by the system and cannot be removed
• / and /md should never be modified

Implementation

/
├── mm
│   ├── isb-mm-1
│   └── isb-mm-2
└── md
    └── vt
        ├── swva
        │   ├── bur
        │   │   ├── bur-md-1
        │   │   ├── bur-md-2
        │   │   ├── bur-md-3
        │   │   └── bur-md-4
        │   ├── col
        │   │   ├── col-md-1
        │   │   ├── col-md-2
        │   │   ├── col-md-3
        │   │   └── col-md-4
        │   ├── res
        │   │   ├── res-md-1
        │   │   ├── res-md-2
        │   │   ├── res-md-3
        │   │   └── res-md-4
        │   └── vtc
        │       ├── vtc-md-1
        │       └── vtc-md-2
        └── nova
            └── equinix
                ├── equinix-md-1
                └── equinix-md-2

Configuration prefixes

VLAN / subnet architecture

VLAN / subnet classifications

The Zero Trust principle says that it doesn’t matter what network a client is coming from. The application should implement it’s own authentication and security controls. Taking this to heart, we do not attempt to implement application security at the network layer.

However, it is , practical to make some broad classifications.

Authenticated

• IPv4: RFC 1918 (172.16.0.0/12)
• IPv6: Globally routed
• Considered “on campus” All authenticated devices land in the same network and have no restrictions.

Our assertion to application administrators is that we know (or can find) the owner of a device on this network.

Notably, by this criteria, a PSK network counts as unauthenticated (though PSK networks are only one-offs, which tend to bend the rules anyway).

Unauthenticated

• IPv4: CG-NAT (100.64.0.0/10)
• IPv6: Globally routed
• Considered “off campus”, that is, the same as traffic from the Internet
• Traffic from this network to campus is hair-pinned at the border

There are no network ACLs artificially limiting access. However, there are services that require being connected to an “on campus” network to use them, which the unauthenticated network is not. Some services that do not work from the unauthenticated network include:

• Zoom rooms
• Digital key access for physical doors

Connected… somewhere

Unfortunately, the real world is messy and things sometimes need their own networks. Notable examples of this include:

• Co-location networks where we pass the clients off to a different entity’s layer 2 connection (e.g., VTC).
• Remote locations where we want to bridge the traffic to the local (to the AP) network (e.g., gcaps).
• Special L2 or multicast connections (e.g., precor stuff)

In this case we use the nomenclature “connected” to indicate that we are not specifying the network where we normally would (see below).

VLAN assignment

The standard networks (eduroam and VT Open WiFi) use user roles to assign the VLAN.

One-off networks are by nature unauthenticated and often need a special VLAN. When using the standard unauthenticated network, they use the corresponding user role. Otherwise, they use a role that does not have the VLAN set (see below) and the VLAN is set on the Virtual AP profile.

VLAN Names

vlan-authenticated and vlan-unauthenticated

As one might expect, these map the authenticated and unauthenticated VLANs. Which exact VLAN ID this maps do depends on which cluster the user is connected to.

vlan-*

Everything else is used to label one-off networks. These are still mapped at the controller, though typically it is a one-to-one mapping.

User Roles

All roles apply basic ACLs to protect the network (prevent clients from acting as a DHCP server or sending RAs, etc).

ur-authenticated

• One of the “standard” roles
• Assigns the authenticated vlan
• All eduroam devices get this role
• Registered devices on VT Open WiFi get this role
• Not to be confused with the preconfigured authenticated role

ur-unauthenticated

• One of the “standard” roles
• Assigns the unauthenticated vlan
• Devices that fail MAC auth on VT Open WiFi get this role
• Used by one-off networks that do not need a special VLAN

ur-connected

• Used only by (some) one-off networks
• Does not assign a VLAN; this must be done by the Virtual AP profile (or be bridged locally)
• These networks are treated as unauthenticated

AAA Profiles

aaa-eduroam and `aaa-vtopenwifi

The AAA profile for the eduroam and VT Open WiFi networks, including RF variants such as for large classrooms. See their respective pages for details.

aaa-eduroam-bridged

The same as aaa-eduroam, except it assigns the ur-connected role so the traffic can be bridged locally instead of being tunneled back to the wireless gateway.

aaa-authenticated, aaa-unauthenticated, and aaa-connected

These are (or may be) used by one-off networks to always put clients in the respective user role.