Mely SNMP-táblák kapcsolják össze a VPNv4 útvonalat a címkéjével?
Válassza ki a szükséges címkét, majd kapcsolja a VRF-útvonalbejegyzést egy kereszthuzalhoz és annak szegmenseihez. Mielőtt bejárja, erősítse meg, hogy az ügynök megvalósítja ezeket az objektumokat.
Három különböző címke utazik egyetlen VPNv4 útvonallal, és az SNMP-bejárás csak azokat mutatja, amelyeket az ügynök megvalósít. A fogadott BGP-attribútum, a helyben kiosztott bejövő szolgáltatáscímke és a kimenő továbbítási címke különböző táblákban, különböző indexek alatt található. A címkét úgy kérni egy eszköztől, hogy előbb nem választjuk ki, melyik hármat értjük, az az, amitől egy gyűjtési projekt már az első házánál elakad.
Válassza ki azt, amelyre a feladatának szüksége van, majd kövesse az indexláncot, amely eléri. Ha a lánc egy olyan objektumnál szakad meg, amelyet az ügynök nem valósít meg, az egy rögzítendő megállapítás, nem pedig egy kitalált OID-del kitöltendő hiány.
Válassza ki, melyik címkére van szüksége a feladatnak
A szomszédtól kapott címke BGP-útvonalattribútumként érkezik, és leírja, mit vár el az a szomszéd, hogy felé toljon. A bejövő szolgáltatáscímkét ez az eszköz osztja ki egy VRF-előtaghoz, és megjelöli az LSP-be belépő forgalmat. A kimenő felső címke az, amit a továbbítási sík valóban tolni szokott a következő ugrás felé, és minden alkalommal változik, amikor a következő ugrás változik.
Csak a második és a harmadik tartozik a lekérdezett doboz továbbítási állapotához. Az első a szomszéd elvárásáról szóló állítás, nem erről a házról.
A szabványos L3VPN-MIB modellezi a VRF-útvonalat és annak kapcsolatát egy kereszthuzallal, ami elég a helyi szolgáltatás- és továbbítási címkék eléréséhez. Nem ígér kiíratást minden attribútumról, amelyet egy BGP-munkamenet kapott. A táblát arról olvassa, amit tartalmaz, nem arról, amit a kérdés sugall. A hibás feltevésre épített gyűjtő nullákat jelent, és hiányzó adatként archiválja őket.
| 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 |
Kapcsolja a VRF-útvonalbejegyzést a kereszthuzalához
RFC 4382 definiálja a mplsL3VpnVrfRteTable-t. Az indexét hat résznek olvassa: a VRF neve, a cél címének típusa, maga az előtag, egy szabályérték, a következő ugrás típusa és a következő ugrás címe. Az IGP- és BGP-bejegyzések ugyanazt a táblát használják, ezért jegyezze fel az útválasztási protokollt az előtag mellé. Két sor ugyanazt az előtagot hordozhatja és csak a következő ugrásban térhet el, és a rossz sor választása más kereszthuzalhoz küldi a kapcsolatot.
A mplsL3VpnVrfRteXCPointer oszlop a kereszthuzal indexét hordozza, nem teljes sorszintű OID-ot, bár a név az ellenkezőjét sugallja. Az egyoktetes nulla érték azt jelenti, hogy nincs társított címkeverem, ezt látja a kötések beállása előtt vagy olyan útvonalnál, amelynek soha nem kellett ilyen.
A bejárás előtt fordítsa le az oszlopot, hogy a kimenet numerikus alrésze egyértelmű legyen. Az alábbi két parancs ugyanazt a csomópontot címezi különböző jelöléssel.
snmptranslate -m +MPLS-L3VPN-STD-MIB -On mplsL3VpnVrfRteXCPointer snmpwalk -v2c -c monitor 192.0.2.10 mplsL3VpnVrfRteXCPointer
Vigye a visszaadott indexet a kereszthuzal-táblába, amelynek bejegyzéskulcsa hármas: kereszthuzal-index, bejövő szegmensindex és kimenő szegmensindex. Ez a hármas az a kapcsolat, amely az útvonalat címkévé alakítja. Az egész tábla helyett az adott indexhez tartozó kereszthuzal-alrészt járja be, mert az indexelt olvasás érintetlenül tartja a kapcsolatot, a tömeges bejárás pedig nem.
Az indexet olvassa, ne a címke számát
A szegmensindex egy sort azonosít, a címke pedig egy érték azon a soron belül, így az egyik helyettesítése a másikkal látszólag hihető választ ad, amely a rossz LSP-re mutat. A bejövő oldalon vizsgálja meg az interfészt és a címkekontextust a mplsInSegmentLabel-gyel együtt, és ne feledje, hogy az objektum helyette egy címketáblára mutató mutatót is hordozhat, amikor a sor máshol lévő bejegyzésre hivatkozik.
A kimenő oldalon ellenőrizze a kimenő interfészt és azt, hogy a sor szerint tolódik-e felső címke, mielőtt a mplsOutSegmentTopLabel-öt olvasná. Egy semmit nem toló soron kitöltött felsőcímke-oszlop elavult érték vagy egy korábbi útvonal maradéka, nem jelenlegi továbbítási állapot. A mélyebb vermekhez a hivatkozott címkeverem-tábla kell, és ez a plusz lépés normális, nem hiba.
Különleges nulla-konvenciók vonatkoznak azokra az útvonalakra, amelyek helyben kezdődnek vagy végződnek az útválasztón. A nulla indexet dokumentált viselkedésnek tekintse, nem üres eredménynek, és erősítse meg a helyi továbbítási állapothoz képest.
Erősítse meg, mit valósít meg az ügynök, mielőtt méretez
Ellenőrizze a megvalósított objektumokat a pontos platform és kiadás, a használt címcsaládok és az alrészekre vonatkozó működési korlátozások szempontjából. Csak olvasási hitelesítő adattal kérdezzen, amely ezekre az alrészekre korlátozódik, és fogadja el, hogy egy hiányzó objektum azt is jelentheti, hogy a szolgáltatás nincs megvalósítva, nem azt, hogy az MIB hibás.
Mielőtt egy gyűjtőt a teljes táblára irányítana, egy ismert VRF-útvonalat korreláljon az eszköz saját működési kimenetével. Minden mintánál őrizze meg az összes indexkomponenst és a gyűjtés idejét, mert az útvonalak és kötések mozognak a bejárások között. A percek különbséggel készült két bejárásból összevarrt pillanatkép összekeverheti a régi kereszthuzal-indexet egy új útvonallal, és teljesen konzisztensnek tűnhet.
Ahol a fogadott BGP nézete vagy egy szállítóra jellemző címkeobjektum valóban hiányzik, lépjen át a platform által dokumentált telemetriai vagy működési interfészre. A szabványos kapcsolat a helyi továbbítási címkéket és kevés mást fed le, ezért egy gyűjtési tervezés első lépéseként kezelje, nem kész dologként.