De BGP Tuner: intuïtief beheer van DNS anycast-infrastructuren

Opmerking: We maken in deze blogserie gebruik van 2 soorten verwijzingen. Met hyperlinks verwijzen we naar aanvullende achtergrondinformatie, terwijl verwijzingen tussen rechte haakjes ([]) betrekking hebben op diepgaand technisch materiaal zoals wetenschappelijke papers.

Anycast

Anycast is een techniek die het routeringssysteem van het internet gebruikt om een bericht van een client naar een van meerdere alternatieve bestemmingen routeert. Hierbij selecteert het routeringssysteem dynamisch het pad met het kleinste aantal hops vanaf de client. Anycast kan latency verminderen, de netwerkweerbaarheid verbeteren en verdedigen tegen DDoS-aanvallen [Moura2015]. Het wordt op grote schaal gebruikt door root DNS-operators, DNS-serviceproviders en CDN's (content distribution networks), waaronder Google, Facebook en Cloudflare.

Figuur 1 geeft een overzicht van het anycast-concept, gebaseerd op een voorbeeld waarbij 3 servers hetzelfde IP-adres gebruiken (10.0.0.1) maar op verschillende locaties worden gehost. Alle clients (onderaan) kunnen de servers bereiken via verschillende paden die afhankelijk zijn van de onderlinge verbindingen tussen AS’en (getekend als clouds). Onder de motorkap bepaalt het BGP-protocol op basis van een reeks parameters en policy’s naar welke server het verkeer van de client wordt gerouteerd en welk pad [Moura2015]. Dit betekent dat het gedrag van een anycast-service heel nauw gekoppeld is aan BGP.

Figuur 1: Anycast-netwerk.

Verschillende clients ‘zien’ een anycast-adres dus anders, afhankelijk van naar welke server BGP de clients uiteindelijk routeert. De groep clients die bij 1 bepaalde site uitkomt heet de ‘catchment’ van die site. Om inzicht te krijgen in en invloed uit te oefenen op welke clients in welk catchment vallen, moeten we met het BGP-protocol werken. Het BGP-protocol heeft verschillende functies voor verkeersmanagement [Quotin2003] waarmee elk AS routeringsvoorkeuren kan instellen en deze informatie kan doorsturen naar buurnetwerken. Het basisgedrag van BGP kunnen we niet veranderen, maar we kunnen wel voorkeuren instellen die mogelijk onze anycast-zichtbaarheid veranderen. Bovendien is het internet dynamisch en kunnen routeringspaden in de loop van de tijd veranderingen ondergaan, bijvoorbeeld als gevolg van instabiliteit en nieuwe onderlinge verbindingen tussen AS’en. Hierdoor kan een client die vandaag via de ene route een bepaalde server bereikt, morgen bij een van de andere servers uitkomen. Dat is geen slechte zaak: dynamiek maakt anycast-netwerken robuust, maar het houdt wel in dat continue meting geboden is.

Waarom moeten anycast-netwerken gemonitord worden?

Tools die operators helpen bij het beheren van hun ge-anycaste DNS-services zijn van cruciaal belang voor een veilige en stabiele werking. Binnen het SAND-project hebben we dergelijke tools ontwikkeld en geëvalueerd, met name om DNS-operators te helpen om de volgende vragen te beantwoorden:

1. Hoe bereiken clients op het internet mijn ge-anycaste DNS-service?

2. Hoe kunnen we de zichtbaarheid van onze DNS-services voor clients beheren door aanpassing van BGP-configuraties?

Operationsteams, zoals die van SIDN, moeten deze vragen kunnen beantwoorden in verschillende praktijksituaties, waaronder:

• Verkeersmanagement Het beheren van de manier waarop het routeringssysteem van het internet clients over anycast-nodes verdeelt. Zoals beschreven, gebruiken anycast-netwerken BGP als platform voor het routeren van het verkeer. BGP beschikt echter niet standaard over functies voor het gelijkmatig verdelen van de belasting. Dit betekent dat we niet kunnen managen hoeveel verkeer een locatie te verwerken krijgt. Dat is gebonden aan waar clients gevestigd zijn en de onderlinge verbindingen tussen hun netwerk en andere netwerken. Laten we bijvoorbeeld nog eens kijken naar Figuur 1. Als een meerderheid van de verzoeken afkomstig is van de eerste client (linksonder), raakt de eerste locatie overbelast. Het goede nieuws is dat we met behulp van BGP-functies kunnen proberen om verkeer te verleggen naar de andere locaties [Hesselman 2017].

