SD-WAN 6.4 release notes¶

We are pleased to announce the release of SD-WAN 6.4. This release brings support for IPv6 bonded tunnels as well as a redesigned interface for bond networking configuration.

Important notes:¶

Warning

The leg hooks have changed and no longer contain interface or address information. If you relied on these values you will need to update your hooks to be either address or interface hooks.

Major Features¶

IPv6 support for bonded tunnel legs, internal tunnel traffic, and private WAN traffic.
A redesigned interface for bond networking configuration.

Errata¶

As per general IPv6 recommendations, features employing NAT do not support IPv6 traffic.
- CPE NAT IP does not support IPv6 addresses.
- Tunnel bypass does not currently support IPv6 traffic classification.
- TCP Proxy does not currently support IPv6 traffic.
- Private WAN “NAT via PWAN router” does not support IPv6 addresses.
- Private WAN port forward and NAT rules do not support IPv6 addresses.
When using PPPoE addresses with IPv6 links, only Router Advertisements are supported. DHCPv6 support in this scenario may be re-evaluated at a later date.
IPv6 addresses are not managed using allocations and delegations at this time.
Aggregators and private WAN routers cannot be set up without an IPv4 address at this time, even if it is intended to operate only via IPv6.
DHCP services with DNS caching enabled conflicts with the separated DNS caching service. The option was left in the DHCP configuration to preserve the configuration from previous versions. If you need to provide IPv6-based DNS caching, the DNS caching should be disabled on the DHCP service before adding the separate DNS caching service.
On bonding versions prior to 6.4, configuring multiple addresses per leg is not supported. Special care should be taken when changing addresses on a legacy leg through the management interface. See Backwards compatibility for more information.

Bondingadmin¶

Note

In the new v4 API, the include_private_wan field on connected IPs and routes now defaults to false. The v3 API behaviour has not been changed.

Note

With the introduction of separate control over interfaces, some user permissions may have to be adjusted. In particular, users that could previously change view/change legs and interfaces but not view bonder details must now be able to view bonder details in order to view/change legs and interfaces.

Additions:

The networking configuration on the bond page has been completely redesigned.
- There is now a more clear distinction between interfaces, legs, and addresses. This avoids undefined behaviour when multiple addresses and legs share the same interface or when settings are applied to VLAN interfaces.
- Legs may now employ multiple IP addresses. For example, this allows legs use an IPv6 address and fall back to an IPv4 address, use a static address and fall back to a DHCP address, or use a PPPoE address and fall back to a DHCP address. This greatly simplifies certain recovery scenarios.
- Legs now support “Auto IPv6” address schemes which uses a combination of DHCPv6 and Router Advertisement to acquire addresses.
- Connected IPs and routes now support IPv6.
- Connected IPs can now be configured with IPv6 link-local addresses, eliminating the need to define IPv6 interconnection ranges between a bonder and an internal router or firewall.
- Routes can now specify an interface in addition to their gateway, covering cases where there may be duplicate networks containing the gateway on multiple interfaces.
- There is a new “Services” category for setting up client services on bonders.
  - DHCP configuration has been moved to the “Services” category.
  - Added services for DHCPv6 IA_NA (Non-temporary Address) and IA_PD (Prefix Delegation).
  - Added service for IPv6 Router Advertisement.
  - Added service for DNS caching.
The default leg upload and download speeds are configurable in the bond defaults page under the administration menu.
Private WAN outbound gateways now support IPv6 addresses.
QoS and classification profiles now support IPv6 network addresses and protocols.
Aggregators and private WAN routers can be configured with IPv6 addresses.
A new version of the API, v4, has been added to support the new IPv6-enabled objects and the separated interfaces, legs, and connected IPs. Calls to the v3 API will continue to work, but support for IPv6 and new features going forward will only be supported in v4. We recommend that any API users update their applications to use the v4 API.
A number of the slower API calls, such as the bond list endpoint, have been optimized and should return results much faster.
Some charts have been improved
- The packet loss charts for bonds now scale to make service-impacting amounts of packet loss more clear.
- Added per-core CPU charts to make it more clear when a core is at full utilization.
Improved the Cloning from template image documentation to account for some issues that may occur where cloned images may conflict when brought up.
CPU usage is measured on both bonder and aggregator when running speed tests and is shown on the speed test results to help identify CPU bottlenecks.

