Blogg

2018-04-24

Refleksjoner rundt den første implementeringen av Cisco SDA med DNA Senter i Europa

Software-Defined Access – er vi klare?

En kunde ønsket å implementere en helt ny infrastruktur som passet bedriftens behov. De var allerede veldig fornøyd med Cisco som nettverksleverandør og bestemte seg derfor for å gå for Cisco HyperFlex, Nexus, Cisco DNA og SD-Access.

SDA er Cisco-nettverksløsning sitt nye flaggskip. Det kombinerer en virtuell utvidbar lokal nettverks (VXLAN), Scalable Group Tags (SGT) og Locator ID separatorprotokoll (LISP). Sammen gir disse teknologiene strømlinjeformede distribusjoner, ett klikks oppgraderinger og en distribuert brannmur i nettet. Dette var den første SDA-installasjonen i Europa og jeg tenkte «Dette kan vel ikke gå galt?». Fullstendig klar over hvilket vanskelig prosjekt jeg hadde foran meg var jeg klar for utfordringen!

Installasjon – Vi er i gang!

SDA krever kun noen få komponenter – DNA Center, Cisco ISE,  «kant» switcher og et underlay. Med litt hjelp begynte jeg på prosjektet med en av mine favoritter: fysisk «rack» stabling og kabling av DNA Center-serveren. DNA Center kommer installert på en Cisco UCS-server. Den eneste forskjellen mellom denne serveren og en vanlig server, er DNA-klistremerket på den. Etter alle de «tunge» løftene var strømforsyningen koblet til, og serveren startet. Nå kunne jeg starte med Cisco-dokumentasjonen. DNA Center kommer med forhåndsdefinerte port oppgaver, og noen andre godbiter. (For de som kan være interessert i hva de er, sjekk den offisielle dokumentasjonen). Da serveren startet opp, ble den vanlige Cisco UCS oppstartsskjermen vist. I en kort stund glemte jeg nesten CMIC-konfigurasjonstastekombinasjonen, men mine raske fingre slo på tastaturet så den var raskt tilbake på rett spor. Deretter sjekket jeg at CMIC fungerte og jeg trakk meg ut fra serverrommet – «servermusikk» er ikke akkurat min favoritt. Endelig satt jeg litt mer komfortabelt , og jeg logget på CMIC og KVM. Derfra ville jeg prøve å starte serveren selv, og ikke bare styringsverktøyet til serveren. Serveren startet, og Maglev installasjonen startet, ingenting fancy, selv om java klient eller flash var nødvendig. Jeg var klar for neste trinn. Etter at jeg hadde satt IP-adressene og fjernet Clusterlink-alternativet, så la jeg merke til noe rart.

 

Første utfordring

Porten som holdt IP-adressen, som jeg nettopp har konfigurert, ble oppført som frakoblet i Maglev. Jeg åpnet Secure CRT og logget inn i kjernebryteren der DNA Center var koblet til. Porten var satt til «up/up». Jeg sjekket dokumentasjonen. Jeg hadde valgt riktig port og gjort de riktige konfigurasjonsstrinnene. Jeg startet serveren igjen og Maglev kom opp, men problemet var fortsatt der. Jeg endret SFP og kabel, startet den igjen, men problemet var fortsatt der. Jeg gjorde all konfigurasjon på nytt igjen, presset det inn og håpet at problemene ville forsvinne. Feilen denne gangen var at konfigurasjonsoppsettet stoppet ved DNS og NTP. Det fikk ikke forbindelse med disse tjenestene. Det virket håpløst, men som et siste forsøk startet jeg DNA-senteret og da kom grensesnittet opp. Resten av installasjonen gikk bra, og jeg fulgte bare Cisco-dokumentasjonen.

Basis – Begynnelsen på slutten

Etter installasjon av DNA-senteret trengte jeg å koble den til Cisco ISE. Dette var veldig enkelt. Bare en mindre sertifikatkonfigurasjon og så var det klart. For å bekrefte at det fungerte, skapte jeg flere SGT på ISE for å se at de fungerte på DNA senteret. Det neste trinnet var å bygge den grunnleggende konfigurasjonen, det vil si NTP, DNS, Radius etc. Det fungerte veldig bra. 

Bygge underlayet

