On Wed, 21 Nov 2012 13:51:11 +0000 Gro-Anita Hillestad Vindheim gro-anita.vindheim@ntnu.no wrote:

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.

Denne diskusjonen har vi vel hatt gjentatte ganger før. Jeg har også skissert en løsning på det jeg tror er det egentlige problemet ditt, men mangler en ordentlig tilbakemelding på det.

Først og fremst forklarer du aldri hvorfor denne "feilklassifiseringen" er et problem for dere, og det tror jeg gjør det vanskelig for andre å engasjere seg i problemstillingen.

For å oppsummere ting som har vært sagt tidligere --------------------------------------------------

Jeg tror og antar at det egentlige problemet dere opplever er at dere mangler trafikkgrafer i Cricket for de såkalt "feilklassifiserte" portene. Muligens også når dere et eller annet sted forsøker å telle antall "porter" i nettet.

I mitt hode munner problemstillingen ut i at NTNU og utstyrsprodusentene har forskjellige oppfatninger om hva begrepet "switcheport" betyr.

I en nettboks er en switcheport et hvilket som helst interface som boksen forwarder ethernet-frames til, basert på en CAM-tabell. Det trenger ikke å dreie seg om en fysisk port på boksen, det kan godt være et virtuelt interface.

Det er dette som skjer når dere f.eks. bundler flere fysiske porter sammen til en Portchannel. Portchannelen oppstår som et virtuelt interface på boksen, anses som en switcheport og er dermed gjenstand for innslag i switchens CAM-tabell. De underliggende fysiske interfacene er ikke lenger gjenstand for innslag i CAM-tabellen, og forsvinner derfor ut av switchens oversikt over switchende porter.

Switchen konsulterer CAM-tabellen og forwarder pakker ut på det virtuelle Portchannel-interfacet. Portchannelen fordeler pakker den får til utsending på de underliggende fysiske interfacene etter eget forgodtbefinnende og uten å konsultere CAM-tabellen.

I SNMP-verdenen representeres dette ved at de bundlede fysiske interfacene forsvinner ut av BRIDGE-MIB. De er ikke lenger referert til i den fordi de ikke driver med switching og aldri vil ha noen relaterte CAM-innslag man kan plukke ut fra BRIDGE-MIB.

Du vil forøvrig også finne at protokoller som CDP og LLDP ikke lenger jobber på nivået til de fysiske portene, men på Portchannel-interfacet. Disse protokollene kan da ikke fortelle deg at A:Gi1/1 fysisk er koblet til B:Gi5/1 og A:Gi1/2 til B:Gi5/2, bare at A:Po1 er koblet til B:Po1.

For å oppsummere mitt tidligere løsningsforslag -----------------------------------------------

Det er mulig hele problemstillingen som fremstilles av dere er av semantisk art.

Jeg tror det dere egentlig er interessert i er hvilke fysiske porter en switch har, ikke i hvilken modus hver enkelt port på den opererer i for øyeblikket.

Oversikt over hvilke porter som er fysisk har NAV allerede, via objektet IF-MIBØØifConnectorPresent, som lagres for hvert interface i NAV i dag. Dette er en boolean som angir om et interface har en fysisk connector eller ikke.

Dette mener jeg ble foreslått allerede på referansegruppemøtet i oktober:

* Hva om ipdevpoll får en egen tab for fysiske porter? * Hva om Cricket konfigureres til å grafe alle fysiske porter?

Utover dette har vi allerede fastsatt punkt 16 på arbeidslisten: LP#1062177 Collect and present aggregated link info [1]. Altså at NAV også skal kunne ha oversikt over hvilke interface som utgjør en portchannel, til eksempel.

----

Så, er det noen som har noen formeninger og innspill til dette utover NTNU?

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

ifType=6 forteller deg bare at dette er et ethernet-interface. Det sier ingenting om det er en ruterport eller en switcheport eller noe annet, og det gir heller ingen sikker indikasjon på om interfacet er fysisk eller virtuelt (det fins derimot andre ifType-verdier som i det minste forteller deg at det er et virtuelt proprietært interface, men det sier heller ikke mye om hva interfacet holder på med).

[1] https://bugs.launchpad.net/nav/+bug/1062177