SD-WAN 2016.2 release notes

August 8, 2016

We’re pleased to announce the release of SD-WAN 2016.2. This version adds four major features:

  • Management of DHCP services for connected IPs—bonders can now offer DHCP and DNS services to networks behind the bonder. This makes it much easier to use the bonder as the only gateway for a office and no longer require an additional device acting as a dedicated DHCP server.

  • Default bonders issue a DHCP IP address to clients connected on eth0, making it much easier to access the default bonder web server to submit a node key. The user no longer needs to configure a static IP address on his or her workstation in order to access the web server.

  • Private WAN (PWAN) spaces can now use a gateway at a bonded site. This allows Internet traffic from branch offices to be routed to a gateway at the head office instead of using a gateway in the datacentre, making it easy to deploy PWAN in an organization that already has a central gateway at their head office.

  • PWAN space gateways, both in a datacentre and at a bonded site, can be used by bonds on aggregators in different routing groups. For example, if a customer has bonds on aggregators in a Vancouver datacentre and in a Montreal datacentre, and a gateway defined only in the Vancouver datacentre, the bonds at the Montreal datacentre will use the Vancouver gateway.

The diagram below demonstrates both PWAN improvements. The dashed blue line represents Internet traffic from branch bonders traveling to the head office bonder. From a branch bonder assigned to an aggregator in the same routing group as the head office bonder, traffic simply goes between the aggregators and the PWAN router on its way to the head office gateway. From a branch bonder assigned to an aggregator in a different routing group from the head office, the traffic goes through its aggregator and PWAN router, over the Internet to the routing group where the head office bonder is located, and then to the head office gateway.

image0

The head office gateway can supply Internet access from a dedicated, non-SD-WAN connection, or it can offer access via the bonder from a connected IP that is excluded from the PWAN.

Note

Due to the significant changes in PWAN in 2016.2, this version is not backwards-compatible with PWAN in 2016.1. If you use PWAN, you must upgrade all PWAN routers, aggregators, and bonders in PWAN spaces in one maintenance period. You cannot mix 2016.2 hosts with 2015.4 or 2016.1 PWAN routers, aggregators, or bonders in PWAN spaces.

You do not need to coordinate upgrades of aggregators that do not participate in PWAN (ie the pwan-aggregator package is not installed), or of bonders that are not in PWAN spaces. These can be upgraded 2016.2 using normal practices—a 2016.2 aggregator will support a 2016.1 or earlier bonder.

Now, the details on 2016.2:

Private WAN

Additions

  • PWAN spaces can now use a gateway at a bonded site. This allows Internet traffic from branch offices to be routed to a gateway at the head office, instead of only using a gateway in the datacentre. No matter what type of gateway is used, or even if no gateway is configured, routes between bonders, aggregators, and PWAN routers are managed using BGP and the BIRD routing daemon. A default route is published in the internal BGP network when a gateway is configured. Since this BGP network is internal to SD-WAN, no integration with other networks is necessary.

  • Space gateways, both in a datacentre and at a bonded site, can be used by bonds on aggregators in different routing groups. For example, if a customer has bonds on aggregators in a Vancouver datacentre and a Montreal datacentre, and a gateway defined only in the Vancouver datacentre, the bonds at the Montreal datacentre will use the Vancouver gateway. If the Montreal routing group had its own gateway, then of course bonds on aggregators in that routing group would use the Montreal gateway. Prior to 2016.2, each routing group needed its own gateway. If a gateway is defined at two or more routing groups, but some routing group has no gateway, then traffic from bonds in the routing group that has no gateway will be routed to one of the other routing groups; the destination routing group depends on routing metrics defined by the internal BGP network.