Kunden hadde flyttet inn i en ny bygning og trengte å starte overføringen til HyperFlex med en gang. Nå var det en utfordring: Måten vi planla å implementere underlayet på var med DNA-senter, men det måtte distribueres før DNA-senteret var klart. Vi bestemte oss for å distribuere kjernebryterne på en tradisjonell måte. DNA-senteret ble klart, og nå kunne jeg ikke ta ned kjernebryterne for å gjenoppbygge dem med Cisco DNA fra bunnen av. Fra dette tidspunktet ble ting mer utfordrende. Jeg visste at noen av mine kolleger i Danmark hadde brukt litt tid med Cisco DNA i laboratoriet, og jeg sendte ham en e-post om hjelp. Som den gode kollegaen han er, var han mer enn villig til å hjelpe meg.

 

Underlayet – Ikke alt når toppen

SDA teknologien trenger et underlag for å transportere VXLAN-tunneler. Med dette designet blir det mye lettere å distribuere tjenester for man trenger bare å utvide overlayet. Underlayet er bare satt opp en gang, eller når det er behov for å skalere ut.

Kjerne – Hvor alle tunnelene går igjennom

Det er viktig å følge SDAs praksis når du bygger underlayet fra bunnen av – gjøre det samme som DNA senteret ville ha gjort. Heldigvis for meg, min kollega i Danmark hadde allerede testet dette i deres lab, og konfigurasjonen var et standard lag 3-rutet nettverk med «loopbacks». Ingen flere lag 2. Vi trengte også en ruteprotokoll, og vi landet på ISIS-protokollen. Jeg startet med kjernen og laget loopbacks og koblingene til et sett med «kant» switcher. Neste er selvsagt ISIS-konfigurasjonen. Følgende viser noen av konfigurasjonene som kreves ved kjernebryterne.

Core 1 interface Loopback0

ip address 10.100.100.128 255.255.255.255

!

interface TenGigabitEthernet 1/1/7

description *** To Firewall - Underlay ***

no switchport

ip address 10.100.101.2 255.255.255.248

standby version 2

standby 0 ip 10.100.101.1

standby 0 preempt

standby 0 priority 120

standby 0 track 1 decrement 30

standby 0 name HSRP-FW-UNDERLAY

standby 0 password OfCoUrSeIcAnTgIvEtHaTaWaY

!

interface TenGigabitEthernet1/1/8

description *** Edge Swithc 1 - Port TenGigabitEthernet1/0/8***

no switchport

ip address 10.100.100.1 255.255.255.252

ip router isis

isis network point-to-point

!

router isis

net 49.0001.0100.3204.7128.00

domain-password cisco

metric-style wide

nsf ietf

passive-interface Loopback0

!

ip route 0.0.0.0 0.0.0.0 10.100.101.4

!

!

#Core 2

interface Loopback0

ip address 10.100.100.129 255.255.255.255

!

interface TenGigabitEthernet 2/1/7

description *** To Firewall - Underlay ***

no switchport

ip address 10.100.101.3 255.255.255.248

standby version 2

standby 0 ip 10.100.101.1

standby 0 preempt

standby 0 priority 100

standby 0 track 1 decrement 30

standby 0 name HSRP-FW-UNDERLAY

standby 0 password OfCoUrSeIcAnTgIvEtHaTaWaY

!

interface TenGigabitEthernet2/1/8

description *** Edge Swithc 1 - Port TenGigabitEthernet2/0/8***

no switchport

ip address 10.100.100.5 255.255.255.252

ip router isis

isis network point-to-point

!

router isis

net 49.0001.0100.3204.7129.00

domain-password cisco

metric-style wide

nsf ietf

passive-interface Loopback0

!

ip route 0.0.0.0 0.0.0.0 10.100.101.4

!

 

«The edge» – Den er langt unna

Det neste trinnet er å konfigurere kantswitchene. For å få det riktig måtte jeg konfigurere ett lag 2-kobling og ett lag 3-link. Det gjorde at jeg kunne bruke SSH gjennom ledelsen VLAN. Følgende er grunnleggende «kantswitchkonfigurasjon».

#Edge 1 - Stack

interface Loopback0

ip address 10.100.100.130 255.255.255.255

!

interface TenGigabitEthernet1/1/8

no switchport

ip address 10.100.100.2 255.255.255.252

ip router isis

isis network point-to-point

!

interface TenGigabitEthernet2/1/8

no switchport

ip address 10.100.100.6255.255.255.252

ip router isis

isis network point-to-point

!

router isis

net 49.0001.0100.3204.7130.00

