nav-ref:navref_051124
Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
| nav-ref:navref_051124 [2024/11/04 16:07] – lagt til en bit om DHCP sommerarbeid morten | nav-ref:navref_051124 [2025/03/12 06:31] (current) – ref til 3325 morten | ||
|---|---|---|---|
| Line 4: | Line 4: | ||
| - | Innkalt: | + | Tilstede: |
| * Peder Smart Sefland, //HiVolda// | * Peder Smart Sefland, //HiVolda// | ||
| * Rune Kittelsen, //UiA// | * Rune Kittelsen, //UiA// | ||
| * Øyvind Nesland, //UiA// | * Øyvind Nesland, //UiA// | ||
| - | * Ingeborg Hellemo, //UiT// | + | * Børge Brunes, //UiT// |
| * Nils-Arild Grav, //NTNU// | * Nils-Arild Grav, //NTNU// | ||
| * Sigurd Refvik, //UiO// | * Sigurd Refvik, //UiO// | ||
| - | * Morten Werner Forsbring, //UiO// | + | * Morten Werner Forsbring, // |
| * Vidar Faltinsen, //Sikt// | * Vidar Faltinsen, //Sikt// | ||
| Line 20: | Line 20: | ||
| * Ilona Podliashanyk, | * Ilona Podliashanyk, | ||
| * Morten Brekkevold, //Sikt// | * Morten Brekkevold, //Sikt// | ||
| + | |||
| + | Forfall: | ||
| + | |||
| + | * Ingeborg Hellemo, //UiT// (Børge Brunes er stedfortreder) | ||
| Line 26: | Line 30: | ||
| Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 09:00 til 12:00. | Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 09:00 til 12:00. | ||
| - | === 0. Velkommen/ | + | ==== 0. Velkommen/ |
| Morten ønsker velkommen på vegne av Sikt. | Morten ønsker velkommen på vegne av Sikt. | ||
| - | === 1. Presentasjoner/ | + | ==== 1. Presentasjoner/ |
| - | == NAV == | + | === 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. | 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. | ||
| Line 53: | Line 57: | ||
| 1 feature-release siden forrige møte: [[https:// | 1 feature-release siden forrige møte: [[https:// | ||
| - | == Argus == | + | === Argus === |
| Sikt tilbød, på tampen av 2023, hele sektoren å få en gratis sky-deployment av Argus i 2024, som et slags pilotprosjekt. | Sikt tilbød, på tampen av 2023, hele sektoren å få en gratis sky-deployment av Argus i 2024, som et slags pilotprosjekt. | ||
| Line 59: | Line 63: | ||
| 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. | 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/ | + | ==== 2. Fokus for videre utvikling/ |
| * Hva er det konkrete behovet bak [[https:// | * Hva er det konkrete behovet bak [[https:// | ||
| + | * Forrige gang meldte UiT inn et ønske relatert til en ny generasjon miljøprober fra Comet. | ||
| - | === 3. Nye ønsker og innspill fra gruppen === | + | ==== 3. Nye ønsker og innspill fra gruppen |
| Runde rundt " | Runde rundt " | ||
| - | == UiT == | + | === UiT === |
| * Støtte for VRF | * Støtte for VRF | ||
| Line 77: | Line 82: | ||
| * [[https:// | * [[https:// | ||
| - | == Sikt/CNaaS == | + | === Sikt/ |
| Sikts CNaaS-team har meldt inn sin egen prioriterte liste over ønsker/ | Sikts CNaaS-team har meldt inn sin egen prioriterte liste over ønsker/ | ||
| Line 92: | Line 97: | ||
| - Støtte for Dell blade svitsjer | - Støtte for Dell blade svitsjer | ||
| - 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 | - 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/ | ||
| + | - Tilgangsstyring for kun tilgang til endring av portbeskrivelse | ||
| + | - Mulighet for registrering av utstyr(MAC) for MAB-autentisering, | ||
| + | - 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 === | + | ==== 4. Neste møte ==== |
| Vi velger neste møtedato. | Vi velger neste møtedato. | ||
| - | ===== Referat ===== | + | ====== Referat ====== |
| + | |||
| + | ==== 0. Velkommen/ | ||
| + | |||
| + | 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, | ||
| + | |||
| + | ==== 1. Presentasjoner/ | ||
| + | |||
| + | Morten gjorde rede for status på NAV og Argus, for det meste slik det fremkom av agenda. | ||
| + | |||
| + | ==== 2. Fokus for videre utvikling/ | ||
| + | |||
| + | === Tilbakemeldinger på #1501 (Log changes to IP devices) === | ||
| + | |||
| + | Ingen i gruppen hadde tilbakemeldinger på hvordan [[https:// | ||
| + | |||
| + | === 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). | ||
| + | |||
| + | ==== 3. Nye ønsker og innspill fra gruppen ==== | ||
| + | |||
| + | UiT og Sikt/CNaaS sendte inn skriftlige punkter i forkant. | ||
| + | |||
| + | === UiT === | ||
| + | |||
| + | * Ønsker støtte for VRF i NAV. | ||
| + | * Litt uklart hva " | ||
| + | * Et aspekt som blir nevnt er at UiT ønsker å legge til alle virtuelle ruterinstanser som egne IP devices i NAV for å overvåke dem individuelt, | ||
| + | * Morten påpeker at sistnevnte allerede er støttet i NAV ved å registrere en " | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * UiT skal teste hvor godt denne funksjonaliteten dekker deres behov. | ||
| + | * Et annet aspekt som kanskje mangler er innsamling av data som bare fins på hver enkelt VRF. Dette fungerer kanskje fint så lenge man har en management-adresse per VRF og registrerer disse i NAV, men Knut-Helge kommenterer at CNaaS ikke gir egne management-adresser til VRF-er, og at NAV kanskje mangler ruting-informasjon for enkeltinstanser. | ||
| + | * :!: **AKSJON:** Uklart om VRF i CNaaS faktisk har problemer med NAV, om det i så fall er utstyrsspesifikt eller config-spesifikt. | ||
| + | * UiT nevner også et behov eller manglende støtte for overvåkning på lag 3, dvs. logiske linker mellom VRF-er som går ned, selv om fysisk link mellom boksene er oppe. Det er litt uklart hva som egentlig mangler her, og det bør UiT greie ut for i en egen VRF-issue. | ||
| + | |||
| + | < | ||
| + | |||
| + | * UiT gjentar et ønske om støtte for Cisco ACI (Application Centric Infrastructure, | ||
| + | * En Cisco ACI-kontroller kan ses på som en avansert ruter. | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * UiT ønsker å trekke frem denne igjen: ([[https:// | ||
| + | * Det er litt uklart hva dette skal inneholde, men prinsipielt skal Device History tilby slik funksjonalitet - men filtermulighetene her er ikke gode nok for UiT. | ||
| + | * CNaaS har en custom SQL-rapport i NAVs rapportsystem for hendelser siste 24 timer. Siden dette ligger i SQL-rapportsystemet er det ikke veldig fleksibelt, men kan dekke opp for noe av behovet for UiT. | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * < | ||
| + | * Vi har laget en " | ||
| + | |||
| + | * UiT trekker fram et gammelt issue som ble forsøkt løst for mange år siden, men hvor endringen måtte rulles tilbake: ([[https:// | ||
| + | * < | ||
| + | * Issue #2915 er egentlig et duplikat av et 12 år gammelt issue som ble forsøkt løst i to omganger, med svært uheldige resultater for NAV, og endringene ble derfor rullet tilbake. | ||
| + | * UiT ber også om oppmerksomhet for to bugs de tidligere har meldt inn: | ||
| + | * [[https:// | ||
| + | * [[https:// | ||
| + | * Det fremgår at det fremdeles var litt uklart hva beste løsning her egentlig er, da UiT og utviklerne er litt uenige om beste fremgangsmåte. | ||
| + | * Vi diskuterte oss frem til en viss enighet om at slettede bokser ikke skal forsvinne i løse luften fra maintenance-tasks, | ||
| + | * < | ||
| + | * Begge bugs ble lagt i backlog for inneværende sprint. | ||
| + | |||
| + | * 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. | ||
| + | |||
| + | * CNaaS har også behov for ARP-innsamling fra Palo Alto-brannmurer, | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * CNaaS registrerer også at det fullstendig mangler informasjon om ruterporter fra Palo Alto-brannmurer. | ||
| + | * Dette er formodentlig også fordi disse brannmurene heller ikke svare på de relevante MIB-ene med IP-informasjon. | ||
| + | * :!: **AKSJON:** Lage GitHub-issue om støtte for ruterport-innhenting fra Palo Altos API. | ||
| + | * CNaaS-teamet opplever problemer med NAVs topologiavledning på en del kundenett. | ||
| + | * Dette tas opp i en intern workshop, for det krever en litt interaktiv debug-sesjon med en interaktiv feedback-cycle mellom utviklere og nettverksingeniørene. | ||
| + | * :!: **AKSJON:** Knut-Helge tar initiativ til en workshop om topologiproblemer. | ||
| + | * CNaaS-teamet ønsker seg " | ||
| + | * Dette er i prinsippet [[https:// | ||
| + | * :!: **AKSJON:** Knut-Helge bør lese #2598 og kommentere der om han har noe konkret å tilføye, f.eks. for Juniper-utstyr, | ||
| + | * Kan tenke seg å se " | ||
| + | * F.eks. | ||
| + | * Dynamisk valgt VLAN | ||
| + | * NAVs VLAN-data for en port er potensielt opptil 6 timer gammelt, men er det noen grunn til at den VLAN-verdien NAV allerede samler ikke skulle være den samme som er dynamisk valgt av 802.1X? | ||
| + | * Pålogget brukernavn | ||
| + | * Er dette innafor personvernmessig sett, tro? | ||
| + | * :!: **AKSJON:** Knut-Helge bør evt. kommentere på de punktene som allerede er observert under [[https:// | ||
| + | * Oktett-tellere på porter blir i dag aggregert over tid med gjennomsnittsverdier. | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * 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. | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * Ønsker muligheten for deling av dashboards mellom brukere | ||
| + | * Allerede notert i [[https:// | ||
| + | * Ønsker innsamling av Port-Address-Translation-data fra Juniper SRX-brannmurer. | ||
| + | * :!: **AKSJON:** Knut-Helge bes registrere issue på GitHub for å dokumentere behovet. | ||
| + | * Ønsker støtte for VLAN-informasjon og CAM-data fra Aruba CX-switcher. | ||
| + | * Dette fungerer ikke i NAV i dag, primært fordi Aruba CX ikke implementerer '' | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * Ønsker støtte for VLAN-informasjon og CAM-data fra Dell Blade-switcher. | ||
| + | * Denne problemstillingen er ny for utviklerteamet, | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * Til sist kom det inn et ønske med et bærekraftsperspektiv: | ||
| + | * 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? | ||
| + | * Om man samler inn effektforbruk hvert minutt kan man f.eks. estimere energifobruket for dette minuttet ved å multiplisere effektforbruket med en faktor på '' | ||
| + | * Hvordan er MIB-støtten for å hente ut slikt på forskjellig utstyr? | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * 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 | ||
| + | PSU 1 (JPSU-920W-AC-AFO | ||
| + | Power redundancy configuration | ||
| + | Total power supplied by all online PSUs : 1720 W | ||
| + | Base power reserved | ||
| + | Non-PoE power being consumed | ||
| + | Total power allocated for PoE : 1440 W | ||
| + | Total PoE power consumed | ||
| + | Total PoE power remaining | ||
| + | |||
| + | |||
| + | === NTNU === | ||
| + | |||
| + | * Gjentar ønsket om at NAV samler inn ytterligere port-data fra Cisco SDA (Software Defined Access). | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * NTNU bruker aktivt søket '' | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * Ønsker seg muligheten til å begrense PortAdmin-brukere til å bare konfigurere port-description, | ||
| + | * < | ||
| + | * [[https:// | ||
| + | * [[https:// | ||
| + | * Ønsker også [[https:// | ||
| + | |||
| + | === 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? | ||
| + | * < | ||
| + | * Det virker som dette skyldes en misforståelse av hvordan NAVs room-tabell bruker romnavn som primærnøkler, | ||
| + | * // | ||
| + | * Morten B formoder dette dreier seg om at transceivere som regel kommer med egne hardkodete terskelverdier som kunne vært avlest og benyttet av terskelregler i NAV. Dette mener har i alle fall å huske har vært en diskusjon i stamnettsgruppa på Sikt. | ||
| + | * < | ||
| + | * Har funnet en del underlagsmateriale some er *Juniper-spesifikt*, | ||
| + | * // | ||
| + | * Morten B mener dette muligens allerede samles inn og grafes, i alle fall for Cisco. | ||
| + | * Jan Sigurd fant muligens en slik sensor da han så etter i egen NAV-installasjon, | ||
| + | * :!: **AKSJON: | ||
| + | * //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/ | ||
| + | * 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: | ||
| + | |||
| + | * //Innspill det med å bidra med kode til nav. Det er flott at det blir publisert en ferdig VM m/NAV. Men den er helt tom av data. Kunne vi også fått en versjon med syntetisk data, slik at vi kan teste på en ikke produksjonsdata?// | ||
| + | * Dette ble under møtet kanskje tolket annerledes enn det var skrevet, da VM-en (virtual appliance) vi tilbyr er mest for demo-formål, | ||
| + | * For ordens skyld kan vi legge til at utviklerne stadig bruker midlertidige kopier av produksjonsdata for testing og utvikling av funksjonalitet - i alle fall inntil det skal utvikles funksjonalitet som krever muligheten til å faktisk snakke med utstyr, da må vi ha tilgang til utstyr enten i labb eller produksjon. | ||
| + | * Ellers nevner Peder gjentatte ganger forslag om å utvide NAV-databasen (PostgreSQL) til en vector-database med [[https:// | ||
| + | * https:// | ||
| + | |||
| + | Peder har ellers ingenting spesielt å melde denne gangen, ut over at det blir hans siste nav-refmøte, | ||
| + | |||
| + | Vi takker Peder for lang og tro tjeneste! | ||
| + | |||
| + | ==== 4. Neste møte ==== | ||
| + | |||
| + | [[navref_040325|4. mars, kl. 09.00-12.00 (videokonferanse) ble valgt som neste møtedato]]. | ||
| - | Kommer. | ||
nav-ref/navref_051124.1730736431.txt.gz · Last modified: by morten