NAV-ref Home

Tilstede:

• Peder Smart Sefland, HiVolda
• Rune Kittelsen, UiA
• Ingeborg Hellemo, UiT
• Sigurd Refvik, UiO

• Hanne Moa, Sikt
• Johanna England, Sikt
• Simon Oliver Tveit, Sikt
• Ilona Podliashanyk, Sikt (Gikk tidlig for å delta i et annet møte)
• Morten Brekkevold, Sikt

Forfall:

• Nils-Arild Grav, NTNU
• Vidar Faltinsen, Sikt

Møtet blir avholdt som videokonferanse vha. Zoom, fra kl. 12:00 til 15:00.

• Morten ønsker velkommen på vegne av Sikt.

• Arbeidsmetodikken fortsetter med “sprints” med varighet på to til tre uker hver, med unntak av under ferieavvikling.
  • Sprintmetodikken hangler litt i 2023, da vi har betydelig redusert timeantallet på Argus fra GÉANT, og teamet har startet opp med utvikling av Zino 2.0 på oppdrag fra NORDUnet. Foreløpig er NAV det eneste enkeltprosjektet som har nok arbeidsoppgaver til å holde hele teamet i gang med oppgaver i en hel sprint.
  • NAV-releases siden forrige møte:
    • 5.5.0
    • 5.5.1
    • 5.5.2
    • 5.6.0
  • Nyttige lenker for fremdriftsinfo:
    • CHANGELOG
    • Åpne pull requests
    • Arbeidslisten som Kanban-board på GitHub

• JWT i NAV-API: Cybersikkerhetssenterets behov for informasjon om subnett-anvendelser.

• Kort status på andre prosjekter enn NAV:
  • Argus
  • CNaaS-NMS
  • Zino 2.0

