Use Case and Reference Architecture

In this chapter, we describe an example of SD-WAN implementation in a typical hub-and-spoke scenario that leverages different transport technologies to show how it is implemented. A similar lab was built to test this JVD which you can see in the test report.

Keep the following design goals in mind:

• Design for a hub-and-spoke scenario from day one on. Mesh designs always have scale limitations and are not usually friendly to cheap broadband Internet and LTE connections.
• Ensure your hubs have the right connectivity so that the spokes can reach them using the transport network.
  • If you have an MPLS network, your service provider usually provides a routed private IP address to you, or the end-customers manage their own private IP address range (VPLS).
  • When the device has any broadband or LTE connection, you can assume that there is a kind of source NAT applied on the path or the IP addresses on the local router are not permanent. In this case, the hub must have a statically assigned public IP address that is reachable from the spoke trying to make a secure vector routing (SVR) connection.
• Local country regulations should not filter or restrict communication on destination UDP port 1280. Because these ports must be at least open for spokes and hubs to establish secure vector routing for the overlay network.
• Consider allowing only VPN traffic inside your SD-WAN to lower the overall traffic. All traffic to services outside your VPN should use local breakout at the spoke.
• Use Session Smart Routers for their secure vector routing (SVR) capability, specifically the adaptive-encryption feature. This feature identifies HTTPS traffic that is already encrypted and avoids re-encrypting it for VPN transmission, conserving processing resources. As a result, the more VPN traffic that is already encrypted, the fewer resources need to be provisioned.

A lab that simulates the real world, having two underlay paths, each with different behavior:

• You can emulate an MPLS path (without the MPLS framing in-between) with private IP addresses that are visible end-to-end. In a real-world environment, those private IP addresses are managed and distributed by the MPLS service provider’s route reflector. Hub-and-spoke interfaces are assigned static IP addresses.
• An Internet path that is subject to a lot of NAT might make the connection of devices difficult. However, this tends to be what you see in production environments today.
  • Spoke devices get a DHCP address lease from an emulated local broadband router. The emulated router applies symmetric source NAT, especially if the device is connected through Dual-Stack Lite (DS-Lite). This forces the spoke to open a tunnel toward the public IP address of the hub using secure vector routing (UDP destination port 1280).
  • Hub devices get a private static IP address that is assigned to the local interface. In front of the hub, there is an emulated public IP where all spokes must send the traffic to if they want to connect to the hub or the Internet. We then emulate a router or firewall that applies 1:1 NAT forwarding to the private interface IP address of the hub. This emulates the exact behavior you would see when the hub is a VM inside a public cloud. A public cloud provider would not give you the option of assigning a public IP directly to an interface on your hub device.
  • The LTE modem connection of a spoke device is expected to have the same topology requirements. Typically, the mobile service provider (MSP) does some kind of carrier-grade NAT (CGNAT) in its network. However, simulating an LTE Network is tricky as privately owned LTE networks and frequencies are rare. Hence, the simulated broadband router should implement a similar behavior where CGNAT is done in the network before traffic appears on the Internet.
• Both paths are assumed to be completely isolated from each other using an internal firewall. Any intentional cross-path communication needs to leverage the hub which has interfaces on both paths for failover.

Based on these two different path designs, we have implemented and tested five different topologies in this JVD:

• A base hub-and-spoke design with two independent hubs and three spokes. This serves as the foundational topology. The other topologies are extensions or changes to the base topology to achieve other goals. See Base SD-WAN Topology with Three Spokes and Two Hubs.
• A topology where the servers at the hub are not directly attached to the LAN interface and there is a router that is placed between the hub and server. This router then exchanges routes using BGP with the hub to advertise its servers and its VPN-reachable networks. We also enabled a hub-to-hub overlay using the hubs’ WAN interfaces to implement a kind of hub redundancy on Layer 3 (L3). See Extended Topology with Hub Overlay and BGP Peering.
• A topology where we form redundant high-availability hub and spokes using the Session Smart Router cluster feature. Those clusters need local Layer 2 (L2) adjacency between the two devices. See High Availability Hub-and-Spoke Using SSR Chassis Cluster Pairs Topology.
• A topology where we add a Juniper Networks® EX Series Switch and a Juniper® Series High-Performance Access Point (AP) at the spoke. This is the most common scenario at a branch where Juniper provided the full-stack networking environment with all components controlled by a single UI in the Juniper Mist™ cloud. The Juniper EX Series Switch can be attached to the Session Smart Router using a single uplink or multiple uplinks via LAG. See Full Stack Topology with Juniper EX Switch and Juniper Mist AP.
• A topology where we extended the above full-stack networking environment with a Juniper EX Series Switch Virtual Chassis and Session Smart Router high-availability cluster. See Extended Full-Stack Topology with Juniper EX Switch as Virtual Chassis and SSR HA Cluster.