NAV-ref Home

Tilstede:

• Morten Brekkevold, Uninett
• Hanne Moa, Uninett
• Sigurd Refvik, UiO
• Peder Magne Sefland, HiVolda
• Rune Kittelsen, UiA
• Ingeborg Hellemo, UiT
• Nils-Arild Grav, NTNU

Forfall:

• Vidar Faltinsen, Uninett

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

• Morten/Vidar ønsker velkommen på vegne av Uninett.

• 5.0.6 har ligget i pipeline lenge - kanskje på tide?
• Ny funksjonalitet som kommer i NAV 5.1
  • Juniper-støtte i PortAdmin (NETCONF / NAPALM)
    • Subsidiært, CNaaS-NMS-støtte
    • Mye omskriving av SNMP-spesifikk håndtering i PortAdmin
    • Bugs som er oppdaget underveis (f.eks “write mem”, andre ting)
  • Kloning av bokser og rom i SeedDB
  • Horisontal skalering av ipdevpoll/pping: Bidrag fra UiO
• Andre endringer i NAV 5.1
  • Django 2.2
  • Python 3.7?
• Dato for NAV 5.1?
• Status på Argus (tidl. AAS)

Foreløpig blankt.

UiA ønsker muligens å diskutere topologiavledning på urutede VLAN, da dette aldri har kommet inn på arbeidslisten. Ellers er ingenting forhåndsinnmeldt, så det blir runde rundt det “virtuelle bordet”.

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

Morten ønsket velkommen til møtet.

Mye av sommeren har vært dedikert til utvikling på Argus, den nye alarm-aggregatoren, samtidig som det er gjort en del på Juniper-støtte via NETCONF i NAV-koden.

• NAV 5.0.6 har ligget i pipeline lenge, vi anser at det er på tide å få den ut, helst denne uka.
• Funksjonalitet som kommer i NAV 5.1 ble diskutert.
  • I NAV har det stort sett vært fokusert på implementasjon av støtte for Juniper i PortAdmin i sommer. Det er vanskelig å gi en god demonstrasjon fra hjemmekontoret pga. av problemer med behov for multiple VPN-løsninger.
    • Støtte er hovedsakelig implementert vha. NAPALM, selv om det er Junipers eget PyEZ-bibliotek som ligger til grunn for dette.
    • Støtte for “noe annet enn SNMP” har tatt mest tid, da PortAdmins backend er full av SNMP-konsepter som også lekker ut til PortAdmins frontend (som ikke burde bry seg om implementasjonsspesifikke protokoll-detaljer). En større restrukturering av PortAdmins backend har vært nødvendig.
    • Mange endringer var allerede gjort ifm. arbeidet med å støtte CNaaS-NMS i PortAdmin, men det var lettere å sette opp testmiljø med Juniper, som gjorde det lettere å komme videre med redesignet.
      • Se #2173, som baserer seg på arbeidet gjort tidligere i år.
    • Under omskriving av koden ble det også oppdaget bugs i den gamle koden, som at endringer på trunk-konfigurasjoner aldri blir gjenstand for en “write mem”-operasjon.
    • HiVolda etterspør NETCONF-støtte også for Cisco-utstyr i PortAdmin. Volda har aldri tatt i bruk PortAdmin skikkelig fordi SNMP v2c er en klartekstprotokoll. Volda ettersendte en del referanser som kommer nederst i referatet.
  • UiT ønsket seg mulighet for å “klone” bokser og rom i SeedDB, mtp. å gjøre dete enklere å legge inn nytt utstyr. Siden Hanne likevel satt og jobbet med omskriving av deler av SeedDB-koden, ble dette gjort i samme slengen.
  • UiOs bidrag som gjør det mulig å skalere innsamling horisontalt blir med i 5.1.
  • NAV 5.1 vil endre noen avhengigheter:
    • Django 2.2 vil støttes (men usikkert på om det vil kreves i første omgang)
    • Python 3.6 vil kreves (men siden vår “target” er Debian Buster, blir dette antagelig satt til Python 3.7)
  • Ingen dato er satt for NAV 5.1 enda. Gruppen har ingen konkrete ønsker, men ny funksjonalitet i PortAdmin er påkrevet av CNaaS-lanseringene Uninett står overfor de neste par månedene, så vi vil gjette på en release innen utgangen av september.
