Lichtpaden 2.0

SURFlichtpaden hebben altijd een behoefte ingevuld om instellingen, of dislocaties van een instelling, met elkaar te verbinden. SURFlichtpaden worden dan ook vaak ingezet voor onderzoeksdoeleinden of voor de interne bedrijfsvoering. De laatste jaren zijn daar ook verbindingen met cloudproviders in alle soorten en maten bij gekomen, denk aan IaaS, SaaS, CaaS, DaaS; kortom *aaS. Voor bedrijfsvoering met *aaS-providers is vaak een hoge mate van beschikbaarheid van diensten noodzakelijk. Daarom zijn lichtpaden met dat doel behoorlijk populair geworden.

Maar lichtpaden hebben een aantal beperkingen. Ten eerste zijn ze Point-2-Point. Dat geeft controle, maar kan ook complex worden als je veel locaties of netwerken met elkaar wilt verbinden, omdat er veel individuele lichtpaden nodig zijn. Daarnaast is het lastig wanneer je over dergelijke lichtpaden redundante VLAN’s wilt doortrekken naar een cloudprovider. Dat veroorzaakt een groot risico op ethernet-loops, wat instabiliteit van het netwerk kan veroorzaken. Hier konden we in SURFnet7 geen goede oplossing voor bieden.

Met de migratie van SURFnet7 naar het nieuwe SURF-netwerk zijn we overgestapt van PBB-TE naar EVPN over MPLS. EVPN is een technologie geheel ge-ent op IP en ethernet-netwerken. Hierdoor heeft het ook nieuwe mogelijkheden om onze lichtpad-diensten door te evolueren naar de huidige tijd en behoeften van de aangesloten instellingen.

Wat is er dan nieuw?

Inmiddels is de migratie naar het nieuwe SURF-netwerk bijna afgerond. Heb je MSP’s (Multi Service Ports) die al naar het nieuwe SURF-netwerk zijn gemigreerd, dan kunnen wij daar nu multipoint lichtpaden aanbieden (L2VPN’s). Stel dat je een VLAN over het lichtpad hebt lopen tussen twee locaties, dan kun je er nu eenvoudig een derde locatie aan toevoegen. Zo heb je drie locaties met elkaar verbonden zonder dat dat een hele wirwar aan lichtpaden moet bouwen. Binnen het nieuwe SURF-netwerk netwerk neemt het verkeer ook altijd de meest optimale route door het netwerk.

Om het geheel te visualiseren laten we in het onderstaande voorbeeld zien hoe we drie netwerken met elkaar willen verbinden over een VLAN met de MSP’s. Ieder netwerk (of locatie) is verbonden met één MSP. Er kunnen daardoor geen ethernet-loops ontstaan, omdat elke locatie één koppeling heeft. Maar voor bedrijfskritische toepassingen is er helaas geen redundantie. Wanneer er iets gebeurt in dit scenario kunnen één of meerdere locaties bij een storing of werkzaamheden geïsoleerd raken.

Liefst zouden we natuurlijk ieder netwerk/locatie kunnen aansluiten op 2 MSP’s, voor meer redundantie. Maar wanneer we dit zomaar doen, ontstaan er gegarandeerd ethernet-loops., met verstoringen als gevolg. Zie hiervoor onderstaand voorbeeld. Ethernet heeft uit zichzelf geen looppreventie-mechanisme. Met als gevolg dat wanneer een loop ontstaat, pakketten eindeloos blijven rondzingen tot de loop onderbroken wordt. In SURFnet7 konden we een dergelijk scenario daarom niet aanbieden.

