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
Hei Morten,
Har du fått respons fra nav-ref? Har ikke sett noe på lista. Jeg kopierer inn Einar som kan ha gode innspill her. En peptalk ved kaffemaskinen kan være forløsende.
- Vidar
On 17.06.2016 14:52, Morten Brekkevold wrote:
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
-
Morten Brekkevold -
Vidar Faltinsen