.png)
Elke maand organiseren we bij I-share een ‘Meetup’ waarbij we een breed scala aan onderwerpen behandelen met de nadruk op Cloud, Networking en Security. Deze sessies worden gegeven door zowel onze eigen medewerkers, als externe sprekers. De sessies worden zorgvuldig samengesteld om zo de meest actuele inzichten en praktische kennis te bieden op deze gebieden. De input vanuit onze eigen medewerkers speelt hierin dan ook een grote rol, want zij werken immers dagelijks aan complexe IT-uitdagingen binnen diverse organisaties. Zo ook Nathanaël van den Hout, onze Tech Lead Networking en Marco Verleun, onze Tech Lead Open Source. In deze blog duiken we in de interessante hackathon die zij samen hebben verzorgd.
Het configureren van routers
Voor de sessie was er een hackathon opgezet voor het configureren van routers. De aanwezigen bij de sessie werden opgedeeld in groepen en kregen als opdracht mee om een aantal zaken te configureren. De opdracht zag er als volgt uit:
o Twee routers configureren via een Linux host.
o Wat moet er geconfigureerd worden?
- Login banner;
- Loopback interface;
- OSPF tussen de twee routers.
• Neem het loopback interface mee in de configuratie!
Marco en Nathanaël hadden elk een eigen set van routers om te configureren. In plaats van het handmatig te configureren gebruikten zij andere methodes. Nathanaël vertelt: ‘’Ik koos ervoor om de routers te configureren via een Python script. Marco daarentegen configureerde de routers via een Ansible Playbook. Wat is nu eigenlijk het verschil tussen het configureren door het gebruik van CLI, scripts en Ansible? Lees snel verder om daarachter te komen!’’
CLI, scripts en Ansible
Als er wordt gekeken naar de routers die handmatig geconfigureerd zijn, valt het op dat de meeste mensen hun eigen interpretatie hebben losgelaten op de configuratie. Nathanaël legt verder uit: ‘’Voor het configureren was er de gedachte om een simpele banner aan te maken, deze heeft de volgende tekst gekregen: ‘Dit is R1 voor de I-share kennissessie.’
Hierbij komt er voor elke router een ander nummer te staan. Wat er opviel was dat er bij de CLI geconfigureerde routers geen banner werd ingesteld. Mogelijke redenen hiervoor kunnen tijdgebrek of onduidelijkheid over de opdracht zijn. Bij het configureren via het Python script en het Ansible Playbook werd dit ook meegenomen.
Voor het configureren van het loopback interface werd ook zichtbaar dat er verschillende opties gehanteerd zijn. Tijdens de sessie kozen de meeste teams ervoor om een loopback 0 interface aan te maken. Ook was er een team dat er voor koos een loopback 3 aan te maken.
Om de teams een eigen invulling aan de opdracht te laten geven, werden er geen kaders opgesteld wat betreft de IP-adressen. Deze verschillen dan ook van team tot team. Hierdoor was er een grote verscheidenheid te zien aan het gebruikte subnet. In het geval dat elk teamlid zijn eigen router zou configureren, in plaats van samen te werken, zouden er configuratie issues tussen beide routers kunnen ontstaan.
De grootste verschillen waren te zien in de OSPF configuratie. Hier kozen mensen geheel hun eigen weg en werd duidelijk dat de teams de opdrachten verschillend interpreteerden. In sommige gevallen werd hierdoor alleen het loopback interface geadverteerd en bij de andere configuraties enkel het subnet dat op de fysieke interface staat.
De areas werden over het algemeen op 0 gehouden, dit omdat OSPF een backbone area nodig heeft (area 0). Ook hier bestaat het gevaar dat elke router anders geconfigureerd wordt. Om dit consistent te houden, is het configureren vanaf een centrale plek aan te raden.
De gebruikte Pyhton scripts zijn meer dan 100 regels lang, waarbij er aan de hand van een argument iets geconfigureerd wordt, opgehaald wordt of verwijderd wordt (POST, GET, DELETE). De configuratie staat in de scripts zelf in dit geval. Dit zorgt er ook voor dat deze niet geheel handig voor gebruik op schaal zijn, maar er zou gekozen kunnen worden om de variabelen per router in een file te zetten.
Het is goed om te weten dat het gebruik van scripts handig is om meer te leren over het gebruik van RESTCONF of NETCONF. Dit kan helpen bij het verder ontwikkelen van automatisering van de omgeving. Het gebruik van Ansible maakt dat er eenmalig een Playbook geschreven kan worden. Wanneer deze af is, wordt er voor elk device een variabele file aangemaakt met unieke waardes. Deze waardes kunnen voor meerdere devices hetzelfde zijn. Deze kunnen in een algemene variabele file gezet worden. Dit zorgt ervoor dat het aanpassen van configuratie eenvoudiger wordt gemaakt. Door het uitvragen van configuratie via RESTCONF krijg je config in JSON of XML terug. Door deze op een website als, JSON to YAML, te configureren naar YAML is het eenvoudig om een hele config voor een device inhost variabele file te zetten.
Door het gebruik van deze files, is het bij het defect raken van een device ook gemakkelijker om deze weer te vervangen met eenzelfde configuratie. In het voorbeeld wat ik gebruikt heb hoeft een device alleen voorzien te zijn van een IP adres die het oude device had en een username met wachtwoord en genoeg privileges, waarna de configuratie gepusht kan worden. Hierdoor is een device in zeer korte tijd te vervangen en weer operationeel te krijgen.
De gebruikte omgeving is opgebouwd in Azure, bestaande uit twee Cisco CSR routers en een stepping stone voor SSH connectie. De gebruikte scripts zijn te vinden op mijn GitHub pagina.''
Coming up: kennissessie TOGAF
Lijkt het je na het lezen van deze recap leuk om ook een sessie van Nathanaël bij te wonen? Dat kan! Op donderdag 28 september (2023) zal hij een sessie geven die in het teken staat van TOGAF: The Open Group Architecture Framework. Hét ultieme raamwerk voor Enterprise architectuur.
Tijdens deze sessie zal onze Tech Lead Networking dieper ingaan op wat TOGAF precies is, hoe het werkt én welke voordelen het biedt. Meld je snel aan via onze Meetup pagina!