nav.ref Juni 2016

nav.ref@lister.sikt.no

4 participants
3 discussions

Re: [nav-ref] RFC: alert on loss of redundancy in an aggregated (portchannel) link
by Morten Brekkevold 20 Sep '16

20 Sep '16

On Fri, 24 Jun 2016 13:01:31 +0000 Rune Kittelsen <rune.kittelsen(a)uia.no> wrote: > Hei! Hei Rune! Jeg har klipt vekk alle detaljene dine, men kopierer nav-ref (som en liten påminnelse om at jeg fremdeles gjerne vil ha tilbakemeldinger på faktisk ønsket funksjonalitet). > Vi har Cisco only. Kjerne og kant. Nexus på serverrom. Vel, så ser du ut til å ha drømmesituasjonen ift. til dette. Ruteren og switchen du lister eksempler fra har en portchannel seg i mellom. NAV har funnet topologi både på det logiske og de fysiske interfacene. Det vil si at dersom en av de fysiske interfacene i portchannelen mister link, så skal NAV allerede varsle deg med en linkDown, ettersom boksen bak fremdeles er nåbar. Det store spørsmålet er selvfølgelig om en linkDown er nok, eller om NAV skal ha et skille, ved at det opprettes en egen alarmtype for "aggregated link degraded". Per i dag ser malen for en linkDown-alarm slik ut: > Subject: Link down on {{ netbox.sysname }}: {{ interface }} > This is an automatically generated message from NAV: > Box {{ netbox.sysname }} ({{ netbox.ip }}) has lost link on interface {{ interface }} ({{ ifalias }}) Det er i dag ikke noe problem å utvide denne malen til å si noe mer om linkpartneren, og muligens også hvorvidt interfacet inngår i en eller annen form for "stack" (som kan bety link-aggregering eller også helt andre ting). Ellers har jeg funnet ut at IEEE8023-LAG-MIB::dot3adAggPortSelectedAggID ser ut til å gi oss helt eksplisitt informasjon om forholdet mellom aggergerte interface. Den forteller oss hvilke ifIndex som er aggregert under en annen ifIndex. Den ser ut til å være greit støttet på Cisco/Nexus og Juniper, men ikke på våre HP-switcher. Når det er sagt, ser vi topologi på både fysisk og logisk port på HP-ene, så de vil være dekket av samme scenario som over. Min foreløpige mening om dette er at vi kommer langt, kanskje helt i mål, med denne oppgaven ved å bare forbedre informasjonen som følger en linkDown-alarm - men avventer altså eksempler fra dere andre (som kanskje har tatt ferie allerede?). -- mvh Morten Brekkevold UNINETT

2 3

[nav-ref] RFC: alert on loss of redundancy in an aggregated (portchannel) link
by Morten Brekkevold 23 Jun '16

23 Jun '16

