========================================
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.0, 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.0, all configuration can be performed
seamlessly via the management web interface.

Spaces no longer have any effect on node functionality
======================================================

In 7.0, 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.0 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.0, 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.