Hvilke SNMP-tabeller knytter en VPNv4-rute til etiketten sin?
Velg etiketten du trenger, og knytt deretter VRF-ruteposten til en krysskobling og segmentene dens. Bekreft at agenten implementerer disse objektene før du går gjennom.
Tre forskjellige etiketter reiser med én enkelt VPNv4-rute, og en SNMP-gjennomgang viser bare dem agenten implementerer. Den mottatte BGP-attributten, den lokalt tildelte inngående tjenesteetiketten og den utgående videresendingsetiketten ligger i forskjellige tabeller under forskjellige indekser. Å spørre en enhet om etiketten uten først å velge hvilken av de tre du mener, er måten et innsamlingsprosjekt stopper på sitt første chassis.
Velg den oppgaven din trenger, og følg deretter indekskjeden som når den. Hvis kjeden bryter på et objekt agenten ikke implementerer, er det et funn å registrere, ikke et hull å fylle med en oppdiktet OID.
Velg hvilken av de tre etikettene oppgaven trenger
En etikett mottatt fra en nabo kommer som en BGP-stiattributt og beskriver hva naboen forventer at du skyver mot den. Den inngående tjenesteetiketten tildeles av denne enheten for et VRF-prefiks og markerer trafikk som går inn i LSP-en. Den utgående toppetiketten er det videresendingsplanet faktisk skyver mot neste hopp, og den endres når neste hopp endres.
Bare den andre og tredje hører til videresendingstilstanden på boksen som polles. Den første er en uttalelse om naboens forventning, ikke om dette chassiset.
Standard L3VPN-MIB modellerer VRF-ruten og dens tilknytning til en krysskobling, noe som er nok til å nå de lokale tjeneste- og videresendingsetikettene. Den lover ikke en dump av hver attributt en BGP-økt har mottatt. Les tabellen for det den inneholder, ikke for det spørsmålet antyder. En innsamler bygget på en feil antakelse rapporterer nuller og arkiverer dem som manglende data.
| What you want | Where it lives | What a walk can return |
|---|---|---|
| Label advertised by a peer | BGP session state for that VRF | Usually outside the standard L3VPN MIB |
| Incoming service label for a prefix | VRF route entry joined to an incoming segment | Available when both tables are implemented |
| Label pushed toward the next hop | Outgoing segment with a push condition | Available, but only meaningful while a top label is pushed |
Knytt VRF-ruteposten til krysskoblingen sin
RFC 4382 definerer mplsL3VpnVrfRteTable. Les indeksen som seks deler: VRF-navnet, adresstypen til målet, selve prefikset, en policyverdi, typen neste hopp og adressen til neste hopp. IGP- og BGP-poster deler denne tabellen, så noter rutingprotokollen ved siden av prefikset. To rader kan bære samme prefiks og avvike bare i neste hopp, og å velge feil rad sender koblingen mot en annen krysskobling.
Kolonnen mplsL3VpnVrfRteXCPointer bærer indeksen til krysskoblingen i stedet for en full rad-OID, selv om navnet antyder det motsatte. En nullverdi på én oktett betyr ingen tilknyttet etikettstakk, som er det du ser før bindinger faller på plass eller for en rute som aldri har trengt en.
Oversett kolonnen før du går gjennom den, slik at det numeriske undertreet i utdataene er entydig. Begge kommandoene nedenfor adresserer samme node i ulik notasjon.
snmptranslate -m +MPLS-L3VPN-STD-MIB -On mplsL3VpnVrfRteXCPointer snmpwalk -v2c -c monitor 192.0.2.10 mplsL3VpnVrfRteXCPointer
Ta den returnerte indeksen inn i krysskoblingstabellen, der postnøkkelen er en trippel: krysskoblingsindeks, inngående segmentindeks og utgående segmentindeks. Den trippelen er koblingen som gjør en rute til en etikett. Gå gjennom undertreet for krysskoblinger for den spesifikke indeksen i stedet for hele tabellen, fordi den indekserte lesingen holder tilknytningen intakt og masselesingen ikke.
Les indeksen i stedet for etikettnummeret
En segmentindeks identifiserer en rad, og en etikett er en verdi inne i den raden, så å bytte den ene med den andre gir et tilsynelatende troverdig svar som peker på feil LSP. På inngående side, inspiser grensesnittet og etikettkonteksten sammen med mplsInSegmentLabel, og husk at objektet i stedet kan bære en peker inn i en etikettabell når raden viser til en post et annet sted.
På utgående side, kontroller det utgående grensesnittet og om raden sier at en toppetikett skyves før du leser mplsOutSegmentTopLabel. En fylt toppetikettkolonne på en rad som ikke skyver noe er en utdatert verdi eller en rest fra en tidligere sti, ikke gjeldende videresendingstilstand. Dypere stakker trenger den refererte etikettstakktabellen, og det ekstra trinnet er normalt, ikke en feil.
Spesielle nullkonvensjoner gjelder for stier som starter eller slutter lokalt på ruteren. Behandle en nullindeks som dokumentert atferd i stedet for et tomt resultat, og bekreft den mot den lokale videresendingstilstanden.
Bekreft hva agenten implementerer før du skalerer
Verifiser de implementerte objektene for den nøyaktige plattformen og utgivelsen, adressefamiliene som brukes og eventuelle driftsmessige begrensninger på undertrærne. Poll med en skrivebeskyttet legitimasjon begrenset til disse undertrærne, og aksepter at et manglende objekt kan bety at funksjonen ikke er implementert, snarere enn at MIB-en er feil.
Korreler én kjent VRF-rute mot enhetens egen driftsutdata før du peker en innsamler mot hele tabellen. Ta vare på hver indekskomponent og innsamlingstidspunktet med hvert utvalg, siden ruter og bindinger flytter seg mellom gjennomganger. Et øyeblikksbilde sydd sammen av to gjennomganger med minutters mellomrom kan blande en gammel krysskoblingsindeks med en ny rute og se helt konsistent ut.
Der visningen av mottatt BGP eller et leverandørspesifikt etikettobjekt virkelig mangler, gå over til et telemetri- eller driftsgrensesnitt som plattformen dokumenterer. Standardkoblingen dekker lokale videresendingsetiketter og lite annet, så behandle den som det første trinnet i et innsamlingsdesign, ikke som den ferdige tingen.