Vilka SNMP-tabeller kopplar en VPNv4-rutt till sin etikett?
Välj den etikett du behöver och koppla sedan VRF-ruttposten till en korskoppling och dess segment. Bekräfta att agenten implementerar dessa objekt innan du går igenom.
Tre olika etiketter färdas med en enda VPNv4-rutt, och en SNMP-vandring visar bara dem som agenten implementerar. Det mottagna BGP-attributet, den lokalt tilldelade inkommande tjänsteetiketten och den utgående vidarebefordringsetiketten ligger i olika tabeller under olika index. Att fråga en enhet efter etiketten utan att först välja vilken av de tre du menar är hur ett insamlingsprojekt fastnar redan på sitt första chassi.
Välj den som din uppgift behöver och följ sedan indexkedjan som når den. Om kedjan bryts vid ett objekt som agenten inte implementerar är det ett fynd att registrera, inte en lucka att fylla med ett påhittat OID.
Välj vilken av de tre etiketterna uppgiften behöver
En etikett som tas emot från en granne kommer som ett BGP-vägattribut och beskriver vad grannen förväntar sig att du ska trycka mot den. Den inkommande tjänsteetiketten tilldelas av den här enheten för ett VRF-prefix och markerar trafik som går in i LSP:n. Den utgående toppetiketten är det som vidarebefordringsplanet faktiskt trycker mot nästa hopp, och den ändras när nästa hopp ändras.
Bara den andra och den tredje hör till vidarebefordringstillståndet på lådan som avfrågas. Den första är ett påstående om grannens förväntan, inte om det här chassit.
Standard-L3VPN-MIB modellerar VRF-rutten och dess koppling till en korskoppling, vilket räcker för att nå de lokala tjänste- och vidarebefordringsetiketterna. Den lovar inte en dump av varje attribut som en BGP-session har tagit emot. Läs tabellen för vad den innehåller, inte för vad frågan antyder. En insamlare byggd på ett felaktigt antagande rapporterar nollor och arkiverar dem som saknade 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 |
Koppla VRF-ruttposten till dess korskoppling
RFC 4382 definierar mplsL3VpnVrfRteTable. Läs dess index som sex delar: VRF-namnet, destinationens adresstyp, själva prefixet, ett policyvärde, typen av nästa hopp och adressen för nästa hopp. IGP- och BGP-poster delar den tabellen, så notera routingprotokollet bredvid prefixet. Två rader kan bära samma prefix och skilja sig bara i nästa hopp, och att välja fel rad skickar kopplingen mot en annan korskoppling.
Kolumnen mplsL3VpnVrfRteXCPointer bär korskopplingens index i stället för ett fullständigt rad-OID, även om namnet antyder motsatsen. Ett nollvärde på en oktett betyder ingen associerad etikettstack, vilket du ser innan bindningarna sätter sig eller för en rutt som aldrig har behövt någon.
Översätt kolumnen innan du går igenom den, så att det numeriska underträdet i utdata är entydigt. Båda kommandona nedan adresserar samma nod i olika notation.
snmptranslate -m +MPLS-L3VPN-STD-MIB -On mplsL3VpnVrfRteXCPointer snmpwalk -v2c -c monitor 192.0.2.10 mplsL3VpnVrfRteXCPointer
Ta det returnerade indexet in i tabellen för korskopplingar, vars postnyckel är en trippel: korskopplingsindex, inkommande segmentindex och utgående segmentindex. Den trippeln är den koppling som gör en rutt till en etikett. Gå igenom underträdet för korskopplingar för det specifika indexet i stället för hela tabellen, eftersom den indexerade läsningen behåller kopplingen och massvandringen inte.
Läs indexet i stället för etikettnumret
Ett segmentindex identifierar en rad, och en etikett är ett värde inne i den raden, så att byta ut det ena mot det andra ger ett till synes trovärdigt svar som pekar på fel LSP. På den inkommande sidan, inspektera gränssnittet och etikettkontexten tillsammans med mplsInSegmentLabel, och kom ihåg att objektet i stället kan bära en pekare in i en etikettabell när raden hänvisar till en post någon annanstans.
På den utgående sidan, kontrollera det utgående gränssnittet och om raden säger att en toppetikett trycks innan du läser mplsOutSegmentTopLabel. En fylld toppetikkolumn på en rad som inte trycker något är ett inaktuellt värde eller en rest från en tidigare väg, inte aktuellt vidarebefordringstillstånd. Djupare stackar kräver den refererade etikettstacktabellen, och det extra steget är normalt, inte en defekt.
Särskilda nollkonventioner gäller för vägar som börjar eller slutar lokalt på routern. Behandla ett nollindex som dokumenterat beteende i stället för ett tomt resultat, och bekräfta det mot det lokala vidarebefordringstillståndet.
Bekräfta vad agenten implementerar innan du skalar
Verifiera de implementerade objekten för den exakta plattformen och utgåvan, de adressfamiljer som används och eventuella driftmässiga begränsningar på underträden. Avfråga med en skrivskyddad autentiseringsuppgift begränsad till dessa underträd, och acceptera att ett saknat objekt kan betyda att funktionen inte är implementerad, snarare än att MIB:en är fel.
Korrelera en känd VRF-rutt mot enhetens egen driftsutdata innan du riktar en insamlare mot hela tabellen. Spara varje indexkomponent och insamlingstidpunkten med varje prov, eftersom rutter och bindningar flyttar sig mellan vandringar. En ögonblicksbild sydd ihop av två vandringar med minuters mellanrum kan blanda ett gammalt korskopplingsindex med en ny rutt och se helt konsekvent ut.
Där vyn över mottagen BGP eller ett leverantörsspecifikt etikettobjekt verkligen saknas, gå över till ett telemetri- eller driftsgränssnitt som plattformen dokumenterar. Standardkopplingen täcker lokala vidarebefordringsetiketter och lite annat, så behandla den som det första steget i en insamlingsdesign, inte som den färdiga saken.