Partner Gateway Upgrade and Migration

This document provides instructions on how to upgrade the Partner Gateway from the 3.3.2 or 3.4 release to the 4.0 release.

The Gateway appliance includes the following changes in the 4.0 release:

  • A new system disk layout based on LVM to allow additional flexibility in volume management.
  • A new kernel version.
  • New and upgraded base OS packages.
  • Improved security hardening based on Center for Internet Security benchmarks.
The Gateway appliance includes the following system changes in the 4.0 release:
  • ifupdown has been deprecated in favor of https://netplan.io/.
    • ifup and ifdown are no longer available.
    • Network configuration is now in /etc/netplan vs /etc/network/.
    • etc/network/ifup.d and /etc/network/ifdown.d no longer work. Network-dispatcher locations should be used /usr/lib/networkd-dispatcher (dormant.d, no-carrier.d, off.d, routable.d).
  • Substantial changes to cloud-init. Cloud-init deployment scripts must be reviewed and tested for compatibility.
  • net-tools (ifconfig, netstat, etc) are considered “deprecated” and may be removed in the future versions.

Network Configuration

ifupdown has been deprecated in favor of https://netplan.io/. Network configuration has moved from /etc/network to /etc/netplan.
Example network configuration (whitespace is important!)- /etc/netplan/50-cloud-init.yaml:
network: version: 2 ethernets: eth0: addresses: - 192.168.151.253/24 gateway4: 192.168.151.1 nameservers: addresses: - 8.8.8.8 - 8.8.4.4 search: [] routes: - to: 192.168.0.0/16 via: 192.168.151.254 metric: 100 eth1: addresses: - 192.168.152.251/24 gateway4: 192.168.152.1 nameservers: addresses: - 8.8.8.8 search: []
Network configuration is regenerated on every boot. To make changes to the location configuration, deactivate the Cloud-init network configuration.
echo 'network: {config: disabled}' > /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg

Cloud-init

Cloud-init was upgraded to version 20.2. More information on Cloud-init can be found here: https://cloudinit.readthedocs.io/en/stable/index.html.

Example 1: Simple

meta-data:

instance-id: vcg1

local-hostname: vcg1

user-data:
#cloud-config hostname: vcg1 password: Velocloud123 chpasswd: {expire: False} ssh_pwauth: True

Example 2: New-style network configuration (network-config file)

meta-data:
instance-id: vcg1 local-hostname: vcg1
user-data:
#cloud-config hostname: vcg1 password: Velocloud123 chpasswd: {expire: False} ssh_pwauth: True ssh_authorized_keys: - ssh-rsa … rsa-key velocloud: vcg: vco: demo.velocloud.net activation_code: F54F-GG4S-XGFI vco_ignore_cert_errors: false runcmd: - 'echo “Welcome to VeloCloud”'

network-config Example 1:

version: 2 ethernets: eth0: addresses: - 192.168.152.55/24 gateway4: 192.168.152.1 nameservers: addresses: - 192.168.152.1 eth1: addresses: - 192.168.151.55/24 gateway4: 192.168.151.1 nameservers: addresses: - 192.168.151.1

network-config Example 2:

Note: If multiple interfaces are present on the Gateway and need an interface to be selected as a preferred interface for the default gateway, the below configuration (with the metric value) can be used to select the correct interface.
version: 2 ethernets: eth0: addresses: [192.168.82.1/24] eth1: addresses: [70.150.1.1/24] routes: - {metric: 1, to: 0.0.0.0/0, via: 70.150.1.254} eth2: addresses: [70.155.1.1/24] routes: - {metric: 2, to: 0.0.0.0/0, via: 70.155.1.254}

Net-tools

Net-tools utilities like ifconfig, netstat, route, etc. are considered “deprecated.” Net-tools suggested replacements are shown in the table below. These commands only display information for the Linux Host and not for the SD-WAN Overlay Network.
Note: For additional information, type: man ip.
Table 1. Net-tools Suggested Replacements
Old Net-tool Utilities New Corresponding Net-tool Utilities
arp ip n (ip neighbor)
ifconfig ip a (ip addr), ip link, ip -s (ip -stats)
nameif ip link, ifrename
netstat ss, ip route (for netstat-r), ip -s link (for netstat -i), ip maddr (for netstat-g)
route ip r (ip route)

Sample Command Output for Net-tool Utilities

The sample output is confirmation that the command is successful. Sample command outputs for ip n (ip neighbor), ip a (ipaddr), and ip link are shown below.

