Két PE, egy prefix: miért az RD dönt a láthatóságról
Két peremrouter, amely ugyanazt a prefixet hirdeti, egy célpontot oszt meg, hacsak a route distinguisherük nem különbözik. Osszon ki szándékosan, majd ellenőrizze a VRF-et.
Két peremrouter, amely ugyanazt az ügyfélprefixet hirdeti, egyetlen VPNv4-célpontot ír le, amíg valami szét nem választja őket, és ez az elválasztó a route distinguisher. Minősíti a prefixet; nem dönti el, ki importálja az eredményt, az a route target dolga. Az RD-ket azoknak az útvonalaknak a halmazából ossza ki, amelyeknek minden domainben megkülönböztethetőnek kell maradniuk, ahol ezek a hirdetések találkozhatnak, nem egyetlen doboz fájlelrendezéséből. A választott szám olyan identitás, amelyre a későbbi átvizsgálások támaszkodni fognak, ezért a leltárba tartozik, mielőtt konfigurációba kerül.
Egy RD és egy prefix egyetlen célpont
Egy RD és egy IPv4-prefix alkotja azt a VPNv4-célpontot, amelyet a vezérlősík összehasonlít. Adjon két PE-nek ugyanazt a prefixet különböző ügyfelek számára, és különböző RD-k nélkül útvonalakat hirdetnek egy célpont felé. Semmi sem mondja meg a képernyőn, hogy ez a csoportosítás hibás, mert a platform pontosan azt teszi, amit az identitás mond. Módosítsa az RD-t az egyiken, és a régi hirdetés visszavonódik, miközben egy másik identitás alatt új jelenik meg. Minden, ami lefelé erre a régi identitásra épült, az útvonalválasztástól egy mentett operátorszűrőig, most valamire hivatkozik, ami már nem létezik.
Több útvonal egy célponthoz a BGP szokásos viselkedése, nem tünet. Egy speaker több fogadott útvonalat is tarthat, miközben egy legjobbat választ továbbításra, és a fogadott és a kiválasztott közötti rés az, ahol a láthatósági kérdések élnek. Amikor egy útvonal eltűnni látszik, erősítse meg, hogy az identitás, amelyhez tartozott, még létezik, mielőtt a munkamenetre nézne.
Ugyanaz az RD, ugyanaz a célpont, más útvonalak
Küldjön egy RD-t és egy prefixet két routerből ugyanazon szolgáltatás nevében, és mindkettő útvonalakat kínál egyetlen célpont felé, általában különböző következő ugrásokkal. Hogy ezek közül melyiket adja tovább egy route reflector, a reflectorról szóló döntés: az útvonalválasztása, a hirdetési képessége és a fölé rétegzett bármilyen házirend. Egyik peremrouter sem irányítja ezt a választást. Adjon a két hirdetésnek külön RD-t, és mindegyik a saját célpontjává válik, így mindkettő túlélhet egy olyan vezérlősíkot, amely egyébként csak a kiválasztott útvonalat viszi egy identitás számára.
A láthatóság és a többutas útvonalválasztás a fogadó VRF-ben találkozik, de nem ugyanaz a döntés, és egy két identitást vivő reflector nem konfigurált második telepített útvonalat. A VRF azt telepíti, amit az importszabályzata beenged, és amit a saját maximális útvonalszáma enged. Ellenőrizze ezt a beállítást külön, ha azt szeretné, hogy a második útvonal használatban legyen, ne csak látható.
A helyi egyediségi szabály nem szabályzat
Ha minden PE és minden útválasztási példány saját RD-t kap, az jó gyakorlat: megnevezi az eredetet, megakadályozza, hogy kapcsolatban nem álló szolgáltatások egy identitáson ütközzenek, és stabil kulcsot ad a leltárnak. Egyes platformok csak a dobozon belüli egyediséget írják elő, és kifejezetten engedik, hogy a routerek ugyanazon VPN-példány számára RD-t osszanak meg. Ez az engedély megvalósítási korlát, nem hálózatok közötti szabály, amelyet egy szállítóra bízhat. Ha a domain több csapatot ölel fel, írja meg maga a kiosztási szabályzatot.
A tagság soha nem a számjegyekből jön. Egy minta, mint 65000:12 az egyik PE-hez és 65000:13 a másikhoz, szokás, míg az egyező export- és importcélok, mint 65000:112, azok, amelyek egy útvonalat VRF-be tesznek. Tekintse az RD-t az útvonal identitásának, a route targetet pedig annak az engedélynek, amely VRF-be viszi.
A VRF-en bizonyítsa a változást, ne a kijelzőn
Mielőtt hozzányúlna egy RD-hez, írjon le négy dolgot: mit hirdet a PE ma, mit tükröz a reflector, mit importál a fogadó VRF, és melyik útvonalat választja. Egy új RD visszavon egy hirdetést és bevezet egy másikat, így a változás a munkamenet mindkét oldalán látszik, és könnyű félreolvasni, ha csak a hirdető oldalt figyeli. Az elfogadásnak a kívánt elérhetőségen kell alapulnia, nem egy prefixlistában megjelenő plusz soron. Az alábbi táblázat megakadályozza, hogy a három azonosító összemosódjon az átvizsgálás során.
| Identifier | Question it answers | What breaks when it is confused with another |
|---|---|---|
| Route distinguisher | Which route identity is this? | Two services collapse into one destination, so one advertisement withdraws the other |
| Route target | Who is allowed to import it? | Routes arrive in a VRF that should not have them, or never arrive at all |
| VRF import policy | What does this instance accept and install? | The route is visible on the PE but never selected in the VRF |
Kezdje a hirdető PE-n, és hasonlítsa össze mindkét identitást ugyanarra a prefixre, mielőtt bármit eltávolítana. Az alábbi IOS-parancsok sorrendben három kérdésre válaszolnak: ott van-e még a régi hirdetés, látható-e az új identitás a reflector számára, és kiválasztja-e a VRF a prefixet.
show bgp vpnv4 unicast rd 65000:12 203.0.113.0/24 show bgp vpnv4 unicast rd 65000:13 203.0.113.0/24 show ip route vrf CUSTOMER-A 203.0.113.0/24
Más platformok ugyanezt az információt más szintaxissal nyomtatják, és a kérdések túlélik ezt a változást. Ha az új identitás hiányzik a reflectornál, miközben a PE hirdetettként listázza, az első gyanúsított a reflector szabályzata vagy hirdetési képessége, nem a számozás.
Rögzítse a PE-t, a példányt, az RD-t, az export- és importcélokat és a prefix tulajdonjogát egy helyen, mert a következő kiosztás csak akkor keresés és nem találgatás, ha ez a rekord létezik. Tartsa meg a régi RD-t, amíg az új identitás láthatóvá nem válik a fogadó VRF-ben, majd vonja vissza egy második lépésben, hogy minden szakasz visszafordítható maradjon.