User Tools

Site Tools


nav-ref:navref_250820

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
nav-ref:navref_250820 [2020/08/24 14:32]
morten [Agenda]
nav-ref:navref_250820 [2020/08/27 10: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 ===
  
-  * 5.0.6 har ligget i pipeline lenge - kanskje på tide?+  * [[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 54: 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]
  
nav-ref/navref_250820.1598272346.txt.gz · Last modified: 2020/08/24 14:32 by morten