ip n (ip neighbor):
root@SS-gateway-1:~# ip n 192.168.0.100 dev eth2 lladdr 00:50:56:84:85:d4 REACHABLE 192.168.0.250 dev eth2 lladdr 00:50:56:84:97:66 REACHABLE 13.1.1.2 dev eth0 lladdr 00:50:56:84:e7:fa REACHABLE root@SS-gateway-1:~#
ip a (ipaddr):
root@SS-gateway-1:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 4096 link/ether 00:50:56:84:a0:09 brd ff:ff:ff:ff:ff:ff inet 13.1.1.1/24 brd 13.1.1.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:fe84:a009/64 scope link valid_lft forever preferred_lft forever 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:84:a6:ab brd ff:ff:ff:ff:ff:ff inet 101.101.101.1/24 brd 101.101.101.255 scope global eth1 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:fe84:a6ab/64 scope link valid_lft forever preferred_lft forever 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 00:50:56:84:bc:75 brd ff:ff:ff:ff:ff:ff inet 192.168.0.201/24 brd 192.168.0.255 scope global eth2 valid_lft forever preferred_lft forever inet6 fe80::250:56ff:fe84:bc75/64 scope link valid_lft forever preferred_lft forever 6: gwd1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 4096 link/none inet 169.254.129.1/32 scope global gwd1 valid_lft forever preferred_lft forever inet6 fe80::27d5:9e46:e7f7:7198/64 scope link stable-privacy valid_lft forever preferred_lft forever root@SS-gateway-1:~#
ip link
root@SS-gateway-1:~# ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 4096 link/ether 00:50:56:84:a0:09 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 00:50:56:84:a6:ab brd ff:ff:ff:ff:ff:ff 4: eth2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 00:50:56:84:bc:75 brd ff:ff:ff:ff:ff:ff 6: gwd1: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 4096 link/none root@SS-gateway-1:~#

Upgrade Considerations

Note: The below steps are based on the assumption that you want to keep the same IP address and Gateway name for the new Gateway deployed in the 4.0 release. However, if you want to create a new Gateway with a different IP address and, you can follow the new Gateway procedures.

Due to substantial changes to the disk layout and system files, an in-place upgrade is not possible from older releases to the 4.0 release. The migration will require deploying new 4.0 Gateway systems and decommissioning systems running older code.

For VPN Gateways or NAT Gateways with well-known public IP addresses, adhere to the following procedure below if the public IP of the Gateway must be preserved.

Procedure: (VNP or NAT Gateways with Well-Known Public IP Addresses)

  1. Launch the new Gateway system based on the 4.0 release image. Refer to the deployment guide for your platform for additional information (Gateway Installation Procedures).
  2. Shutdown the old Gateway system. (Bring down the old Gateway VM (either by running the sudo poweroff command on the CLI console, or by powering off from the available Hypervisor options).
  3. Migrate the public IP to the new system: update the NAT record to point to the new Gateway system, or configure the public IP on the new Gateway network interface. Deploy the new Gateway with the Cloud-int examples given above using the same IP address as the previous Gateway.
  4. Obtain the activation key from the existing Gateway record in the Orchestrator (as described in the steps below).
    1. From the Orchestrator, go to Gateway Management > Gateways .
    2. On the Gateways screen, select the Gateway for which you to obtain the activation key and select the right arrow before the Gateway name.
    3. An information box expands and you can find the activation key at the bottom, as shown in the image below.
      Figure 1. Gateways
  5. Set the following system property gateway.activation.validate.deviceId to False, as shown in the image below. Refer to the System Properties section in the VeloCloud SD-WAN Operator Guide, if necessary for additional information.
    Figure 2. System Properties
  6. Re-activate the new Gateway system: from the CLI console run: sudo /opt/vc/bin/activate.py -s <vco_address> <activation_code>
  7. Restore the following system property gateway.activation.validate.deviceId to the original value (if necessary).

    The Gateway is now registered and ready to receive a connection from the Edges.

    Note: The Gateway reactivation can be performed via Cloud-int, as discussed in the User Data section in this document.

    Activation Example Output

    root@gateway/opt/vc# /opt/vc/bin/activate.py FLM6-CSV6-REJS-XFR5 -i -s 169.254.8.2

    Activation successful, VCO overridden back to 169.254.8.2 root@SS1-gateway-2:/opt/vc#.

Gateways Without Well-known Public IPs

This section is only for Gateways without a well-known public IP, such as, VPN Gateways. If this scenario applies, follow the procedure below.

Gateways Without Well-known Public IPs)

  1. Launch a new Gateway system. Refer to the deployment guide for your platform if necessary (Gateway Installation Procedures).
  2. Activate a new Gateway system.
  3. Add new Gateway to the Orchestrator Gateway pool. Refer to the Gateway Management section in the Arista VeloCloud SD-WAN Operator Guide for additional details.
    1. The Gateway is now registered and ready to receive a connection from the Edges.
  4. Remove the old Gateway from Orchestrator Gateway pool. Refer to the Manage Gateways section in Arista VeloCloud SD-WAN Operator Guide for additional information.
  5. Decommission the old Gateway VM. (Remove the Gateway record from the Orchestrator and decommission the VM instance).

Obtaining Gateway Activation Key Via API

To deploy using the API Method, use the following: network/getNetworkGateways.

Sample response:

{"jsonrpc":"2.0","result":[{"id":1, "activationKey":"69PX-YHY2-N5PZ-G3UW …

Configure Handoff Interface in Data Plane

To configure Handoff Interface in Data Plane, see Post-Installation Tasks.