nav-ref:navref_250820
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
nav-ref:navref_250820 [2020/08/27 08:02] morten Referat fra del 1 |
nav-ref:navref_250820 [2020/08/27 08:43] (current) morten referanser fra volda |
||
|---|---|---|---|
| Line 85: | Line 85: | ||
| === Del 2 - Fokus for videre utvikling/tilbakemelding === | === 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 === | === 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.1598515351.txt.gz · Last modified: 2020/08/27 08:02 by morten
Page Tools
