Astăzi vom analiza protocolul BGP. Nu vom discuta prea mult despre de ce este folosit și de ce este singurul protocol. Există o mulțime de informații pe această temă, de exemplu, .
Deci, ce este BGP? BGP este un protocol de rutare dinamic, fiind singurul protocol EGP (External Gateway Protocol). Acest protocol este folosit pentru a construi rutarea în internet. Să vedem cum se stabilește vecinătatea între doi routeri BGP.
Să analizăm vecinătatea între Router1 și Router3. Să-i configurăm folosind comenzile următoare:
router bgp 10
network 192.168.12.0
network 192.168.13.0
neighbor 192.168.13.3 remote-as 10
router bgp 10
network 192.168.13.0
network 192.168.24.0
neighbor 192.168.13.1 remote-as 10Vecinătatea într-o singură sistem autonom — AS 10. După introducerea datelor pe router, de exemplu, pe Router1, acest router încearcă să configureze relațiile de vecinătate cu routerul Router3. Starea inițială, când nimic nu se întâmplă, se numește Idle. Odată ce BGP este configurat pe Router1, acesta va începe să asculte pe portul TCP 179 — va trece în starea Conectare, iar când încearcă să deschidă o sesiune cu Router3, va trece în starea Activ.
După ce sesiunea se va stabili între Router1 și Router3, va avea loc schimbul de mesaje Open. Când acest mesaj este trimis de Router1, starea se va numi Open Sent. Iar când va primi mesajul Open de la Router3, va trece în starea Open Confirm. Să analizăm mai în detaliu mesajul Open:
În acest mesaj este transmisă informația despre protocolul BGP utilizat de router. Schimbând mesaje Open, Router1 și Router3 își comunică informațiile despre configurațiile lor. Se transmit următorii parametri:
- Version: aceasta include versiunea BGP pe care o folosește routerul. Versiunea curentă a BGP este versiunea 4, care este descrisă în RFC 4271. Două routere BGP vor încerca să negocieze o versiune compatibilă; când există o nepotrivire, nu va exista o sesiune BGP.
- My AS: aceasta include numărul AS al routerului BGP, routerele vor trebui să convină asupra numărului AS și definește de asemenea dacă vor rula iBGP sau eBGP.
- Hold Time: dacă BGP nu primește niciun mesaj keepalive sau update din partea cealaltă pentru durata timpului de menținere, acesta va declara partea cealaltă 'moartă' și va închide sesiunea BGP. În mod implicit, timpul de menținere este setat la 180 de secunde pe routerele Cisco IOS, mesajul keepalive este trimis la fiecare 60 de secunde. Ambele routere trebuie să convină asupra timpului de menținere sau nu va exista o sesiune BGP.
- BGP Identifier: acesta este ID-ul local al routerului BGP care este ales la fel ca OSPF:
- Folosește router-ID-ul care a fost configurat manual cu comanda bgp router-id.
- Folosește cea mai mare adresă IP de pe o interfață de tip loopback.
- Folosește cea mai mare adresă IP de pe o interfață fizică.
- Optional Parameters: aici veți găsi câteva capacități opționale ale routerului BGP. Acest câmp a fost adăugat pentru ca noile funcții să poată fi integrate în BGP fără a fi necesară crearea unei noi versiuni. Ceea ce ați putea găsi aici sunt:
- suport pentru MP-BGP (Multi Protocol BGP).
- suport pentru Route Refresh.
- suport pentru numere AS pe 4 octeți.
Pentru a stabili vecinătatea, este necesar să îndepliniți următoarele condiții:
- Numărul versiunii. Versiunea actuală este 4.
- Numărul AS trebuie să corespundă celor pe care le-ați configurat. neighbor 192.168.13.3 remote-as 10.
- Router ID trebuie să fie diferit de cel al vecinului.
Dacă vreunul dintre parametrii nu îndeplinește aceste condiții, routerul va trimite Notification un mesaj, în care va indica eroarea. După ce s-au trimis și primit mesajele Open, relația de vecinătate trece în starea ESTABLISHED. După aceasta, routerele pot schimba informații despre rute și fac acest lucru prin intermediul Actualizare mesajelor. Iată un astfel de mesaj Update pe care Router1 îl trimite către Router3:
Aici sunt indicate rețelele despre care informează Router1 și atributele Path, care sunt echivalentul metricilor. Vom discuta despre atributele Path în detaliu. De asemenea, în cadrul sesiunii TCP se transmit mesaje Keepalive. Acestea sunt transmise, în mod normal, la fiecare 60 de secunde. Acesta este Keepalive Timer. Dacă în timpul Hold Timer-ului nu se primește un mesaj Keepalive, aceasta va însemna pierderea conexiunii cu vecinul. În mod normal, acesta este setat la 180 de secunde.
O tabelă utilă:
Se pare că am înțeles cum routerele comunică între ele informații, acum să încercăm să înțelegem logica de funcționare a protocolului BGP.
Pentru a anunța o rută în tabela BGP, la fel ca în protocoalele IGP, se folosește comanda network, dar logica de funcționare diferă. În IGP, după specificarea rutei cu comanda network, IGP verifică care interfețe aparțin acestui subnet și le include în tabela sa, în timp ce comanda network din BGP verifică tabela de rutare și caută o potrivire exactă cu ruta din comanda network. La găsirea acestora, rutele respective vor fi incluse în tabela BGP.
Caută o rută în tabela de rutare IP curentă a routerului care se potrivește exact parametrilor comenzii network; dacă ruta IP există, adaugă echivalentul NLRI în tabela locală BGP.
Acum vom ridica BGP pe toate celelalte și vom observa cum se face selecția rutei în cadrul unei singure AS. După ce routerul BGP primește rutele de la vecin, începe selecția rutei optime. Aici trebuie să înțelegem ce tip de vecini pot exista - interni și externi. Routerul, conform configurației, înțelege dacă vecinul configurat este intern sau extern. Dacă în comandă:
neighbor 192.168.13.3 remote-as 10 AS-ul specificat ca parametru remote-as este AS-ul care este configurat pe router în comanda router bgp 10. Rutele venite dintr-un AS intern sunt considerate interne, iar rutele dintr-un AS extern sunt, în mod corespunzător, externe. Logica de obținere și transmitere diferă pentru fiecare. Să analizăm această topologie:
Pe fiecare router este configurat un interfață loopback cu ip: x.x.x.x 255.255.255.0 - unde x reprezintă numărul routerului. Pe Router9 avem un interfață loopback cu adresa - 9.9.9.9 255.255.255.0. O vom anunța prin BGP și vom observa cum se propagă. Această rută va fi transmisă la Router8 și Router12. Din Router8, această rută va ajunge pe Router6, dar pe Router5 nu va apărea în tabela de rutare. De asemenea, pe Router12, această rută va apărea în tabel, dar pe Router11 nu va fi prezentă. Să încercăm să înțelegem asta. Să analizăm ce date și parametri transmite Router9 vecinilor săi, informându-i despre această rută. Pachetul de mai jos va fi trimis de la Router9 la Router8.
Informația despre rută constă din atributele de cale (Path attributes).
Atributele de cale sunt împărțite în 4 categorii:
- Well-known mandatory — toate routerele care funcționează pe protocolul BGP trebuie să recunoască aceste atribute. Trebuie să fie prezente în toate actualizările.
- Well-known discretionary — toate routerele care funcționează pe protocolul BGP trebuie să recunoască aceste atribute. Pot apărea în actualizări, dar nu este obligatoriu să fie prezente.
- Optional transitive — pot să nu fie recunoscute de toate implementările BGP. Dacă un router nu recunoaște atributul, îl marchează pe actualizare ca parțial și îl transmite mai departe vecinilor, păstrând atributul nerecunoscut.
- Optional non-transitive — pot să nu fie recunoscute de toate implementările BGP. Dacă un router nu recunoaște atributul, acesta este ignorat și, la transmiterea către vecini, este eliminat.
Exemple de atribute BGP:
- Well-known mandatory:
- Calea sistemului autonom
- Următorul hop
- Origin
- Well-known discretionary:
- Preferință locală
- Agregat atomic
- Optional transitive:
- Agregator
- Comunități
- Optional non-transitive:
- Discriminator multi-iexit (MED)
- ID-ul generatorului
- Lista clusterelor
În acest caz, ne vor interesa deocamdată Origin, Next-hop și AS Path. Deoarece ruta este transmisă între Router8 și Router9, adică în interiorul aceleași AS, aceasta este considerată internă și vom observa Origin.
Atributul Origin - indică modul în care a fost obținută ruta în actualizare. Valorile posibile ale atributului sunt:
- 0 - IGP: NLRI obținută în interiorul sistemului autonom inițial;
- 1 - EGP: NLRI învățată prin protocolul Exterior Gateway Protocol (EGP). Predecesorul BGP, care nu este folosit
- 2 - Incomplete: NLRI a fost învățată prin alt mod
În cazul nostru, după cum se poate observa din pachet, este 0. Când această rută va fi transmisă către Router12, codul va avea valoarea - 1.
În continuare, Next-hop. Atributul Next-hop
- Este adresa IP a routerului eBGP, prin care trece calea către rețeaua destinatie.
- Atributul se schimbă când prefixul este transmis într-o altă AS.
În cazul iBGP, adică în interiorul aceleași AS, Next-hop va fi acela care a aflat sau a comunicat despre această rută. În cazul nostru, va fi 192.168.89.9. Dar când va transmite această rută de la Router8 la Router6, Router8 o va modifica și o va înlocui cu a sa. Next-hop va fi - 192.168.68.8. Aceasta ne conduce către două reguli:
- Dacă un router transmite o rută unui vecin său intern, acesta nu schimbă parametru Next-hop.
- Dacă un router transmite o rută unui vecin extern, acesta schimbă Next-hop cu ip-ul interfeței prin care transmite acest router.
Aceasta ne duce la înțelegerea primei probleme - De ce nu va exista rută în tabela de rutare pe Router5 și Router11. Să analizăm mai în detaliu. Așadar, Router6 a primit informația despre ruta 9.9.9.0/24 și a adăugat-o cu succes în tabela de rutare:
Router6#show ip route bgp
Coduri: L - local, C - conectat, S - static, R - RIP, M - mobil, B - BGP
D - EIGRP, EX - EIGRP extern, O - OSPF, IA - OSPF inter zone
N1 - OSPF NSSA extern tip 1, N2 - OSPF NSSA extern tip 2
E1 - OSPF extern tip 1, E2 - OSPF extern tip 2
i - IS-IS, su - rezumat IS-IS, L1 - IS-IS nivel-1, L2 - IS-IS nivel-2
ia - IS-IS inter zonă, * - rută implicită candidată, U - rută statică per utilizator
o - ODR, P - rută statică descărcată periodic, H - NHRP, l - LISP
a - rută de aplicație
+ - rută replicată, % - suprascriere punct de acces, p - suprascriere din PfR
Gateway-ul de rezervă nu este setat
9.0.0.0/24 este subdivizat, 1 subrețea
B 9.9.9.0 [20/0] prin 192.168.68.8, 00:38:25<source>
Acum Router6 a transmis ruta Router5 și primul regulă Next-hop nu s-a schimbat. Asta înseamnă că Router5 trebuie să adauge <b>9.9.9.0 [20/0] prin 192.168.68.8</b> , dar el nu are o rută către 192.168.68.8 și, prin urmare, această rută nu va fi adăugată, deși informația despre această rută va fi păstrată în tabela BGP:
<source><b>Router5#show ip bgp
Versiunea tabelului BGP este 1, ID-ul routerului local este 5.5.5.5
Coduri de stare: s suprimat, d îmbătrânit, h istoric, * valid, > cel mai bun, i - intern,
r eșec RIB, S vechi, m multipath, b cale de rezervă, f RT-Filter,
x cel mai bun extern, a cale suplimentară, c RIB-comprimat,
Coduri de origine: i - IGP, e - EGP, ? - incomplet
Coduri de validare RPKI: V valid, I invalid, N Negăsit
Rețea Punct de acces Metric LocPrf Weight Path
* i 9.9.9.0/24 192.168.68.8 0 100 0 45 i</b>Aceeași situație se va întâmpla și între Router11-Router12. Pentru a evita o astfel de situație, trebuie să configurăm astfel încât Router6 sau Router12, atunci când transmit rute vecinilor lor interni, să introducă adresa lor IP ca Next-hop. Se face prin comanda:
neighbor 192.168.56.5 next-hop-selfDupă această comandă, Router6 va trimite un mesaj Update, unde pentru rutele Next-hop va fi specificată adresa IP a interfeței Gi0/0 Router6 - 192.168.56.6, după care această rută va fi inclusă în tabla de rutare.
Să continuăm și să vedem dacă această rută va apărea pe Router7 și Router10. În tabelul de rutare, nu va fi prezent și am putea crede că problema este similară cu cea anterioară legată de parametru Next-hop, dar dacă ne uităm la ieșirea comenzii show ip bgp, vom vedea că ruta nu a fost obținută nici măcar cu Next-hop incorect, ceea ce înseamnă că ruta nu a fost transmisă. Iar acest lucru ne va conduce la existența unei alte reguli:
Rutele obținute de la vecinii interni nu sunt transmise altor vecini interni.
Așa cum Router5 a obținut ruta de la Router6, aceasta nu va fi transmisă altui vecin intern. Pentru ca transferul să aibă loc, este necesară configurarea funcției , sau configurarea relațiilor de vecinătate complete (Full Mesh), adică Router5-7 fiecare va fi vecin cu fiecare. În acest caz, vom folosi Route Reflector. Pe Router5, trebuie să folosim această comandă:
neighbor 192.168.57.7 route-reflector-clientRoute Reflector schimbă comportamentul BGP la transmiterea rutei către un vecin intern. Dacă vecinul intern este specificat ca route-reflector-client, atunci aceste clienți vor avea anunțate rutele interne.
Ruta nu a apărut pe Router7? Să nu uităm și de Next-hop. După aceste manevre, ruta ar trebui să apară și pe Router7, dar acest lucru nu se întâmplă. Acest lucru ne conduce la o altă regulă:
Regula next-hop funcționează doar pentru rutele externe. Pentru rutele interne, înlocuirea atributului next-hop nu are loc.
Și obținem o situație în care este necesar să creăm un mediu folosind rutare statică sau protocoale IGP pentru a informa routerele despre toate rutele din AS. Vom scrie rute statice pe Router6 și Router7 și după aceea vom obține ruta necesară în tabelul routerului. În AS 678, vom proceda puțin diferit - vom scrie rute statice pentru 192.168.112.0/24 pe Router10 și pentru 192.168.110.0/24 pe Router12. Apoi, vom stabili relații de vecinătate între Router10 și Router12. De asemenea, pe Router12 vom configura trimiterea propriului next-hop pentru Router10:
neighbor 192.168.110.10 next-hop-selfRezultatul va fi că Router10 va obține ruta 9.9.9.0/24, care va fi obținută atât de la Router7, cât și de la Router12. Să vedem ce alegere va face Router10:
Router10#show ip bgp
Versi tabel BGP este 3, ID-ul router-ului local este 6.6.6.6
Coduri de stare: s suprimate, d amortizate, h istoric, * valid, > cel mai bun, i - intern,
r eșec RIB, S Stale, m multipath, b cale de rezervă, f RT-Filter,
x cel mai bun extern, a cale suplimentară, c RIB-comprimat,
Coduri de origini: i - IGP, e - EGP, ? - incomplet
Coduri de validare RPKI: V valid, I invalid, N Net găsit
Rețea Next Hop Metric LocPrf Weight Path
* > 9.9.9.0/24 192.168.112.12 0 100 0 45 i
192.168.107.7 0 123 45 i După cum vedem, există două rute și săgeata ( > ) semnifică că ruta prin 192.168.112.12 a fost aleasă.
Să vedem cum se desfășoară procesul de selecție a rutei:
- Primul lucru pe care îl verificăm la primirea unei rute este disponibilitatea Next-hop-ului acesteia. De aceea, când am primit ruta pe Router5 fără configurarea Next-hop-self, ruta respectivă nu a fost procesată mai departe.
- Apoi urmează parametrul Weight. Acest parametru nu este un atribut al rutei (PA) și nu este transmis în mesajele BGP. El se configurează local pe fiecare router și este folosit doar pentru manipularea selecției rutei pe acel router. Să luăm un exemplu. Așa cum s-a arătat mai sus, Router10 a ales ruta pentru 9.9.9.0/24 prin Router12 (192.168.112.12). Pentru a schimba parametrul Weight, se poate utiliza route-map pentru a defini un anumit Weight pentru anumite rute, sau îi putem atribui o greutate vecinului prin comanda:
neighbor 192.168.107.7 weight 200Acum toate rutele de la acest vecin vor avea această greutate. Să vedem cum se va schimba selecția rutei după această manipulare:
Router10#show bgp *Mar 2 11:58:13.956: %SYS-5-CONFIG_I: Configurat din consolă de către consolă Versiunea tabelului BGP este 2, ID-ul router-ului local este 6.6.6.6 Coduri de stare: s suprimate, d amortizate, h istoric, * valid, > cel mai bun, i - intern, r eșec RIB, S Stale, m multipath, b cale de rezervă, f RT-Filter, x cel mai bun extern, a cale suplimentară, c RIB-comprimat, Coduri de origini: i - IGP, e - EGP, ? - incomplet Coduri de validare RPKI: V valid, I invalid, N Net găsit Rețea Next Hop Metric LocPrf Weight Path * > 9.9.9.0/24 192.168.107.7 200 123 45 i * i 192.168.112.12 0 100 0 45 iDupă cum vedeți, acum a fost aleasă ruta prin Router7, dar acest lucru nu va avea niciun efect asupra celorlalte routere.
- Pe locul trei avem - Local Preference. Acest parametru este un atribut discreționar binecunoscut, ceea ce înseamnă că prezența sa nu este obligatorie. Acest parametru are forța doar în cadrul unei singure AS și influențează selecția căii doar pentru vecinii interni. De aceea, acesta este transmis doar în mesajele de Update destinate vecinilor interni. În mesajele de Update pentru vecinii externi, acesta lipsește. Acesta a fost clasificat ca un atribut discreționar binecunoscut. Să încercăm să-l aplicăm pe Router5. Pe Router5 ar trebui să avem două rute pentru 9.9.9.0/24 - una prin Router6 și cealaltă prin Router7.
Să vedem:
Router5#show bgp BGP table version is 2, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * >i 9.9.9.0/24 192.168.56.6 0 100 0 45 iDar, așa cum vedem, există o rută prin Router6. Unde este ruta prin Router7? Poate că nu există nici pe Router7? Să vedem:
Router#show bgp BGP table version is 10, local router ID is 7.7.7.7 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * >i 9.9.9.0/24 192.168.56.6 0 100 0 45 i 192.168.107.10 0 678 45 iCiudat, totul pare în ordine. De ce nu este transmis pe Router5? Totul se datorează faptului că BGP are o regulă:
Routerul transmite doar acele rute pe care le folosește el însuși.
Router7 folosește ruta prin Router5, de aceea ruta prin Router10 nu va fi transmisă. Revenim la Local Preference. Să stabilim Local Preference pe Router7 și să vedem cum va reacționa Router5:
route-map BGP permit 10 match ip address 10 set local-preference 250 access-list 10 permit any router bgp 123 neighbor 192.168.107.10 route-map BGP in</b>Așadar, am creat un route-map în care se regăsesc toate rutele și am spus Router7 să schimbe parametrul Local Preference la 250, care în mod implicit este 100. Să vedem ce s-a întâmplat pe Router5:
Router5#show bgp BGP table version is 8, local router ID is 5.5.5.5 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path * >i 9.9.9.0/24 192.168.57.7 0 250 0 678 45 iDupă cum vedem, Router5 preferă ruta prin Router7. Aceeași situație va fi și pe Router6, deși acesta ar avea avantajul de a alege ruta prin Router8. De asemenea, adăugăm că schimbarea acestui parametru necesită repornirea vecinătății pentru ca modificarea să aibă efect. Citește . Am înțeles Local Preference. Trecem la următorul parametru.
- Preferința rutei cu parametrul Next-hop 0.0.0.0, adică rute locale sau agregate. Acestor rute li se atribuie automat, după introducerea comenzii network, parametrul Weight egal cu maximul — 32678:
Router#show bgp Versiunea tabelului BGP este 2, ID-ul routerului local este 9.9.9.9 Coduri de stare: s supresat, d amortizat, h istoric, * valid, > cel mai bun, i - intern, r eșec RIB, S Stale, m multipath, b backup-path, f RT-Filter, x cel mai bun extern, a cale suplimentară, c RIB-comprimat, Coduri de origine: i - IGP, e - EGP, ? - incomplet Coduri de validare RPKI: V valid, I invalid, N Nepregătit Rețea Next Hop Metric LocPrf Weight Path * > 9.9.9.0/24 0.0.0.0 0 32768 i - Calea cea mai scurtă prin AS. Se alege cel mai scurt parametru AS_Path. Cu cât ruta trece printr-un număr mai mic de AS, cu atât este mai bună. Să examinăm ruta către 9.9.9.0/24 pe Router10:
Router10#show bgp Versiunea tabelului BGP este 2, ID-ul routerului local este 6.6.6.6 Coduri de stare: s supresat, d amortizat, h istoric, * valid, > cel mai bun, i - intern, r eșec RIB, S Stale, m multipath, b backup-path, f RT-Filter, x cel mai bun extern, a cale suplimentară, c RIB-comprimat, Coduri de origine: i - IGP, e - EGP, ? - incomplet Coduri de validare RPKI: V valid, I invalid, N Nepregătit Rețea Next Hop Metric LocPrf Weight Path * 9.9.9.0/24 192.168.107.7 0 123 45 i * >i 192.168.112.12 0 100 0 45 iDupă cum vedeți, Router10 a ales ruta prin 192.168.112.12 pentru că, în acest caz, parametrul AS_Path conține doar 45, iar în celălalt caz 123 și 45. Este intuitiv.
- Următorul parametru este Origin. IGP (ruta obținută prin BGP) este mai bună decât EGP (ruta obținută prin predecesorul BGP, care nu mai este utilizat), iar EGP este mai bun decât Incomplete? (obținută printr-o altă metodă, de exemplu redistribuție).
- Următorul parametru este MED. Am avut Weight, care funcționa doar local pe router. A fost Local Preference, care acționa doar în cadrul unei singure sisteme autonome. După cum ne putem da seama, MED este parametrul care va fi transmis între sistemele autonome. Foarte bun despre acest parametru.
Nu vor mai fi folosite alteatribute, dar dacă două rute au aceleași, se aplică următoarele reguli:
- Selectați calea prin cel mai apropiat vecin IGP.
- Alegeți cea mai veche rută pentru calea eBGP.
- Alegeți ruta prin vecinul cu cel mai mic BGP router ID.
- Alegeți ruta prin vecinul cu cel mai mic IP.
Acum să discutăm despre problema convergenței BGP.
Să vedem ce se întâmplă dacă Router6 pierde ruta 9.9.9.0/24 prin Router9. Vom dezactiva interfața Gi0/1 a Router6, care va înțelege imediat că sesiunea BGP cu Router8 a fost întreruptă și vecinul a dispărut, astfel încât și ruta obținută de la el nu mai este valabilă. Router6 va trimite imediat un mesaj Update, indicând rețeaua 9.9.9.0/24 în câmpul Withdrawn Routes. Odată ce Router5 va primi un astfel de mesaj, îl va trimite la Router7. Dar, deoarece Router7 are o rută prin Router10, va trimite imediat un Update cu noua rută. Dacă nu se poate detecta căderea vecinului din starea interfeței, va trebui să așteptăm activarea Hold Timer-ului.
Confederație.
Dacă vă amintiți, am vorbit despre faptul că este adesea necesar să se utilizeze o topologie complet conectată. Având un număr mare de routere într-un singur AS, acest lucru poate cauza mari probleme, iar pentru a evita acest lucru, este necesar să se folosească confederații. Un AS este împărțit în mai multe sub-AS, ceea ce le permite să funcționeze fără a necesita o topologie complet conectată.
Aici este un link către această , iar configurație pentru GNS3.
De exemplu, într-o astfel de topologie, am fi fost nevoiți să conectăm toate routerele din AS 2345 între ele, dar folosind Confederation, putem stabili relații de vecinătate doar între routerele direct conectate între ele. Să discutăm despre asta în detaliu. Dacă am fi avut doar AS 2345, atunci laForge obținând ruta de la Picard le-ar povesti routerelor sale Data și Worf, dar ele nu i-ar povesti routerului Crusher . De asemenea, rutele pe care le propagă routerul laForge, nu ar fi fost transmise Crusher nici Worf-ului, nici Data.
Ar fi fost necesar să configurăm Route-Reflector sau relații de vecinătate complet conectate. Împărțind un AS 2345 în 4 sub-AS (2, 3, 4, 5) pentru fiecare router, obținem în cele din urmă o altă logică de funcționare. Toate sunt bine descrise în .
Surse:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- Site
- Site .
Sursa: habr.com