• DDoS-mitigatie Grote DDoS-aanvallen kunnen anycast-locaties overbelasten. Door inzicht in de kenmerken van dergelijke aanvallen en aanpassing van anycast catchments kan de operator de anycast-service her-configureren en de belasting verleggen naar de andere locaties. Operators kunnen verschillende mitigatiestrategieën toepassen om het verkeer in bepaalde regio's te isoleren of om te leiden naar een locatie met meer capaciteit die beter in staat is om het verkeer te verwerken.

• Gebruikerservaring Idealiter zou elke client terecht moeten komen bij de dichtstbijzijnde anycast-locatie wat betreft het aantal hops op het AS-pad en dat zou dan de laagst mogelijke RTT moeten opleveren. Maar ‘dichtstbijzijnd’ is bij anycast-routering niet altijd gerelateerd aan geolocatie of latency. Welke locatie het dichtstbij is, hangt af van een combinatie van routeringsbeleid en onderlinge verbindingen tussen AS’en. Als clients van een bepaald AS in de VS bijvoorbeeld naar een locatie in Japan worden geleid, zal dat voor hen een negatief effect hebben op de latency van de service en moet de operator mogelijk ingrijpen. Dit vereist dat operators de catchment-verdeling van hun anycast-service monitoren en vervolgens BPG-instellingen aanpassen om invloed uit te oefenen op de latency die door gebruikers wordt ervaren.

Het anycast-testbed Tangled

‘Tangled’ is de naam van het anycast-testbed dat we in het SAND-project hebben ontwikkeld. Het is een volledig functionerende infrastructuur die draait op 13 locaties over de hele wereld en meer dan 50 BGP-sessies biedt met verschillende ISP's en Internet Exchange Points (IXP’s). Tot de locaties behoren onder meer de University of Southern California, het WIDE-project in Japan en een aantal commerciële cloudproviders. Tangled is al sinds 2017 in bedrijf, maar in de laatste 2 jaar van het SAND-project voerden we onder andere de volgende grote verbeteringen door:

'Tangled' is the name of an anycast testbed that we have developed in the SAND project, which runs a full anycast provider infrastructure. Tangled runs at 13 locations around the globe, providing more than 50 BGP sessions with several ISPs and Internet Exchange Points (IXPs). Sites include the University of Southern California, the WIDE Project in Japan and several commercial cloud providers. Tangled has been in operation since 2017, but in the last 2 years of the SAND project we implemented several big improvements, such as:

• We zijn van 8 naar 13 locaties gegaan.

• We hebben IPv6 BGP-sessies mogelijk gemaakt.

• We hebben een nieuw AS gemaakt speciaal voor ons testbed.

• We hebben een nieuw IPv4-prefix toegevoegd (/23).

• We hebben een nieuw IPv6-prefix toegevoegd (/40).

• We hebben een CLI-interface toegevoegd.

De meeste locaties binnen Tangled worden beheerd door vrijwilligers, maar we hebben totale controle over de BGP-sessies. We gebruiken 'exabgp' als interface voor het beheren van de sessie en het implementeren van onze policy’s. Exabgp ondersteunt verschillende BGP-policy’s door middel van AS-Path Prepending, BGP Communities en aankondigingen met verschillende prefixlengtes. Deze flexibiliteit is cruciaal om te kunnen meten hoe verkeer in verschillende anycast-configuraties over de nodes wordt verdeeld.

Figuur 2 toont de aan Tangled toegewezen prefixen die we in onze experimenten gebruiken. We hebben een relatief grote prefixlengte voor zowel IPv4 als IPv6. Daardoor kunnen we binnen Tangled meer dan 1 routeringsprefix gebruiken. We kunnen bijvoorbeeld een specifieker prefix gebruiken en dan in kaart brengen hoe dit van invloed is op de manier waarop het verkeer over de nodes wordt verdeeld.