Fixes:

The account page now invalidates the login session when the password is changed to ensure that the user logs in with the new credentials
Fixed an issue with the configuration update service where, in a rare situation involving a temporary loss of network connectivity, an update would never be sent to a node even after connectivity was restored.
Fixed an issue that could occur on a heavily loaded bondingadmin server where the management VPN would take too long to connect a node, resulting in a loss of reporting capability for the node, even after the load subsides.
Fixed an issue where the /api/v3/system/status/backups/latest-backup/ API call could fail to return the backup file due to a spurious filesystem permission problem.
Fixed packet loss reporting on speed tests where the loss reported would be much larger than the actual loss.
The nginx web server is now properly restarted on Let’s Encrypt certificate updates.
The wording in the automated notification emails about aggregator failover suspension has been changed to be more clear.
Fixed an issue where aggregator failover wasn’t updating its status to reflect that an aggregator was recovered.
Added a new API endpoint for faster listing of spaces, /api/v4/flat/spaces. The detail url still points to the original /api/v4/spaces/<space-key>.

Bonding Node¶

Additions:

Legs now support IPv6 addresses. IP addresses may be assigned statically or via the “Auto IPv6” address scheme which employs a combination of DHCPv6 and Router Advertisements to acquire addresses.
Legs may now employ multiple IP addresses. For example, this allows legs use an IPv6 address and fall back to an IPv4 address, use a static address and fall back to a DHCP address, or use a PPPoE address and fall back to a DHCP address. This greatly simplifies certain recovery scenarios.
Tunnels have IPv6 addresses and can now route IPv6 traffic.
Connected IPs and routes now support IPv6.
Connected IPs can now be configured with IPv6 link-local addresses, eliminating the need to define IPv6 interconnection ranges between a bonder and an internal router or firewall.
Routes can now specify an interface in addition to their gateway, covering cases where there may be duplicate networks containing the gateway on multiple interfaces.
DHCPv6 IA_NA (Non-temporary Address) and IA_PD (Prefix Delegation) can be served to local interfaces.
Private WAN outbound gateways now support IPv6 addresses.
QoS and classification profiles now support IPv6 network addresses and protocols.
Aggregators and private WAN routers can be configured with IPv6 addresses.
The bonder informational web server now supports IPv6 connections.
Custom BIRD configuration files can be placed in .conf files under /etc/bonding/bird/spaces/<key>/ to inject custom BGP or OSPF dynamic routing and static routes for private WAN spaces.
Management tunnels now employ IPv6 addresses in addition to IPv4 addresses.
The 10.207.35.254 troubleshooting IP on bonders is now added with link scope to avoid polluting the global routing table.
The Linux kernel version deployed on new nodes as well as nodes with the bonding-kernel package installed has been updated to 4.18.
Restructured the iptables chains that are set up on the devices to avoid potential duplicates or conflicts on restarts.

Note

These changes have caused the transmission of packets to consume about 5% additional CPU resources, which could lead to CPU contention problems if the bonder or aggregator were already very close to reaching CPU limits under heavy load. There are some new options available to mitigate this problem. With the following options enabled we have observed better performance than 6.3 on certain hardware platforms.

A new bond-level option “Batched leg send operations” which can improve CPU utilization at the cost of a small (about 1ms) increase in latency on any sent packets. This option does not work on Debian 7 (Wheezy) bonders or aggregators and will be ignored.
On a bonder, the tunnel process can now be assigned to work on a specific CPU core, which can have performance improvements on some hardware platforms.

Fixes:

Fixed an issue where private WAN route sets on an a busy aggregator could be incomplete after recovering from an outage caused by a large amount of packet loss at the upstream provider.
Fixed a memory leak that could occur on private WAN routers when it’s peer nodes frequently reconnect due to restarts or outages.
Fixed a rare crash that could occur on peer private WAN nodes when disabling a private WAN router as it’s connections are being established or reestablished on the other nodes.
Fixed a memory leak that could occur on aggregators if an aggregator record for it’s IP address was duplicated on another management server.
Fixed a rare crash in the path MTU detection that could occur when the leg is flapping.
Fixed an issue where private WAN routers would check for a primary router between routing groups instead of just inside the local routing group, leading to network flaps under certain scenarios.