nav.ref November 2012

nav.ref@lister.sikt.no

8 participants
6 discussions

[nav-ref] Agenda nav-ref møte #4: 9/3 2013
by Morten Brekkevold 05 Apr '13

05 Apr '13

Vel møtt til nytt nav-ref-møte, 9. april hos UNINETT! Møtet blir på møterom Turkis i 5. etg, kl. 09-15. Møtene genererer mange nye og gode idéer, men vi får ofte litt lite tid til å diskutere detaljene. Det er heller ikke alltid vi får noe særlig respons når vi etterspør detaljer på denne listen i etterkant. Derfor håper vi at vi kan bruke litt av tiden til å diskutere nettopp detaljer rundt noen av punktene vi har på arbeidslista. Vi foreslår følgende overordnede agenda (men tar gjerne i mot forslag til endringer): 0900-1000 Status gjeldende arbeidsliste. Release-plan (3.15 = 12/9, 3.16 = 13/12). 1000-1200 Innspill til implementasjonsdetaljer. Oppgaver med lite "kjøtt på beina": - LP#1069763: Graph topology as seen from a device in ipdevinfo - LP#1062288: NAV should provide a topology-based analysis of "what-happens-if-this-device-goes-down" - LP#1062286: Add a tool for deploying and undeploying VLANs 1200-1300 Lunch 1300-1500 Innspill fra referansegruppen - vi har ikke fått mange nye siden sist møte, så vi kjører åpent forum. Meld gjerne inn punkter til agendaen om du har noe du vet du vil snakke om. Har ikke lagt inn kaffepauser i planen - disse tar vi underveis når det passer inn. Vi får forøvrig servert kaffe i møterommet. Før vi reiser hvert til vårt avtaler vi nytt møte til høsten. UNINETT-konferansen er i Trondheim fra 2.-3. oktober. Vi skal også avholde en verktøysamling rundt denne tiden, dato er enda ikke fastsatt. Det kan være en fordel å legge møtedagen back-to-back med en av disse. Foreløpige forslag: 1/10 eller 4/10. -- mvh Morten Brekkevold UNINETT

2 2

[nav-ref] Manglende deteksjon av interface-type
by Gro-Anita Hillestad Vindheim 23 Nov '12

23 Nov '12

Hei alle! På NTNU har vi problemer med at NAV ikke forstår at en del porter er switcheporter. Pr i dag tolker NAV interfaces på følgende måte (ref Morten): "Dersom porten fins i BRIDGE-MIB::dot1dBasePortTable driver den med switching. Dersom porten har en IP-adresse i IP-MIB er den på lag 3. Andre porter har vi ingen klassifisering av - mao hvis ingen av disse treffer så får den N/A." Denne algoritmen er ikke tilfredsstillende for NTNUs utstyr, vi "mister" en hel del swporter av helt standard type. Jeg lurer på hvor utbredt dette er hos dere andre? Hvor mange treff får dere i følgende rapport, og hvor mange av disse vurderer dere til å være feil? https://NAVBOKSENDIN /report/interfaces?layer=N%2FA Sorter gjerne på ifType. -------------- Vår verktøykasse gir oss nå 1502 interfaces med ifType=6 som ikke klassifiseres til swporter. 1268 av dem er heller ikke portchannel av noe slag. Mao anser vi at vi har minst 1268 feilklassifiserte interface . Vi på NTNU vurderer å lage en lokal database-oppdateringsjobb som overskriver NAV sin klassifisering. Har dere andre noen tanker om noe tilsvarende, eller er det bare på NTNU dette er et problem ? Gro-Anita -- Gro-Anita

3 2

[nav-ref] Liten oppdatering i arbeidslisten
by Morten Brekkevold 14 Nov '12

14 Nov '12

Kort info: John-Magne tok opp designarbeidet på grafing av IP-adresseforbruk igjen i dag, og så klarte vi plutselig ikke å finne det igjen i arbeidslisten. Det må ha falt ut da vi sydde sammen den nye listen, uten at noen har merket det før nå - det er i alle fall lagt inn som punkt 6 på https://openwiki.uninett.no/gigacampus:nav-ref-arbeidsliste nå. -- Morten Brekkevold UNINETT

1 0

[nav-ref] Arnold
by John-Magne Bredal 13 Nov '12

13 Nov '12

Hei! Det er ikke alle her som kjenner like godt til Arnold, men jeg vet at i alle fall noen av dere er aktive brukere av det. Arnold er gammel, og har stort sett "bare fungert". Vanligvis ville vi ikke tatt i denne koden, problemet er bare at Arnold ikke bruker noen av de rammeverkene som resten av NAV bruker og det forhindrer flere ting - mest av alt det å komme seg vekk fra mod_python. Derfor holder jeg på med å skrive om Arnold til å bruke andre rammeverk. I forbindelse med dette vil jeg gjerne at dere svarer på følgende spm: - Hvem av dere bruker Arnold? - Bruker dere forfølgelse av sperrede maskiner som flytter seg (t1000)? - Bruker dere automatisk sperring (start_arnold)? - Bruker dere automatisk åpning av maskiner etter en tidsperiode? -- John-Magne Bredal UNINETT AS

