Tag: network

  • SURF netwerk blijft vernieuwen: intelligent, onafhankelijk en flexibel

    SURF netwerk blijft vernieuwen: intelligent, onafhankelijk en flexibel

    SURF bouwt aan een nieuwe generatie van het SURF-netwerk. Dit doen we met een nieuwe netwerkarchitectuur en de doorontwikkeling van de netwerkautomatisering stack naar een intelligent netwerk. Het netwerk is gebaseerd op open standaarden en de inkoop van netwerkapparatuur gaat via een intermediair.

    Digitale snelweg in Nederland

    Met het SURF-netwerk beschikt het Nederlandse onderwijs en onderzoek over een eigen autonome netwerkinfrastructuur. In lijn met onze publieke waarden bepalen we zelf de toegankelijkheid, keuzevrijheid en privacy op ons netwerk. Al sinds 1988 bouwen we op basis van deze uitganspunten aan deze eigen digitale snelweg, bedoeld voor onafhankelijk en betrouwbaar onderzoek en het delen van kennis.

    Het SURF-netwerk heeft verschillende kenmerken waarmee studenten, docenten en onderzoekers wereldwijd veilig, betrouwbaar en razendsnel kunnen samenwerken. Dat komt door de hoge continuïteit en betrouwbaarheid van het SURF-netwerk, dat simpelweg altijd beschikbaar moet zijn. Ook heeft het SURF-netwerk een hoge bandbreedte voor het verplaatsen van grote hoeveelheden data. De lage latency zorgt voor een minimale reistijd tussen versturen en ontvangen van gegevens binnen het netwerk. Bovendien zijn alle netwerkdiensten geïntegreerd met elkaar en werken we aan een goede integratie met andere SURF-diensten.

    Groei netwerkverkeer

    Al sinds het ontstaan van SURF groeit het internetverkeer jaarlijks met zo’n 29%. Bij onderzoeksprojecten ligt dit percentage soms nog hoger. Deze groei is één van de redenen waarom netwerktechnologie zich zo snel blijft ontwikkelen en waarom het SURF-netwerk elke 5 tot 8 jaar vernieuwd moet worden. De apparatuur veroudert snel en de vraag naar capaciteit blijft sterk toenemen.

    Nieuwe aanpak voor het SURF netwerk

    In 2024 zijn we gestart met het project voor de inrichting van een nieuwe generatie van het netwerk na SURFnet8. In eerdere generaties van het SURF-netwerk, van SURFnet1 tot SURFnet8, werd de architectuur sterk bepaald door de keuze van een leverancier van de netwerkapparatuur. Met de nieuwste generatie van het netwerk streeft SURF naar een leverancier van onafhankelijke architectuur. Op basis van open standaarden kunnen nieuwe technologieën worden toegepast op de plek waar het nodig is en kan het netwerk zich oneindig blijven doorontwikkelen. Vandaar ook dat deze nieuwe generatie niet SURFnet9 heet, maar SURFnet Infinity.

    Workflow Orchestrator

    De eerste stap voor deze nieuwe netwerkarchitectuur werd al gezet in 2018. Met de door SURF ontwikkelde Workflow Orchestrator op basis van open-sourcesoftware kunnen verschillende technologiedomeinen binnen het netwerk centraal aangestuurd worden. De Orchestrator zorgt ervoor dat taken in de juiste volgorde worden uitgevoerd en data correct wordt doorgegeven zodat bottlenecks worden voorkomen en betrouwbaarheid toeneemt. Hiermee is een solide basis gelegd voor de volgende stap: de verdere ontwikkeling naar een intelligent netwerk in SURFnet Infinity.

    Inkoop netwerkapparatuur via intermediair 

    De inkoop van netwerkapparatuur wordt georganiseerd via een intermediair. Op deze manier heeft SURF een grotere vrijheid voor het maken van technologiekeuzes en kunnen we bij de inkoop van netwerkapparatuur flexibeler en efficiënter inspelen op de netwerkbehoeften van onderwijs- en onderzoeksinstellingen, zonder gebonden te zijn aan één leverancier.

    Nieuwe netwerkarchitectuur SURFnet ∞

    In de nieuwe architectuur van het SURF-netwerk is een duidelijke hiërarchie en functiescheiding aangebracht tussen het transport van netwerkverkeer, het leveren van diensten aan eindgebruikers en de connectiviteit met het internet. Hiermee wordt capaciteitsmanagement gemakkelijker, wordt het netwerk voorspelbaarder, kunnen problemen makkelijker gedetecteerd en opgelost worden en kan het netwerk gerichter worden beveiligd. Ook wordt een belangrijk deel van het netwerkhart van een commercieel datacenter verhuisd naar het datacentrum van Nikhef. De 4 core locaties van het SURF-netwerk bevinden zich hiermee binnen de eigen coöperatie.

    De eerste apparatuur aangeschaft

    Na een uitgebreid selectieproces heeft SURF onlangs de apparatuur aangeschaft waarmee de nieuwe core- en borderfunctionaliteit kan worden gebouwd. Hiermee wordt direct de nieuwe architectuur van het SURF-netwerk verwezenlijkt.

    Voor de SURFnet Infinity netwerkinfrastructuur heeft SURF gekozen voor de Juniper PTX-serie, die nog krachtiger, compacter en energiezuiniger is dan de verouderde MX-serie die SURF gebruikt. Daarnaast werkt SURF samen met Salumanus als onafhankelijke leverancier van transceivers op basis van de OpenZR+-technologie. Deze combinatie maakt het mogelijk om routers rechtstreeks aan te sluiten op DWDM-infrastructuur, zonder gebruik van aparte optische apparatuur. Dit verlaagt niet alleen de kosten en het energieverbruik, maar vergroot ook de flexibiliteit en toekomstbestendigheid van het netwerk. Door te kiezen voor een onafhankelijke leverancier is de levensduur van de transceivers bovendien niet gekoppeld aan die van de routerhardware.

    Start doorontwikkeling SURFnet Infinity

    De doorontwikkeling van het SURF-netwerk begint met de vernieuwing van het hart van ons netwerk: de core en border routers. Samen met onze beheerpartner Quanza zijn we in de zomer van 2025 met de voorbereidingen gestart .

    Op 55 locaties door heel Nederland gaan we SURFnet8 apparatuur vervangen door nieuwe apparatuur. Het grootste deel van de aangesloten instellingen op het SURF-netwerk zal hier niets van merken. Voor de werkzaamheden nemen we rechtstreeks contact op met onze contactpersonen. Deze migratie loopt tot begin 2027. 

    Voor de internationale aansluitingen vervangen we in deze fase ook de NetherLight apparatuur en optimaliseren we onze Cross Border Fiber infrastructuur. In de jaren na 2027 plannen we de vervanging van de optische apparatuur die hoge capaciteit tussen netwerkcomponenten faciliteert, en ook de accesslaag waarop alle instellingen zijn aangesloten. 

    Meer weten over SURFnet Infinity?

    Volg dit project op deze pagina.  
    Ook op het netwerkdashboard plaatsen we regelmatig projectupdates.  
    Ben je netwerkspecialist? Schrijf je dan in voor de updates over het project SURF-netwerk Infinity.  

  • Hoogtepunten van Internet2 TechEx 2025

    Hoogtepunten van Internet2 TechEx 2025

    Op Internet2 TechEx 2025 stond de wereldwijde ontwikkeling van de netwerkinfrastructuur voor onderzoek en onderwijs (R&E;) hoog op de agenda. In een drukbezochte update gaf Brenna Meade (International Networks, Indiana University) een overzicht van de belangrijkste stappen die wereldwijd worden genomen om de capaciteit, veerkracht en automatisering van federatieve netwerkdiensten te vergroten.

    Grote verbeteringen in capaciteit, zoals verbindingen over de oceaan

    Meade vertelde over allerlei upgrades die nu gebeuren en gepland zijn voor internationale backbone- en exchange-infrastructuren. Dit omvatte nieuwe transoceanische verbindingen van 400 Gbps, die superbelangrijk zijn voor data-intensief onderzoek en samenwerking tussen continenten. Ze benadrukte ook de activiteiten en voortdurende ontwikkeling van meerdere Global Exchange Points (GXP’s), waaronder FUJI-XP, SOE, GOREX, MANLAN, MOXY, NetherLight en Pacific Wave. Samen vormen deze hubs een belangrijke basis voor hoogwaardige wereldwijde connectiviteit tussen R&E-netwerken.

    NSI is klaar om te beginnen met de productie

    Een belangrijke mijlpaal die tijdens de sessie werd benadrukt: NSI (Network Service Interface) is nu klaar voor productie. NSI maakt het mogelijk om diensten op een automatische manier en over verschillende netwerkdomeinen heen te leveren. In de praktijk betekent dit dat organisaties en netwerken op een gestandaardiseerde manier end-to-end-diensten kunnen aanvragen, opzetten en beheren over meerdere administratieve grenzen heen.

    Voor NREN’s sluit dit goed aan bij de vraag naar schaalbare, federatieve connectiviteit: minder handmatige coördinatie, snellere levering van diensten en meer herbruikbare interfaces en operationele afspraken tussen domeinen. Het bereiken van productiegereedheid is dus een concrete stap naar meer geautomatiseerde en betrouwbare internationale netwerkservice-ecosystemen.

    Technologie – en de mensen erachter

    Naast het technische programma blijft TechEx een toffe plek om elkaar te ontmoeten. Door even bij te praten tussen de sessies door, ervaringen uit te wisselen over verschillende werkomgevingen en sociale activiteiten zoals de 5 km-loop, worden het vertrouwen en de relaties versterkt die nodig zijn om een sterke infrastructuur op te bouwen en te runnen.

    Kortom: TechEx 2025 liet zien hoe wereldwijde R&E-netwerken vooruitgang boeken op het gebied van zowel capaciteit als automatisering, waarbij NSI een belangrijke stap zet in de richting van interoperabele, gefedereerde dienstverlening.

    Screenshot
  • Onderwijs Kampioenschap patchen

    Het eerste Onderwijs Kampioenschap patchen op het SURF Netwerk en cloud event 2025 was een groot succes!

    Ruim Tien deelnemers deden een gooi naar de titel patchmaster. Er was serieuze strijd en een eindtijd die steeds scherper kwam te staan met Dimitry Schoenmakers van de Tilburg University als uiteindelijke winnaar!

    Dimitry hartelijk gefeliciteerd met de wisselbeker! 

    Ben je ook lid van SURF en wil je ook een keer jouw patching skills te laten zien en ga jij er de volgende keer met de wisselbeker vandoor? Sluit je dan aan bij de sign community! https://communities.surf.nl/sign/about

    De Beeldredaktie / Sander Koning t.b.v SURF Hilversum d.d. 30.09.2025 SURF Netwerk & Cloud Event 2025 in Gooiland Hilversum Foto copyright – Sander Koning
    De Beeldredaktie / Sander Koning t.b.v SURF Hilversum d.d. 30.09.2025 SURF Netwerk & Cloud Event 2025 in Gooiland Hilversum Foto copyright – Sander Koning
    De Beeldredaktie / Sander Koning t.b.v SURF Hilversum d.d. 30.09.2025 SURF Netwerk & Cloud Event 2025 in Gooiland Hilversum Foto copyright – Sander Koning
  • SURF bij het 6e Global Research Platform: Bouwen aan de toekomst van internationale onderzoeksnetwerken

    SURF bij het 6e Global Research Platform: Bouwen aan de toekomst van internationale onderzoeksnetwerken

    Chicago, september – Tijdens het 6e Global Research Platform (GRP) sloot SURF zich aan bij collega’s van over de hele wereld om vooruitgang te delen, inzichten uit te wisselen en de samenwerking in wereldwijde onderzoeksnetwerken te versterken.

    In mijn presentatie heb ik de volgende stappen van SURF belicht:

    • Updates over SURFnet Infinity en NetherLight
    • Terabit trials met CERN en tussen Snellius en de LUMI supercomputer in Kajaani
    • Ontwikkelingen in quantumveilige netwerken en fiber sensing

    Een terugkerend thema tijdens GRP was het belang van de gefedereerde aanpak: elke NREN bedient zijn eigen leden, maar samen vormen we een wereldwijde infrastructuur die onderzoek en onderwijs op schaal ondersteunt. Deze balans tussen lokale autonomie en internationale samenwerking is van vitaal belang voor het succes van de gemeenschap.

    Veel dank aan Joe Mambretti, Maxine Brown en de GRP gemeenschap voor het stimuleren van een open, collaboratieve omgeving. SURF kijkt ernaar uit om dit werk voort te zetten en de toekomst van internationale onderzoeks- en onderwijsnetwerken mee vorm te geven.

  • Hoe werkt privacyvriendelijke DNS-logging op de resolvers van SURFdomeinen?

    Om mogelijke aanvallen en besmettingen beter te kunnen detecteren en opsporen, is het handig om DNS-logging te kunnen doorzoeken. Omdat DNS-logs privacygevoelig zijn, heeft SURF een systeem ontwikkeld waarbij het mogelijk is om DNS-data met zo veel mogelijk behoud van privacy van de eindgebruikers te loggen. In deze blog leg ik uit hoe deze privacyvriendelijke DNS-logging technisch werkt.

    Aanleiding privacyvriendelijke DNS-logging

    Als een bij SURF aangesloten instelling getroffen is door een cyberaanval, willen andere instellingen weten of de daders mogelijk ook hun infrastructuur zijn binnengedrongen. Een van de bronnen om te raadplegen zijn DNS-logs: overzichten van domeinnamen die door eindgebruikers of systemen zijn opgevraagd. Veel instellingen gebruiken de DNS-servers van SURF via SURFdomeinen en daarvoor werden deze logs eerder niet vastgelegd. Op verzoek van de instellingen heeft SURF een systeem ontwikkeld om dit doen, maar met zo veel mogelijk behoud van privacy van de eindgebruikers.

    Privacy-by-design

    Hoewel de DNS-verzoeken nuttig kunnen zijn voor het beschermen van de gebruikers van het SURF-netwerk, zijn ze ook privacygevoelig. Ze laten bijvoorbeeld zien welke websites een gebruiker heeft bezocht. Het is daarom belangrijk om zorgvuldig met deze data om te gaan en een privacy-by-design-aanpak te volgen bij het beschikbaar stellen van DNS-logging.

    Om beveiligingsproblemen te detecteren hoeven we niet alle DNS-verzoeken van een individuele gebruiker te weten; we hoeven alleen te weten welke gebruikers een kwaadaardige domeinnaam hebben opgevraagd. We hebben daarom een systeem ontwikkeld waarbij we precies dit afdwingen met behulp van cryptografische technieken: het is alleen mogelijk om in de DNS-logging te zoeken op basis van een domeinnaam. We slaan echter niet de opgevraagde domeinnaam op, maar alleen afgeleide informatie hiervan, gebaseerd op een zogenaamde hash. We combineren deze hash met een geheime sleutel, zodat alleen personen met toegang tot deze sleutel de benodigde hash kunnen berekenen (voor de kenners: we gebruiken HMAC-SHA256).

    Logdata veilig opgeslagen door middel van hashing
    Met een hash-algoritme kan voor een gegeven tekst (zoals een domeinnaam) een schijnbaar willekeurige code worden berekend. Dit werkt echter niet de andere kant op: voor een code kan je niet eenvoudig terugrekenen welke tekst hierbij hoort. Je kan dus wel makkelijk berekenen dat voor surf.nl de bijbehorende hash 92A406…683887 is, maar je kan dus niet zomaar achterhalen welke domeinnaam hoort bij de hash C75871…93D2B2.

    Het systeem slaat de informatie over de gebruiker versleuteld op – met behulp van het cryptografische algoritme ChaCha20Poly1305. Deze informatie kan alleen worden ontsleuteld als deze gebruiker een domeinnaam heeft opgevraagd waarnaar gezocht wordt in het systeem. De sleutel die wordt gebruikt om de gebruikersinformatie op te slaan, berekenen we namelijk door een geheime sleutel te combineren met de opgevraagde domeinnaam. Als je deze domeinnaam niet weet, kan je de benodigde sleutel niet achterhalen en de gebruikersinformatie dus niet ontsleutelen.

    In Figuur 1 zie je een voorbeeld van de informatie die we opslaan. De opgevraagde domeinnaam (malware.evil.nl) en het hoofddomein (evil.nl) worden zodanig opgeslagen dat deze niet meer kunnen worden ontsleuteld (ook niet met de rode respectievelijk groene sleutel) en alleen kunnen worden gebruikt voor het opzoeken van data. Om de informatie over de client (192.0.2.123) die de domeinnaam heeft opgevraagd te kunnen ontsleutelen is zowel de blauwe sleutel als de opgevraagde hoofddomeinnaam (evil.nl) nodig om de benodigde gele sleutel te kunnen berekenen. Het is later dus wel mogelijk om op te zoeken wie malware.evil.nl heeft opgevraagd, maar niet welke domeinnamen de gebruiker met IP-adres 192.0.2.123 allemaal heeft opgevraagd.

    De domeinnaam malware.evil.nl wordt gehasht samen met een rode sleutel, evil.nl wordt gehasht samen met een groene sleutel, evil.nl wordt met een paarse sleutel combineerd tot een gele sleutel die vervolgens wordt gebruikt om het IP adres 192.0.2.123 te versleutelen. Deze hashes en versleutelde data worden samen met het tijdstip opgeslagen in de database.

    Procedurele maatregelen om privacy van eindgebruikers te beschermen

    Verder treffen we nog een aantal procedurele maatregelen om de privacy van eindgebruikers zo veel mogelijk te beschermen: alleen leden van SURFcert krijgen toegang tot het systeem, en alle zoekopdrachten in het systeem worden bijgehouden in een auditlog. Dit auditlog zal regelmatig worden nagelopen, waarbij degene die de zoekopdracht heeft uitgevoerd moet verantwoorden waarom deze is uitgevoerd. Verder worden alle logdata maximaal negentig dagen bewaard.

    Met deze technische en procedurele maatregelen hebben we een systeem ontwikkeld dat SURFcert de mogelijkheden geeft om beveiligingsproblemen op te sporen, terwijl we tegelijk de privacy van de gebruikers zoveel mogelijk beschermen doordat het gedrag van individuele gebruikers niet kan worden gevolgd.

    Meer weten?

    Wil je meer weten over dit systeem, neem dan contact met me op via joeri.deruiter@surf.nl.

  • Werkbezoek naar onze collega’s bij DFN-Verein

    Werkbezoek naar onze collega’s bij DFN-Verein

    Wat een leerzame dag in Berlijn! Hartelijk dank aan Stefan Piger en Leonie Schäfer van DFN-Verein voor de boeiende discussies en waardevolle kennisuitwisseling. Het was een genoegen om samen te sparren en samenwerkingsmogelijkheden te verkennen. We kijken ernaar uit om dit gesprek voort te zetten!

  • Network dashboard goes electric!

    Network dashboard goes electric!

    Afgelopen zomer is onder de motorkap van het Network Dashboard een enorme transitie doorgevoerd. Op het oog lijkt er weinig gewijzigd, maar vooral als je rond klikt, zul je nu merken dat het veel sneller werkt. De grote ombouw van het netwerkdashboard stond al lang op onze verlanglijst, omdat door de complexe autorisatie regels het…

    De architectuur van het Network Dashboard is compleet op de schop gegaan door niet meer realtime alle data uit verschillende systemen (orchestrator/ipam/CMDB/CRM/jira) te verzamelen, maar alle statische data vooraf al klaar te zetten in een document in de replica set. Hierdoor hoeven we in plaats van 500 losse API-calls, slechts een paar zeer snelle call te doen. Alleen de verkeersgrafieken en health status van de diensten worden nu live uit de influx database gehaald.

    Hoe snel is zo’n replica set bijgewerkt?

    Het klaarzetten van deze documenten in de replica set, wordt getriggerd bij elke wijziging op een subscription die de Workflow Orchestrator (zie workfloworchestrator.org)uitvoert op een dienst. Ook wordt elke nacht de replica gerefresht. Hierdoor kunnen we de data integriteit tussen orchestrator en replica set garanderen. Alleen bij realtime changes op het netwerk of door bij self-service acties zal de replica set kortstondig achterlopen op de werkelijke `state`zoals vastgelegd in de Workflow Orchestrator. Bijvoorbeeld het aanpassen van een customer alias is daarmee niet instantaan zichtbaar in het netwerk dashboard, maar moet verwerkt worden in de replica set. Eenvoudige wijzigingen duren ~4 seconden, terwijl grotere wijzigingen gemiddeld vele malen langer kunnen duren. Op dit moment werken we nog aan het verbeteren van de automatisch refresh van de pagina’s na self service acties, tot die tijd zal je na een wijziging een pagina handmatig moeten verversen om de laatste up-to-date informatie te zien.

    SURFdomeinen zal begin volgend jaar beschikbaar komen in het netwerk dashboard. Vanwege de complexe migratie van domeinnamen en zones wordt deze gefaseerd uitgevoerd. De product manager van SURFdomeinen zal hierover tijdig communiceren.

    Tot slot hebben we een nieuwe look-and-feel geïntroduceerd met een vernieuwde landingspagina, waarop alle netwerkdiensten van het standaard netwerkportfolio overzichtelijk in één tegel worden gepresenteerd.

  • Lichtpaden 2.0

    Lichtpaden 2.0

    Al heel lang leveren we SURFlichtpaden. Tot nu toe waren dit altijd ethernet-diensten met twee eindpunten. SURFlichtpaden hadden we in grofweg vier smaken; protected of redundant en op een Single Service Port (SSP, untagged) of Multi Service Port (MSP, tagged). Nu, met het nieuwe SURF-netwerk kunnen we nieuwe mogelijkheden toevoegen aan de SURFlichtpaden. Zo bieden we nu een multipoint-variant (ofwel L2VPN) aan en zijn er meer mogelijkheden op het gebied van redundantie en resiliency. Lees hier wat we tot nu toe hebben gedaan en wat we van plan zijn.

    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.

    Figuur 1: niet redundant L2VPN
    Figuur 1: niet redundant L2VPN

    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.

    Figuur 2 Ethernet loops in een redundant L2VPN
    Figuur 2 Ethernet loops in een redundant L2VPN

    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.

    Figuur 3 Loop preventie mbv single-active multihoming in L2VPN
    Figuur 3 Loop preventie mbv single-active multihoming in L2VPN

    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.

    Figuur 4 Usecase EduVPN
    Figuur 4 Usecase EduVPN

    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.

    Figuur 5 Multi-chassis link aggregation
    Figuur 5 Multi-chassis link aggregation

    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.

    Figuur 6 L3VPN multicloud voorbeeld
    Figuur 6 L3VPN multicloud voorbeeld

    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!