Figuur 2: Op het Tangled-testbed gebruikt BGP-routeringsprefix.

Hoe kunnen we de zichtbaarheid van anycast-services monitoren?

Deze eerste onderzoeksvraag gaat over het begrijpen van hoe clients over de locaties van de anycast-service worden verdeeld. Het in kaart brengen van deze verdeling wordt ‘catchment mapping’ genoemd. Hierbij ontdekken we welke clients naar welke locaties gaan [ISI2020].

In grote lijnen zijn er 2 mogelijke benaderingen: (1) gebruikmaken van ‘vantage points’ aan de client-kant, zoals RIPE Atlas, om voor elke client te bepalen bij welke server ze terechtkomt, of (2) gebruik maken van de opensourcetool 'Verfploeter' die je kunt draaien op ge-anycaste DNS-servers. Verfploeter pingt om de zoveel tijd een groot aantal clients, registreert vervolgens bij welke anycast-locaties de antwoorden terechtkomen en gebruikt die gegevens om anycast catchments te berekenen. Dit noemen we ‘global probing’.

Figuur 3 geeft globaal weer hoe Verfploeter werkt. De server ‘verfploeter’ stuurt ICMP-verzoeken (pings) naar alle netwerken op het internet. Dit verzoek wordt verstuurd met het anycast-IP-adres uit ons voorbeeld (10.0.0.1) als source-adres. Clients gebruiken dat adres als bestemming in hun antwoord, waardoor die terechtkomen bij een van de anycast-locaties.

Figuur 3: Verfploeter berekent anycast catchment d.m.v. global probing.

Verfploeter doet er ongeveer 15 minuten over om het hele internet te testen. Hierbij komen er meer dan 3,9 miljoen ping-antwoorden van clients binnen. Deze antwoorden beschrijven eigenlijk het netwerk en de verschillende catchments, d.w.z. bij welke anycast-locatie elk afzonderlijk netwerk terechtkomt. Om deze informatie inzichtelijker te maken, hebben we een interactieve webinterface ontwikkeld (Figuur 4) die afwijkingen aan het licht brengt en beheerders in staat stelt om de clientverdeling over anycast-sites te verkennen. Het is bijvoorbeeld mogelijk om te bepalen bij welke server clients uit een bepaald land terechtkomen. Ook kunnen we zien welke AS’en in een land een bepaald gedrag vertonen.

Figuur 4: SAND GUI: Verfploeters grafische interface voor gegevensanalyse.

Hoe kunnen we anycast catchments wijzigen?

Het catchment van een ge-anycaste service wijzigen komt neer op het wijzigen van de groep van clients van wie de verzoeken bij de server terechtkomen. Een operator kan de clientverdeling bijvoorbeeld willen wijzigen om de serviceprestaties te verbeteren (latency en gebruikerservaring), om het verkeer tussen locaties gelijkmatiger te verdelen door middel van verkeersmanagement of om zich te verdedigen tegen DDoS-aanvallen (zie hierboven).

BGP biedt een reeks functies waarmee operationsteams de zichtbaarheid van hun nodes kunnen veranderen, zoals AS-Path Prepending en BGP Communities. Door BGP-policy’s in te stellen kunnen ze bepaalde routeringspaden prioriteren en de voorkeur van het routeringssysteem voor andere paden verminderen, waardoor het verkeer anders over de anycast-servers wordt verdeeld. Bij het wijzigen van catchments is het vooral belangrijk om in kaart te brengen wat de effecten van BGP-policy’s zijn wat betreft de loadverdeling over de locaties.

Als operationsteams wijzigingen aanbrengen in BGP-policy’s, is het essentieel dat ze kunnen monitoren hoe BGP hun prefixen doorgeeft en hoe consistent de prefix-aankondigingen zijn. BGP-routes hebben tijd nodig om zich over het internet te verspreiden en meerdere opeenvolgende wijzigingen kunnen resulteren in inconsistente prefix-zichtbaarheid. Om dit soort situaties te monitoren maken we gebruik van BGP RIPE RIS, dat verschillende route-collectors heeft en op grote schaal wordt gebruikt door de operator- en onderzoekscommunity's.