4 3

[nav-ref] Trenger innspill til visning av topologigrafer i ipdevinfo
by Roy Sindre Norangshol 13 Nov '12

13 Nov '12

Hei hei! Det er et ønske for å vise topologigrafer i ipdevinfo, men her trenger vi innspill på hva som ønskes av funksjonalitet og hvordan vi skal løse problemene. Det første er hvordan dere ser for dere de to toplogigrafene skal representeres i ipdevinfo. Den første grafen, «Next-hop grafen» er relativt en liten og enkel graf som lett kan vises ved siden av andre elementer i same arkfane (f.eks. «Device Info») under ipdevinfo . Jeg ser for meg at grafen vil se tilsvarende ut som dette: (Netbox)<------+ +----------------> (Netbox) + + (Selected Netbox) + + | | | +-----> (Netbox) | (Netbox)<-----+ Vi ser for oss at det er naturlig at vi bare viser den «fysiske» topologien for «Next-hop grafen» (les lag2), eller er det ønskelig å kunne endre visning mellom lag2 og lag3? Om ja, hvordan? Mitt forslag om det skal støttes visning mellom lag 2 og lag 3 i «Next-hop grafen», gjøres dette ved å ha et klikkbart bilde som illustrerer å bytte visning mellom lag 2 og lag 3 i topologien. Selve kartet blir plassert i en «blå infoboks» (Jeg tenker på de blå infoboksene som har overskrifter som «IP Device: ip-adresse» og «DNS: ip-adresse» som vises på http://nav/ipdevinfo/x.x.x.x ) hvor overskriften kan være «Next-hop graph [bildelink for å endre visning mellom nettverkslagene]{egenskaper på bildet: flyter til høyre i infoboksen slik bildet alltid dukker opp helt til høyre i infoboksen}». Har dere forslag til hvordan bildet for visning mellom lag 2 og lag 3 ev. skal se ut? Eksisterer det allerede et allment kjent ikon som bør brukes? Funksjonaliteten til «Next-hop grafen» er å gi et kjapt innblikk over hvem som er dens nærmeste nabo for valgt «netbox». Når du klikker på en «netbox» i grafen, vil du bli videresendt til ipdevinfo-siden til «netboxen» du klikket på med visning for dens «Next-hop graf». I tillegg vil det nedenfor «Next-hop grafen» ligge en hyperlenke til /netmap hvor du kan se hele topologien med den valgte «netboxen» som nullpunkt i nettkartet. Den andre grafen som er ønsket er en visning av «downlinks» fra en valgt «netbox». Jeg velger å kalle grafen TFSDID («Topology from selected device and it's downlinks») inntil dere kommer med et betre forslag. :-) TFSDID-grafen har flere spennende problemer. Om valgt «netbox» er en GW eller GSW vil det å navigere seg ned igjennom grafen føre til at vi viser hele topologien som NAV kjenner til, og dette er vel allerede jobben til /netmap. Det same problemet oppstår om «next-hop» fra valgt «netbox» er en GW eller GSW, og vil ende opp med at du viser store deler av topologien som NAV kjenner til. Hvordan løser vi dette? Skal vi tillate å vise en TFSDID-graf om valgt «netbox» er av typen GW eller GSW? Ønsker dere å vise «downlinks» til GW-en om GW-en står som «next-hop» til valgt «netbox»? Vil det fungere å legge inn et unntak for å ikke utvide grenen i grafen om «next-hop netboxen» til den valgte «netboxen» er av typen GW eller GSW? Jeg har også et inntrykk av at TFSDID-grafen kan bli ganske diger, og må plasseres i egen arkfane i /ipdevinfo. Er det kanskje bedre at dette blir en funksjon i /netmap? Jeg ser for meg at TFSDID-grafen vil se tilsvarende ut som dette: (SW)<-------+ +----> (SW)+ +----> (SW) | | | | This is actaully fine, as it limits | | | | the topology graph somehow at least... + + | + (Selected Netbox) +-> (GW)+------> (SW)+------>(GW)+--->(SW) + + | | | +-------> (GW)+--->(SW) (GW)<----------+ -- Roy Sindre Norangshol Studenthospitant hos UNINETT norangshol(a)uninett.no

2 1

Re: [nav-ref] Arnold
by Borge Brunes 05 Nov '12

05 Nov '12

john.m.bredal(a)uninett.no said: > Det er ikke alle her som kjenner like godt til Arnold, men jeg vet at i alle > fall noen av dere er aktive brukere av det. [cut] UiTø bruker ikke Arnold. Børge

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

nav.ref November 2012