Binnen EVPN (het protocol wat in het nieuwe SURF-netwerk gebruikt wordt voor lichtpaden en L2VPN’s) bestaan een aantal mechanismen die ervoor zorgen dat ethernet-loops niet meer kunnen ontstaan. Eén daarvan kunnen we nu aanbieden op het nieuwe SURF-netwerk: ‘Single-Active multihoming’ op een VLAN-service. Hiermee kunnen we een VLAN-service configureren op meerdere MSP’s op dezelfde locatie. Deze MSP’s worden gegroepeerd in een ESI (Ethernet Segment Identifier) en in deze ESI is altijd maar 1 poort actief. Wanneer de actieve poort down gaat wordt onmiddellijk de andere poort actief en deze nieuwe poort zal het verkeer forwarden. Bij de instelling zal MAC-learning ervoor zorgen dat alle MAC-adressen verplaatsen naar de nieuwe actieve poort. Dit gebeurt in slechts 1-2 seconden. In onderstaande figuur zie je hoe dat er uit zou zien. Daar zie je dat steeds 1 poort in een ESI-groep actief is en er een loopvrije topologie bestaat.

Mogelijke use cases

Nu is bovenstaande een vrij technisch verhaal. Mogelijk gaat het meer leven wanneer we wat mogelijke use cases toelichten.

EduVPN scenario

eduVPN is een VPN-dienst van SURF om medewerkers en studenten van een instelling thuis of op afstand veilig te laten werken. Op dit moment zijn we aan het testen of we de eduVPN-dienst betrouwbaarder kunnen maken met behulp van multihomed L2VPN, dat meer resiliance toevoegt op de eduVPN dienst. Dit scenario ziet er als volgt uit:

De eduVPN-servers draaien in twee datacenters in Amsterdam en worden met een lichtpad verbonden met de instelling. De eduVPN-dienst kan op dit moment alleen maar met statische routes verkeer uitwisselen tussen de instelling en eduVPN. Hierdoor is het niet mogelijk om met traditionele lichtpaden een redundant scenario te maken van deze dienst. Met gebruik van het ESI-mechanisme in de L2VPN kan dit wel.

Bovenstaand scenario laat bovenin de eduVPN-dienst zien. De eduVPN-server kan bij outages verplaatst worden tussen datacentra. Bij de eduVPN -instelling wordt resilience bereikt door het gebruik van VRRP (of een variant hierop, zoals HSRP).

Twin datacenter plus cloud IaaS provider

Wanneer een instelling meerdere datacentra heeft en ook gebruik wil maken van een IaaS-provider, kan het gebruik van een L2VPN redundantie bieden. Dit kan gebruikt worden om bijvoorbeeld services naar de cloud provider te migreren of om bepaalde zaken uit te besteden. Hierdoor kan de behoefte ontstaan om de VLAN’s in de datacentra door te kunnen trekken naar de IaaS provider. Hierdoor kunnen systemen verplaatst worden zonder dat er omgenummerd hoeft te worden. Een dergelijk scenario zou er als volgt uit kunnen zien:

Ieder datacenter is dubbel aangesloten en heeft 2 poorten in een ESI-groep. Hierdoor ontstaan er geen loops en is voldoende redundantie. De L2VPN kan een bundel van VLAN’s bevatten.

Je krijgt dan het scenario in figuur 3. Waarbij 1 van de locaties een cloudprovider kan zijn

Toekomst

Met deze functionaliteit denken we een stap in de goede richting te hebben gezet om functies toe te voegen aan onze lichtpad-diensten die instellingen kunnen helpen.

EVPN kent nog meer mogelijkheden die wij kunnen benutten om, hopelijk, nog beter aan te sluiten bij de behoeften van instellingen.

Binnen de lichtpad-diensten hopen wij in de toekomst ook nog link-bundeling te kunnen doen op basis van LACP over meerdere chassis’ (MC-LAG). Veel instellingen gebruiken al een vorm van Virtual-Chassis of VSS voor redundantie. MC-LAG zou hier mooi op aan kunnen sluiten. Hierdoor kunnen beide interfaces die een ESI vormen tegelijk actief zijn.

Daarnaast zijn we bezig met het ontwikkelen van een L3VPN dienst. L3VPN is een virtuele router die op SN8 geconfigureerd kan worden. Deze virtuele router kan bijvoorbeeld gebruikt worden om meerdere cloud providers (MS Azure of Amazon AWS) op efficiënte wijze met een instellingsnetwerk te koppelen.

Heb je ideeën of vragen over deze nieuwe mogelijkheden en functionaliteiten? Of heb je suggesties die ons kunnen helpen de dienst verder te ontwikkelen? Neem dan contact met mij op!