EdgeConnect SD-WAN Hub Design
This section explores the basics for designing a SD-WAN deployment at hub locations and outlines key design points:
The above video summarizes the information in this chapter of the VSG.
Table of contents
Note: Aruba recommends using the SaaS option of Orchestrator because it decreases the operational complexity of the deployment. For information on the on-premise options, refer to the Aruba Edge Connect Enterprise User Guides.
WAN Transport Integration
Hub locations should accommodate every transport type that branches use to enable full hub-and-spoke connectivity. For example, if the environment includes both ISP1 and ISP2 MPLS circuits for underlay transport, both MPLS circuits should have a presence at the hub.
For private circuits, such as MPLS, it is critical to maintain underlay routing with those providers. This enables traffic flows during migrations and ensures reachability to underlay services, such as SIP trunks, that may continue to be used in the future.
Inline Deployment Methods
Inline deployment is the preferred method of deploying EdgeConnect gateways to connect two or more network segments.
The gateway is the device placed between the WAN and LAN network segments. Assigned gateways serve as routers for locally attached subnets and can provide pass-through capability for local traffic flow.
In addition to pass-through, the appliances can exchange route updates using OSPF or BGP (LAN side) and BGP (WAN side) with non-EdgeConnect SD-WAN devices to accommodate varying topologies.
The inline deployment method is generally selected when WAN bandwidth will be less than 10Gbps. Other design considerations include:
- The hubs must be installed during scheduled outage windows, since the edge router is being replaced.
- The gateway must be configured properly to support existing underlay flows during migration. This commonly entails peering BGP with existing MPLS providers to ensure reachability to data center resources from non-SD-WAN sites.
- The hub should operate with two gateways functioning as an active/standby pair.
Out-of-Path Deployment Methods
Some situations may require deployment of an EdgeConnect gateway in a router mode configuration placed out-of-path from the existing flow of data within the network. Typically, this is due to an architectural constraint or pre-existing design.
To accommodate this requirement, deploying gateways in out-of-path mode supports dynamic routing capabilities to interface with the network infrastructure and assist with traffic redirection.
While not preferred, the out-of-path deployment method is typically used in data center hub-style environments and used as a concentration point so overlay tunnels can access data center resources.
The out-of-path design adds the gateways to the topology, leaving edge routers in place to terminate circuits. This can be useful when “scale out” architectures are required for WAN environments with extremely high throughput or when replacing the edge router is not possible.
When possible, routing protocols should be used to attract traffic to the gateways, avoiding redirection protocols such as WCCP and PBR.
High Availability
At hub locations, traditional high availability (HA) is recommended over EdgeHA. Each WAN transport is brought into each appliance, generally requiring WAN side switches or WAN-side VLANs on existing switching infrastructure. This is recommended to provide more resiliency compared to EdgeHA. In the example below, a switch stack is used to provide WAN-side aggregation of connections. The connections should be spread across the stack in a manner that mitigates the risk of a single switch failure.
LAN Routing Integration
At the hub, LAN integration should always be layer 3. The gateway should use transit P2P links (/30 or /31) to peer via BGP or OSPF with the downstream WAN Aggregation block.
BGP should be used in scenarios where there are 4+ hub locations and 1000+ gateways to provide enterprise class control of routing. BGP also is commonly deployed in highly complex environments where specific route filtering needs to be applied. This is commonly seen when there is a large amounts of mergers and acquisitions and for complex migrations from a legacy WAN to SD-WAN.
OSPF should be used in scenarios where simplicity is desired and the deployment size is under the above mentioned scale. For this example design OSPF is selected.
When advertising routes into the LAN, set the routing metric higher on the standby appliance to ensure that traffic is sent there only during an outage of the first appliance and avoid ECMP. This maintains flow symmetry to help ensure that features such as Boost function properly.
When multiple hubs are interconnected using a back-end interconnect, suboptimal routing must be avoided when introducing SD-WAN hubs. Set the routing metric sufficiently high or use more specific prefixes between the hubs to ensure the SD-WAN overlay is used only when the middle mile is unavailable. A tag should be applied to the routes as they are redistributed from subnet sharing into the IGP. Routes with this tag should then be filtered by other gateways connected by the middle mile. This avoids unwanted transit behavior.
WAN Routing Integration - Overlay
The main goal when designing overlay WAN routing is to simplify the routing design while achieving the desired reachability. Proper IP scheme design is critical to network architectures and especially important in WAN designs.
Well-planned IP schemes allow for easy summarization of sites in the network. Summarization produces clean and minimal route tables which, in turn, enable easier troubleshooting and network scalability.
The recommended approach for summarization at the hubs is that each hub advertises a hub summary route and a default route. A summary route covers the prefixes at that hub while a default route attracts all other traffic as a path-of-last-resort. Branches should be configured, utilizing a template, to hub peer-priority to select a next-hop gateway should the same prefix, such as the default route, be received from two specific hubs. This simplifies hub selection and allows for flexibility in the future with regional designs, where different groupings of branches may have different hub priorities.
Numerous valid methods can be used to generate these two summary routes, based on the topology. Aruba recommends the method of using a static route set to null0 on the core for the hub summary route, which is redistributed into OSPF. The default route may come via OSPF from an Internet router or firewall or it can be a static route redistributed into OSPF with the core pointed to an upstream Internet device. Ensure that a method such as a route track is in place to remove the default route from the table. This avoids blackholing backhauled Internet traffic if an Internet outage occurs at the hub. When redistributing routes for subnet sharing, use a route map to limit the redistribution to only those two summary routes.
WAN Routing Integration - Provider
Routing integration with the WAN providers, also known as the underlay, ensures route reachability between the gateways to establish IPsec tunnels.
For private transport types such as MPLS, eBGP is used to advertise reachability of the WAN interface for IPsec tunnel establishment
In most deployments, operators are migrating from a traditional WAN to an SD-WAN solution. As sites are converted from traditional to SD-WAN, branch-to-branch connectivity must be considered. When planning the migration, ensure that the hub advertises a default route into the underlay to attract traffic for converted to non-converted traffic flows.
For public transports such as Internet or cellular, a static default route is used.