Hei nav-ref! Endelig begynner jeg å få litt tid til å se på nye features i NAV igjen, og først på arbeidslisten står "LP#1248086 - alert on loss of redundancy in an aggregated (portchannel) link" [1]. Jeg har gjort noen undersøkelser, og føler jeg trenger noen innspill fra dere før jeg kan gå videre. Jeg forventer selvfølgelig at dere tar dere god tid til å lese det jeg skriver og komme med innpsill, ettersom dere har stemt frem dette som den viktigste oppgaven fremover :-) Først, litt bakgrunn: NAVs primære måte å oppdage portchannels på i dag (uten at det kalles portchannel av NAV) er IF-MIB::ifStackTable. Denne tabellen er beskrevet som følger: > The table containing information on the relationships > between the multiple sub-layers of network interfaces. In > particular, it contains information on which sub-layers run > 'on top of' which other sub-layers, where each sub-layer > corresponds to a conceptual row in the ifTable. For > example, when the sub-layer with ifIndex value x runs over > the sub-layer with ifIndex value y, then this table > contains: > > ifStackStatus.x.y=active > > For each ifIndex value, I, which identifies an active > interface, there are always at least two instantiated rows > in this table associated with I. For one of these rows, I > is the value of ifStackHigherLayer; for the other, I is the > value of ifStackLowerLayer. (If I is not involved in > multiplexing, then these are the only two rows associated > with I.) > > For example, two rows exist even for an interface which has > no others stacked on top or below it: > > ifStackStatus.0.x=active > ifStackStatus.x.0=active Tabellen er altså ikke spesifikk på hva det er som gjør at to interface har et forhold til hverandre, og det brukes følgelig til flere forskjellige ting av forskjellige leverandører. Ofte finner man forholdet mellom logiske porter og de fysiske portene som er bundlet sammen til denne channelen. På HP ser vi at alle VLAN-interface ser ut til å ha et forhold til alle switcheportene som hører til dette VLANet (der VLAN-porten da er higher layer, mens de fysiske portene er lower layer). Uansett hva informasjonen faktisk beskriver, så brukes det ikke til noe spesielt av NAV i dag, annet enn at relasjonen mellom portene vises i ipdevinfo. Naboskap/topologi ================= Vi har sett flere varianter av hva utstyret rapporterer når man bundler porter. Den første vi ble klar over var at de fysiske portene opphørte å rapportere seg som switcheporter, og all naboskapsinformasjon fra dem forsvant. Den logiske bundlede porten fremsto som en switcheport, og hadde naboskapsinformasjon. Den andre vi har sett, oppgir både den logiske og de fysiske portene som switcheporter, der alle har naboskapsinformasjon. Sistnevnte er sannsynligvis den mest nyttige formen, da man ser hvilke fysiske porter som er koblet sammen, ikke bare hvilke logiske som er det. Varsling er allerede støttet i NAV ================================== Under sistnevnte modell skal man faktisk allerede oppnå at NAV varsler dersom en av de fysiske linkene går ned. Default-mode for linkvarsling er at hvis boksen bak fremdeles er nåbar når en link mot den går ned, så har man tap av redundans, og dermed varsles det med linkDown (alarmen sier altså ikke noe spesifikt om tap av redundans, men det kunne den potensielt ha gjort). Situasjoner som ikke er støttet i dagens NAV ============================================ Under førstnevnte modell vil ikke NAV se naboskap på de fysiske portene, og vil derfor ikke bry seg om at de mister link. Vi kunne potensielt sjekke om porter som mister link har en relasjon til et interface på et høyere lag, og anta at den derfor er en bundlet port og at linkDown skal varsles. Problemet er at NAV da vil gjøre det samme for en vilkårlig switcheport på HP, fordi den har en relasjon til et VLAN-interface på et høyere lag. Eventuelt måtte man ha en eller annen heuristikk som avgjorde hvorvidt porten er bundlet eller ikke, basert på navn eller hvorvidt den logiske porten er et interface på lag 2 eller lag 3. Det jeg også lurer på er hvordan bundling skjer på plattformer utover de vi har vært mest vant til. Jeg ser NTNU har mange Nexus-switcher med porter navngitt etter mønsteret 'port-channelXXX'. Jeg antar at dette er logiske porter, men det ser ikke ut til at disse Nexus-switchene sier noe spesielt om disse portene i ifStackTable. Er det noen som har noen idé om hvordan vi skal finne denne informasjonen på Nexus? Tilsynelatende kan man få noe ut av IEEE802-LAG-MIB [2] (og muligens CISCO-LAG-MIB, men vi vil helst forholde oss til standardiserte MIB-er). Kan forøvrig alle som har portchannels og andre varianter av portbundling i dag være så snille å melde inn noen av disse og beskrive hvordan de ser ut i NAV i dag? Alternativ alarm ================ Er en linkDown-alarm for degraderte aggregerte linker godt nok, eller skal vi ha en helt egen og ny event/alerttype for tap av redundans i aggregerte linker? [1] https://bugs.launchpad.net/nav/+bug/1248086 [2] http://www.ieee802.org/3/publication/ad/IEEE8023-LAG-MIB.txt -- mvh Morten Brekkevold UNINETT

2 1

[nav-ref] Avklaringer hierarkisk lokasjon
by John Magne Bredal 14 Jun '16

14 Jun '16

Hei, allerede uken etter ny NAV-release er vi i gang med flere forbedringer i NAV. Hierarkiske lokasjoner har blitt stemt frem som en oppgave, noe vi antagelig kan takke de mange sammenslåingene og innlemmingene av utdanningsinstitusjoner for. Det at en lokasjon kan hierarkisk sett være under en annen lokasjon gjør at vi må avklare en ting angående Maintenance: Når man velger en lokasjon i en Maintenance-task, skal maintenancen da gjelde alle rom som er med i hierarkiet? Eller skal det bare gjelde de rommene som er direkte med i lokasjonen, slik at man velger alle lokasjonene i et hierarki dersom man vil ha med alle? Vårt initielle forslag er at brukeren velger alle lokasjonene selv. Det samme gjelder forøvrig Device History. mvh -- John Magne Bredal john.m.bredal(a)uninett.no +4791897366 Abels gt. 5- Teknobyen NO-7465 Trondheim

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

nav.ref Juni 2016