NAV-ref Home

Tilstede:

• Morten Brekkevold, Uninett
• Hanne Moa, Uninett
• Peder Magne Sefland, HiVolda
• Rune Kittelsen, UiA
• Ingeborg Hellemo, UiT
• Nils-Arild Grav, NTNU (fra 13:30)

Forfall:

• Sigurd Refvik, UiO
• Vidar Faltinsen, Uninett

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

• Morten ønsker velkommen på vegne av Uninett.
• Da det er ikke er mange NAV-nyheter å presentere, slår vi sammen de to sedvanlige første punktene på agendaen.

• Veien videre for PortAdmin
  • Utvikling av støtte for CNaaS-NMS som backend viser behov for enda mer fleksibilitet i PortAdmin-grensesnittet.
  • Kan relateres til flere ønsker rundt funksjonalitet i PortAdmin, f.eks.
    • Make it possible to turn on PoE in PortAdmin #1938
    • Control over 802.1X options per port in PortAdmin #2164
• Redefinisjon av Severity-begrepet i NAV:
  • Make event/alert severity values configurable #2259
• Status på Argus
  • Veien videre
  • Limetjenester
    • NAV
    • Zino
    • Mist
    • Aruba
    • Zabbix… ?

Ingenting er forhåndsinnmeldt. Runde rundt “bordet”.

Neste møte blir et videomøte. Foreløpig datoforslag: Tirsdag 24. august

Morten ønsket velkommen til møtet.

Ettersom det ikke er mange nyheter å presentere fra NAV-utvikling, ble møtet for det meste en gjennomgang av pågående arbeid innmeldte ønsker til utvidelser i PortAdmin-verktøyet i NAV - samt litt status på redefinisjon av severity-begrepet i NAVs alarmsystem.

Morten redegjorde for omstruktureringer som har vært gjort i PortAdmins kodebase det siste året. For tiden jobbes det med å integrere proxy-aktig backend for å delegere alle konfigurasjonsendringer gjort med PortAdmin til CNaaS-NMS, gjennom dens REST-API.

Dette arbeidet har avdekket flere behov for endringer i frontend, som gjør det mer fleksibelt å styre hvilke konfigurasjonsinnstillinger det skal være mulig å styre for hver enkelt port. CNaaS-NMS kan for eksempel forby VLAN-endringer på porter som kjører 802.1X eller på annet vis er låst i CNaaS-NMS, mens endringer på description, eller shutdown/enable forblir tillatt.

I tillegg kommer ønsker om mulighet til å skru på andre konfigurasjonsparametre for porter, så som PoE (Power-over-Ethernet) og 802.1X-konfigurasjon.

Et tredje innspill, som kan dekke flere av disse ønskene, er at i stedet for å la brukeren konfigurere VLAN fritt, kan PortAdmin la brukeren velge mellom forhåndsdefinerterte profiler. En profil angir et sett med konfigurasjonsparametre for en port, så som VLAN, 802.1X-parametre, VOIP-vlan.

Profiler kan formodentlig konfigureres uten et skreddersydd grensesnitt i PortAdmin, f.eks. i en konfigurasjonsfil. Enkelte utstyrsleverandører kan tom. tilby innebygde konsepter som ligner på dette. For eksempel har Juniper konseptet “interface range”. En “interface range” er en mal-konfigurasjon for et interface, og så kan man melde interfaces inn og ut av denne malkonfigurasjonen.

NTNUs eksisterende verktøy for 802.1X-konfigurasjon brukes i stor grad kun til å justere fallback-VLAN, dvs. hvilket VLAN en port skal stå på dersom en tilkoblet klient ikke støtter 802.1X - det meste andre av parametre kunne vært lagt i en profil.

Backend-systemet til PortAdmin mangler foreløpig også en måte å signalisere hvilken funksjonalitet som støttes eller ikke støttes av en backend. De fleste operasjoner som har vært støttet frem til nå er såpass basale at de fins i alle switcher, som admState, ifAlias og VLAN-konfigurasjon. Cisco-proprietær VOIP-konfigurasjon er den første funksjonaliteten som kommer utenom, og dette kan det bli mer av om man blander inn PoE, 802.1X og CNaaS-NMS.

