This shows you the differences between two versions of the page.
Next revision | Previous revision | ||
nav-ref:navref_250820 [2020/08/24 12:26] morten created |
nav-ref:navref_250820 [2020/08/27 08:43] (current) morten referanser fra volda |
||
---|---|---|---|
Line 4: | Line 4: | ||
- | Innkalt: | + | Tilstede: |
* Morten Brekkevold, //Uninett// | * Morten Brekkevold, //Uninett// | ||
- | * Vidar Faltinsen, //Uninett// | ||
* Hanne Moa, //Uninett// | * Hanne Moa, //Uninett// | ||
* Sigurd Refvik, //UiO// | * Sigurd Refvik, //UiO// | ||
Line 15: | Line 14: | ||
* Nils-Arild Grav, //NTNU// | * Nils-Arild Grav, //NTNU// | ||
+ | Forfall: | ||
+ | |||
+ | * Vidar Faltinsen, //Uninett// | ||
===== Agenda ===== | ===== Agenda ===== | ||
Line 26: | Line 28: | ||
=== 1. Presentasjoner/Status === | === 1. Presentasjoner/Status === | ||
+ | * [[https://github.com/Uninett/nav/milestone/171?closed=1|5.0.6]] har ligget i pipeline lenge - kanskje på tide? | ||
* Ny funksjonalitet som kommer i NAV 5.1 | * Ny funksjonalitet som kommer i NAV 5.1 | ||
* Juniper-støtte i PortAdmin (NETCONF / NAPALM) | * Juniper-støtte i PortAdmin (NETCONF / NAPALM) | ||
Line 53: | Line 56: | ||
===== Referat ===== | ===== Referat ===== | ||
- | Referat kommer. | + | 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. | ||
+ | |||
+ | === Del 1 - Presentasjoner/Status === | ||
+ | |||
+ | * [[https://github.com/Uninett/nav/milestone/171|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. [[https://github.com/Uninett/nav/pull/2175|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. [[https://github.com/Uninett/nav/pull/2126|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 [[https://github.com/Uninett/nav/pull/2173|#2173]], som baserer seg på [[https://github.com/Uninett/nav/pull/2122|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 [[https://github.com/Uninett/nav/issues/2021|dette gjort i samme slengen]]. | ||
+ | * UiOs [[https://github.com/Uninett/nav/pull/2128|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 | ||
+ | * [[https://en.wikipedia.org/wiki/Argus_Panoptes|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. | ||
+ | |||
+ | === Del 2 - Fokus for videre utvikling/tilbakemelding === | ||
+ | |||
+ | 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. | ||
+ | |||
+ | === Del 3 - Nye ønsker og innspill 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: | ||
+ | - 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. | ||
+ | - 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. | ||
+ | |||
+ | |||
+ | === Del 4 - Neste møte === | ||
+ | |||
+ | |||
+ | Neste møte ble avtalt til **torsdag 19. november**, klokken 12-15, over Zoom/videokonferanse. | ||
+ | |||
+ | |||
+ | === Referanser === | ||
+ | |||
+ | 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] | ||