Differences from SD-WAN version 6.x¶
There are no longer different node types¶
In SD-WAN 7, distinct node types have been eliminated, as all nodes can now perform all functions. In general:
Any node with a static address can be used in place of an aggregator. In documentation or communication, nodes that reside in data centers or central locations for the purpose of accepting connections from other nodes may be referred to as “core nodes”.
Any node can connect to another node or group of nodes; such nodes were previously called bonders. In documentation or communication, these may be referred to as “edge nodes”.
Connections are now referred to as “peers”¶
Connections between two nodes are now termed “peers”. In previous versions, these were known as “bonds”.
All connections are interface-level¶
What was formerly known as a “leg” is now simply an interface assigned to a peer. All IP addressing is defined at the interface level for consistency with other networking systems.
Furthermore, what used to be known as a “connected IP” is now simply an address defined on an interface.
Routing is now configured via “nexthops” and “routes”¶
In version 7, routing configuration is now split between “nexthops” and “routes” to provide more granular control.
A “nexthop” defines an intermediary point in a route, such as a gateway, an interface, or a peer (tunnel).
A “route” defines a routing destination and can have multiple nexthops, allowing for the establishment of custom failover scenarios. The use of multiple nexthops replaces what were formerly known as “classification profiles”.
Nodes are no longer limited to one tunnel¶
“Edge nodes” (formerly referred to as “bonders”) are no longer limited to a single tunnel. A node can establish any number of tunnels (“peers”) to any number of other “core” or “edge” nodes, provided the target nodes have at least one static address defined on an interface.
Configuration is handled solely via the management interface¶
In previous versions, IP addressing on aggregators had to be configured using network setup tools native to the Linux distribution, rather than the SD-WAN software. With version 7, all configuration can be performed seamlessly via the management web interface.
Spaces no longer have any effect on node functionality¶
In 7, spaces are now used only for managing node ownership and no longer affect node functionality such as routing and inclusion in private WAN networks.
VRFs replace private WAN spaces¶
Whereas previous versions used private WAN spaces to manage software-defined routing, 7 uses VRF (Virtual Routing and Forwarding), allowing multiple routing tables to coexist within a single router. This change means:
A node can participate in any number of VRFs across a given tunnel (“peer”). Previously, a tunnel was limited to a single private WAN space.
Global routing traffic uses a predefined global VRF and is treated the same as traffic on a private VRF.
VRFs are defined at the interface level. Any traffic entering the interface will enter the associated VRF.
Interfaces can be defined without a VRF. Such interfaces are used only for establishing tunnels and not for routing client traffic.
Nodes can be added to one or more groups¶
Nodes can be added to any number of “groups”, which can then be used to easily apply certain aspects of configuration across multiple nodes.
For instance, when defining tunnels (“peers”), node groups can be used as the peer target instead of individual nodes. In these cases, only one node will be used to carry traffic, but a connection will be maintained with all of them to facilitate fast failover.
Access rules are now part of the node configuration¶
Node access rules, such as those for SSH access, are now specified in the node configuration. Rules can be applied to individual nodes as well as arbitrary groups of nodes.
Failover no longer requires coordination by the manager¶
In version 7, failover is handled directly by the nodes and is no longer coordinated by the management server. When peers have multiple remote nodes defined, they regularly monitor all remote nodes to make more accurate failover decisions.
The management VPN has been removed¶
A mesh-based remote command line interface with similar functionality and improved permissions control is planned for a future release.
For the time being, defining and routing a private dedicated VRF across peers can achieve a similar effect.