BGP útvonal reflektor - site hálózati szakemberek!
Jó idő, uraim.
Most nézzük egy nagyon érdekes téma, amely az úgynevezett útvonal reflektor.
De először nézzük fokozatosan jöttünk rá.
Van egy csomó router és BGP kimondja, hogy legyen teljes háló.
Képzeljük el, hogy van 20 router, teljes háló, mennyit kellene tönkölybúza TCP ülés? A képlet egyszerű: n * (n-1) / 2, összesen 190 ülés, nem kicsi, nem?
Ugyanez hátránya egy ilyen hálózat az, hogy a nagy forgalmú duplikatny Roth.
Mindezt úgy érjük el, két mechanizmus:
- Útvonal Reflektor
- Szövetség (al-AS)
Tekintsük mindkettő, de kezdődik reflektorok.
IBGP osztott horizont azt mondja, hogy ha megkapjuk az útvonal IBGP, akkor sem az útvonal már nem küld, és miért? Már teljes háló. Tehát meg kell változtatni 🙂
Van egy csomó router, meg kell választani egy router, és ez egy szerver (tükör), minden router, már csak egy linket a szerver, mint a router nevezzük ügyfelek. Egy ilyen szerver (reflektor) és a fogyasztók együttesen a klaszterek.
Most, hogy a Útvonal reflektor elküldi az ügyfelek ezt az utat, az ügyfél kap, vagy küld el senkit, mert nincs kapcsolatokat senkinek.
Így sem igen jelentős mértékben csökkentette a testreszabási és természetesen TCP ülések között társaik.
A mi AS lehet 1 RR (Route reflektor), előfordulhat, hogy több, és talán csak nem hierarchikus, nézzük meg a szabályokat minden:
Ha egy útvonalat már kapott az ügyfél, akkor ez az út nem lesz átirányítva az ügyfelek és az ügyfelek.
Ha RR nem kapott az útvonalat a kliens (a IBGP peer), akkor ezt az utat csak akkor lesz elküldve ügyfeleiknek.
Ha az RR útvonalon érkező EBGP szomszéd, akkor elküldi az útvonal nem minden kliens és az összes kliens.
Minden RR kell konfigurálni egy Cluster_ID
Minden RR azonos Cluseter_ID kell teljes háló
RR ügyfél legyen teljes háló minden a RR Cluster_ID
Minden router kell konfigurálni az azonos CLUSTER_ID
RR ügyfelek kell teljes háló a RR
RR kell teljes háló egymást abban az esetben, hierarchia, egy hierarchia nincs mélysége korlátai.
Elméletileg az RR, akkor kap egy hurkot, a BGP két olyan biztonsági mechanizmus a csukló, és origitator_id cluster_list.
Például, van egy klaszterek száma, annak érdekében, hogy nyomon kövesse a hurok attribútum kötelező, ami kell jelölni minden fürt útvonal (hasonlóan AS-PATH), akkor ellenőrizzük a klaszter-lista RR néz ki, és ischit ott a CLUSTER_ID, ha ő ott van, az útvonal nem lehet elküldeni senkit, egyszerűen eldobjuk.
ORIGINATOR_ID nem tranzitív tulajdonság, ez az attribútum ROUTER_ID router, hogy létrehozta ezt az útvonalat, ha a frissítés jött valaki, és a router látja ugyanazt vvide originator_id magad, akkor ezt az utat kell dobni.
Ez azt jelenti, cluster_list védelmi körök közötti klaszterek és originator_id a klaszteren belül. Hogy mit jelent a munka ugyanaz.
Lehetséges problémák merülhetnek fel, ha a RR:
Ha az ügyfél nem csatlakozik az összes RR a fürt nem minden IBGP útvonalak kapott.
Ha a kliens csatlakozik különböző klaszterek RR, akkor jön ismétli.
Ha a fürt ügyfél vissza van kötve a többi ügyfél, akkor jön a másolatokat.
Ha megfelelően van konfigurálva, RR és megfelelő tervezés, ezek a problémák nem fordulnak elő.