NAV-ref Home | forrige møte

Innkalt:

• Øyvind Nesland, UiA
• Ingeborg Hellemo, UiT
• Nils-Arild Grav, NTNU
• Sigurd Refvik, UiO
• Morten Werner Forsbring, UiO

• Vidar Faltinsen, Sikt
• Knut-Helge Vindheim, Sikt
• Hanne Moa, Sikt
• Johanna England, Sikt
• Simon Oliver Tveit, Sikt
• Aleksander Fløtten, Sikt
• Morten Brekkevold, 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?