Ännu ett avsnitt i vår serie av artiklar där vi tar en titt under huven på Cisco NSO. Denna gång kommer vi titta närmare på hur Cisco NSO hanterar konfiguration och hur systemet kan hjälpa till att säkra nätverk samt underlätta felsökning och hantering av tjänsterna. NSO gör detta genom att använda referensräknare och en Cisco-proprietär algoritm kallad FASTMAP.
Vad är då FASTMAP och referensräknare?
Vi börjar med den enklare av de två, referensräknare, eller ”reference counting,” ett koncept som alla Python- och Java-programmerare borde vara väl medvetna om, tillsammans med alla som programmerar i språk som använder ”garbage collection” för att hantera variabler och minne åt programmeraren.
NSO har interna funktioner för samma typ av hantering, fast för den konfiguration som skapas av tjänster. Observera dock att både referensräknarna och FASTMAP arbetar med den YANG-modell av konfigurationen som NEDs och Device Manager skickar och hämtar från utrustningen, inte konfigurationen i utrustningen direkt.
Så när en tjänst skapas i Cisco NSO, och tjänsten i sin tur genererar konfiguration som skickas ut till utrustningen, får varje del av den konfigurationen en referensräknare som håller reda på hur många tjänster som använder denna konfiguration, eftersom det kan vara mer än en. Ett exempel är en accesslista som vi återanvänder på alla tjänster av en specifik typ. Konfigurationen får även en referenspekare tillbaka till tjänsten eller tjänsterna i fråga. Med denna pekare tillbaka till tjänsten, kallad ”backpointer”, har vi svaret på en första viktig fråga: Hur kan vi veta vilka tjänster som påverkas av att vi ändrar en viss del av konfigurationen i utrustningen?
Vad är FASTMAP?
Förutom att skapa referensräknare och pekare är FASTMAP algoritmen som ser till att vi inte behöver göra extra steg för att hantera tjänsternas konfiguration under dess livscykel, inklusive uppdateringar och när de tas bort från nätet. När en tjänst skapas sparas en ”reverse diff” för konfigurationen av denna tjänst, som innehåller vad som behövs för att ta bort denna instans av tjänsten. Om tjänsten uppdateras, används denna diff för att (utan att ändra på utrustningen) ta bort tjänsten, och sedan kör Cisco NSO koden för att skapa tjänsten igen med de gjorda ändringarna, skillnaden mellan denna nya konfiguration och den konfiguration som finns i utrustningen är då ändringarna som behöver göras. Sista steget är att denna lista av ändringar skickas till den NED som hanterar utrustningen och uppdaterar dess konfiguration.
Tillbaka till verkligheten
Så vad betyder detta rent konkret för ett företag som vill använda Cisco NSO? Låt oss titta på ett exempel.
I detta scenario har vi redan infört Cisco NSO och hanterar vår utrustning och dess tjänster genom NSO. En tekniker har dock loggat in direkt på en enhet och ändrat konfigurationen. Cisco NSO kommer i detta fall säga till att utrustningen i fråga inte längre är i synk, eftersom konfigurationen inte stämmer överens med den förväntade. Vi hanterar först det enklaste fallet: Teknikern gjorde fel och ändringen borde ha gjorts via tjänsten i NSO istället. Då instruerar vi Cisco NSO att trycka ut sin version av konfigurationen och skriva över ändringen. Därefter, om det behövs, uppdaterar vi tjänstens parametrar, och denna uppdatering skickas sedan ut i nätet via Cisco NSO. Teknikern får en utbildning i vad som skulle ha gjorts istället.
Men vad händer om teknikern hade rätt? Om tjänsten inte fungerar som den skulle, och ändringen som gjordes inte finns som en parameter att ställa in i NSO? Då instruerar vi NSO att synka sin vy från utrustningen istället. Den uppdaterade konfigurationen som importeras kommer inte att stämma överens med vad tjänsten förväntar sig, så Cisco NSO kan använda backpointern för att identifiera vilka tjänster som påverkas. Om till exempel en accesslista som används av flera tjänster har uppdaterats, kan vi ha löst ett problem i en tjänst men skapat problem i fyra andra.
Vi måste nu undersöka det underliggande problemet och dess lösning. Kanske behöver vi uppdatera tjänsten så att den inkluderar denna ändring och rulla ut den på alla instanser av denna tjänst på alla utrustningar som vi har? Alternativt att vi skapar en version 2 av tjänsten där man kan välja om denna funktion ska vara på eller av, och uppdatera tjänsterna för de kunder som vill ha ändringen, medan de som inte vill ha den kan behålla den äldre versionen?
Observera att denna vy av tjänster inte bara är begränsad till tjänster som levereras till andra. Exakt samma logik och hantering av konfigurationen kan appliceras på exempelvis AAA-konfigurationer. Detta är en tjänst som all utrustning ska ha direkt när de tas i drift så vi kan automatiskt lägga till den. Dessutom vill vi verkligen veta om någon har ändrat på den och kunna återställa den till förväntad konfiguration, men det är ju inte otroligt att den kan behöva uppdateras eller ändras på ibland heller. Detsamma gäller alla andra delar av "standard"-konfigurationen som appliceras på utrustningen, från COPP-filter till autentiseringsbannern när man loggar in.
Att tänka på all konfiguration i termer av tjänster, där all konfiguration i utrustningen egentligen kommer från och hanteras som en tjänst, kan vara en stor omställning för ett företag. Särskilt för organisationer som är vana vid att manuellt ändra konfiguration tills symptomen försvinner (men troligtvis inte det underliggande felet). På samma sätt är det en omställning att tänka på tjänstens hela livscykel och alla dess instanser mer industriellt, istället för att ständigt hitta och "fixa" samma problem om och om igen.
Behöver ni hjälp att komma igång med nätverksautomation och Cisco NSO?
Oavsett om du behöver hjälp med analys, implementering eller långsiktigt stöd, kan våra erfarna Cisco NSO-konsulter guida dig genom varje steg i processen. Med rätt stöd kan du maximera fördelarna med nätverksautomation, minska kostnaderna och förbättra den övergripande effektiviteten i ditt nätverk. Kontakta oss idag för att få reda på hur vi kan hjälpa ditt företag att lyckas med Cisco NSO!
Commenti