I forrige afsnit snakkede vi om, hvad anycast DNS er, hvorfor man kunne finde på at bruge det, og en overordnet metode til at implementere det. I dette afsnit vil vi se på, hvordan man i praksis kan konfigurere det i ACI og på Umbrella VA (virtual appliances).

Umbrella VA

Hvis vi starter med Umbrella VA’en, så er anycast DNS kun supporteret via BGP, og konfigurationen er meget simpel, men til gengæld ikke super fleksibel. Det konfigureres per VA fra CLI’et (ikke nogen GUI her), og basalt set kan man kun angive, hvilken adresse man vil annoncere, og hvilken BGP peer man vil snakke med, i formatet:

config anycast bgp enable :

Hvis man eksempelvis vil annoncere adressen 10.10.10.10, og man skal snakke med 172.22.20.2 i AS# 65512, får man:

config anycast bgp enable 10.10.10.10 65512:172.22.20.2

Bemærk, at der ikke er noget sted, man kan konfigurere VA’ens eget AS-nummer. Det ‘genereres’ automatisk ud fra VA’ens egen unicast-adresse (sic!), sådan at hvis VA’en IP-adresse fx er 172.22.20.37, så bliver VA’ens AS# 222037. Ja, det er mærkeligt.

Hvis man ønsker at køre TTL security eller eBGP-multihop, kan man ikke konfigurere det selv, men Umbrella Support kan slå det til per VA, hvis man etablerer support tunnelen på VA’en.

Men nu er VA’en altså konfigureret, og forsøger at snakke BGP med den angivne nabo

ACI

I ACI skelner man mellem almindelige endepunkter (som servere), der findes i EPG’er og eksterne enheder, der nås via en L3Out. Dynamisk routing kan man kun lave på en L3Out, og da vi her ønsker dynamisk routing med BGP, skal vi altså bruge en L3Out til formålet.

Hvis man har lavet VMM-integration mellem ACI og sit hypervisor-miljø (som VMware ESX), vil man vide, at det er super simpelt at oprette en EPG, pushe den til vCenter i form af port-grupper, og derefter flytte VM’er over i de nyoprettede portgrupper. Alt det kedelige switch-konfiguration sker helt automatisk på de relevante porte, hvor ESX’erne sidder. Men VMM-integration virker kun med EPG’er, ikke med L3Outs.

For at køre BGP mellem en VM og ACI, skal vi altså lave L3Out, og vi er nødt til at lave al switch- og port-konfigurationen i leafs manuelt, da vi ikke får hjælp af VMM-integration.

Konfigurationen i APIC bliver dermed:

  • Statisk reservering af et VLAN-nummer fra den relevante VLAN-pulje, sådan at VLAN’et er tilladt i det pågældende domæne, men ikke dynamisk allokeres af APIC.
  • Statisk oprettelse af en port-gruppe i den virtuelle switch i vCenter, VA’en skal sidde i, med brug af det VLAN-nummer, man har reserveret.
  • Statisk konfiguration af leaf-porte med L3Out. Nemmest er brug af et SVI.

Hvis man har mulighed for det, bør man i VMware lave en separat vSwitch til formålet, hvor man bruger separate (v)NICs som uplinks, for APIC vil normalt rejse en fejl på en VMM-kontrolleret DVS med manuelt oprettede port-grupper. Men ikke alle har jo UCS, hvor man kan lave ca. alle de NICs, man har lyst til.

Hvis man har mange ESX’er, som VM’en kan flytte til, kan det blive til ganske meget leaf- og port-konfiguration i ACI… og så bliver man jo mindet om, hvor besværligt datacenter-netværk op mod VMware var, før vi fik ACI. Når man bliver træt af museklik, kan man selvfølgelig lave resten med et script eller fra Postman.

Og dermed er ACI konfigureret og begynder at snakke BGP med VA’ern

Operationelt

Lad os runde af med et par operationelle ting, man skal være opmærksom på med anycast DNS.

For det første skal man være opmærksom på, at det kan være svært at lave centraliseret overvågning af en anycast DNS-tjeneste. Hvis man fra centralt hold tester DNS mod anycast-adressen, får man jo kun svar fra den nærmeste anycast DNS-server. Man kan ikke nemt få en status på dem alle. I tilfældet med Umbrella, kan man dog se status på alle VA’er i Umbrella-portalen.

Hvis man er træt af, at alt muligt udstyr i netværket er statisk konfigureret med DNS (fx 8.8.8.8), kan man køre et par VA’er op med den pågældende adresse som anycast, og dermed tiltrække de pågældende DNS-opslag, og altså se, hvem (hvilket udstyr), der bruger ikke-standard DNS og ‘snyde’ dem over på Umbrella. Det er lidt mere nænsomt end den hårde metode, der er at lukke for al udgående DNS, bortset fra VA’ernes.

Tag fat i din sælger eller din foretrukne konsulent, hvis vi skal hjælpe dig med at konfigurere anycast DNS i dit netværk.

-A

Relaterede artikler

AI og kundeservice. 4 trends i 2024 der vil forandre din hverdag
AI i kundeservice

4 trends der vil forandre din hverdag i 2024

Udforsk den revolutionerende verden af Generativ AI, der transformerer arbejdsmetoder og kundeservice. Opdag potentialet for at løse kritiske udfordringer inden for kundeservice og få indblik i, hvordan AI kan inspirere forbedringer på konkrete områder. Men er potentialet større end truslerne? Scan QR-koden for at se, hvordan et forsikringsselskab automatiserer kundeserviceelementer og giver dig et glimt af fremtidens interaktion med AI.

Læs mere
Der findes ikke flere artikler i arkivet
CTO, Asbjørn Højmark, Datacenter, Wingmen
CTO

Asbjørn Højmark

Har Tech Tanken gjort dig nysgerrig på at vide mere? Så kan du følge med på hjemmesiden her eller du kan kontakte mig, hvis du har spørgsmål til denne tanke.

Mail: ah@wingmen.dk

Kontakt DIN WINGMAN

Kbh.: Tobaksvejen 23B, 2. sal, 2860 Søborg
Aarhus: Lyshøjen 2, 1. sal tv., 8520 Lystrup
Odense: Stenhuggervej 21, 5230 Odense M

Telefon: 70202110
Mail: info@wingmen.dk

CVR: 36440228