• Device lifecycle management (#1997) er 2/3 ferdig og ute i NAV-release.
  • Mangler event når utstyr “forsvinner” ut av drift
  • En del problemer med duplikathåndtering, hovedsakelig relatert til Juniper.
  • UiT rapporterer også problemer med “missing alert templates”, som vi ikke helt klarer å finne ut hvorfor skjer.

• DHCP-statistikk i NAV
  • Gjøre NAV i stand til å koble DHCP-metrikker sendt inn i Graphite fra eksterne verktøy mot VLAN som NAV kjenner.
  • Dette er en feature som er delvis implementert, hovedsakelig på bakgrunn av ønsker fra CNaaS - men også UiT ønsker å ta i bruk dette, og det er noen betydelige forskjeller i hvordan Sikt CNaaS og UiT navngir sine DHCP-pools.
  • Vi trenger en diskusjon på navnestandard for Graphite-metrikker før vi kommer helt i havn.

• UiT jobber med et kodebidrag for å kunne lese ARP-data fra PaloAlto-brannmurer.

• Ranked statistics is slow (#1504) er en nøtt. Vi foreslår at vi lukker denne og evt. gjenåpner eller lager en ny sak når folk har fått testet om cache-funksjonaliteten vi har lagd hjelper dem.

Runde rundt “bordet”. Forhåndsinnmeldte ting:

• HiVolda kan tenkes å ville snakke om “Morpheus”: https://youtu.be/9figuE_LJPo
• UiT har følgende innspill:

Flere i sektoren bruker Mazemap som verktøy for å finne fram til rom. UiT har
hatt stor nytte av å legge til et eget Mazemap-felt i room-versikten med link
til rommet i Mazemap.

I tillegg inneholder Mazemap geografiske koordinater til rommet og beskrivelse
av rommet (undervisningsrom, auditorium etc). Dette er informasjon vi svært
gjerne skulle hatt hentet inn i NAV i eksisterende felt i stedet for å skrive
inn manuelt.

Mazemap har et API der alle disse opplysningene kan hentes ut.

Man ønsker ikke å trøkke heile Mazemap-databasen inn i NAV, slik at dette må
gjøres for de aktuelle rommene man har lagt inn i NAV. Jeg ser også at man må
tenke ut noe lurt rundt navngiving i NAV kontra Mazemap slik at man greier å
mappe de mot hverandre.

Vi velger neste møtedato, ca. 6. juni, halv dag over videokonferanse.

• Morten ønsket velkommen på vegne av Sikt.

Utviklerteamets arbeidsmetodikker ble kort presentert, deretter ble NAVs changelog siden sist gjennomgått.

Gjennomgang av Cybersikkerhetssenterets behov for å finne informasjon om et kundesubnetts formål. Ved hjelp av KUDAF-midler har man jobbet frem et API som gjør CSC i stand til å slå opp informasjon om IP-adressetildelinger i forskningsnettets IP-register. Dette IP-registeret sier derimot ikke så mye om kundens faktiske formål med subnettet, bare at kunden er tildelt et adresseområde.

“The last mile” her er å gjøre CSC i stand til å slå opp i kundenes egne subnett-data i NAV, gitt en IP-adresse. Dette kan gi mer informasjon om hva slags formål et subnett faktisk har hos kunden (ansattnett, studentnett, servernett osv.). For å gjøre noe sånt, krever det muligheten til å delegere ansvaret for API-autorisasjon til en tredjepart, f.eks. Feide. Dette er noe som kan løses ved å bruke JWT-tokens i NAV i stedet for dagens løsning med genererte, ugjennomsiktige tokens. Et JWT-token er et kryptografisk signert krav om aksess, og med den nye løsningen kan NAV konfigureres til å stole på JWT-tokens signert av Feide. NAVs interne tokenløsning vil også etter hvert byttes ut med en JWT-basert løsning (slik at NAV vil utstede og signere sine egne JWT-tokens fra Useradmin-panelet).

Sikt får finansiert færre timer for Argus-utvikling fra GÉANT i år, noe som nødvendigvis vil medføre mindre aktivitet her. NAV og CNaaS-NMS har tilnærmet lik aktivitet som før, men i tillegg har Sikt nå fått i oppdrag fra NORDUnet å omskrive Zino til Python.

Uninett utviklet Zino til overvåkning av forskningsnettet på midten av 90-tallet, og har brukt det i produksjon siden. Zino er et rimelig småskala, robust system med få avhengigheter, som har tjent både Uninett, NORDUnet og SUNET godt i mange år.

En ulempe ved Zino er at det er implementert i Tcl, et språk som nesten ingen bruker lenger, og har hovedsakelig bare én utvikler (som har få år igjen i yrkeslivet). Sikt har derfor lagt frem et prosjektforslag for NORDUnet for å skrive om Zino til Python, i tillegg til å lage et web-basert grensesnitt som et tillegg til eksisterende X11 og terminal-baserte grensesnitt. Dette prosjektforslaget er godkjent av NORDUnet, som finansierer opp mot et årsverk for denne oppgaven i 2023. Oppgaven har tilfalt utviklerteamet i PO Campusnett, da dette teamet både har bred faglig kompetanse på både Python og nettverksovervåkning.

Det som gjenstår her er hovedsakelig å poste events når utstyr forsvinner ut av drift. I tillegg jobbes det med et problem som UiT har rapportert, hvor varsler om sw/hw/fw-oppgraderinger kommer med feilmeldingen “No alert template defined” i stedet for en pent formatert alarm (dette har man funnet et løsning på i etterkant, i #2594).

Det er et ønske fra CNaaS-teamet om at NAV skal kunne presentere statistikk over DHCP-leases i subnett, selv om dette statistikken nødvendigvis må sendes til NAVs Graphite-server fra et eksternt system. Ettersom CNaaS bruker ISC DHCP, er det utviklet et contrib-script i NAV som kan lese tilstandsdata om dhcp-pools fra ISC DHCP og sende disse tallene som metrikker til en Graphite-tjener (scriptet må kjøre på selve DHCP-tjeneren).

Scriptet er utviklet basert på innmeldte behov for CNaaS, men dette representerer bare ett brukseksempel. UiT har forsøkt å ta i bruk det samme scriptet på sin ISC DHCP-tjener, men fordi UiT bruker en annen konvensjon enn CNaaS for navngiving av sine DHCP-pools har forsøket foreløpig strandet.

For at NAV skal være i stand til å relatere en ekstern metrikk i Graphite til et VLAN eller Prefix i NAVs database, må metrikkene ha navn/stier som gjør dette mulig (ettersom det er svært begrensede muligheter for å legge til andre metadata til metrikker i Graphite). Derfor må det defineres en navnestandard som kan tjene flere parter, og som muliggjør integrering av også andre DHCP-tjenere enn ISC.

Tanken var å ha en slik diskusjon på dette møtet, men ettersom ingen representanter for CNaaS-teamet hadde anledning til å delta, ble det valgt å utsette diskusjonen til et eget møte, der Vidar Stokke (Sikt/CNaaS) og Ingeborg Hellemo (UiT), samt representanter for utviklerteamet, deltar.

UiT har engasjert en student (Joar Heimonen) til å arbeide frem et kodebidrag til NAV som vil gjøre NAV i stand til å hente ARP-informasjon fra PaloAlto-brannmurer. Denne informasjonen har aldri vært mulig å få ut med SNMP, men PaloAlto tilbyr ARP-data gjennom et lettfattelig REST-API. Joar har utarbeidet en proof-of-concept til NAV, men basert på NAVs service-monitor. UiT og Sikt har møttes for å veilede Joar i hvordan han kan innlemme sin implementasjon i ipdevpoll-motoren i NAV i stedet, der den hører mer naturlig hjemme, og hvor koden også kan støtte seg på eksisterende funksjonalitet for håndtering av ARP-logger i NAV-databasen.

Sikt har foreløpig ikke hørt mer fra Joar etter dette møtet (24.02.2023).

Peder spilte inn to PaloAlto-lenker i chatten underveis:

• https://github.com/netdisco/snmp-info/issues/256 (om å gjøre noe tilsvarende med SSH i netdisco, men konklusjonen i møtet er at REST-API er mye enklere å implementere, så UiT har valgt riktig vei)
• PaloAlto MIB-dokumentasjon

Dette står fremdeles som punkt nr. 2 på arbeidslisten, men vi velger å lukke dette punktet med caching-implementasjonen som kom i siste NAV-versjon (#2398).

Cachingen hjelper dessverre ikke mot det underliggende problemet, som er at Graphite i seg selv er veldig treg til å svare på en forespørsel om rangering av store mengder data. Det største problemet i dag er kanskje at deler av infrastrukturen timer ut mens man venter på svar fra Graphite, dersom man har veldig store datamengder å prosessere. Selv den nye funksjonaliteten som cacher resultatet vil feile pga. timeouts. Man kan kanskje bøte noe på akkurat dette problemet ved å øke noen timeoutverdier, men det underliggende problemet med at Graphite er tregt er vanskeligere å gjøre noe fornuftig med.

Møtet er enige om at dette ikke lenger har veldig høy prioritet, og kan lukkes fra listen. UiT åpner et nytt issue om timeout-problematikken (#2575).

Peder ønsket å trekke frem frem “Morpheus”-konseptet (https://youtu.be/9figuE_LJPo), en slags GPU-powered AI fra NVIDIA som analyserer nettverkstrafikk i realtime og detekterer trusler. Spørsmålet fra Peder er om ikke noe sånt kunne vært foret med data fra NAV, men det kom ingen konkrete forslag ut av dette.

UiT har i likhet med mange andre UH-institusjoner valgt å benytte Mazemap som løsning for å la ansatte, studenter og publikum navigere sine campus. Man kan for eksempel få navigeringshjelp til ethvert telematikkrom på Campus. UiT kunne tenkt seg en løsning hvor alle telematikkrom i NAV kan kobles til Mazemap for å fysisk kunne navigere til dem i den virkelige verden.

Ingeborg deler lenke i chat:

Eksempel på standardisert link inn mot Mazemap. Legg merke til campusid og sharepoi som identifiserer campus og rom. https://use.mazemap.com/?campusid=39&sharepoitype=identifier&sharepoi=1043

Peder deler lenker i chat:

https://www.mazemap.com/solutions/system-integrations
https://www.mazemap.com/solutions/heat-maps

Utviklerteamets kommentar: Dette høres ut som noe som best løses med et tillegsverktøy til NAV. Et slikt verktøy må kommunisere både med NAVs API og med Mazemaps API, og være i stand til å oversette roomid i NAV til rom-id i Mazemap (disse kan fort ha forskjellig standard). Verktøyet kan gå over alle rom i en NAV-installasjon, finne rommets tilsvarende innslag i Mazemap, og annotere NAV-rommet (med data-attributter) med en URL til rommets Mazemap-innslag.

Det er uklart hvordan og hvem som kan jobbe med en slik oppgave ut i fra forutsetningene, men det kan gjerne forfattes et issue med navref-label på det i NAVs tracker.

Innspillet om Mazemap avstedkom en diskusjon om dokumentasjon av fiberføringer på kart i NAV. På generell basis er ikke dette noe NAV vil befatte seg med. NAV kan brukes til å dokumentere fysisk ethernet-kabling og patching innenfor bygningsmassen, mens de fleste som ønsker å dokumentere fiberføringer bruker verktøy som Telemator for oppnå dette.

Sigurd nevner at han har litt lyst til å lage et NAV-tillegg som gjør det mulig å koble fiberføringsinformasjon i andre systemer til NAV.

Morten påpeker at både UiT og Sikt har gjort hver sin integrasjon mellom Telemator og NAV, som kanskje kunne vært delt. UiTs løsning baserer seg på å dumpe Telemator-databaser inn i NAV-databasen. Sikts løsning baserer seg på å gjøre oppslag direkte mot Telemators MS-SQL-database fra et NAV-tillegg, slik at fiberføringsinformasjon kan søkes opp via sambandsnumre, direkte fra søkeboksen i NAVbar.

Rune melder sin interesse for fiberdokumentasjon, og nevner at UiA i dag har noe “håndtegnet” dokumentasjon i Visio som ser ut som en KLM-sketsj. UiO har også papirtegninger av fiberføringer.

Noen delte en lenke til 2023 Internet 2 Technology Exchange, men det fremgår ikke av møtenotatene hva hensikten var.

Møtet ble foreløpig enige om 6. juni, kl. 12-15 som neste møtedato (digitalt). Det må gjøres avsjekk med Nils-Arild/NTNU om dette passer. Dessuten viser det seg i etterkant at dette kanskje kræsjer med datoer TNC 2023, så det er mulig vi likevel må sende ut en Doodle for å enes om ny dato.