• Status på Argus
  • Argus er det nye navnet på det som tidligere ble omtalt som AAS (Aggregated Alert System), et navn som ble valgt etter en intern navnekonkurranse i Uninett.
  • To sommerstudenter, Anders Hovden og Jørgen Bele Reinfjell, har jobbet 6 uker i sommer med videreutvikling av Argus-prototypen.
  • I tett samarbeid med Hanne og Morten, har innspill fra Uninett Servicesenter veid tungt inn mot endringer i Argus, blant annet på navngiving av objekter i datamodellen, med inspirasjon fra ITIL.
  • Man er uansett avhengig av å skrive “limetjenester” som får shippet alarmer fra tredjepartssystemer (som NAV og Zabbix) inn i Argus, så vi har gått vekk fra tanken om at kunnskap om kildesystemet skal kodes inn i Argus (eller Argus-plugins). Denne oversetterfunksjonen kan like gjerne bakes inn i limetjenestene, og slik blir det lettere å vedlikeholde selve kjernen i Argus.
  • UiT melder at de gleder seg veldig til første versjon av Argus kommer.

Frem mot neste møte i gruppen anser ikke utviklerne det for nødvendig med tilbakemelding på noen oppgaver. Det kom heller ingen uoppfordrede tilbakemeldinger fra gruppen.

• UiA
  • UiA har forsøkt å ta i bruk PortAdmin, men har problemer med at det ikke er mulig å velge urutede VLAN i dropdown-boksene (i alle fall ikke for vanlige dødelige brukere)
    • Dette skyldes til dels at det er snakk om urutede VLAN, som NAV ikke alltid tar vare på, fordi NAV ikke er i stand til avlede topologi på urutede VLAN.
    • Avledning av urutede VLAN er diskutert før av denne gruppen, men ser aldri ut til å ha blitt et punkt på arbeidslisten.
    • Utviklerne anser problemet som todelt, men det krever litt mer etterforskning av NAVs 20 år gamle VLAN-modell:
      1. PortAdmin burde ikke nødvendigvis være avhengig av at NAV har avledet et VLANs topologi - så lenge en switch sier at et VLAN er konfigurert, burde det være valgbart
         • Det kan tenkes, derimot, at problemet ligger i autorisasjonskoden: Dersom NAV ikke har funnet et aktiv VLAN på en ruterport, har NAV heller ikke organisasjonstilknytning til VLANet, og kan kanskje ikke avgjøre om brukeren har lov til å redigere dette VLANet i PortAdmin.
      2. Avledning av urutede VLAN er en mer komplisert oppgave som kanskje må inn opp på oppgavelisten.

• UiO
  • Ønsker muligens mer fingranulert tilgangsstyring i NAV-grensesnittet, mtp. begrenset tilgang til utstyr i “sikre soner”.
    • Dette er et tilbakevendende moment i nav-ref, som aldri har munnet ut i en konkret plan. Uninett utfordrer UiO på å komme tilbake med en helhetlig spesifikasjon for hvordan de ønsker at slik tilgangsstyring skal fungere.

• NTNU har ingen nye innspill p.t.

• UiT har ingen nye innspill p.t.

• HiVolda
  • Interessert i mer informasjon om multicast i nettet.
    • Antall abonnenter på en IGMP-gruppe.
    • IP-adresser på abonnenter i en IGMP-gruppe.
    • MAC-adresser på abonnenter i en IGMP-gruppe.
    • NAV samler allerede tall på antall abonnenter, men av alle utstyrleverandører som har vært aktuelle, har man bare funnet at HP støtter å levere denne informasjonen, gjennom en proprietær MIB (Der CISCOs proprietære MIB ikke så ut til å være implementert i noe av Cisco-utstyret i sektoren).
  • Ønsker støtte for NETCONF mot Cisco-utstyr i PortAdmin, som nevnt over.

Neste møte ble avtalt til torsdag 19. november, klokken 12-15, over Zoom/videokonferanse.

Peder fra Høgskulen i Volda sendte inn følgende referanser mtp. Multicast:

• https://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_monitor_maint_support_TSD_Island_of_Content_Chapter.html#wp1032445
• CISCO-IPMROUTE-MIB
• MSDP-MIB
• IGMP-STD-MIB

Som generell referanse til Cisco og NETCONF:

• PyATS:
  • https://developer.cisco.com/docs/pyats/#!hands-on-learning/podcasts--videos
  • https://blogs.cisco.com/developer/pyats-genie-beneath-the-surface

    Because these models remain structurally consistent across different
    OS/platforms, automation built around Genie models are portable across your
    network: write them once and use them across different topologies and device
    types.
    
    Can it get even better? Of course! Genie’s opens source library implementations
    are not limited to just Cisco devices. Whilst the team here is focused on
    building support for Cisco platforms (duh!), it is 100% possible to support 3rd
    party vendors and even competitor platforms through library extensions and
    plugins – see example here [https://github.com/CiscoTestAutomation/genielibs/tree/master/pkgs/ops-pkg/src/genie/libs/ops/ntp/junos]