Hodiaŭ ni rigardos la BGP-protokolon. Ni ne parolos longe pri kial ĝi estas kaj kial ĝi estas uzata kiel la sola protokolo. Estas sufiĉe multe da informoj pri ĉi tiu temo, ekzemple .
Do kio estas BGP? BGP estas dinamika vojiga protokolo kaj estas la nura EGP (External Gateway Protocol) protokolo. Ĉi tiu protokolo estas uzata por konstrui vojigon en la Interreto. Ni rigardu kiel najbareco estas konstruita inter du BGP-enkursigiloj.
Konsideru la najbarecon inter Router1 kaj Router3. Ni agordu ilin per la sekvaj komandoj:
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 10Najbareco ene de ununura aŭtonoma sistemo estas AS 10. Post enirado de informoj pri enkursigilo, kiel ekzemple Router1, tiu enkursigilo provas starigi apudecrilaton kun Router3. La komenca stato kiam nenio okazas estas nomita Iru lin. Tuj kiam bgp estas agordita sur Router1, ĝi komencos aŭskulti TCP-havenon 179 - ĝi iros en la staton. konekti, kaj kiam ĝi provas malfermi sesion kun Router3, ĝi iros en la ŝtaton aktiva.
Post kiam la sesio estas establita inter Router1 kaj Router3, Malfermaj mesaĝoj estas interŝanĝitaj. Kiam ĉi tiu mesaĝo estas sendita de Router1, ĉi tiu stato estos vokita Malfermu Sendita. Kaj kiam ĝi ricevas Malferman mesaĝon de Router3, ĝi iros en la ŝtaton Malfermu Konfirmu. Ni rigardu pli detale la Malferman mesaĝon:
Ĉi tiu mesaĝo peras informojn pri la BGP-protokolo mem, kiun la enkursigilo uzas. Interŝanĝante Malfermajn mesaĝojn, Router1 kaj Router3 komunikas informojn pri siaj agordoj unu al la alia. La sekvaj parametroj estas pasigitaj:
- versio: ĉi tio inkluzivas la BGP-version, kiun la enkursigilo uzas. La nuna versio de BGP estas versio 4 kiu estas priskribita en RFC 4271. Du BGP-enkursigiloj provos negoci kongruan version, kiam estas miskongruo, tiam ne estos BGP-sesio.
- Mia AS: ĉi tio inkluzivas la AS-numeron de la BGP-enkursigilo, la enkursigiloj devos konsenti pri la AS-numero(j) kaj ĝi ankaŭ difinas ĉu ili funkcios iBGP aŭ eBGP.
- Tenu Tempo: se BGP ne ricevas iujn ajn daŭrajn aŭ ĝisdatigajn mesaĝojn de la alia flanko dum la tempodaŭro, tiam ĝi deklaros la alian flankon 'malviva' kaj ĝi malkonstruos la BGP-sesion. Defaŭlte la tentempo estas agordita al 180 sekundoj ĉe Cisco IOS-enkursigiloj, la konserva mesaĝo estas sendita ĉiujn 60 sekundojn. Ambaŭ enkursigiloj devas konsenti pri la tentempo aŭ ne estos BGP-sesio.
- BGP-Identigilo: ĉi tiu estas la loka BGP-enkursigilo ID kiu estas elektita same kiel OSPF faras:
- Uzu la router-ID kiu estis agordita permane kun la bgp router-id komando.
- Uzu la plej altan IP-adreson sur loopback-interfaco.
- Uzu la plej altan IP-adreson sur fizika interfaco.
- Laŭvolaj Parametroj: ĉi tie vi trovos kelkajn laŭvolajn kapablojn de la BGP-enkursigilo. Ĉi tiu kampo estis aldonita por ke novaj funkcioj povus esti aldonitaj al BGP sen devi krei novan version. Aĵoj kiujn vi eble trovos ĉi tie estas:
- subteno por MP-BGP (Multi Protocol BGP).
- subteno por Route Refresh.
- subteno por 4-oktetaj AS-numeroj.
Por establi najbarecon, la sekvaj kondiĉoj devas esti plenumitaj:
- Versionumero. La nuna versio estas 4.
- La AS-numero devas kongrui kun tio, kion vi agordis najbaro 192.168.13.3 remote-as 10.
- Router ID devas esti malsama de la najbaro.
Se iu el la parametroj ne kontentigas ĉi tiujn kondiĉojn, la enkursigilo sendos sciigo mesaĝo indikante la eraron. Post sendado kaj ricevado de Malfermaj mesaĝoj, la najbara rilato eniras la ŝtaton ESTABLITA. Post ĉi tio, enkursigiloj povas interŝanĝi informojn pri itineroj kaj fari tion uzante Ĝisdatigu mesaĝojn. Jen la Ĝisdatigo-mesaĝo sendita de Router1 al Router3:
Ĉi tie vi povas vidi la retojn raportitajn de Router1 kaj Path-atributoj, kiuj estas analogaj al metrikoj. Ni parolos pri Path-atributoj pli detale. Keepalive mesaĝoj ankaŭ estas senditaj ene de TCP-sesio. Ili estas transdonitaj, defaŭlte, ĉiujn 60 sekundojn. Ĉi tio estas Keepalive Timer. Se Keepalive-mesaĝo ne estas ricevita dum la Hold Timer, tio signifos perdon de komunikado kun la najbaro. Defaŭlte, ĝi estas egala al 180 sekundoj.
Utila signo:
Ŝajnas, ke ni eltrovis kiel enkursigiloj transdonas informojn unu al la alia, nun ni provu kompreni la logikon de la BGP-protokolo.
Por reklami itineron al la BGP-tabelo, kiel en la IGP-protokoloj, la reta komando estas uzata, sed la operacia logiko estas malsama. Se en IGP, post specifi la itineron en la reta komando, la IGP rigardas kiuj interfacoj apartenas al ĉi tiu subreto kaj inkluzivas ilin en sia tabelo, tiam la reta komando en BGP rigardas la enrutigan tabelon kaj serĉas preciza kongruas kun la itinero en la reta komando. Se tiaj estas trovitaj, ĉi tiuj itineroj aperos en la BGP-tabelo.
Serĉu itineron en la nuna IP-vojigtabelo de la enkursigilo, kiu precize kongruas kun la parametroj de la reta komando; se la IP-itinero ekzistas, metu la ekvivalentan NLRI en la lokan BGP-tabelon.
Nun ni altigu BGP al ĉiuj ceteraj kaj vidu kiel la itinero estas elektita ene de unu AS. Post kiam la BGP-enkursigilo ricevas itinerojn de sia najbaro, ĝi komencas elekti la optimuman itineron. Ĉi tie vi devas kompreni, kiaj najbaroj povas esti - internaj kaj eksteraj. Ĉu la enkursigilo komprenas per agordo ĉu la agordita najbaro estas interna aŭ ekstera? Se en teamo:
neighbor 192.168.13.3 remote-as 10 la parametro remote-as precizigas AS, kiu estas agordita sur la enkursigilo mem en la router bgp 10-komando.Itineroj venantaj de la interna AS estas konsideritaj internaj, kaj itineroj de la ekstera AS estas konsideritaj eksteraj. Kaj por ĉiu funkcias malsama logiko de ricevado kaj sendo. Konsideru ĉi tiun topologion:
Ĉiu enkursigilo havas loopback-interfacon agordita kun ip: xxxx 255.255.255.0 - kie x estas la numero de enkursigilo. Sur Router9 ni havas loopback-interfacon kun la adreso - 9.9.9.9 255.255.255.0. Ni anoncos ĝin per BGP kaj vidos kiel ĝi disvastiĝas. Ĉi tiu itinero estos transdonita al Router8 kaj Router12. De Router8, ĉi tiu itinero iros al Router6, sed al Router5 ĝi ne estos en la vojtabelo. Ankaŭ ĉe Router12 ĉi tiu itinero aperos en la tabelo, sed ĉe Router11 ĝi ankaŭ ne estos tie. Ni provu eltrovi ĉi tion. Ni konsideru kiajn datumojn kaj parametrojn Router9 transdonas al siaj najbaroj, raportante ĉi tiun itineron. La suba pako estos sendita de Router9 al Router8.
Itinerinformoj konsistas el Padaj atributoj.
Padaj atributoj estas dividitaj en 4 kategoriojn:
- Konata deviga - Ĉiuj enkursigiloj kurantaj BGP devas rekoni ĉi tiujn atributojn. Devas ĉeesti en ĉiuj ĝisdatigoj.
- Konata diskreta - Ĉiuj enkursigiloj kurantaj BGP devas rekoni ĉi tiujn atributojn. Ili povas ĉeesti en ĝisdatigoj, sed ilia ĉeesto ne estas postulata.
- Laŭvola transitiva - eble ne estas rekonita de ĉiuj BGP-efektivigoj. Se la enkursigilo ne rekonas la atributon, ĝi markas la ĝisdatigon kiel parta kaj plusendas ĝin al siaj najbaroj, stokante la nerekonitan atributon.
- Laŭvola ne-transitiva - eble ne estas rekonita de ĉiuj BGP-efektivigoj. Se la enkursigilo ne rekonas la atributon, tiam la atributo estas ignorita kaj forĵetita kiam transdonita al najbaroj.
Ekzemploj de BGP-atributoj:
- Konata deviga:
- Aŭtonoma sistemo vojo
- Sekva-salteto
- Origino
- Konata diskreta:
- Loka prefero
- Atoma agregaĵo
- Laŭvola transitiva:
- Agregator
- komunumoj
- Laŭvola ne-transitiva:
- Plur-elira diskriminanto (MED)
- Originanto ID
- Listo de aretoj
En ĉi tiu kazo, nuntempe ni interesiĝos pri Origino, Next-hop, AS Path. Ĉar la itinero transdonas inter Router8 kaj Router9, tio estas, ene de unu AS, ĝi estas konsiderata interna kaj ni atentos Originon.
Origina atributo - indikas kiel la itinero en la ĝisdatigo estis akirita. Eblaj atributaj valoroj:
- 0 - IGP: NLRI ricevita ene de la originala aŭtonoma sistemo;
- 1 - EGP: NLRI estas lernita uzante la Eksteran Enirejan Protokolon (EGP). Antaŭulo al BGP, ne uzata
- 2 - Nekompleta: NLRI estis lernita alimaniere
En nia kazo, kiel videblas el la pako, ĝi estas egala al 0. Kiam ĉi tiu itinero estas transdonita al Router12, ĉi tiu kodo havos kodon 1.
Poste, Sekva-salteto. Next-hop-atributo
- Ĉi tiu estas la IP-adreso de la eBGP-enkursigilo tra kiu iras la vojo al la celreto.
- La atributo ŝanĝiĝas kiam la prefikso estas sendita al alia AS.
En la kazo de iBGP, tio estas, ene de unu AS, Next-hop estos indikita de tiu, kiu lernis aŭ rakontis pri ĉi tiu itinero. En nia kazo, ĝi estos 192.168.89.9. Sed kiam ĉi tiu itinero estas transdonita de Router8 al Router6, Router8 ŝanĝos ĝin kaj anstataŭigos ĝin per sia propra. La sekva salto estos 192.168.68.8. Ĉi tio kondukas nin al du reguloj:
- Se enkursigilo plusendas itineron al sia interna najbaro, ĝi ne ŝanĝas la Next-hop-parametron.
- Se enkursigilo elsendas itineron al sia ekstera najbaro, ĝi ŝanĝas Next-hop al la ip de la interfaco de kiu ĉi tiu enkursigilo transdonas.
Ĉi tio kondukas nin kompreni la unuan problemon - Kial ne estos itinero en la vojtabelo sur Router5 kaj Router11. Ni rigardu pli detale. Do, Router6 ricevis informojn pri itinero 9.9.9.0/24 kaj sukcese aldonis ĝin al la vojtabelo:
Router6#show ip route bgp
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override, p - overrides from PfR
Gateway of last resort is not set
9.0.0.0/24 is subnetted, 1 subnets
B 9.9.9.0 [20/0] via 192.168.68.8, 00:38:25<source>
Теперь Router6 передал маршрут Router5 и первому правилу Next-hop не изменил. То есть, Router5 должен добавить <b>9.9.9.0 [20/0] via 192.168.68.8</b> , но у него нет маршрута до 192.168.68.8 и поэтому данный маршрут добавлен не будет, хотя информация о данном маршруте будет храниться в таблице BGP:
<source><b>Router5#show ip bgp
BGP table version is 1, 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.68.8 0 100 0 45 i</b>La sama situacio okazos inter Router11-Router12. Por eviti ĉi tiun situacion, vi devas agordi Router6 aŭ Router12, kiam vi pasas la itineron al iliaj internaj najbaroj, por anstataŭigi ilian IP-adreson kiel Next-hop. Ĉi tio estas farita per la komando:
neighbor 192.168.56.5 next-hop-selfPost ĉi tiu komando, Router6 sendos Ĝisdatigitan mesaĝon, kie la ip de interfaco Gi0/0 Router6 estos specifita kiel Next-hop por itineroj - 192.168.56.6, post kio ĉi tiu itinero jam estos inkluzivita en la vojtabelo.
Ni iru plu kaj vidu ĉu ĉi tiu itinero aperas sur Router7 kaj Router10. Ĝi ne estos en la vojtabelo kaj ni povus pensi, ke la problemo estas la sama kiel en la unua kun la parametro Next-hop, sed se ni rigardas la eligon de la komando show ip bgp, ni vidos, ke la itinero ne estis ricevita tie eĉ kun la malĝusta Next-hop, kio signifas, ke la itinero eĉ ne estis transdonita. Kaj ĉi tio kondukos nin al la ekzisto de alia regulo:
Itineroj ricevitaj de internaj najbaroj ne estas disvastigitaj al aliaj internaj najbaroj.
Ĉar Router5 ricevis la itineron de Router6, ĝi ne estos elsendita al sia alia interna najbaro. Por ke la translokigo okazu, vi devas agordi la funkcion , aŭ agordi plene konektitajn najbarajn rilatojn (Plena Reto), tio estas, Router5-7 ĉiuj estos najbaro de ĉiuj. En ĉi tiu kazo ni uzos Route Reflector. Sur Router5 vi devas uzi ĉi tiun komandon:
neighbor 192.168.57.7 route-reflector-clientRoute-Reflector ŝanĝas la konduton de BGP kiam oni pasas itineron al interna najbaro. Se la interna najbaro estas specifita kiel itinero-reflector-kliento, tiam internaj itineroj estos reklamitaj al ĉi tiuj klientoj.
La itinero ne aperis sur Router7? Ankaŭ pri Next-hop ne forgesu. Post ĉi tiuj manipuladoj, la itinero ankaŭ devus iri al Router7, sed ĉi tio ne okazas. Ĉi tio kondukas nin al alia regulo:
La sekva salta regulo funkcias nur por Eksteraj itineroj. Por internaj itineroj, la next-hop-atributo ne estas anstataŭigita.
Kaj ni ricevas situacion en kiu necesas krei medion uzante statikan vojigon aŭ IGP-protokolojn por informi enkursigilojn pri ĉiuj itineroj ene de la AS. Ni enregistru senmovajn itinerojn sur Router6 kaj Router7 kaj post tio ni ricevos la deziratan itineron en la enkursigilo-tabelo. En AS 678, ni faros ĝin iomete alimaniere - ni registros senmovajn itinerojn por 192.168.112.0/24 sur Router10 kaj 192.168.110.0/24 sur Router12. Poste, ni establos la najbaran rilaton inter Router10 kaj Router12. Ni ankaŭ agordos Router12 por sendi sian sekvan salton al Router10:
neighbor 192.168.110.10 next-hop-selfLa rezulto estos, ke Router10 ricevos itineron 9.9.9.0/24, ĝi estos ricevita de ambaŭ Router7 kaj Router12. Ni vidu kian elekton faras Router10:
Router10#show ip bgp
BGP table version is 3, local router ID is 6.6.6.6
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.112.12 0 100 0 45 i
192.168.107.7 0 123 45 i
Kiel ni povas vidi, du itineroj kaj sago (>) signifas, ke la itinero per 192.168.112.12 estas elektita.
Ni vidu kiel funkcias la procezo de elekto de itinero:
- La unua paŝo kiam vi ricevas itineron estas kontroli la haveblecon de ĝia Sekva-hop. Tial, kiam ni ricevis itineron sur Router5 sen agordi Next-hop-self, ĉi tiu itinero ne estis plu prilaborita.
- Poste venas la parametro Pezo. Ĉi tiu parametro ne estas Path Atribute (PA) kaj ne estas sendita en BGP-mesaĝoj. Ĝi estas agordita loke sur ĉiu enkursigilo kaj estas nur uzata por manipuli itinerelekton sur la enkursigilo mem. Ni rigardu ekzemplon. Ĝuste super vi povas vidi, ke Router10 elektis itineron por 9.9.9.0/24 per Router12 (192.168.112.12). Por ŝanĝi la parametron Wieght, vi povas uzi itinero-mapon por agordi specifajn itinerojn, aŭ atribui pezon al ĝia najbaro per la komando:
neighbor 192.168.107.7 weight 200Nun ĉiuj itineroj de ĉi tiu najbaro havos ĉi tiun pezon. Ni vidu kiel la elekto de itinero ŝanĝiĝas post ĉi tiu manipulado:
Router10#show bgp *Mar 2 11:58:13.956: %SYS-5-CONFIG_I: Configured from console by console BGP table version is 2, local router ID is 6.6.6.6 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 *> 9.9.9.0/24 192.168.107.7 200 123 45 i * i 192.168.112.12 0 100 0 45 iKiel vi povas vidi, la itinero tra Router7 nun estas elektita, sed ĉi tio ne efikos al la aliaj enkursigiloj.
- En tria pozicio ni havas Lokan Preferon. Ĉi tiu parametro estas Konata libervola atributo, kio signifas, ke ĝia ĉeesto estas laŭvola. Ĉi tiu parametro validas nur ene de unu AS kaj influas la elekton de vojo nur por internaj najbaroj. Tial ĝi estas transdonita nur en Ĝisdatigaj mesaĝoj destinitaj al la interna najbaro. Ĝi ne ĉeestas en Ĝisdatigaj mesaĝoj por eksteraj najbaroj. Tial, ĝi estis klasifikita kiel Konata libervola. Ni provu apliki ĝin sur Router5. Sur Router5 ni devus havi du itinerojn por 9.9.9.0/24 - unu tra Router6 kaj la dua tra Router7.
Ni rigardas:
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 iSed kiel ni vidas unu itineron tra Router6. Kie estas la itinero tra Router7? Eble ankaŭ Router7 ne havas ĝin? Ni rigardu:
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 iStrange, ĉio ŝajnas esti bona. Kial ĝi ne estas transdonita al Router5? La afero estas, ke BGP havas regulon:
La enkursigilo elsendas nur tiujn itinerojn, kiujn ĝi uzas.
Router7 uzas itineron tra Router5, do la itinero tra Router10 ne estos elsendita. Ni revenu al Loka Prefero. Ni agordu Lokan Preferon sur Router7 kaj vidu kiel Router5 reagas al ĉi tio:
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>Do, ni kreis itinero-mapon kiu enhavas ĉiujn itinerojn kaj diris al Router7 ŝanĝi la Lokan Preferan parametron al 250 kiam ricevite, la defaŭlta estas 100. Ni vidu kio okazis sur 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 iKiel ni povas vidi nun Router5 preferas la itineron tra Router7. La sama bildo estos sur Router6, kvankam estas pli profite por li elekti itineron tra Router8. Ni ankaŭ aldonas, ke ŝanĝi ĉi tiun parametron postulas rekomencon de la najbareco por ke la ŝanĝo efektiviĝu. Legu . Ni ordigis Lokan Preferon. Ni transiru al la sekva parametro.
- Preferu la itineron kun la Next-hop-parametro 0.0.0.0, tio estas lokaj aŭ agregitaj itineroj. Ĉi tiuj itineroj estas aŭtomate asignitaj Pezo-parametron egalan al la maksimumo—32678—post enigo de la reta komando:
Router#show bgp BGP table version is 2, local router ID is 9.9.9.9 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 *> 9.9.9.0/24 0.0.0.0 0 32768 i - Plej mallonga vojo tra AS. La plej mallonga AS_Path-parametro estas elektita. Ju malpli da AS vojo trairas, des pli bona ĝi estas. Konsideru la itineron al 9.9.9.0/24 sur Router10:
Router10#show bgp BGP table version is 2, local router ID is 6.6.6.6 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 * 9.9.9.0/24 192.168.107.7 0 123 45 i *>i 192.168.112.12 0 100 0 45 iKiel vi povas vidi, Router10 elektis la itineron per 192.168.112.12 ĉar por ĉi tiu itinero la parametro AS_Path enhavas nur 45, kaj en alia kazo 123 kaj 45. Intuicie klara.
- La sekva parametro estas Origino. IGP (itinero akirita per BGP) estas pli bona ol EGP (itinero akirita per la antaŭulo de BGP, ne plu uzata), kaj EGP estas pli bona ol Nekompleta? (akirita per iu alia metodo, ekzemple per redistribuo).
- La sekva parametro estas MED. Ni havis Wieght, kiu nur funkciis loke sur la enkursigilo. Estis Loka Prefero, kiu nur funkciis ene de unu aŭtonoma sistemo. Kiel vi povas supozi, MED estas parametro, kiu estos transdonita inter aŭtonomaj sistemoj. Tre bona pri ĉi tiu parametro.
Ne pliaj atributoj estos uzataj, sed se du itineroj havas la samajn atributojn, tiam la sekvaj reguloj estas uzataj:
- Elektu la vojon tra la plej proksima IGP-najbaro.
- Elektu la plej malnovan itineron por la eBGP-vojo.
- Elektu la vojon tra la najbaro kun la plej malgranda BGP-enkursigilo ID.
- Elektu vojon tra la najbaro kun la plej malalta IP-adreso.
Nun ni rigardu la aferon de BGP-konverĝo.
Ni vidu kio okazas se Router6 perdas la itineron 9.9.9.0/24 tra Router9. Ni malŝaltu la interfacon Gi0/1 de Router6, kiu tuj komprenos, ke la BGP-sesio kun Router8 finiĝis kaj la najbaro malaperis, kio signifas, ke la itinero ricevita de ĝi ne validas. Router6 tuj sendas Ĝisdatigitajn mesaĝojn, kie ĝi indikas la reton 9.9.9.0/24 en la kampo Fortirita Itineroj. Tuj kiam Router5 ricevos tian mesaĝon, ĝi sendos ĝin al Router7. Sed ĉar Router7 havas itineron tra Router10, ĝi tuj respondos per Ĝisdatigo kun nova itinero. Se ne eblas detekti la falon de najbaro surbaze de la stato de la interfaco, tiam vi devos atendi ke la Hold Timer ekbrulos.
Konfederacio.
Se vi memoras, ni parolis pri tio, ke vi ofte devas uzi plene ligitan topologion. Kun granda nombro da enkursigiloj en unu AS tio povas kaŭzi grandajn problemojn, por eviti tion vi devas uzi konfederaciojn. Unu AS estas dividita en plurajn sub-AS, kio permesas al ili funkcii sen la postulo de plene ligita topologio.
Jen ligo al ĉi tio kaj agordo por GNS3.
Ekzemple, kun ĉi tiu topologio ni devus ligi ĉiujn enkursigilojn en AS 2345 unu al la alia, sed uzante Konfederacion, ni povas establi apudecrilatojn nur inter enkursigiloj rekte ligitaj unu al la alia. Ni parolu pri ĉi tio detale. Se ni nur havus AS 2345, do laForge ricevinte marŝon de Picard dirus ĝin al la enkursigiloj datumoj и Worf, sed ili ne dirus al la enkursigilo pri ĝi Disbatilo . Ankaŭ itineroj distribuitaj de la enkursigilo mem laForge, ne estus translokigita Disbatilo nek Worf-Ho ne datumoj.
Vi devus agordi Itineron-Reflektilon aŭ plene ligitan najbaran rilaton. Dividante unu AS 2345 en 4 sub-AS (2,3,4,5) por ĉiu enkursigilo, ni finas kun malsama operacia logiko. Ĉio estas perfekte priskribita .
Fontoj:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volumo 2, Kvina Eldono, Narbik Kocharians, Terry Vinson.
- retpaĝaro
- retpaĝaro .
fonto: www.habr.com