Figuur 5: BGP - zichtbaarheid en convergentietijd.

Figuur 5 illustreert de zichtbaarheid van de prefix van ons Tangled-testbed op het internet tijdens het uitvoeren van een AS-Path Prepending-experiment dat we uitvoerden op het testbed. Volgens de statistieken in RIPE RIS zouden we verwachten dat ons prefix onder normale omstandigheden door 267 peers zou worden gezien. Om de convergentietijd en zichtbaarheid in kaart te brengen, brachten we 2 wijzigingen aan in ons BGP-beleid: de eerste (withdraw) betrof het verwijderen van de prefix-aankondiging en de tweede (announcement) het opnieuw instellen van de aankondiging.

De convergentietijd, zoals even na 19:00 uur weergegeven in Figuur 5, was vrij laag: minder dan 5 minuten (van de groene lijn tot aan de rode lijn). Aangezien de convergentietijd van het internet meestal rond de 15 minuten ligt [Teixeira2017], verschaft ons experiment waardevolle informatie voor de verfijning van onze experimenten op het testbed. Een andere interessante bevinding is het aantal peers dat onze prefix niet ‘vergeet’, ook al is er een bericht verstuurd dat dit is verwijderd. Zoals de grafiek laat zien, bleven ongeveer 50 peers ons prefix zien nadat we dit hadden verwijderd. We hebben deze bevinding niet nader onderzocht, maar het zou een interessant onderwerp zijn voor toekomstig onderzoek.

Verwachte effecten op anycast-services

De verdeling van clients over anycast-locaties is afhankelijk van BGP-routering. Zoals uitgelegd, is het internet heel dynamisch en is het mogelijk dat de geselecteerde routes in de loop van de tijd veranderen. Daarom is het zinvol om de verdeling van de anycast-load regelmatig te monitoren.

Het zou bovendien interessant zijn om te begrijpen hoe BGP-policy’s de loadverdeling op anyast-servers kunnen beïnvloeden. Wat zijn bijvoorbeeld de gevolgen voor de load van het implementeren van een AS-Path Prepend? Om die reden ontwikkelden we een methode om de neveneffecten van elke uitgevoerde BGP-configuratie systematisch te meten en in kaart te brengen. We pasten deze methode toe binnen het Tangled-testbed, maar het zou ook werken voor productiesystemen zoals die van .nl. We definieerden de volgende stappen:

1. Baseline creëren: de verdeling van clients over onze ge-anycaste locaties meten en in kaart brengen met de reguliere BGP-configuratie.

2. Wijzigingen toepassen: de BGP-policy wijzigen en opnieuw meten.

3. Verkeersverschuiving: opnieuw meten en in kaart brengen om te berekenen hoe clients over onze locaties worden verdeeld na de wijziging (d.w.z. de afwijking van de baseline).

In een van onze experimenten configureerden we 6 locaties als anycast-service. Om de sites een naam te geven, gebruikten we luchthavencode als identificatie. Tabel 1 geeft de klantverdeling per locatie weer volgens de toegepaste BGP-policy. De policy baseline vertegenwoordigt de verdeling van clients over de locaties bij gebruik van onze standaardpolicy (reguliere BGP-prefix-aankondiging). Om de afwijkingen van de baseline in kaart te brengen, maakten we gebruik van AS-Path Prepends om de BGP-prefix-aankondiging te veranderen, waarbij we in totaal 78 verschillende policy’s implementeerden. De beleidsregel met de naam 1xCDG betreft een eenmalige AS-Path Prepend in Parijs (CDG=Luchthaven Parijs-Charles de Gaulle). De namen van de overige policy’s zijn op dezelfde manier samengesteld en bestaan uit het aantal prepends en een luchthavencode die aangeeft om welke anycast-locatie het gaat.

Tabel 1: Client-distributie: elke rij toont het gemeten verkeersverdelingspercentage per node voor het betreffende BGP-policy.