domain-password cisco

metric-style wide

nsf ietf

passive-interface Loopback0

Med underlayet på plass, kunne vi endelig begynne å bruke DNA-senteret for å bestemme overlayet.

Inventar – Hvor er alt?

Før DNA-senteret kan begynne å administrere overlayet, må det først vite hvilke enheter det trenger å administrere. Derfor var det neste trinnet å få DNA Center til å oppdage kantswitchene, og deretter konfigurere noen legitimasjonsbeskrivelser og SNMP.

Jeg trengte også å legge til IP-adressepoolene som kunden trengte. Så kunne vi endelig starte provisjoneringen av switchene.

Provisjonering

Dette var GUI som møtte oss:

Prosessen var ganske enkel. Målet her er å gi grunnleggende konfigurasjon, som NTP, SNMP, Radius etc. Det fungerte uten problemer og tok omtrent fem minutter. Etter at provisjoneringen var ferdig, kunne jeg logge på bryterne med Active Directory-kontoen min. Nedenfor er et skjermbilde av lagerlisten.

Fabric  – Denne gangen er det på topp

Til slutt kunne vi begynne å bygge overlayet. Dette var også enkelt, vi har nettopp lagt til kjerne som Control Plan / Border and Edges som kanten. Bildet nedenfor er tatt under den første overlay-SDA-prosessen.

Etter å ha satt den innledende overlay-konfigurasjonen, måtte vi bare legge til riktig nettverk til de riktige portene. Der møtte vi den største utfordringen.

Noen etasjer jobbet det allerede folk i, og noen gjorde det ikke. Vi prøvde å fjerne fabric på switchene og legge dem tilbake igjen. Det fungerte ikke. Etter en stund ringte vi Cisco TAC. Etter to minutter hadde jeg fått tak i en TAC tekniker og vi hadde en WebEx sesjon. Vi feilsøkte i 30 minutter, han ba meg holde linjen og litt senere var vi plutselig 4 på linjen. Vi feilsøkte i omtrent to timer til, og etter det fant vi ut at trafikken falt i Control Plan/Border node. Vi så trafikken gå ut gjennom brannmuren og tilbake til Control Plan / Border node. Derfra forsvant pakkene. Vi brukte det innbygde Wireshark-verktøyet på switchene for å bekrefte dette. Det «morsomme» var at PCen fikk en IP-adresse fra DHCP, men all annen trafikk ble droppet. Vi holdt på en time til før vi tok kvelden.

Neste dag hadde TAC teknikerne gitt opp og vi kontaktet utviklingsavdelingen. Tre personer koblet seg til vår Webex-økt. Der satt jeg, med fire TAC teknikere og tre utviklere. Utviklerne mente de ikke kunne finne noen åpenbare feil. Jeg tok en pause og snakket med kunden. Vi bestemte oss for å reversere underlayet til et standard lag 2-nettverk og bruke det på den måten mens Cisco-teamet jobbet på saken. Dette var ikke blant mine stolteste øyeblikk, men jeg forstod kundens driftskrav. Vi fjernet fabric og den fastsatte konfigurasjonen. Noen timer etter at vi dro pluggen, fikk jeg en e-post fra en av utviklerne. De hadde funnet problemet. Catalyst 9500 hadde en minne lekkasje. De kontaktet Catalyst-teamet og de ga ut en ny programvare-versjon for å fikse det. Dessverre kunne vi ikke rulle det tilbake umiddelbart, da det allerede hadde blitt sent og vi hadde andre problemer å ta hensyn til. Uken etter at vi fant et vedlikeholds vindu for å oppgradere Catalyst 9500, og etter et par dager til, ble det også tid til å teste «kant» switchene. Det funket. Ingen trafikk ble droppet. Etter dette trengte vi bare å distribuere resten av switchene.

Inntrykket av at jeg er igjen er at Cisco SDA og DNA Center er et veldig bra produkt, og med tiden blir dette den nye standarden i klient adgang.

Hvis du har spørsmål eller ønsker å vite mer, send meg gjerne en mail tsp@conscia.com eller kontakt meg via Linkedin. 

 

Tom-Sverre Pedersen
Senior Nettverksarkitekt
CCENT, CCNA, CCNP, CMNA
CCNA, CCI R&S

tsp@conscia.com

Kontakt oss!

Vi svarer på dine spørsmål, ta kontakt idag.

Kontakt oss!

Svar innen 24h