NAV referansegruppemøte 24. september 2026

NAV-ref Home | forrige møte

Tilstede:

• Øyvind Nesland, UiA (video)
• Ingeborg Hellemo, UiT (fysisk)
• Nils-Arild Grav, NTNU (video)
• Knut-Helge Vindheim, Sikt (fysisk)
• Hanne Moa, Sikt (fysisk)
• Johanna England, Sikt (video)
• Simon Oliver Tveit, Sikt (fysisk, kom 11:15)
• Aleksander Fløtten, Sikt (fysisk)
• Morten Brekkevold, Sikt (fysisk)

Forfall:

• Morten Werner Forsbring, UiO
• Sigurd Refvik, UiO
• Vidar Faltinsen, Sikt

Møtet blir avholdt fysisk i Sikts lokaler i Teknostallen (Professor Brochs gate 8A), men med mulighet for påkobling med video. Møtetid 09:00-12:00.

• NAV 5.18.1
  • Bugfiksrunde, blant annet de to sakene som ble oppdaget under demo på forrige møtes (alias-sletting, MFA/TOTP-innloggingsløkke)
• NAV 5.19.0
  • CAM-logging for enheter bak “unmanaged” naboer – Machine Tracker kan nå finne utstyr (og sluttbrukerenheter) bak f.eks. Crestron-kontrollere og annet ikke-SNMP-utstyr. Løser den tilbakevendende saken #2915 som har vært diskutert på flere tidligere møter. Må skrus på eksplisitt, se [cam]-seksjonen i ipdevpoll-dokumentasjonen.
  • Fikset feil/manglende naboskap på Juniper-aggregat (LAG/ae)-interfaces, og at VLAN falt bort på samme type oppsett (#4029, #1687)
  • Interface-detaljer viser nå hele aggregat-/stacking-hierarkiet som et tre, inkludert MLAG-naboer, slik at man får bedre oversikt over hvordan interface-stacken og naboskapsinformasjonen faktisk er organisert.
  • Nye REST API-endepunkter: maintenance-tasks, organisasjoner, gwportprefix
  • Aliaser vises nå som tooltip i IP device info
  • Nytt navdashboard-CLI-verktøy for å liste/eksportere/importere dashboards
  • Forbedret 2FA-oppsett med tydeligere status og veiledning
  • (I tillegg: Django oppgradert til 5.2, samt en del opprydding/refaktorering under panseret)

De siste møtene har inneholdt mange topologi-diskusjoner, og NAV 5.19 satte seg fore å løse mange av de opplevde problemene. En gjenganger er rapporter om at topologi “henger igjen” på porter som er nede. Dette er et bevisst valg i NAV, fordi overgangen operUp til operDown regnes som en midlertidig feiltilstand som ikke skal forstyrre topologiforståelsen. Dersom porten derimot går fra operUp til admDown, forstås dette som et villet/konfigurert nedetilstand, og topologien oppdateres umiddelbart. Dette designvalget er nok noe underkommuinisert i NAVs dokumentasjon. Noen halvgode ideer har også blitt lansert for hvordan NAV kan oppdage at topologien er utdatert på en port som er nede (f.eks. at naboen blir oppdaget et annet sted i topologien).

Hva med en knapp på port-details-siden som lar admins manuelt fjerne utdatert topologi-informasjon, kan det være noe?

Vi opplevde nylig den sjelden “Verden er nede”-situasjonen på en kundeinstallasjon av NAV. Serveren mistet konnektivitet til nettverket og varslet alle bokser som nede. Denne problemstillingen har vært diskutert ved noen anledninger tidligere, for mange år siden. Dette har aldri resultert i et faktisk feature-ønske i issue-trackeren, og vi lurer på om vi kanskje kan få til en brukbar diskusjon i gruppen?

• Hadde det vært mer rasjonelt at NAV innså problemet og i stedet for hundrevis av alarmer lagde en enkelt “verden er nede”-alarm?
• Hvordan skal i såfall dette oppdages?
• Hvordan skal alarmen se ut?
• Hva skjer når ting kommer opp én og én boks av gangen etter utfallet?

#2598 har ligget på arbeidslisten siden det først ble nevnt i referatet fra 25. mai 2021, uten at vi har klart å lande en løsning. Spesifikasjonen er fortsatt vag, og vi trenger en reell avklaring fra gruppen på noen konkrete spørsmål før dette kan bli en implementerbar oppgave:

• Lagring av profiler: Skal internt konfigurerte port-profiler lagres i en konfigurasjonsfil, eller i databasen? Og hvilke attributter må en profil kunne inneholde?
• Global eller enhets-lokal: Skal profiler være globale for hele NAV-installasjonen, eller må det finnes en måte å knytte et subsett av profiler til enkeltenheter eller enhetsgrupper?
• Mapping til utstyrs-interne profiler: Noen leverandører har et internt config-konsept for profiler/“templates” (f.eks. JunOS interface ranges, CNaaS-NMS sine configtyper/-maler). Skal NAV eksponere/gjenbruke slike, og for hvilke plattformer i så fall?

Mål for denne bolken: få en tydelig retning på spørsmålene over, slik at vi kan bryte #2598 ned i konkrete, implementerbare underoppgaver.

• NTNUs ønske om å begrense PortAdmin-brukere til kun å endre portbeskrivelse (#3298): Simon har en PR ute (per-attributt-rettigheter i PortAdmin – vlan, beskrivelse, admin-status, PoE, voice-vlan, trunk kan styres hver for seg), men den er ikke godkjent/merget ennå - men potensielt demo-bar til møtet.
• #1936 (dynamisk VLAN-visning): fortsatt noen åpne underoppgaver (MIB-identifikasjon, datamodell, API), men teamet tror de er klare til å fullføre dette i neste sprint.
• Fortsatt uten fremdrift: #3217 (SDA-portstatus), #3300 (MAB-enhetsregister), #2164 (dot1x-admin på Cisco)

Runde rundt “bordet”. Foreløpig ingen forhåndsinnmeldte saker.

Vi velger neste møtedato. Medio desember?

Sikt ønsket velkommen til møte, det første med invitasjon til fysisk oppmøte på en stund - et tilbud som av de eksterne dessverre bare ble benyttet av UiT. Vi melder tilbake til arrangementskomité for Nett- og cybersikkerhetssamlingen at det hadde vært en stor fordel om neste utgave gikk av stabelen tirsdag-torsdag, slik at det er lettere å legge sidemøter både før og etter konferansedagene.

NAV-releasene siden forrige møte (5.18.1 og 5.19.0) ble gjennomgått som beskrevet i agendaen.

Rett etter NAV-release-bolken kom det opp en diskusjon om Argus som kommende verktøy på VK-plattformen:

• UiA har mange systemer/kilder som i prinsippet kunne sendt alarmer inn i Argus, men vet ikke hvelt hvordan de vil integrere.
  • Utviklerne nevner intern etterspørsel i Sikt etter en “kommandolinjeklient” for de som ikke er villige til å investere tid å utvikle en fullbåren klient i Python (vha. pyargus-biblioteket). Om Sikt lager noe slikt kan det være et lavterskeltilbud til shell-scripting.

Gruppen var positiv til idéen om en knapp for å manuelt fjerne utdatert topologi-informasjon fra port-details-siden.

• AKSJON: Trenger et issue i tracker.
  • #4223

I samme slengen kom det opp at “Last used: Never” på en port som samtidig viser link nå, er en forvirrende og lite meningsfull melding – gjelder både port-listen for enkeltbokser og room-interfaces-visningen. Forslag fra gruppen: Bytt ut “Never” med “N/A” i disse tilfellene.

• AKSJON: Trenger et issue i tracker.

Anti-burst-mekanismer for alarmutsending ble diskutert - dette trengs også i Argus. Det holder ikke at en slik mekanisme kun finnes i SMS-daemonen (som slår sammen alle utgående meldinger til samme nummer innenfor et 30-sekunders vindu).

• Det bør være mulig å lage en egen “verden er nede”-alarm for 100%-tilfellet (alt nede samtidig).
  • Det som er vanskelig er hvordan håndtere tilfellet at bare deler av verden kommer opp igjen.
  • Dette er tildels et problem som ligner på boxShadow-problemet: boxShadow-tilstander blir aldri re-evaluert dersom boksen “foran” i topologien kommer opp igjen, for boxShadow-alarmen ikke har noen kobling til boxDown-alarmen som forårsaket den i utgangspunktet (i.e. det er ingen måte å oppdage hvilken korrelasjon som opprinnelig ble gjort av eventengine).

Vi bør tenke gjennom flere løsninger, både kortsiktige og langsiktige. Ingen revolusjonerende idéer falt ut av skapet under selve møtet.

• AKSJON: Trenger et issue i tracker for oppfølging.

Det virker som det er konsensus om at det som trengs er profiler som inneholder konfigurasjons-“snippets”, og at det er forgjeves å forsøke å lage en løsning som også skal støtte SNMP-konfigurasjon. Det betyr at en profil må potensielt ha et sett med “templates” med config for forskjellige vendors. Mer viktig er at dette betyr at det i dag bare vil være mulig å støtte en slik løsning for Juniper, der PortAdmins backend er NETCONF-basert (en NAPALM-profil i NAV).

• Inntil medlemmene får gransket sine egne behov nærmere kan det virke som at et første steg fra utviklingsteamet vil være å se på hvordan det kan bygges en tilsvarende NETCONF-basert backend også for Cisco-utstyr.
  • CNaaS har Cisco-utstyr som kan settes opp i lab til dette formålet.
    • AKSJON: Lenk opp issue.

Det må også gjøres en jobb for å avklare/definere hvordan en operatør skal velge gyldighetsområde for en profil: D.v.s., skal en profil kunne begrenses til et subsett med enheter i nettet, og hvordan er utvalgskriteriet for en slik begrensning? (For eksempel, ser en “printerport”-profil lik ut på alle fysiske lokasjoner eller organisatoriske enheter i organisasjonen?)

Knut-Helge mener multi-profil (flere profiler kan gjelde samtidig for én port) er aktuelt, slik CNaaS-NMS allerede løser det(“tagging”). Et uavklart spørsmål er da om og hvordan man unngår å la brukerene velge profiler som er i konflikt med hverandre.

I forbindelse med diskusjonen om tilgangsbegrensninger i PortAdmin (#3298) kom Knut-Helge med et interessant grensetilfelle: En konsulent var leid inn for å portscanne en organisasjon fra alle VLAN. Han forsøkte å gi konsulenten fri tilgang til å konfigurere en enkelport (som han selv var oppkoblet mot), så han kunne bytte sitt eget VLAN for hver scannejobb - men dette var ikke mulig med web_access-privilegier alene i NAV. Ingen direkte konklusjon på hvor nyttig dette var, men mulige workarounds som ble diskutert var:

• Gi konsulenten en trunk-port så de kan tagge pakkene med VLAN selv. Dette er kanskje ikke mulig på en Windows-PC?
• Gi konsulenten en switch med trunk til uplink og forskjellig VLAN på hver port. Konsulenten bytter fysisk port for hvert scanneforsøk.

Runde rundt bordet:

• Opplever problemer med at man ikke kan registrere scope-prefix som samtidig rutes, da NAV vil endre klassifiseringen av scope-prefikset basert på funn på ruterport.
  • Dette er et kjent “problem”, da NAV blander “kart” og “terreng” i samme modell. Dette er samme grunn til at enkelte ikke ønsker å bruke NAV som en IPAM-løsning.
  • Uklart hvordan dette kan løses.
    • AKSJON: Trenger et issue i tracker?
• Netmap: ønsker å kunne se L2 og L3 på samme nivå/i samme visning. Uklart hvordan dette skal fungere.
  • AKSJON: Knut-Helge tar initiativ til et møte med utviklerne for å definere hvordan et slikt kart skal tegnes for at det skal gi mening.
• Ønsker seg en funksjon for å bruke eksisterende bokser i SeedDB som mal for nye. Det ble påpekt og demonstrert at dette allerede fins i “copy”-knappen.
  • UiT nevner en bugrapport i denne funksjonaliteten i samme slengen: Auditlog registrerer ikke en kopiert netbox som nyopprettet, men som redigert (Audit Log should log copied items from SeedDB as created, not edited #4017)

Ingen nye saker denne gangen.

• Ønsket om et utstyrsregister for MAB-autentisering ser fremdeles ut til å sammenfalle med funksjonalitet som tilbys av iotroam, som Sikt nå jobber med å sette opp en pilot av. Vi oppfordrer til å se på iotroam fremfor å bygge noe eget i NAV.
  • AKSJON: Morten ber Vidar Stokke sende gi beskjed til Nils-Arild/NTNU når iotroam er oppe og går i pilot.

• Duplikate VLAN-referanser som kommer og går - “hvorfor har vi så mange vlan 300?”.
  • Dette har faktisk vært et kjent problem i mange år, men dette er første gangen noen har klagd.
  • Morten undersøkte nettopp dette problemet før sommeren, ifm. de forbedringene som ble gjort i topologiavlederen etter forrige nav-ref.
    • AKSJON: Morten sammenfatter funnene sine i et nytt issue i trackeren.

Neste møte: 26. januar 2027, kl. 09:00-12:00, over video.