Changes

  • All hosts supporting PWAN—PWAN routers, aggregators, and bonders in a PWAN space—must run 2016.2. PWAN 2016.2 is not compatible with PWAN in 2016.1. You must upgrade all relevant hosts in a single maintenance period.

  • Dynamic routing configuration requirements have changed; both redistribute connected and redistribute kernel must be specified in the routing protocol configuration in Quagga. This is normally only necessary when using NAT via PWAN router modes, not when using dedicated gateway modes. For more information, see Configuring private WAN dynamic routing in Quagga.

  • Debian 6 is not supported for PWAN bonders. Prior to 2016.2, bonders didn’t have any special function related to PWAN, but in 2016.2 bonders do apply special configurations when they are in a PWAN space, and these configurations require Debian 7 or 8.

Fixes

  • PWAN NAT rules for an IP address other than a gateway address work properly.

Bonding Node

Additions

  • When enabled in the management application, bonders supervise DHCP and DNS servers for connected IPs. DHCP can be managed locally or can forward requests to one or more relay servers. DHCP and DNS is served by dnsmasq.

  • On a default bonder, DHCP addresses are assigned to clients connected to the eth0 inteface, eliminating the need to configure a static IP address on a client in order to access the bonder, although the static IP address method still works. All DNS requests are directed to the bonder’s IP address, so a request for any HTTP page will result in the client’s browser loading the bonder web page.

  • The core node service supervises the BIRD daemon when the bond is in a PWAN space.

Changes

  • Routing tables have been completely redesigned, even on bonds and aggregators not in PWAN spaces. If your bonders or aggregators have customized routes or rules, please test your configurations before upgrading. If you have questions, please contact technical support.

  • The bonding package conflicts with the NetworkManager package. This fixes a provisioning issue occurring since July 2016 related to unreliability with Debian’s HTTP mirrors.

Fixes

  • When traffic is sent to a host in the network of one of a bond’s legs, it is routed through the tunnel. Previously it was routed directly through the leg, resulting in triangular routing that would result in connection failures. This change allows connections to complete successfully.

  • When provisioning or updating a bonder, configuration files, keys, and certificates are written to disk in a more reliable way to avoid writing corrupt or empty files.

  • When a bonder’s automatic source IP option is disabled, certain iptables rules are now updated properly so that bonders can continue to make DNS requests.

  • TCP proxy no longer becomes unresponsive while taking 100% of a CPU core after the connection between the bonder and aggregator is interrupted in certain circumstances.

Bonding Admin

Additions

  • Options for managing DHCP servers are available in an “advanced” pane for each connected IP on the bond page.

  • Three new charts have been added to the System Charts page in the Administration section—a chart recording the time taken to run a worker job in the Huey service, and two charts monitoring OpenVPN server metrics.

  • There is an internal setting for the Debian mirror referenced in ISO files. This defaults to Debian’s httpredir service. To change this, please contact technical support.

Changes

  • Provisioning ISOs boot with a Linux 4.5 kernel instead of the default Debian 8 Linux 3.16 kernel.

  • A new service queries InfluxDB data periodically to downsample it to the level used in week, month, and year charts. Previously this was handled internally in InfluxDB but it suffered from issues on high and medium load servers. The dedicated service eliminates this issue and provides future flexibility for this capability.

  • Certain limits are applied to InfluxDB queries, such as a limit on execution time.

  • When a password reset is requested for an email that does not have a registered account, a error message is shown. Previously no notice was given if the email was not found.

  • Logs are persisted in the systemd journal rather than being removed after about one day.

  • A variety of changes have been made to the collectd service to make it more reliable.

Fixes

  • Various exceptions in the web application and other services are now handled properly, especially related to managing PWAN gateway and NAT options and bond options.

  • HTML templates and CSS files are served in a way that prevents versions cached by a browser from being used improperly. It also speeds up rendering of web pages.

  • Metrics on the space statistics page are accurate again.

  • The user that triggers a speed test by using the “repeat” button is logged properly. Previously tests executed this way were recorded as being triggered by the system.

  • Configuration updates no longer fail to execute in a certain circumstance.