Møtet ble enig om at utviklerne sonderer terrenget internt (i CNaaS-teamet, ettersom de var for travle til å delta denne dagen) og lager et slags forslag til funksjonalitet som legges fram for referansegruppen.

Oppgaven, som definert i #2259, er underveis. Migrasjoner for eksisterende data er definert, og alle steder i NAV-koden som setter verdier i gammel skala er oppdatert. Men den viktigste oppgaven gjenstår: Nemlig muligheten til å konfigurere verdiene som settes av eventEngine.

Runde rundt bordet:

• UiA:
  • Ønsker seg fremdeles muligheten til å trekke ut noen former for statistikk fra NAT44-boksene Uninett har levert. Hovedsakelig tenkt brukt til å se at ikke kapasiteten overskrides.
    • En NAT-pool består av et sett offentlige IP-adresser, hvor et eller flere klientnett skjuler seg bak. Hver offentlige IP-adresse er bare i stand til å understøtte omtrent 64K samtidige connections (sannsynligvis færre), så man ønsker statistikk som viser om denne kapasiteten er i ferd med å bli brukt opp.
    • AKSJON: Spørre Svein Ove i stamnett nok en gang om hvordan det står til med SNMP-støtte i disse boksene.
    • AKSJON: Sjekk om dette ønsket allerede er notert i NAVs issuetracker.
  • Lignende statistikk er kanskje mulig/ønskelig å få ut fra eduVPN også
  • UiA er også i ferd med å rulle ut brannmurprodukter fra Juniper og kunne tenke seg samme type statistikk fra disse. Det er mer uklart hvordan dette gjøres, men man formoder at Juniper kanskje allerede har publiserte MIBs som gir tilgang til ønsket informasjon.

• HiVolda:
  • Har begynt å rulle ut brannmurprodukter fra PaloAlto. Foreløpig uklart hvordan disse blir sett av NAV, men Peder ettersender rapport når de har mer erfaring.
  • Har begynt å rulle ut Cisco-switcher i 9300-serien og tatt i bruk stacking for første gang. Disse ser alle ut til å bli beskrevet riktig av NAV. Dette skyldes nok mest at Cisco er ganske flinke til å forholde seg til ENTITY-MIB.
  • Ønsker seg fremdeles bedre PoE-info i NAV
    • AKSJON: Morten gjorde en del MIB-research på dette hos HiVolda for en stund tilbake. Funnene bør dokumenteres på den eksisterende issuen: More power usage stats on individual PoE-enabled ports #2163
    • Har tidligere spilt inn et ønske om å integrere NAVs GeoMap med MazeMap og ønsket en liten diskusjon rundt dette.
      • API-et til MazeMap er ukjent for oss, men ser ut til å være kompatibelt med OpenStreetMap-API-ene som GeoMap allerede benytter.
      • UiT benytter en workaround hvor de bare setter en MazeMap-URL på hvert enkelt rom i NAV.
      • Uavklart om det holder at NAV har sin eksisterende romreferanse og bruker den, eller om NAV trenger å ha med etasje-info med mer.
      • AKSJON: Se nærmere på API-dokumentasjon Peder har sendt til nav-ref

• UiT:
  • Ønsker bare å påpeke igjen to maintenance-relaterte bugrapporter de venter på en løsning på:
    • Optimize Maintenance interface #2251
      • Morten påpekte at denne er såpass omfattende at det nok ikke kan regnes som en enkel bugfiks
    • Deleted netboxes should be deleted from Maintenance tasks #2243

• Uninett:
  • Påminner om at aksjeselskapet Uninett opphører å eksistere 1. januar: Uninett, NSD og deler av Unit blir slått sammen til Kunnskapssektorens Tjenesteleverandør. Se pressemelding fra KD.

Neste møte ble satt til tirsdag 21. september 2021, kl. 12:30-15:00, over Zoom.