Network Interfaces¶

The physical and/or virtual network interfaces of the appliance are configured in the interfaces section of the appliance configuration. Note that these network interfaces are different from the SCION interfaces - a SCION interface is a purely logical interface that always binds to a physical or virtual network interface, usually a WAN interface. In addition to WAN interfaces, an appliance can have multiple LAN interfaces.

All interface types have standard configuration properties, such as the addresses assigned to the interface, routes specific to the interface, mtu, etc. The gateway field must only be set on one interface. It is a shortcut to configure the default routes 0.0.0.0/0 and/or ::/0 on a particular interface. If a custom metric or from is necessary for the default route, configure it using the routes section instead.

Additionally, most interface types can be configured to be part of a virtual router using the Virtual Router Redundancy Protocol (VRRP). For more details about the exact configuration entries for each interface type, please refer to the Appliance Management API specification.

There is a wide range of network interface types supported:

Ethernet Interfaces¶

An Ethernet interface is a physical network interface. Availability depends on the platform the appliance runs on. Please consult the platform documentation to find out what physical interfaces are available. Alternatively, the /api/v1/network/physical-interfaces API endpoint can be used to retrieve the available physical interfaces.

The interface driver can be explicitly configured. The following options are available:

LINUX: The interface is bound by Linux with the native driver. This driver should be selected for management interfaces, or if there is no DPDK driver support in VPP for the physical interface (e.g., old hardware or WIFI interfaces). Using this driver for management interfaces is strongly recommended to guarantee management access even if the performance optimized dataplane is misbehaving.
VPP_DPDK: The interface driver is bound by VPP with the bundled DPDK driver. This driver is optimized for performance and should be selected for interfaces that service dataplane traffic whenever possible. With this driver, you might also need to configure the vlan-strip-offload mode based your configuration. See the VPP documentation for more information.
VPP_VMXNET3: Same as VPP_DPDK but for VMXNET3 interfaces. This driver is only available on VMware ESXi hosts.
VPP_MEMIF: This driver can be used to communicate over shared memory with another client using memif. This driver is only available on Linux hosts and unless you know what you are doing, you should not use this driver.

Note

If you are using virtio interfaces, please consult the Virtio Network Interfaces user guide.

If no driver is configured, the default driver is VPP_DPDK.

Separate LAN, WAN and management interfaces

{
  "ethernets": [
    {
      "addresses": [
        "10.10.0.2/24"
      ],
      "name": "lan",
      "gateway": {
        "ipv4_gateway": "10.10.0.1"
      },
      "driver": "VPP_DPDK"
    },
    {
      "addresses": [
        "169.254.10.2/30"
      ],
      "name": "wan",
      "driver": "VPP_DPDK"
    },
    {
      "addresses": [
        "192.168.1.2/24"
      ],
      "name": "mgmt",
      "driver": "LINUX"
    }
  ]
}
This examples shows a configuration for an appliance with three physical interfaces:

Interface lan configures the LAN access with the address 10.10.0.2. We also configure the IPv4 gateway on this interface via 10.10.0.1. This means that a default route 0.0.0.0/0 via 10.10.0.1 is installed. The interface driver is VPP for performance, and we will use this interface to deliver traffic towards the AS internal network.

Interface wan configures the WAN access with the link-local address 169.254.10.2. The interface driver is VPP for performance, and we will use this interface to deliver traffic towards the neighboring AS.

Interface mgmt configures the management access with the address 192.168.1.2. Because we use this interface for management, we do not bind it in VPP and use the LINUX driver. We will use this interface for management traffic, e.g., to interact with the management API.

Virtual Functions¶

A Virtual Function (VF) is a virtual network interface that can be configured on top of a physical interface supporting SR-IOV. Please consult the platform documentation to find out if and which interfaces support the creation of VFs. A VF is always bound to a physical interface that is configured in the interfaces.ethernets section (specified by the link property). This interface must use the LINUX driver.

