Dingen waarvan ik wilde dat ik ze wist voordat ik met SONiC NOS ging werken - Het perspectief van een CCIE
Als je jaren hebt besteed aan het beheersen van traditionele netwerkbesturingssystemen - Cisco IOS, NX-OS, Junos - is de overstap naar een gedesaggregeerd platform zoals SONiC (Software voor Open Netwerken in de Cloud) is een schokkende ervaring. Als CCIE dacht ik dat ik over de kerncompetenties beschikte om elk netwerkbesturingssysteem op te pakken. SONiC maakte me nederig. Het is een krachtig platform, maar wel een dat een heel andere mindset en vaardigheden vereist. Als u op het punt staat uw SONiC-reis te beginnen, zijn dit de belangrijkste vaardigheden waarvan ik wilde dat ik ze van tevoren had ontwikkeld.
1. Linux grondbeginselen verder dan de basis
SONiC is gebouwd op Linux, en dan bedoel ik ook ECHT erop gebouwd. In tegenstelling tot traditionele NOS'en, waar het onderliggende besturingssysteem verborgen blijft, stelt SONiC je bloot aan alles - systemd, containers, bash-scripts en meer. Basis Linux is niet genoeg. Je moet vertrouwd zijn met:
- Navigeren door het bestandssysteem
- Logboeken lezen in /var/log/
- Problemen oplossen met systemd diensten (systemctl status, journalctl)
- Gecontaineriseerde services beheren via Docker (docker exec, docker logs)
Als je nog nooit een Linux CLI hebt aangeraakt buiten SSH of ping, ben je snel verloren.
2. De containerarchitectuur begrijpen
SONiC is gebaseerd op microservices. Elke netwerkfunctie (BGP, LLDP, DHCP-relay) draait in zijn eigen Docker-container. Dat betekent het volgende:
- Logs zijn containerspecifiek.
- Netwerk namespaces kunnen verkeer isoleren.
- Storingen kunnen worden geïsoleerd naar een specifieke container zonder de rest van het systeem te beïnvloeden.
Ik moest mijn "monolithisch OS" instincten afleren, ik ben tenslotte opgegroeid met Cisco IOS waar alles gecentraliseerd is. Problemen oplossen is heel anders wanneer routeringsbeslissingen worden genomen in de ene container en interfaces worden beheerd in een andere.
3. Werken met Redis en het SONiC DB-model
SONiC gebruikt een Redis DB als tussenpersoon tussen configuratie, toestand en de onderliggende hardware abstractielaag. Er zijn meerdere logische DB's - CONFIG_DB, STATE_DB, APPL_DB - die elk een verschillend doel dienen. Dit moet je weten:
- Hoe DB-items te bevragen (redis-cli -n keys *)
- Het schema (hulp bij SONiC YANG-modellen)
- Hoe de swss-processen gegevens van Redis gebruiken
Ik wou dat ik vooraf meer tijd had genomen om het DB-schema en de orkestratiepijplijn van SONiC te begrijpen, dat had me veel hoofdbrekens bespaard.
4. Git en broncode-navigatie
SONiC is open source. Als er iets kapot gaat of zich niet gedraagt zoals verwacht, is de kans groot dat uw zoekopdrachten leiden naar openbare GitHub-problemen, u kunt zelfs de broncode lezen, of als u het lef hebt, het systeem zelf bouwen/debuggen. Het helpt om een goed begrip te hebben van:
- Git basisbeginselen (clone, diff, branch)
- Python/C++ code lezen (vooral in swss, syncd, orchagent)
- Afbeeldingen bouwen via het SONiC bouwsysteem
BTW, als u ondersteuning op SONiC krijgt van een fabrikant, integrator of partner, hoeft u het bovenstaande waarschijnlijk nooit te doen, maar ik probeer altijd nieuwe dingen te leren.
5. DevOps en automatiseringsmentaliteit
SONiC is oorspronkelijk gebouwd voor beheerders op cloudschaal. Handmatige configuratie wordt afgeraden. Omarmen:
- Terraform-middelenblokken
- Ansible-afspeelmappen
- Configuratiebeheer via config_db.json
- Beeldbeheer en ZTP
- CI/CD-pijplijnen voor netwerkwijzigingen
Als je nog steeds regel voor regel configuraties bewerkt via CLI, dan doe je het verkeerd.
Conclusie
SONiC is niet zomaar een NOS - het is echt een platform dat toekomstige netwerkmogelijkheden mogelijk maakt. Het beloont engineers die denken als SRE's en straft degenen die vasthouden aan legacy workflows. Ik heb veel geleerd van mijn ervaringen met SONiC, maar als ik terug kon gaan, zou ik meer voorbereiden op Linux, containers en automatisering. SONiC is de toekomst van open netwerken - wees alleen klaar om een level omhoog te gaan als je daar aankomt.
Josh Saul
VP Product Marketing
Josh Saul is al meer dan 25 jaar pionier op het gebied van open source netwerkoplossingen. Als architect bouwde hij kernnetwerken voor GE, Pfizer en NBC Universal. Als ingenieur bij Cisco adviseerde Josh klanten in de Fortune 100 financiële sector en evangeliseerde hij nieuwe technologieën bij klanten. Meer recent leidde Josh marketing- en productteams bij VMware (overgenomen door Broadcom), Cumulus Networks (overgenomen door Nvidia) en Apstra (overgenomen door Juniper).
