Hub-to-Spoke sessions
As you have learned from the reference designs described so far, the Spokes are responsible for the sessions originated behind them. They constantly measure the health of all available paths and apply the configured SD-WAN rules to all the outgoing traffic, deciding where to steer it at any given moment.
This technique cannot be applied to the Hub-to-Spoke (Hub-to-Edge) sessions, that is, the sessions originated behind the Hub. While, in theory, the Hub could measure the health of all the overlay paths towards all the Spokes, this design would be suboptimal for at least two reasons:
-
It is a clear scaling bottleneck, because a single Hub should be able to serve hundreds and thousands of Spokes
-
It is a duplicate effort, because all the Spokes already measure the health of the overlay paths towards their serving Hubs by actively sending PING probes over all the static overlay tunnels.
|
It is important to highlight that we are NOT talking about the replies to the sessions originated by the Spokes! This problem does not exist for the replies, because they automatically follow a symmetrical path. That is, once the originating Spoke selects a particular overlay for the Spoke-to-Hub session, the reply packets will automatically prefer the same overlay on their way back from the Hub. In this section, however, we are specifically addressing the sessions originated behind the Hubs! |
Our solution to this problem is depicted on the following diagram:
-
First, the Spokes will embed their health measurements (latency, jitter, and packet loss) into the probe packets themselves. When these probes arrive at the Hubs, the Hubs will read the measurements, as if they were actively probing the Spokes. This method is called Remote Health Probing.
-
Next, the Hubs will apply different route priorities to the LAN prefixes learned from the Spokes, making sure that the routes through healthy overlays get better priorities than those through unhealthy overlays.
As a result, even the conventional routing on the Hubs can skip the unhealthy overlays for the Hub-to-Spoke sessions.
|
|
Note that when all the Hub-to-Spoke overlays are healthy, the route priorities are equal, and hence the path is selected in ECMP manner. If this is not desired, SD-WAN rules can be configured on the Hubs to further customize the behavior. For example, a Primary/Backup model can be configured, so that the Hubs will prefer a particular overlay, as long as it meets the configured SLA target. |