Elke rij in Tabel 1 vertegenwoordigt een meting in het Tangled-testbed en toont het percentage /24-netwerken dat per locatie voor het betreffende BGP-policy werd afgehandeld. De eerste rij toont de baseline voor onze service, waarbij gebruik werd gemaakt van onze reguliere BGP prefix-aankondiging. Bij deze configuratie ging 3,994% van de clients naar de locatie in Parijs (CDG), 8,453% ging naar Washington D.C. (IAD), 12,936% naar Londen (LHR), 8,832% naar Miami (MIA), 11,608% naar Porto Alegre in Brazilië en 9,494% naar Sydney. De kolom ‘unknown’ toont het percentage netwerken (/24) waarvan we geen antwoord ontvingen (via Verfploeter). Dat houdt in dat we 44,683% van de /24-netwerken niet in kaart konden brengen. Ook hier geldt dat de effectiviteit van de methodologie is besproken [Vries2017].

De tweede rij toont de resultaten bij gebruik van 1 prepend in Parijs. Dat wil zeggen dat we 1 prepend toevoegden aan de Tangled-locatie in Parijs, maar de prefix-aankondiging op de andere locaties ongewijzigd lieten. Zoals in de tweede regel te zien is, neemt bij het BGP-beleid in kwestie (1xCDG) de load van CDG af in vergelijking met de basislijn.

Bij elkaar kunnen de metingen in Tabel 1 worden gebruikt om voor elke BGP-configuratie te voorspellen hoeveel clients daaraan gebonden zijn. Operators kunnen hun anycast-services aan de hand van de tabel zodanig configureren dat de gewenste load op de anycast-locaties worden verkregen. Bij anycast-services met veel locaties kan dat echter een onoverzichtelijk en foutgevoelig proces zijn. Om daar iets aan te doen, hebben we de BGP Anycast Tuner ontwikkeld, een tool dat de bovenstaande tabel gebruikt als input.

BGP Anycast Tuner

De BGP Tuner is een prototype van een grafische interface die weergeeft hoe clients bij een vooraf bepaalde BGP-configuratie over de anycast-locaties worden verdeeld. We gebruikten Verfploeter om de metingen op Tangled uit te voeren, bewerkten deze voor (‘preprocessing’) en gebruikten ze daarna als de input voor onze interface.

Figuur 6: De interface van de BGP Anycast Tuner.

Met behulp van de intuïtieve interface (Figuur 6) kunnen operators het verkeersvolume of de catchments op elke anycast-locatie op eenvoudige wijze ‘egaliseren’. Een interactief display toont de verkeersverdeling over de locaties wanneer de eerder gemeten BGP-policy wordt toegepast. De grafiek in het midden laat de verdeling van clients over de verschillende anycast-locaties zien. Daaronder worden 6 schuifregelaars weergegeven, een voor elke locatie. De operator kan met de schuifregelaars spelen om het aantal clients per locatie te verhogen/verlagen. Merk op dat de schuifregelaars geen lineaire aanpassingen maken. In plaats daarvan correspondeert elke markering op de schaal van een schuifregelaar met een eerder gemeten BGP-policy. Voor sommige anycast-locaties zijn de markeringen verspreid over de volle lengte van de schaal, terwijl voor andere de markeringen dichter bij elkaar liggen. Deze verschillen weerspiegelen de mate waarin de diverse locaties in staat zijn om clients te verleggen naar andere anycast-nodes. Sommige locaties hebben daar meer invloed op dankzij hun relaties met buurnetwerken en hun verkeersovereenkomsten.

Met onze tool kunnen operators de best policy bepalen voor hun DNS-anycast-service, d.w.z. het aantal clients dat bij een bepaalde locatie terechtkomt verhogen of verlagen. Operators kunnen ook gebruik maken van meer geavanceerde policy’s. Zo bevat het vervolgkeuzemenu aan de linkerkant opties als ‘Bring traffic to Europe’ en ‘Reduce traffic to USA’. Met dit soort opties kunnen operators achterhalen welke van de aangeboden beleidsregels het meest geschikt zijn.

De BGP Anycast Tuner is een opensourcetool en hier beschikbaar.

Conclusies

