Last week SURFs network automation team spent a fruitful week in Berkeley (CA) together with colleagues from ESnet and Géant. As workflow orchestrator partner members, SURF, ESnet and Géant are committed to the workflow orchestrator software ecosystem and collaborate on creating a useful set of tools for parties who are interested in automating their network.
First codesprint
As users of the orchestrator software we share the need to continuously improve and add more features. The coming year SURF, ESnet and Geant plan to execute 12 sprints to work on the backlog of issues. This will be done by forming a (virtual) team of software engineers who will together work on issues that have been identified as important. The codesprint represents an important step in sharing knowledge and kickstarting this process.
Results
The codesprint results in a nutshell:
22 issues closed with a combined issue weight of 45
7 issues in progress with a total weight of 23
2 releases including one Major release candidate. version 2.10, version 3.0.0rc1
Traditionally, the Netherlands has been an important digital hub in Europe. Sea cables landed in the Netherlands and made Amsterdam a digital hub. That had enormous appeal for parties that need a strong digital network, such as education and research. The leading position that the Netherlands has had for a long time is now under pressure. Why is that? Why is it bad if we lose that position? And what will it take not to lose this important position?
Listen to this episode (in Dutch) of SURFsounds with Peter van Burgel, CEO of Amsterdam Internet Exchange (AMS-IX) and Alexander van der Hil, international policy and strategy advisor at SURF.
Last summer, a huge transition was implemented under the hood of the Network Dashboard. At first glance, little seems to have changed, but especially if you click around, you will now notice that it works much faster. The major overhaul of the network dashboard had been on our wish list for a long time, because the complex authorization rules made the Network Dashboard feel like an old diesel at times (or even slower!).
The architecture of the Network Dashboard has been completely overhauled by no longer collecting all data from different systems (orchestrator/ipam/CMDB/CRM/jira) in real time, but by preparing all static data in advance in a document in the replica set. As a result, we only have to make a few very fast calls instead of 500 separate API calls. Only the traffic graphs and health status of the services are now retrieved live from the influx database.
How quickly is such a replica set updated?
The preparation of these documents in the replica set is triggered with every change to a subscription that the Workflow Orchestrator (see workfloworchestrator.org) executes on a service. The replica is also refreshed every night. This allows us to guarantee the data integrity between the orchestrator and the replica set. Only in the case of real-time changes on the network or due to self-service actions will the replica set briefly lag behind the actual state as recorded in the Workflow Orchestrator. For example, adjusting a customer alias is not immediately visible in the network dashboard, but must be processed in the replica set. Simple changes take ~4 seconds, while larger changes can take many times longer on average. At the moment we are still working on improving the automatic refresh of the pages after self-service actions, until then you will have to manually refresh a page after a change to see the latest up-to-date information.
SURFdomeinen will be available in the network dashboard early next year. Due to the complex migration of domain names and zones, this will be carried out in phases. The product manager of SURFdomeinen will communicate about this in due time.
Finally, we have introduced a new look-and-feel with a renewed landing page, on which all network services of the standard network portfolio are clearly presented in one tile.
As of January 2024, the names of the network services will change. We are doing this to better align our services with the terms and conventions used in the network community. We hope that this will make it clearer to network administrators which services are provided.
Current service name
New service name per 1 Jan 2024
SURFlichtpad
EVPN – Point-to-point
SURFlichtpad – Redundant
EVPN – Point-to-point Redundant
L2VPN
EVPN – Multipoint
L3VPN
L3VPN – Multipoint
SURFinternet
Internet
Multi Service Poort (MSP)
Service Port
Lightpath becomes EVPN
The term lightpath, although well established in SURF language, has always caused some confusion. This is not an optically illuminated path but a dedicated network connection over the service layer between two points. EVPN (Ethernet-VPN) is what is provided here and the addition (Point to point vs Multipoint) indicates whether it is set up between two points or more than two points.
Multi Service Port becomes Service Port
Under the new All-In Network Tariff, which came into effect on September 1, 2023, institutions can adjust their network port configuration as they see fit. This effectively makes all the network ports “multi” service ports. That is why they will simply be called Service Port from 2024.
The changed names have been implemented in the network dashboard, on (mijn)surf.nl and on invoices.
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.
Figuur 1: niet redundant L2VPN
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.
Figuur 2 Ethernet loops in een redundant L2VPN
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.
Figuur 3 Loop preventie mbv single-active multihoming in L2VPN
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.
Figuur 4 Usecase EduVPN
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.
Figuur 5 Multi-chassis link aggregation
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.
Figuur 6 L3VPN multicloud voorbeeld
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!
