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?

• NTNUs ønske om å begrense PortAdmin-brukere til kun å endre portbeskrivelse (#3298): Simon har laget per-attributt-rettigheter i PortAdmin (vlan, beskrivelse, admin-status, PoE, voice-vlan, trunk kan styres hver for seg). Ikke sluppet ennå, men muligens klar til demo.
• 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?