We have been providing SURFlichtpaden for a long time. Up until now, these were always ethernet services with two endpoints. We had SURFlichtpaden in roughly four flavors; protected or redundant and on a Single Service Port (SSP, untagged) or Multi Service Port (MSP, tagged). Now, with the new SURF network, we can add new possibilities to the SURFlichtpaden. For example, we now offer a multipoint variant (or L2VPN) and there are more possibilities in the field of redundancy and resiliency. Read here what we have done so far and what we plan to do.

SURF light paths have always met a need to connect institutions, or dislocations of an institution, with each other. SURF light paths are therefore often used for research purposes or for internal business operations. In recent years, connections with cloud providers of all shapes and sizes have also been added, such as IaaS, SaaS, CaaS, DaaS; in short, *aaS. Business operations with *aaS providers often require a high degree of service availability. That is why light paths have become quite popular for that purpose.

However, light paths have a number of limitations. Firstly, they are Point-2-Point. That provides control, but can also become complex if you want to connect many locations or networks with each other, because many individual light paths are required. In addition, it is difficult if you want to extend redundant VLANs to a cloud provider via such light paths. That causes a major risk of Ethernet loops, which can cause network instability. We could not offer a good solution for this in SURFnet7.

With the migration of SURFnet7 to the new SURF network, we have switched from PBB-TE to EVPN over MPLS. EVPN is a technology that is fully based on IP and Ethernet networks. This also provides new opportunities to evolve our light path services to the current times and needs of the connected institutions.

So what’s new?

The migration to the new SURF network is now almost complete. If you have MSPs (Multi Service Ports) that have already migrated to the new SURF network, we can now offer multipoint light paths (L2VPNs) there. Suppose you have a VLAN running over the light path between two locations, you can now easily add a third location. This way you have three locations connected to each other without having to build a whole tangle of light paths. Within the new SURF network, traffic always takes the most optimal route through the network.

To visualize the whole thing, we show in the example below how we want to connect three networks to each other over a VLAN with the MSPs. Each network (or location) is connected to one MSP. This means that no Ethernet loops can be created, because each location has one connection. But unfortunately there is no redundancy for business-critical applications. If something happens in this scenario, one or more locations can become isolated in the event of a malfunction or work.

Ideally, we would of course be able to connect each network/location to 2 MSPs, for more redundancy. But if we just do this, Ethernet loops are guaranteed to occur, resulting in disruptions. See the example below. Ethernet does not have a loop prevention mechanism by itself. As a result, when a loop occurs, packets continue to circulate endlessly until the loop is interrupted. In SURFnet7, we could therefore not offer such a scenario.

Within EVPN (the protocol used in the new SURF network for light paths and L2VPNs) there are a number of mechanisms that ensure that Ethernet loops can no longer occur. We can now offer one of these on the new SURF network: ‘Single-Active multihoming’ on a VLAN service. This allows us to configure a VLAN service on multiple MSPs at the same location. These MSPs are grouped in an ESI (Ethernet Segment Identifier) ​​and in this ESI only 1 port is active at any given time. When the active port goes down, the other port immediately becomes active and this new port will forward the traffic. During the setup, MAC learning will ensure that all MAC addresses move to the new active port. This happens in just 1-2 seconds. The figure below shows what that would look like. There you can see that 1 port in an ESI group is always active and there is a loop-free topology.

Possible use cases

The above is quite a technical story. It may come to life more if we explain some possible use cases.

EduVPN scenario

eduVPN is a VPN service from SURF to allow employees and students of an institution to work safely at home or remotely. We are currently testing whether we can make the eduVPN service more reliable using multihomed L2VPN, which adds more resilience to the eduVPN service. This scenario looks like this:

The eduVPN servers run in two data centers in Amsterdam and are connected to the institution with a light path. The eduVPN service can currently only exchange traffic between the institution and eduVPN using static routes. This makes it impossible to create a redundant scenario of this service using traditional light paths. This is possible using the ESI mechanism in the L2VPN.

The above scenario shows the eduVPN service at the top. The eduVPN server can be moved between data centers in the event of outages. In the eduVPN setting, resilience is achieved by using VRRP (or a variant of this, such as HSRP).

Twin data center plus cloud IaaS provider

When an institution has multiple data centers and also wants to use an IaaS provider, the use of an L2VPN can provide redundancy. This can be used to, for example, migrate services to the cloud provider or to outsource certain matters. This may create the need to be able to extend the VLANs in the data centers to the IaaS provider. This allows systems to be moved without having to be renumbered. Such a scenario could look like this:

Each data center is doubly connected and has 2 ports in an ESI group. This prevents loops and provides sufficient redundancy. The L2VPN can contain a bundle of VLANs.

You then get the scenario in figure 3. Where 1 of the locations can be a cloud provider

Future

With this functionality, we believe we have taken a step in the right direction to add functions to our lightpath services that can help institutions.

EVPN has even more possibilities that we can use to, hopefully, even better meet the needs of institutions.

Within the lightpath services, we also hope to be able to do link bundling based on LACP over multiple chassis (MC-LAG) in the future. Many institutions already use a form of Virtual Chassis or VSS for redundancy. MC-LAG could tie in nicely with this. This allows both interfaces that form an ESI to be active at the same time.

In addition, we are developing an L3VPN service. L3VPN is a virtual router that can be configured on SN8. This virtual router can be used, for example, to efficiently connect multiple cloud providers (MS Azure or Amazon AWS) to a setup network.

Do you have any ideas or questions about these new features and functionalities? Or do you have suggestions that can help us further develop the service? Then please contact me!