Operators maken steeds meer gebruik van anycast-netwerken om de robuustheid van hun services en de kwaliteit van de gebruikerservaring te verbeteren. DNS-operators en CDN-providers gebruiken al langer anycast-netwerken om content te leveren aan gebruikers in binnen- en buitenland. Het beheer van deze netwerken heeft nieuwe uitdagingen met zich meegebracht voor de community van DNS-operators. Hoeveel locaties zijn er nodig? [Schmidt2017] Waar moeten die locaties worden gevestigd om het verkeer te optimaliseren? Hoe kan BGP worden aangewend zodat alle locaties gelijkmatig worden belast? Hoe debuggen we de prestaties van clients? Hoe kunnen ge-anycaste services in het algemeen worden geoptimaliseerd wat betreft latency en doorvoer?

In deze laatste fase van het SAND-project hebben we anycast-services gemeten en in kaart gebracht met behulp van de tool Verfploeter, die we in een eerdere fase van SAND ontwikkelden. We bouwden daarnaast een interactieve interface (de BGP Anycast Tuner) die de catchments van een anycast-locaties inzichtelijk maakt. Ook werd er een gestructureerde methode ontwikkeld voor het meten van de clientverdeling over anycast-locaties en de effecten van het toepassen van verschillende BGP-policy’s. Tot slot publiceerden we de BGP Anycast Tuner om operators in staat te stellen de effecten van verschillende BGP-configuraties op hun locaties te analyseren en beheren.

Als vervolg op het werk dat we hebben gedaan, werken we samen met SIDN’s operationsteam om onze meetmethode te implementeren als onderdeel van de anycast-monitoring voor .nl. Zowel de hier gepresenteerde bevindingen als de testbedinfrastructuur worden momenteel gebruikt in andere onderzoeken, zoals het PAADDoS-project.

Met dank aan

Dit onderzoek werd gefinancierd door SIDN Labs en NLnet Labs via het project Self-managing Anycast Networks for the DNS (SAND). SAND is een gezamenlijk project van Universiteit Twente, SIDN Labs en NLnet Labs.

Deze blog heeft betrekking op de tweede fase van het SAND-project (2018-2020). De eerste fase van het SAND-project resulteerde onder andere in de Verfploeter-tool.

Verder bedanken we de University of Southern California voor de goede samenwerking, en in het bijzonder John Heidemann voor zijn waardevolle feedback gedurende het project.

Bibliografie

• [Moura2015] Moura, G. C. M., Schmidt, R. D. O., Heidemann, J., De Vries, W. B., Möller, M., Wei, L., & Hesselman, C. (2016). Anycast vs. DDoS: Evaluating the November 2015 Root DNS Event. Paper gepresenteerd tijdens Proceedings of the ACM SIGCOMM Internet Measurement Conference, IMC.

• [Quotin2003] Quoitin, B., Pelsser, C., Swinnen, L., Bonaventure, O., & Uhlig, S. (2003). Interdomain traffic engineering with BGP. IEEE Communications Magazine, 41(5), 122-128. doi:10.1109/mcom.2003.1200112

• Broad and load-aware anycast mapping with verfploeter. Paper gepresenteerd tijdens Proceedings of the 2017 Internet Measurement Conference, Londen, Verenigd Koninkrijk. https://doi.org/10.1145/3131365.3131371

• [Schmidt2017] Schmidt, R. D. O., Heidemann, J., & Kuipers, J. H. (2017, maart). Anycast Latency: How many locations are enough? In Proceedings of the Passive and Active Measurement Workshop. Springer, Sydney, Australië (pp. 188-200).

• [ISI2020] The ANT Lab: Analysis of Network Traffic. Online: https://ant.isi.edu/anycast/catchment/index.html

• [Teixeira2007] Renata Teixeira, Steve Uhlig en Christophe Diot. BGP route propagation between neighboring domains. In International Conference on Passive and Active Network Measurement, pp. 11–21. Springer, 2007.

• [Hesselman 2017] C. Hesselman, G. C. M. Moura, R. d. O. Schmidt en C. Toet, Increasing DNS Security and Stability through a Control Plane for Top-Level Domain Operators, in IEEE Communications Magazine, vol. 55, nr. 1, pp. 197-203, januari 2017.