Infrastructure as Code og AI i netværksdrift

Netværksdrift ændrer sig. Før loggede man ind på hver enkelt switch og skrev kommandoer. I dag styres netværk i stigende grad fra controllere, cloud-portaler, kode og AI-assistenter. Derfor har CCNA 200-301 v2.0 et helt domæne om det: 5.0 AI, and Network Operations and Management (10 %). I denne artikel gennemgår vi emne 5.1–5.3: agentic AI, prompts til generativ AI og management-tilgange, herunder Infrastructure as Code (IaC).

Fem måder at styre et netværk på (emne 5.3)

1. Enhedsbaseret (device-based)

Du logger ind på hver enhed med SSH eller konsol og konfigurerer den via CLI eller en web-GUI. Det giver fuld kontrol over den enkelte enhed, men skalerer dårligt og giver let afvigelser (configuration drift) mellem enhederne.

2. Controller-baseret

En central controller, fx Cisco Catalyst Center eller en trådløs controller (WLC), styrer mange enheder. Du beskriver hensigten ét sted, og controlleren skubber konfigurationen ud. Man taler om northbound API’er (fra applikationer til controlleren) og southbound API’er/protokoller (fra controlleren til enhederne).

3. Cloud-baseret

Controlleren ligger i skyen, fx Cisco Meraki. Enhederne “ringer hjem”, og du styrer dem fra en webportal. Det er nemt at komme i gang med og passer godt til mange små lokationer, men det kræver internetforbindelse, og du afhænger af leverandørens platform.

4. Automationsbaseret

Scripts og værktøjer som Python eller Ansible udfører opgaverne. Du automatiserer det, du ellers ville gøre manuelt, fx backups, standardkonfiguration og indsamling af status. Se vores artikel om Ansible.

5. Infrastructure as Code (IaC)

Hele netværkets ønskede tilstand beskrives som kode eller data (fx YAML), som gemmes i versionsstyring (Git). Ændringer laves som commits, gennemgås af kolleger (pull requests), testes automatisk og rulles ud af en pipeline.

Infrastructure as Code i praksis

IaC bygger på et par grundprincipper:

• Én sandhedskilde (source of truth): Fx en Git-mappe med YAML-filer eller et værktøj som NetBox. Netværket skal afspejle det, der står dér, og ikke omvendt.
• Deklarativ beskrivelse: Du skriver hvad du vil have (“VLAN 20 skal hedde Servere”), ikke hvordan det skal gøres trin for trin.
• Versionsstyring: Hver ændring kan spores, gennemgås og rulles tilbage.
• Idempotens: Kører du automatikken igen, sker der kun noget, hvis virkeligheden afviger fra det ønskede.
• Automatisk test og validering: Pipeline-trin kan tjekke syntaks, køre --check/dry-run og bagefter kontrollere, at netværket virker.

Et simpelt eksempel på en datafil i et IaC-repository:

# host_vars/SW1.yml
vlans:
  - id: 10
    name: Klienter
  - id: 20
    name: Servere
interfaces:
  - name: GigabitEthernet1/0/1
    mode: access
    vlan: 10

Et Ansible-playbook eller et Terraform-modul læser filen og konfigurerer switchen. Det svarer til at skrive:

SW1(config)# vlan 10
SW1(config-vlan)# name Klienter
SW1(config-vlan)# vlan 20
SW1(config-vlan)# name Servere
SW1(config-vlan)# interface GigabitEthernet1/0/1
SW1(config-if)# switchport mode access
SW1(config-if)# switchport access vlan 10

Forskellen er, at ændringen er dokumenteret, gennemgået og kan gentages på 500 switche.

Typiske værktøjer er Ansible, Terraform, Git, CI/CD-pipelines og NetBox. Danske jobopslag inden for netværksdrift nævner netop Ansible, Terraform, Python og NetBox oftere og oftere.

Agentic AI i netværksdrift (emne 5.1)

Generativ AI (fx en chatassistent) svarer på spørgsmål og producerer tekst eller kode. Agentic AI går et skridt videre: En AI-agent kan selv planlægge og udføre en række trin for at nå et mål. Den kan fx hente data fra værktøjer, køre show-kommandoer via API’er, analysere output og foreslå eller udføre en ændring.

Eksempler på anvendelse:

• Fejlsøgning: Agenten indsamler show-output, syslog og SNMP-data fra flere enheder, finder sammenhænge og foreslår en årsag.
• Ændringsforslag: Agenten laver et udkast til konfigurationen og en plan for tilbagerulning.
• Dokumentation: Agenten sammenholder den faktiske konfiguration med sandhedskilden og rapporterer afvigelser.

Vigtige forbehold, som du også skal kunne forklare:

• Mennesket i loopet: Ændringer i produktion bør godkendes af en person, især når agenten kan udføre kommandoer.
• Mindste privilegium: Giv agenten så lidt adgang som muligt, fx kun læseadgang.
• AI kan tage fejl: Generative modeller kan “hallucinere”, altså lyde sikre og alligevel være forkerte. Kontrollér output mod rådata.
• Sporbarhed: Log, hvad agenten har gjort og hvorfor.

Ifølge Ciscos v2.0-materiale kan eksamen bede dig vurdere output og anbefalinger fra agentic AI og digitale netværksassistenter. Du skal altså kunne se, om et AI-forslag er rigtigt.

Gode prompts til generativ AI (emne 5.2)

Cisco nævner fire komponenter i en prompt: dataklassificering, outputformat, persona og instruktioner.

Eksempel på en god prompt:

Du er en erfaren Cisco-netværkstekniker. Nedenfor er output fra show ip ospf interface og show ip ospf neighbor fra to routere (adgangskoder og offentlige adresser er fjernet). Find den mest sandsynlige årsag til, at de ikke danner naboskab. Svar i en tabel med kolonnerne Mulig årsag, Bevis i output og Kommando til at rette det. Foreslå ingen ændringer, der kan afbryde anden trafik.

En dårlig prompt er “hvorfor virker min OSPF ikke?” uden kontekst, uden data og uden ønsket format.

Det skal du kunne til eksamen

• Beskrive de fem management-tilgange og deres fordele og ulemper.
• Forklare IaC: sandhedskilde, deklarativ beskrivelse, versionsstyring og idempotens.
• Forklare, hvad agentic AI er, og hvilke risici og kontroller der hører til.
• Vælge den bedste prompt ud fra persona, instruktioner, outputformat og dataklassificering.

Relateret: vores artikler om Ansible og om Syslog og SNMP samt Running & startup configuration.