Meratalyst / Catraki Part II – The next generation
Meraki og Catalyst Nyhed: Vores egen Tech Lead, Thomas Obbekær Thomsen, guider dig i, hvordan du gør din Catalyst-switch Meraki-monitored. Læs guiden her.
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).
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
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:
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
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
Meraki og Catalyst Nyhed: Vores egen Tech Lead, Thomas Obbekær Thomsen, guider dig i, hvordan du gør din Catalyst-switch Meraki-monitored. Læs guiden her.
Netværksautomatisering kan virke kompleks og teknisk, men den tekniske side er ofte den enkleste del. Den virkelige udfordring ligger i det organisatoriske og planlægningsmæssige arbejde før, under og efter kodning. Her er de første 6 trin til at opnå succes med netværksautomatisering.
Netværksautomatisering kan virke kompleks og teknisk, men den tekniske side er ofte den enkleste del. Den virkelige udfordring ligger i det organisatoriske og planlægningsmæssige arbejde før, under og efter kodning. Her er de første 6 trin til at opnå succes med netværksautomatisering.
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
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