Vi har for nylig hjulpet en kunde med at konfigurere anycast DNS mellem nogle Umbrella virtuelle appliances og et ACI-net. Det vil mine næste par blog posts handle om.

Umbrella VA anycast DNS

I første omgang gennemgår vi de generelle design-spørgsmål, og næste gang kigger vi på, hvordan det så konfigureres på en Umbrella VA og i ACI.

Hvorfor?

Lad os starte med svaret på hvorfor. Jo, man kan godt nok konfigurere de fleste operativsystemer med flere DNS-servere (typisk mindst to), men det er ikke alle OS’er og applikationer, der lige godt håndterer den situation, at den ene DNS-server er nede.

Hvis en ældre Windows-maskine eksempelvis er konfigureret med to DNS-servere, og den første DNS-server ikke svarer, så spørger Windows pænt den første server om alting, venter på timeout, og spørger først derefter den anden server. Og det bliver den ved med, i stedet for at skifte til at bruge den anden server som primær.

Win10 sender ligesom moderne operativsystemer flere DNS-forespørgsler afsted parallelt… men nogle versioner venter på svar fra begge servere, før svaret afleveres til applikationen! Og selv på en fuldt opdateret Win10 fejler nogle applikationer helt. Fx vil “nslookup” på en kommandolinie kun spørge den primære DNS-server, men til gengæld spørger den fire gange, før den giver op…

Den præcise opførsel af DNS-klienter afhænger altså af både operativsystem og den enkelte applikation, men det korte af det lange er, at DNS-timeouts kan være ekstremt irriterende for brugerne, og de vil ofte blive rapporteret til netværksfolkene som den sædvanlige “Netværket er langsomt!”

Hvad?

Men hvad er så anycast? Jo, meget kort fortalt går anycast ud på, at man har flere servere konfigureret med samme IP-adresse, og man er ligeglad med, hvilken server der svarer.

Når en klient sender sin forespørgsel, besvares den af den Lag 3-mæssigt ‘nærmeste’ server, og hvis den server forsvinder, besvares forespørgsler ubemærket af den ‘næst-nærmeste’ server med samme IP-adresse. Anycast giver dermed en super redundans, uden brug af fx en ekstern load-balancer, og anycast kan også automatisk fordele load mellem flere servere, alt efter hvilken server, der topologisk er nærmest klienten.

I modsætning til unicast, der er til en enkelt modtager, multicast, der er til mange modtagere, og broadcast, der er til alle på et medie, er anycast altså til “en hvilken som helst server”, eller i praksis “nærmeste server”.

Anycast DNS giver dermed en elegant måde at sikre, at en bestemt IP-adresse altid er tilgængelig med god performance… og alle de store DNS resolvere køres da også som anycast (Googles 8.8.8.8, CloudFlares 1.1.1.1, IBM’s 9.9.9.9, og selvfølgelig Ciscos Umbrella på 208.67.222.222, og flere til).

Hvordan?

Hvordan laver man så anycast? Ja, der er selvfølgelige flere potentielle metoder, men den mest almindelige er, at man lader sin server snakke routing med den nærmeste Lag 3-enhed (router eller Lag 3-switch).

Serveren kan konfigureres med BGP eller ens foretrukne IGP, og bruger routing-protokollen til at annoncere sin service-adresse til routeren, lidt ligesom man har et loopback-interface på en router.

For optimal failover-performance og for load-distribuering, bør man sikre sig, at konfigurationen af routing-protokollen tillader, at der installeres flere lige gode routes (ECMP, Equal Cost Multi-Path), men hvis man primært ønsker redundansen, er det ikke et strengt krav.

Konklusion?

Servere med duplikerede IP-adresser og servere, der snakker en routing-protokol? Jeg ved godt, det kan lyde lidt mærkeligt og måske endda virke en anelse angstfremkaldende for en traditionel netværksmand, men det er faktisk en rigtig god løsning.

I næste afsnit vil vi se på, hvordan man konfigurerer det i praksis på ACI og Umbrella.

-A