NAV referansegruppemøte 5. november 2024
NAV-ref Home
Tilstede:
Peder Smart Sefland, HiVolda
Rune Kittelsen, UiA
Øyvind Nesland, UiA
Børge Brunes, UiT
Nils-Arild Grav, NTNU
Sigurd Refvik, UiO
Morten Werner Forsbring, UiO (Forlot møtet etter ca. 1 time)
Vidar Faltinsen, Sikt
Hanne Moa, Sikt
Johanna England, Sikt
Simon Oliver Tveit, Sikt
Ilona Podliashanyk, Sikt
Morten Brekkevold, Sikt
Forfall:
Agenda
Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 09:00 til 12:00.
0. Velkommen/Innledning
Morten ønsker velkommen på vegne av Sikt.
1. Presentasjoner/Status
NAV
Det har siden sist ikke skjedd stort på funksjonalitetsfronten i NAV. Utviklerteamet har i hele år vært i innspurt på andre prosjekter enn NAV, og det var også grunnen til at det ble et halvår mellom forrige møte og dette. Disse prosjektene begynner å komme i mål, og Sikt ønsker derfor fornyet satsing på NAV i 2025.
Teamet har fortsatt jobbet iherdig med å blitt kvitt teknisk gjeld, slik at NAV vil være i stand til å kjøre på Python 3.11 - og dermed også på OS-distribusjoner som fortsatt vil få sikkerhetsoppdateringer i tiden fremover. Imidlertid har vi siden sist møte funnet en fungerende strategi, og jobber med å bli kvitt avhengigheter som holder oss fast på gamle Python-versjoner.
Overordnet issue her er Make nav run on python3.11 #2788, men det forløsende arbeidet ligger i Get rid of crispy-forms #2794.
Vi har hatt sommerstudent Jørund på plass i hele sommer og på deltid i høst, til å jobbe med DHCP-statistikkinnsamling fra KEA DHCP-tjenere, og har kommet mye lenger i en brukbar definisjon av hvordan DHCP-statistikk skal se ut og integreres i NAV. Jørund ser i den forbindelse også på hvordan vi kan få inn management profiles for utstyr som støtter REST-API-er, noe som i første omgang er aktuelt å ta i bruk ifm. Palto Alto-bidraget fra UiT. Vi satser på at begge disse bidragene skal bli tiljgengelige i NAV 5.12 før året er omme.
På forrige møte ble det vedtatt et aksjonspunkt som vi dessverre ikke har fått jobbet med:
Sikt utarbeider en redegjørelse for status på, og evt. manglende
spesifikasjon av de enkelte punktene på arbeidslisten og sender ut denne til
nav-ref for vurdering i forkant av neste møte, slik at alle har et
utgangspunkt for å vurdere/revurdere hva som står på listen.
Vi foreslår å utsette dette til neste gang. Det tegner uansett til å bli behov for mer tid til å diskutere nye behov i NAV i dette møtet.
1 feature-release siden forrige møte: NAV 5.11.0
Argus
Sikt tilbød, på tampen av 2023, hele sektoren å få en gratis sky-deployment av Argus i 2024, som et slags pilotprosjekt. Ingen har meldt seg interessert i dette. Derimot har et par kunder uttrykt ønske om å få Argus på verktøykassen i stedet for i sky. Dette er noe vi vurderer for 2025.
Som tidligere nevnt har GÉANT NOC fattet interesse for Argus, og mye av 2024 har vært brukt på å bygge et nytt brukergrensesnitt til Argus, basert på HTMX. Dette er teknologi som hele utviklerteamet behersker, det gjør Argus-grensesnittet mer tilgjengelig for skreddersøm (som er den viktigste funksjonen for GÉANT) og det gjør det enklere å installere og drifte en Argus-installasjon.
2. Fokus for videre utvikling/tilbakemelding
3. Nye ønsker og innspill fra gruppen
Runde rundt “bordet”. Skriftlig innmeldte saker tas først.
UiT
Sikt/CNaaS
Sikts CNaaS-team har meldt inn sin egen prioriterte liste over ønsker/problemer i NAV:
Støtte for Palo Alto: ARP + ruterportliste m.m.
Topologiavledningen “fungerer ikke” - workshop for å se på konkrete case - og jakte bugs
Portadmin: config template / port profil
Portadmin: Se livedata - hvem er pålogget en port
Linkstat: ønsker å ha stat på peak-in og peak-out - altså samle på max verdier for historien
CPU-stat: se avg verdi over 5 min
Dashboard-deling som oppdateres når dashboard eier gjør endringer i sitt “master dashboard” (use case: vi setter opp et delt dashboard til CNaaS-kunder og så utvikler vi det dashboardet over tid)
PAT-statistikk - ønsker å se ledige TCP og UDP porter i NAT poolene
Støtte for Aruba CX-svitsjer (svitsjeporter, brotabell) (må kanskje bruke REST
API?)
Støtte for Dell blade svitsjer (svitsjeporter, brotabell)
Hente inn faktisk strømforbruk fra power supplies på utstyr. Da kan vi regne på faktisk strømforbruk og det er interessant i disse bærekraftstider
NTNU
Øyeblikksbilde/livedata av portstatus på SDA-svitsj (eks VRF (VN), VLAN, SGT, Autentisering, type utstyr, maskinnavn, IP, MAC, hastighet, link, portbeskrivelse)
Tilgangsstyring for kun tilgang til endring av portbeskrivelse
Mulighet for registrering av utstyr(MAC) for MAB-autentisering, ref iotroam-løsning presentert i tidligere NAV ref-gruppemøte
Dot1x-admin på Cisco-svitsjer utenfor SDA
Last seen-filteret - ønsker mulighet for også å kunne se alle porter med aktivitet nyere enn x dager. I dag er det kun mulighet til å vise porter som ikke er brukt etter mer enn x dager.
MFA-innlogging ønskes i NAV, ref #2613
4. Neste møte
Vi velger neste møtedato. Medio mars?
Referat
0. Velkommen/Innledning
Morten ønsket velkommen på vegne av Sikt. To nye (avhengig av hvordan man ser det) fjes stilte i møtet, slik at møtet startet med en presentasjonsrunde.
Rune Kittelsen (UiA) pensjonerer seg i 2025. Øyvind Nesland stilte som hans potensielle arvtaker i gruppen.
Morten Werner Forsbring stilte i tillegg til Jan Sigurd Refsvik for UiO. Morten Werner er seksjonssjef for Nettdrift på UiO, og var også NAV-utvikler for mange år siden.
Børge Brunes stilte som stedfortreder for Ingeborg Hellemo (UiT). Børge satt i nav-ref i flere år før Ingeborg tok over, så han kjenner allerede gruppen godt.
Peder Smart Sefland meddelte at dette dessverre ble hans siste møte i referansegruppen, da han har sagt opp sin stilling ved HiVolda for å bli selvstendig næringsdrivende. Andreas Høydalsvik blir mest sannsynlig hans arvtaker i gruppen.
1. Presentasjoner/Status
Morten gjorde rede for status på NAV og Argus, for det meste slik det fremkom av agenda.
2. Fokus for videre utvikling/tilbakemelding
Tilbakemeldinger på #1501 (Log changes to IP devices)
Støtte for ny type Comet-miljøprobe hos UiT
UiT har (som nevnt på forrige møte) kjøpt et nytt miljøprobe-produkt fra Comet, som dessverre ikke er støttet av NAV i dag (Comet er en leverandør som ser ut til å produsere en helt ny MIB for hvert produkt de lager). AKSJON UiT tar selv ansvar for å lage et NAV-issue med ønske om støtte for produktet, og dokumenterer ved å legge ved den relevante MIB-definisjonen.
3. Nye ønsker og innspill fra gruppen
UiT og Sikt/CNaaS sendte inn skriftlige punkter i forkant. NTNU la inn skriftlige punkter underveis i møtet.
UiT
AKSJON: Lag et GitHub-issue for å kartlegge evt. nye behov for VRF-støtte i NAV og be de som er interessert i dette kommentere på issuet.
-
AKSJON: Kartlegg hva som skjedde sist dette ble forsøkt løst og legg inn som en kommentar på #2915
Til sist rekker Børge slenge inn et kommentar om at UiT gjerne skulle ønsket støtte for overvåkning av OSPF i NAV, men det blir ingen diskusjon om innholdet i forslaget, så UiT henvises til å poste et issue GitHub-trackeren om det.
Sikt/CNaaS
Sikt/CNaaS raste gjennom sin egen ønskeliste uten at det ble noen større diskusjon om innhold eller løsningsforslag. Slik diskusjon kan evt. lett tas på “bakrommet”, da utviklerne stort sett har fysisk kontorsted i samme lokale som CNaaS-teamet.
CNaaS har også behov for ARP-innsamling fra Palo Alto-brannmurer, etter å ha tatt over noen fra nye kunder. Men, det er dessverre bugs i tillegget som UiT bidro med.
AKSJON: Utviklerne registrerer GitHub-issue på den aktuelle buggen i Palo Alto-pluginen i ipdevpoll.
CNaaS registrerer også at det fullstendig mangler informasjon om ruterporter fra Palo Alto-brannmurer.
CNaaS-teamet opplever problemer med NAVs topologiavledning på en del kundenett.
CNaaS-teamet ønsker seg “portprofiler” i PortAdmin.
-
AKSJON: Knut-Helge bør lese #2598 og kommentere der om han har noe konkret å tilføye, f.eks. for Juniper-utstyr, som CNaaS bruker.
Kan tenke seg å se “live” portdata om 802.1X-tilstand på en port
F.eks.
Dynamisk valgt VLAN
Pålogget brukernavn
-
Oktett-tellere på porter blir i dag aggregert over tid med gjennomsnittsverdier. Her ønsker CNaaS-teamet at det også ble aggregert minimums og maksimumsverdier (slik det ble gjort da NAV brukte rrdtool
.
AKSJON: Utviklerteamet lager et GitHub-issue og dokumenterer behovet for Graphite-research, da Graphite ikke umiddelbart støtter multiple aggregeringsmetoder for samme metrikk. Fører formodentlig til tredobling av lagringsbehovet, om vi finner en løsning.
Mener CPU-lastdatene som hentes inn av NAV i dag er et øyeblikksbilde som er kunstig forhøyet i innsamlingsøyeblikket pga. utstyrets arbeid med å besvare SNMP-forespørselen som henter dataene. Det påstås at det skal være mulig å hente ut gjennomsnittsverdier for siste 5-minuttersperiode i stedet.
AKSJON: Kilde for dette er visstnok Vidar Stokke, som også har noen MIB-referanser. Han bør snarest opprette et GitHuub-issue som dokumenterer behovet og aktuelle MIB-er.
Ønsker muligheten for deling av dashboards mellom brukere
Ønsker innsamling av Port-Address-Translation-data fra Juniper SRX-brannmurer. Uklart både hvordan dette skal fungere i NAV eller hvor dataene kan hentes fra.
AKSJON: Knut-Helge bes registrere issue på GitHub for å dokumentere behovet.
Ønsker støtte for VLAN-informasjon og CAM-data fra Aruba CX-switcher.
Ønsker støtte for VLAN-informasjon og CAM-data fra Dell Blade-switcher.
Til sist kom det inn et ønske med et bærekraftsperspektiv: Kan NAV hente inn informasjon om faktisk strømforbruk fra utstyr?
Litt uklart her hva som skal hentes inn. CLI gir formodentlig mulighet for å hente ut et øyeblikksbilde på effektforbruk (Watt), men dette sier jo ingenting om energiforbruk over tid (Watt-timer).
Effektforbruk kan grafes, men hvordan oppsummerer man best energiforbruk over tid?
Hvordan er MIB-støtten for å hente ut slikt på forskjellig utstyr?
AKSJON: Utviklerteamet kan registrere et GitHub-issue, men dette krever noe kartleggingsarbeid som CNaaS-teamet selv må fylle på med.
Chatlog fra Vidar F:
Eksempel her er en boks med to stykk strømforsyninger på 920W. Men den bruker faktisk bare 76+16W.
fpc 0:
-------------------------------------------------------------------------
PSU 0 (JPSU-920W-AC-AFO ) : 860 W Online
PSU 1 (JPSU-920W-AC-AFO ) : 860 W Online
Power redundancy configuration : N+0
Total power supplied by all online PSUs : 1720 W
Base power reserved : 120 W
Non-PoE power being consumed : 76 W
Total power allocated for PoE : 1440 W
Total PoE power consumed : 16 W
Total PoE power remaining : 1424 W
NTNU
Gjentar ønsket om at NAV samler inn ytterligere port-data fra Cisco SDA (Software Defined Access). Sist nevnt på
navref_050324
AKSJON: Morten finner tilbake skjermbildet Nils-Arild oversendte den gangen og oppretter et GitHub-issue.
NTNU bruker aktivt søket Last seen (days ago)
under fanen Netbox interfaces
i et Room-view (/search/room/<roomid>/#!netboxinterfaces
) for å finne porter som ikke har vært i bruk de siste N
dagene. Men, de kan også tenke seg et invertert søk, altså formodentlig at man kan vise alle porter som *har vært i bruk* de siste N
dagene.
AKSJON: Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.
Ønsker seg muligheten til å begrense PortAdmin-brukere til å bare konfigurere port-description, ikke VLAN og andre ting.
AKSJON: Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.
-
-
UiA
UiA har ingen spesielle ønsker de vil trekke frem denne gang, ut over at de ønsker seg Argus som nytt verktøy på verktøykassen.
UiO
Morten Werner måtte forlate møtet tidlig, men etterlot seg en skriftlig liste som Jan Sigurd gikk gjennom.
UiO støtter arbeidet med å komme opp på siste Debian Stable (python3.11-jobbinga).
Databaseskjema - er det noen tanker med å se på hvordan man kobler sammen tabeller, overgang til relasjonell databasemodell?
AKSJON: Det var uklart for både møtet og Jan Sigurd hva Morten Werner mente med dette punktet, all den tid NAV alltid har brukt en relasjonsdatabase. Kan Werner klare opp i kommentaren?
Overvåking av transceivere - hente ut alarmgrensene med alarmer ved overskridelse.
Overvåking av bias-spenning på tranceivere for å se at disse ikke endrer seg.
Morten B mener dette muligens allerede samles inn og grafes, i alle fall for Cisco. Dette registreres som sensorer på en boks, men det er ikke alltid garantert at NAV klarer å koble en sensor opp mot en spesifikk port på boksen, slik at den i stedet blir liggende i den generelle oversikten over sensorer som fins på boksen.
Jan Sigurd fant muligens en slik sensor da han så etter i egen NAV-installasjon, og det ble spørsmål om ikke NAV kunne tilby manuel kobling mellom en sensor og en port om ikke NAV oppdaget dette automatisk.
AKSJON:: Jan Sigurd eller Werner verifiserer om de finner de aktuelle datene i sin NAV-installasjon. Anbefales å opprette GitHub-issue om de ikke gjør det, eventuelt opprette issue på manuell kobling mellom sensorer og porter, som for så vidt er en god idé.
Noe som har kommet opp ifm. Vikingtidsmuseet og grønt IT er mulighet for å gjøre noe med PoE-porter på kvelds- og nattestid (natt-senking eller skru helt av på kveld/natt), kanskje løst med kron på switchene. Ikke sikkert det er riktig å gjøre noe med dette i NAV, men greit å høre om dette er noe andre har tenkt på eller er interessert i.
Litt diskusjon rundt dette avstedkom egentlig ingen gode svar, men heller ingen sterk mening om at dette hører hjemme i NAV.
UiT mener at Cisco allerede har noe funksjonalitet som tar ned aksesspunkter via PoE der det er lite behov for dem. Dette har vært så irriterende at de har pleid å slå det av.
Morten B foreslår at i den grad NAV har mulighet for å skru på PoE-options på utstyr (som PortAdmin i noen grad kan gjøre), haddet kanskje vært bedre om NAV tilbød et
API for å gjøre dette utenifra, så UiO kunne bygd noe eget oppå dette.
Foreslår at UiO heller tar opp dette på et senere tidspunkt om det fremdeles er aktuelt.
HiVolda
Peder meldte et par ting i Zoom-chatten i starten av møtet, før vi kom til runden rundt bordet:
Peder har ellers ingenting spesielt å melde denne gangen, ut over at det blir hans siste nav-refmøte, ettersom han har sagt opp sin stilling på HiVolda. Andreas Høydalsvik blir mest sannsynlig hans arvtaker i gruppen, og bør formodentlig inn på epostlista.
Vi takker Peder for lang og tro tjeneste!
4. Neste møte