Skip to main content

Anapaya EDGE WAN connectivity

Every EDGE establishes one or more SCION links to an Anapaya CORE of a SCIONabled provider. A SCION link is not a physical connection, it runs over an IP underlay network: any network that provides bidirectional IPv4 or IPv6 UDP reachability between the two link endpoints can carry it. The options below are the common ways to provide that, from a dedicated circuit to the public Internet, rather than an exhaustive list.

First mile only

The WAN connectivity option affects the first mile only, i.e., the segment between the site and the CORE. Once traffic is on the SCION Internet, path control, multipathing, and sub-second failover apply end to end, independently of how a site is attached.

Options at a glance​

OptionFirst-mile SLARelative costTypical use
Direct ISP accessYesMediumReference case; sites served by a SCIONabled ISP
Private third-party accessYesHighSites or cloud regions without a local SCIONabled ISP
Peering at an IXPNoLowSites already present at an IXP
Internet-based accessNoLowestSites where the above are unavailable or disproportionate

The underlay is independent of the rest of the deployment. The deployment mode, the LAN integration, the SCION address space, the path policies, and the communication partners of an AS do not depend on how a first mile is carried, so a site can start with one option and move to another later without being redesigned.

Path diversity

An EDGE can hold links to COREs of several providers, and those links can use different underlays, which also improves path diversity.

Direct ISP access​

A SCIONabled ISP delivers SCION connectivity over the same access technology it already uses for its other services, for example Ethernet, MPLS, or a routed IP network. The EDGE receives a WAN interface on a dedicated VLAN or access circuit, and the SCION link runs over that circuit to the CORE of the provider.

This is the reference deployment and the recommended option: the first mile is a managed service with a contractual SLA on bandwidth, latency, and availability, and the EDGE WAN interface is not exposed to the public Internet. The constraint is availability, as SCIONabled access is not offered in every location. Sites that no SCIONabled ISP reaches use one of the other options.

Private third-party access​

Where no SCIONabled ISP reaches a site directly, the first mile can be carried by a private connection from a third party, such as a leased line, a network-as-a-service provider, or a cloud interconnect into a hyperscaler region. The SCION link then runs over that connection to a CORE in a location the provider does reach.

The characteristics are comparable to direct ISP access, including a contractual SLA, and this option extends SCION reach to sites and cloud regions that are otherwise unreachable. The trade-off is cost: dedicated circuits and cloud interconnects are the most expensive option in this list, and for small sites the connectivity cost can exceed the cost of the SCION service itself.

Peering at an IXP​

At an Internet Exchange Point (IXP), the EDGE is connected to the exchange fabric and establishes SCION links to one or more COREs reachable there. The peering LAN of the IXP is the IP underlay network of those links, which all share a single network interface as described in Multiple SCION interfaces per network interface.

This is inexpensive relative to a dedicated circuit and flexible: a single connection at the exchange allows SCION links to several COREs, including COREs of different providers, which improves path diversity without additional circuits. The first mile does not traverse the wider Internet, but there is no SLA on the exchange fabric, and the EDGE is reachable from the peering LAN, therefore slightly more exposed than with a dedicated circuit.

Internet-based access​

The SCION link runs over an existing Internet connection to a publicly reachable CORE of the provider. Neither a new circuit nor a new provider relationship is required, which makes this the fastest and cheapest way to attach a site, and sometimes the only practical option for remote sites, small branches, and cloud environments where a private interconnect is disproportionate. The consequences of that choice are described in Properties of an Internet-based first mile.

Two underlay variants are available.

Direct public IP underlay​

The SCION link is established directly between the public IP address of the EDGE and the public IP address of the CORE of the provider. This is the default variant: it has the lowest overhead and is easiest to operate. It requires a static public IP address on the CORE as well as on the customer site where the EDGE is deployed.

Tunnel underlay​

The SCION link runs inside a tunnel to the CORE of the provider. Anapaya appliances support this natively with WireGuard interfaces. Where a different tunnel technology is required, for example IPsec on an existing VPN gateway, the tunnel is terminated on that device. Use this variant in either of two cases:

  • NAT traversal. The site has no static public IP address, or the EDGE is behind a NAT device or a firewall that does not permit the required inbound UDP traffic. The tunnel is established outbound, so no inbound reachability is needed.
  • Encryption of the first mile itself, including the SCION headers and the control-plane traffic.

The cost is encapsulation overhead, which reduces the usable MTU and can impact performance.

Encrypt at the higher layer

Protecting payload traffic is not a reason to choose a tunnel underlay. EDGE-to-EDGE encryption protects traffic end to end across the SCION Internet rather than only on the first mile, and requires no per-link key management.

Properties of an Internet-based first mile​

Performance and availability​

The first mile inherits the latency, jitter, packet loss, and availability of the Internet connection and is not covered by an SLA. For latency-sensitive or high-availability workloads this is usually the deciding factor.

Attack surface​

With a direct public IP underlay, the EDGE WAN address is reachable from the Internet and is exposed to scanning and volumetric attacks like any other Internet-facing device. Restrict this with the firewall configuration of the appliance, so that the WAN interface only accepts underlay traffic from the CORE of the provider.

Routing security​

Traffic on the SCION Internet is not subject to BGP route hijacking, but the first-mile segment of an Internet-based connection is ordinary BGP-routed traffic and does not benefit from that protection. Peering at an IXP, or an arrangement where the EDGE is a single BGP hop from the CORE, removes this exposure while keeping most of the cost advantage.

NAT, firewalls, and redundancy​

The underlay requires bidirectional UDP connectivity between the EDGE and the CORE of the provider, and no intermediate device may rewrite or rate-limit that traffic.

A single Internet connection can carry several SCION links to different COREs, of the same or of different providers, as the SCION interfaces share one network interface and differ only in their UDP port. This adds path diversity and protects against the failure of an individual CORE without requiring an additional uplink.

It does not, however, make the first mile redundant: all those links fail together with the Internet connection. Redundant EDGEs likewise improve availability only to the extent that their underlays are independent. Where first-mile redundancy matters, use uplinks of different providers, or combine an Internet-based link on one appliance with a dedicated circuit on the other.

How to choose the right WAN connectivity option​

  1. Is a SCIONabled ISP available at the site?

  2. Is the site present at an IXP where COREs are reachable?

  3. Does the workload require an SLA or predictable latency on the first mile?

The WAN connectivity option determines the underlay parameters of a SCION link, not how the link itself is configured. Refer to Configure a SCION link for the parameters to agree with the provider and the configuration procedure, and to the deployment examples for complete configurations of the individual deployment modes.