UAP Branch Designs

As previously mentioned, UAP removes traditional limitations and allows microsegmentation even in simple branch deployments without requiring an EVPN fabric. To get started, you only need a UAP-capable switch at the access layer. In the example below, a UAP-capable switch has also been added.

Figure : UAP Branch with standalone UAP Switch

From a high-level perspective, the network topology remains unchanged in this scenario.

• The WAN router serves as the demarcation point between VLANs and acts as the default gateway for all of them.
• For a single SSID with an assigned VLAN for wireless clients, the network must ensure that this VLAN is available on every AP through the switch to support roaming.
• Wired clients may share the same VLAN as wireless clients, depending on design preference.
• If dynamic authentication using RADIUS is required, that service must be deployed somewhere in the network, though it is not shown here.

In the next scenario, a second access switch is added as a Virtual Chassis, and two or more VLANs are configured and shared via IRB interfaces on the WAN router.

Figure : UAP Branch without distribution Switch

In the next topology, we assume the deployment uses an SRX 1500 Series or above or an SSR. Since there are no IRB interfaces on the WAN router to interconnect the VLANs, a distribution/aggregation switch is placed between the WAN router and the access layer. This switch distributes the VLANs to the connected access switches or Virtual Chassis and provides a trunk uplink to the WAN router, allowing the VLANs to communicate upstream.

Figure : UAP Branch with UAP distribution switch

For UAP to function, the distribution switch does not need to support UAP. This capability is required only on access layer switches. If the upstream device is not detected as UAP-capable, which is determined through an additional LLDP extension, the access switches automatically use Layer 2 multicast to send UAP update and lookup messages. As a result, message flooding continues to work as expected.

In this scenario, a third-party distribution switch requires no special configuration beyond the standard port setup and any optional LAG configuration.

Figure : UAP Branch with third-party distribution switch

Note: In a branch deployment with only a few switches, it makes little difference whether the distribution switch supports UAP. However, LLDP-based detection of UAP-capable neighbors becomes important in campus fabric environments. Within an EVPN fabric, the control plane distributes MAC-to-GBP tag information in a reliable manner, allowing the design to avoid relying on Layer 2 multicast inside the fabric.

If you are low on physical devices, this allows you to build labs with virtual distribution switches (vJunos-switch) and WAN router VMs to explore branch scenarios like in the example below.

Figure : Minimal UAP Branch Lab

To better understand the last scenario, the following points outline the complete workflow for a wireless client connected to an AP on the Access1 switch and a wired client (not shown) connected to the Access2 switch within the same VLAN:

• In steps 3 through 10, the administrator, typically through the Juniper Mist cloud, deploys the required configuration, including:
  • UAP settings, such as the shared encryption key.
  • GBP tag identification, whether assigned statically or dynamically.
  • SGT enforcement on UAP-capable access switches.
• In steps 11 through 21, the wireless client authenticates using EAP-TLS. When the final RADIUS access-accept message is received, the dynamically assigned GBP tag is included and becomes known to the AP.
• In steps 22 through 24, the AP sends a Layer 2 multicast UAP update message to the locally connected access switch and other devices in the network. At this point, Access2 does not yet have the new MAC address in its table, so it does not process the MAC-to-GBP mapping.
• In steps 25 through 26, the wireless client begins sending traffic, potentially toward clients in the same VLAN connected to Access2. As a result, Access2 learns a new MAC address but does not yet have an associated GBP tag.
• In steps 27 through 29, Access2 sends a UAP lookup message into the network and receives the corresponding MAC-to-GBP mapping, which it stores in its local table.
• In steps 30 through 31, both UAP-capable access switches now have the MAC-to-GBP mapping for the wireless client and can enforce traffic policies as it enters the wired network.

Figure : Call graph UAP Branch wireless EAP-TLS

Next, we show the entire workflow for a wired client on the Access1 switch and a wired client (not shown) attached to the Access2 switch within the same VLAN:

• In Steps 3 through 8, the administrator, typically through the Juniper Mist cloud, deploys the required configuration, including:
  • UAP settings, such as the shared encryption key.
  • GBP tag identification, whether assigned statically or dynamically.
  • SGT enforcement on UAP-capable access switches.
• In Steps 9 through 16, a wired client authenticates using MAB. The process is very similar to the EAP authentication described earlier. When the final RADIUS access-accept message is received, it includes the dynamically assigned GBP tag, which is then learned by the UAP-capable access switch.
• In Steps 17 through 19, the access switch sends a Layer 2 multicast UAP update message to other devices in the network. At this stage, Access2 does not yet have the new MAC address in its table, so it does not act on the MAC-to-GBP mapping.
• In Steps 20 through 21, the wired client begins sending traffic and may attempt to communicate with devices in the same VLAN connected to Access2. As a result, Access2 learns the new MAC address but does not yet have an associated GBP tag for it.
• In Steps 22 through 24, Access2 sends a UAP lookup message into the network and receives the corresponding MAC-to-GBP mapping, which it stores in its local table.
• In Steps 25 through 26, both UAP-capable access switches now have the MAC-to-GBP mapping for the client and can enforce traffic policies as it enters the wired network.

Figure : Call graph UAP Branch wired MAB

The branch topology shown in the previous scenario is designed to support larger scale and provide high availability on the WAN router side. When implementing high availability with a Juniper SSR or SRX-based WAN router using LAG for failover, the connected distribution switch must operate as a Juniper Virtual Chassis. This allows it to appear as a single logical switch to the WAN router across the LAG uplinks.

If standalone switches were used instead, forming a LAG toward the WAN router would not be possible because each switch would present a different chassis MAC address on the aggregated links. As noted earlier, the distribution Virtual Chassis does not need to support UAP, but it must support and operate using Juniper Virtual Chassis technology in this design.

Figure : UAP Branch redundant WAN-Router and distribution virtual chassis

We have not covered every possible variation of branch designs that support UAP here. However, you should now have a general sense of which devices are required to be UAP-capable and which are not.

If your network design does not extend VLANs all the way to the WAN router as the default gateway, you can still use UAP and classify remote networks based on destination IP prefixes. Keep in mind, however, that these rules do not apply to traffic within the same network or VLAN.

---