nav-ref:navref_051124
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_051124 [2025/02/26 10:53] morten Lagt til 3298 |
nav-ref:navref_051124 [2025/03/12 06:31] (current) morten ref til 3325 |
||
|---|---|---|---|
| Line 146: | Line 146: | ||
| * Et aspekt som blir nevnt er at UiT ønsker å legge til alle virtuelle ruterinstanser som egne IP devices i NAV for å overvåke dem individuelt, men at man da helst vil unngå flerdobbel SNMP-belastning av de som er en og samme fysiske boks. | * Et aspekt som blir nevnt er at UiT ønsker å legge til alle virtuelle ruterinstanser som egne IP devices i NAV for å overvåke dem individuelt, men at man da helst vil unngå flerdobbel SNMP-belastning av de som er en og samme fysiske boks. | ||
| * Morten påpeker at sistnevnte allerede er støttet i NAV ved å registrere en "master device" under ''Advanced options'' i SeedDB-siden for IP Devices. | * Morten påpeker at sistnevnte allerede er støttet i NAV ved å registrere en "master device" under ''Advanced options'' i SeedDB-siden for IP Devices. | ||
| - | * :!: **AKSJON:** Funksjonaliteten er dessverre ikke beskrevet noe annet sted enn i [[https://nav.readthedocs.io/en/latest/release-notes.html#avoiding-redundant-snmp-polling-for-virtual-device-contexts|release notes for NAV 4.7]], så dette bør nok dokumenteres bedre. | + | * <del>:!: **AKSJON:** Funksjonaliteten er dessverre ikke beskrevet noe annet sted enn i [[https://nav.readthedocs.io/en/latest/release-notes.html#avoiding-redundant-snmp-polling-for-virtual-device-contexts|release notes for NAV 4.7]], så dette bør nok dokumenteres bedre.</del> |
| + | * [[https://github.com/Uninett/nav/issues/3303|NAV's feature to avoid VRF polling redundancies using master/slave device registrations is not documented #3303]] | ||
| * UiT skal teste hvor godt denne funksjonaliteten dekker deres behov. | * UiT skal teste hvor godt denne funksjonaliteten dekker deres behov. | ||
| * Et annet aspekt som kanskje mangler er innsamling av data som bare fins på hver enkelt VRF. Dette fungerer kanskje fint så lenge man har en management-adresse per VRF og registrerer disse i NAV, men Knut-Helge kommenterer at CNaaS ikke gir egne management-adresser til VRF-er, og at NAV kanskje mangler ruting-informasjon for enkeltinstanser. | * Et annet aspekt som kanskje mangler er innsamling av data som bare fins på hver enkelt VRF. Dette fungerer kanskje fint så lenge man har en management-adresse per VRF og registrerer disse i NAV, men Knut-Helge kommenterer at CNaaS ikke gir egne management-adresser til VRF-er, og at NAV kanskje mangler ruting-informasjon for enkeltinstanser. | ||
| Line 152: | Line 153: | ||
| * UiT nevner også et behov eller manglende støtte for overvåkning på lag 3, dvs. logiske linker mellom VRF-er som går ned, selv om fysisk link mellom boksene er oppe. Det er litt uklart hva som egentlig mangler her, og det bør UiT greie ut for i en egen VRF-issue. | * UiT nevner også et behov eller manglende støtte for overvåkning på lag 3, dvs. logiske linker mellom VRF-er som går ned, selv om fysisk link mellom boksene er oppe. Det er litt uklart hva som egentlig mangler her, og det bør UiT greie ut for i en egen VRF-issue. | ||
| - | :!: **AKSJON:** Lag et GitHub-issue for å kartlegge evt. nye behov for VRF-støtte i NAV og be de som er interessert i dette kommentere på issuet. | + | <del>:!: **AKSJON:** Lag et GitHub-issue for å kartlegge evt. nye behov for VRF-støtte i NAV og be de som er interessert i dette kommentere på issuet.</del>. Vi har i stedet laget en GitHub discussion (som senere kan gjøres om til en issue, ved behov): [[https://github.com/Uninett/nav/discussions/3304| Add more "support" for VRF #3304 ]] |
| * UiT gjentar et ønske om støtte for Cisco ACI (Application Centric Infrastructure, en Cisco-implementasjon av SDN) i NAV. Dette har vært nevnt også i tidligere møter. | * UiT gjentar et ønske om støtte for Cisco ACI (Application Centric Infrastructure, en Cisco-implementasjon av SDN) i NAV. Dette har vært nevnt også i tidligere møter. | ||
| Line 161: | Line 162: | ||
| * Det er litt uklart hva dette skal inneholde, men prinsipielt skal Device History tilby slik funksjonalitet - men filtermulighetene her er ikke gode nok for UiT. | * Det er litt uklart hva dette skal inneholde, men prinsipielt skal Device History tilby slik funksjonalitet - men filtermulighetene her er ikke gode nok for UiT. | ||
| * CNaaS har en custom SQL-rapport i NAVs rapportsystem for hendelser siste 24 timer. Siden dette ligger i SQL-rapportsystemet er det ikke veldig fleksibelt, men kan dekke opp for noe av behovet for UiT. | * CNaaS har en custom SQL-rapport i NAVs rapportsystem for hendelser siste 24 timer. Siden dette ligger i SQL-rapportsystemet er det ikke veldig fleksibelt, men kan dekke opp for noe av behovet for UiT. | ||
| - | * :!: **AKSJON:** Denne rapporten bør distribueres med NAV så alle har et eksempel de eventuelt kan tilpasse selv | + | * <del>:!: **AKSJON:** Denne rapporten bør distribueres med NAV så alle har et eksempel de eventuelt kan tilpasse selv</del> |
| - | * :!: **AKSJON:** Vurdere å lage et eget GitHub-issue for å tenke nytt rundt Device History-verktøyet (i.e. ta idéer fra, eller smelte sammen med, status-verktøyet). | + | * [[https://github.com/Uninett/nav/issues/3305|Add an "Events detected last 24 hours" SQL report #3305]] |
| + | * <del>:!: **AKSJON:** Vurdere å lage et eget GitHub-issue for å tenke nytt rundt Device History-verktøyet (i.e. ta idéer fra, eller smelte sammen med, status-verktøyet).</del> | ||
| + | * Vi har laget en "discussion" på dette her: [[https://github.com/Uninett/nav/discussions/3306| Revamp IP Device History tool #3306 ]] | ||
| | | ||
| * UiT trekker fram et gammelt issue som ble forsøkt løst for mange år siden, men hvor endringen måtte rulles tilbake: ([[https://github.com/Uninett/nav/issues/2915|[BUG] CAM data not collected for devices of type SRV and OTHER #2915]]) | * UiT trekker fram et gammelt issue som ble forsøkt løst for mange år siden, men hvor endringen måtte rulles tilbake: ([[https://github.com/Uninett/nav/issues/2915|[BUG] CAM data not collected for devices of type SRV and OTHER #2915]]) | ||
| - | * :!: **AKSJON:** Kartlegg hva som skjedde sist dette ble forsøkt løst og legg inn som en kommentar på #2915 | + | * <del>:!: **AKSJON:** Kartlegg hva som skjedde sist dette ble forsøkt løst og legg inn som en kommentar på #2915</del> |
| + | * Issue #2915 er egentlig et duplikat av et 12 år gammelt issue som ble forsøkt løst i to omganger, med svært uheldige resultater for NAV, og endringene ble derfor rullet tilbake. Issue-historikk er kommentert på #2915. | ||
| * UiT ber også om oppmerksomhet for to bugs de tidligere har meldt inn: | * UiT ber også om oppmerksomhet for to bugs de tidligere har meldt inn: | ||
| * [[https://github.com/Uninett/nav/issues/2908|[BUG] Alert profile filter - list_limit reached #2908]] | * [[https://github.com/Uninett/nav/issues/2908|[BUG] Alert profile filter - list_limit reached #2908]] | ||
| Line 172: | Line 175: | ||
| * Det fremgår at det fremdeles var litt uklart hva beste løsning her egentlig er, da UiT og utviklerne er litt uenige om beste fremgangsmåte. | * Det fremgår at det fremdeles var litt uklart hva beste løsning her egentlig er, da UiT og utviklerne er litt uenige om beste fremgangsmåte. | ||
| * Vi diskuterte oss frem til en viss enighet om at slettede bokser ikke skal forsvinne i løse luften fra maintenance-tasks, men at tasks som ikke lenger har igjen gyldige komponenter i seg automatisk skal kanselleres av NAV. | * Vi diskuterte oss frem til en viss enighet om at slettede bokser ikke skal forsvinne i løse luften fra maintenance-tasks, men at tasks som ikke lenger har igjen gyldige komponenter i seg automatisk skal kanselleres av NAV. | ||
| - | * :!: **AKSJON:** Utviklerteamet oppdaterer #2243 og lager et forslag til løsning/ | + | * <del>:!: **AKSJON:** Utviklerteamet oppdaterer #2243 og lager et forslag til løsning/</del> |
| * Begge bugs ble lagt i backlog for inneværende sprint. Det betyr ikke nødvendigvis at vi rekker over dem, men det øker teamets oppmerksomhet på dem. | * Begge bugs ble lagt i backlog for inneværende sprint. Det betyr ikke nødvendigvis at vi rekker over dem, men det øker teamets oppmerksomhet på dem. | ||
| Line 201: | Line 204: | ||
| * :!: **AKSJON:** Knut-Helge bør evt. kommentere på de punktene som allerede er observert under [[https://github.com/Uninett/nav/issues/1936| Is it possible to show more information about 802.1X enabled ports? #1936]] | * :!: **AKSJON:** Knut-Helge bør evt. kommentere på de punktene som allerede er observert under [[https://github.com/Uninett/nav/issues/1936| Is it possible to show more information about 802.1X enabled ports? #1936]] | ||
| * Oktett-tellere på porter blir i dag aggregert over tid med gjennomsnittsverdier. Her ønsker CNaaS-teamet at det også ble aggregert minimums og maksimumsverdier (slik det ble gjort da NAV brukte ''rrdtool''. | * Oktett-tellere på porter blir i dag aggregert over tid med gjennomsnittsverdier. Her ønsker CNaaS-teamet at det også ble aggregert minimums og maksimumsverdier (slik det ble gjort da NAV brukte ''rrdtool''. | ||
| - | * :!: **AKSJON:** Utviklerteamet lager et GitHub-issue og dokumenterer behovet for Graphite-research, da Graphite ikke umiddelbart støtter multiple aggregeringsmetoder for samme metrikk. Fører formodentlig til tredobling av lagringsbehovet, om vi finner en løsning. | + | * <del>:!: **AKSJON:** Utviklerteamet lager et GitHub-issue og dokumenterer behovet for Graphite-research, da Graphite ikke umiddelbart støtter multiple aggregeringsmetoder for samme metrikk. Fører formodentlig til tredobling av lagringsbehovet, om vi finner en løsning.</del> |
| + | * [[https://github.com/Uninett/nav/issues/3309][Research how Graphite can support multiple aggregation methods for a single metric #3309]] | ||
| * Mener CPU-lastdatene som hentes inn av NAV i dag er et øyeblikksbilde som er kunstig forhøyet i innsamlingsøyeblikket pga. utstyrets arbeid med å besvare SNMP-forespørselen som henter dataene. Det påstås at det skal være mulig å hente ut gjennomsnittsverdier for siste 5-minuttersperiode i stedet. | * Mener CPU-lastdatene som hentes inn av NAV i dag er et øyeblikksbilde som er kunstig forhøyet i innsamlingsøyeblikket pga. utstyrets arbeid med å besvare SNMP-forespørselen som henter dataene. Det påstås at det skal være mulig å hente ut gjennomsnittsverdier for siste 5-minuttersperiode i stedet. | ||
| - | * :!: **AKSJON:** Kilde for dette er visstnok Vidar Stokke, som også har noen MIB-referanser. Han bør snarest opprette et GitHuub-issue som dokumenterer behovet og aktuelle MIB-er. | + | * <del>:!: **AKSJON:** Kilde for dette er visstnok Vidar Stokke, som også har noen MIB-referanser. Han bør snarest opprette et GitHub-issue som dokumenterer behovet og aktuelle MIB-er.</del> |
| + | * [[https://github.com/Uninett/nav/issues/3325|Collect and graph system metrics for CPU utilization avg 1, 5 and 15 minutes on Juniper SRX #3325]] | ||
| * Ønsker muligheten for deling av dashboards mellom brukere | * Ønsker muligheten for deling av dashboards mellom brukere | ||
| * Allerede notert i [[https://github.com/Uninett/nav/issues/2344|Add shareable dashboards to NAV #2344]] | * Allerede notert i [[https://github.com/Uninett/nav/issues/2344|Add shareable dashboards to NAV #2344]] | ||
| Line 210: | Line 215: | ||
| * Ønsker støtte for VLAN-informasjon og CAM-data fra Aruba CX-switcher. | * Ønsker støtte for VLAN-informasjon og CAM-data fra Aruba CX-switcher. | ||
| * Dette fungerer ikke i NAV i dag, primært fordi Aruba CX ikke implementerer ''Q-BRIDGE-MIB'' (slik de fleste leverandører gjør), men tilbyr i stedet ''IEEE8021-Q-BRIDGE-MIB''. | * Dette fungerer ikke i NAV i dag, primært fordi Aruba CX ikke implementerer ''Q-BRIDGE-MIB'' (slik de fleste leverandører gjør), men tilbyr i stedet ''IEEE8021-Q-BRIDGE-MIB''. | ||
| - | * :!: **AKSJON:** Utviklerteamet registrerer GitHub-issue om Aruba CX. | + | * <del>:!: **AKSJON:** Utviklerteamet registrerer GitHub-issue om Aruba CX.</del> |
| + | * [[https://github.com/Uninett/nav/issues/3310|Support VLAN (802.1Q) information on Aruba CX switches #3310]] | ||
| * Ønsker støtte for VLAN-informasjon og CAM-data fra Dell Blade-switcher. | * Ønsker støtte for VLAN-informasjon og CAM-data fra Dell Blade-switcher. | ||
| * Denne problemstillingen er ny for utviklerteamet, så det er vanskelig å si hvorfor dette ikke fungerer i dag. | * Denne problemstillingen er ny for utviklerteamet, så det er vanskelig å si hvorfor dette ikke fungerer i dag. | ||
| - | * :!: **AKSJON:** Utviklerteamet registrerer GitHub-issue om Dell Blade-switcher | + | * <del>:!: **AKSJON:** Utviklerteamet registrerer GitHub-issue om Dell Blade-switcher</del> |
| + | * [[https://github.com/Uninett/nav/issues/3311|Support VLAN (802.1Q) and CAM information on Dell Blade switches #3311]] | ||
| * Til sist kom det inn et ønske med et bærekraftsperspektiv: Kan NAV hente inn informasjon om faktisk strømforbruk fra utstyr? | * Til sist kom det inn et ønske med et bærekraftsperspektiv: Kan NAV hente inn informasjon om faktisk strømforbruk fra utstyr? | ||
| * Litt uklart her hva som skal hentes inn. CLI gir formodentlig mulighet for å hente ut et øyeblikksbilde på effektforbruk (Watt), men dette sier jo ingenting om energiforbruk over tid (Watt-timer). | * Litt uklart her hva som skal hentes inn. CLI gir formodentlig mulighet for å hente ut et øyeblikksbilde på effektforbruk (Watt), men dette sier jo ingenting om energiforbruk over tid (Watt-timer). | ||
| Line 219: | Line 226: | ||
| * Om man samler inn effektforbruk hvert minutt kan man f.eks. estimere energifobruket for dette minuttet ved å multiplisere effektforbruket med en faktor på ''1/60'' (en PSU som forbruker 1000W konstant i 60 sekunder har forbrukt ca. 16.7Wh). | * Om man samler inn effektforbruk hvert minutt kan man f.eks. estimere energifobruket for dette minuttet ved å multiplisere effektforbruket med en faktor på ''1/60'' (en PSU som forbruker 1000W konstant i 60 sekunder har forbrukt ca. 16.7Wh). | ||
| * Hvordan er MIB-støtten for å hente ut slikt på forskjellig utstyr? | * Hvordan er MIB-støtten for å hente ut slikt på forskjellig utstyr? | ||
| - | * :!: **AKSJON:** Utviklerteamet kan registrere et GitHub-issue, men dette krever noe kartleggingsarbeid som CNaaS-teamet selv må fylle på med. | + | * <del>:!: **AKSJON:** Utviklerteamet kan registrere et GitHub-issue, men dette krever noe kartleggingsarbeid som CNaaS-teamet selv må fylle på med.</del> |
| + | * [[https://github.com/Uninett/nav/issues/3312|Collect and graph device power usage #3312]] | ||
| * Chatlog fra Vidar F: | * Chatlog fra Vidar F: | ||
| Line 243: | Line 251: | ||
| * [[https://github.com/Uninett/nav/issues/3217| Fetch switch port VN (VRF) and Security Group Tag (SGT) from Cisco SDA #3217 ]] | * [[https://github.com/Uninett/nav/issues/3217| Fetch switch port VN (VRF) and Security Group Tag (SGT) from Cisco SDA #3217 ]] | ||
| * NTNU bruker aktivt søket ''Last seen (days ago)'' under fanen ''Netbox interfaces'' i et Room-view (''/search/room/<roomid>/#!netboxinterfaces'') for å finne porter som ikke har vært i bruk de siste ''N'' dagene. Men, de kan også tenke seg et invertert søk, altså formodentlig at man kan vise alle porter som *har vært i bruk* de siste ''N'' dagene. | * NTNU bruker aktivt søket ''Last seen (days ago)'' under fanen ''Netbox interfaces'' i et Room-view (''/search/room/<roomid>/#!netboxinterfaces'') for å finne porter som ikke har vært i bruk de siste ''N'' dagene. Men, de kan også tenke seg et invertert søk, altså formodentlig at man kan vise alle porter som *har vært i bruk* de siste ''N'' dagene. | ||
| - | * :!: **AKSJON:** Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det. | + | * <del>:!: **AKSJON:** Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.</del> |
| + | * [[https://github.com/Uninett/nav/issues/3313|Add complementary activity search to "Last seen" view in the Room view interfaces list #3313]] | ||
| * Ønsker seg muligheten til å begrense PortAdmin-brukere til å bare konfigurere port-description, ikke VLAN og andre ting. | * Ønsker seg muligheten til å begrense PortAdmin-brukere til å bare konfigurere port-description, ikke VLAN og andre ting. | ||
| * <del>:!: **AKSJON:** Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.</del> | * <del>:!: **AKSJON:** Utviklerteamet lager et GitHub-issue og ber Nils-Arild kvalitetssikre det.</del> | ||
| Line 260: | Line 269: | ||
| * UiO støtter arbeidet med å komme opp på siste Debian Stable (python3.11-jobbinga). | * UiO støtter arbeidet med å komme opp på siste Debian Stable (python3.11-jobbinga). | ||
| * Databaseskjema - er det noen tanker med å se på hvordan man kobler sammen tabeller, overgang til relasjonell databasemodell? | * Databaseskjema - er det noen tanker med å se på hvordan man kobler sammen tabeller, overgang til relasjonell databasemodell? | ||
| - | * :!: **AKSJON:** Det var uklart for både møtet og Jan Sigurd hva Morten Werner mente med dette punktet, all den tid NAV alltid har brukt en relasjonsdatabase. Kan Werner klare opp i kommentaren? | + | * <del>:!: **AKSJON:** Det var uklart for både møtet og Jan Sigurd hva Morten Werner mente med dette punktet, all den tid NAV alltid har brukt en relasjonsdatabase. Kan Werner klare opp i kommentaren?</del> |
| + | * Det virker som dette skyldes en misforståelse av hvordan NAVs room-tabell bruker romnavn som primærnøkler, og at det egentlig dreier seg om de punktene nav-ref har diskutert før om muligheten til å ha ikke-unike romnavn. | ||
| * //Overvåking av transceivere - hente ut alarmgrensene med alarmer ved overskridelse.// | * //Overvåking av transceivere - hente ut alarmgrensene med alarmer ved overskridelse.// | ||
| * Morten B formoder dette dreier seg om at transceivere som regel kommer med egne hardkodete terskelverdier som kunne vært avlest og benyttet av terskelregler i NAV. Dette mener har i alle fall å huske har vært en diskusjon i stamnettsgruppa på Sikt. | * Morten B formoder dette dreier seg om at transceivere som regel kommer med egne hardkodete terskelverdier som kunne vært avlest og benyttet av terskelregler i NAV. Dette mener har i alle fall å huske har vært en diskusjon i stamnettsgruppa på Sikt. | ||
| - | * :!: **AKSJON:** Morten B leter opp om han har noe underlagsmateriale om transceiverterskler fra før. | + | * <del>:!: **AKSJON:** Morten B leter opp om han har noe underlagsmateriale om transceiverterskler fra før.</del> |
| + | * Har funnet en del underlagsmateriale some er *Juniper-spesifikt*, der optikkterskler fins å lese av fra kolonner i ''JUNIPER-DOM-MIB::jnxDomCurrentTable'', som NAV allerede har delvis støtte for. | ||
| * //Overvåking av bias-spenning på tranceivere for å se at disse ikke endrer seg.// | * //Overvåking av bias-spenning på tranceivere for å se at disse ikke endrer seg.// | ||
| * Morten B mener dette muligens allerede samles inn og grafes, i alle fall for Cisco. Dette registreres som sensorer på en boks, men det er ikke alltid garantert at NAV klarer å koble en sensor opp mot en spesifikk port på boksen, slik at den i stedet blir liggende i den generelle oversikten over sensorer som fins på boksen. | * Morten B mener dette muligens allerede samles inn og grafes, i alle fall for Cisco. Dette registreres som sensorer på en boks, men det er ikke alltid garantert at NAV klarer å koble en sensor opp mot en spesifikk port på boksen, slik at den i stedet blir liggende i den generelle oversikten over sensorer som fins på boksen. | ||
nav-ref/navref_051124.1740567209.txt.gz · Last modified: 2025/02/26 10:53 by morten
Page Tools