Virtual Function

{
  "ethernets": [
    {
      "name": "ens1",
      "driver": "LINUX"
    }
  ],
  "virtual_functions": [
    {
      "addresses": [
        "169.254.10.2/30"
      ],
      "link": "ens1",
      "name": "ens1vf0"
    }
  ]
}

This example shows a configuration for an appliance with a physical interface that supports SR-IOV. The ens1vf0 VF on top of this interface.

VLAN Interfaces¶

A VLAN interface is a logical interface that is bound to an underlying network interface. A VLAN interface can be configured on top of ethernets, virtual_functions and bonds. The underlying network interface is specified by the link property. The name of the VLAN interface must be of the form <link>.<id>, e.g., eth0.42 where eth0 is the name of the physical interface, and 42 is the VLAN ID.

VLAN

{
  "ethernets": [
    {
      "name": "eth0",
      "driver": "VPP_DPDK"
    }
  ],
  "vlans": [
    {
      "addresses": [
        "169.254.10.2/30"
      ],
      "link": "eth0",
      "name": "eth0.42"
    }
  ]
}

This example shows a configuration for an appliance with a VLAN interface on the ethernet interface eth0 with the VLAN ID 42.

Bond Interfaces¶

A bond interface groups multiple network interfaces together to a single logical network interface. Bonding can offer performance improvements and increased redundancy. A bond can only consist of ethernet interfaces. Additionally, all ethernet interfaces that are part of a bond must use the VPP driver.

Bond

{
  "bonds": [
    {
      "addresses": [
        "169.254.10.2/30"
      ],
      "interfaces": [
        "eno5",
        "eno6"
      ],
      "name": "bond0"
    }
  ],
  "ethernets": [
    {
      "name": "eno5",
      "driver": "VPP_DPDK"
    },
    {
      "name": "eno6",
      "driver": "VPP_DPDK"
    }
  ]
}

This example shows a configuration of an appliance that bonds two interfaces together. The bond is created over two virtual functions.

Loopback Interfaces¶

A loopback interface is a logical network interface that a host can use to communicate with itself. Each loopback interface must be configured with a list of IP prefixes and the name of the interface must start with loop, e.g., loop0. Note that a default loopback interface with IP prefixes 127.0.0.0/8 and ::1/128 is automatically created for each appliance host and must not be configured.

Loopback interfaces can be useful in various scenarios. We will mention two examples here:

In a single appliance setup where you do not need the SCION services to be reachable from the internal network, you can configure a loopback and use it for the SCION control and router addresses. Even if the SCION services are not reachable from the outside, you can still configure the appliance to provide IP-in-SCION tunneling between your internal network to the remote SCION ASes.
You might want the SCION services of an appliance to be reachable via multiple interfaces for redundancy on the network interface level. In that case, you can configure a loopback and bind the SCION services to that address. This can be paired with BGP such that the chosen loopback address is announced to the internal network. If no dynamic routing protocol is used, you will need to install the routes appropriately in the internal network.

Loopback

{
  "loopbacks": [
    {
      "addresses": [
        "10.10.0.1/32"
      ],
      "name": "loop0"
    }
  ]
}

Wireguard Interfaces¶

A wireguard interface is a virtual network interface using the WireGuard protocol to establish a secure tunnel to other wireguard peers. When configuring a wireguard interface, the appliance automatically generates a private key and a public key. The public key is then exposed in the configuration as the public_key property of wireguard interface entry, which you can request via the Appliance Management API.

To add a new wireguard peer, a peer entry needs to be configured containing the network endpoint of the form host:port as well as the public key of the peer.

Wireguard

{
  "wireguards": [
    {
      "addresses": [
        "10.10.0.1/32"
      ],
      "name": "wg0",
      "port": 51021,
      "peers": [
        {
          "endpoint": "10.10.0.1:51021",
          "public_key": "<public key>"
        }
      ]
    }
  ]
}