Bine, domnilor.
Acum vom analiza un subiect destul de interesant, numit reflectorul rutei.
Dar mai întâi să abordăm treptat.
Avem o mulțime de routere, iar BGP spune că ar trebui să existe o rețea completă.
Imaginați-vă că avem 20 de routere, Full Mesh, asta ar trebui să avem sesiuni TCP? Formula este simplă: n * (n-1) / 2, total: 190 sesiuni, nu câteva, nu-i așa?
Ca minus într-o astfel de rețea este faptul că există o mulțime de rute de trafic duplicat.
Toate acestea sunt rezolvate de două mecanisme:
- Reflector ruta
- Confederația (sub-AS)
Luați aminte, dar să începeți cu reflectorii.
Orizontul IBGP Split spune că, dacă obținem o rută IBGP, atunci nu mai trimitem acest traseu nimănui, dar de ce? avem Full Mesh. Așa că trebuie să schimbăm 🙂
Avem o grămadă de routere, avem nevoie pentru a alege un router, și să-l un server (oglindă), fiecare router va avea doar un singur link către server, astfel de routere sunt numite clienti. Un astfel de server (reflector) și clienții sunt numiți în mod colectiv clustere.
Acum, obținerea rutei Route Reflector își trimite clienții pe acest traseu, clientul primește și nu trimite nimănui, deoarece nu are legături cu nimeni altcineva.
Astfel, numărul de setări și sesiunile TCP între colegi sunt mult reduse.
În AS poate exista 1 RR (reflector rute), poate câteva, sau poate doar ierarhic, să ne uităm la regulile fiecăruia:
Dacă traseul a fost primit de la clientul dvs., acest traseu va fi redirecționat nu către clienți și clienții lor.
Dacă RR a primit un traseu de la un non-client (de la sărbătoarea IBGP), atunci acest traseu va fi trimis numai clienților săi.
Dacă RR a primit o rută de la vecinul EBGP, atunci acesta trimite acest traseu tuturor non-clienților și tuturor clienților.
Toate RR trebuie să fie configurate cu un singur nume Cluster_ID
Toate RR cu același Cluseter_ID trebuie să fie Full MEsh
Clientul RR trebuie să fie o rețea completă cu toate RR-urile acestui Cluster_ID
Toate routerele trebuie să fie configurate cu același CLUSTER_ID
Clienții RR ar trebui să fie complet cu RR
RR nu ar trebui să fie o rețea completă între ele în cazul ierarhiei, iar ierarhia nu are limite în profunzime.
Teoretic, folosind RR, puteți obține bucle, BGP oferă două mecanisme de protecție pentru buclă, este origitator_id și cluster_list.
De exemplu, avem un număr de zone geografice, în scopul de a urmări bucla este necesar atribut, care va fi marcat de orice grup într-un traseu (similar cu AS-PATH), este monitorizată prin intermediul cluster-lista, RR arată și ischit acolo de CLUSTER_ID, dacă el el găsește, atunci ruta nu este trimisă nimănui, este pur și simplu aruncată.
ORIGINATOR_ID nu este atributul tranzitiv, acest atribut este un router ROUTER_ID care a creat acest traseu, dacă actualizarea a venit de la cineva și router vede originator_id același vvide le, atunci această cale este eliminată.
Asta este, cluster_list este protecția de la buclele între clustere, iar origitor_id este în interiorul clusterului. Semnificația lucrării este aceeași.
Probleme potențiale care pot apărea atunci când utilizați RR:
Dacă clientul nu este conectat la toate RR din cluster, atunci toate rutele IBGP nu vor fi primite.
Dacă clientul este conectat la mai multe RR-uri ale diferitelor clustere, atunci vor sosi duplicate.
Dacă clientul Cluster este conectat la alți clienți, vor apărea și duplicate.
Dacă configurați corect RR și planificați corect astfel de probleme, nu ar trebui să existe.
Articole similare
Trimiteți-le prietenilor: