I dag skal vi se pÄ BGP-protokollen. Vi skal ikke gÄ inn pÄ hvorfor den brukes som den eneste protokollen. Det finnes ganske mye informasjon om dette, for eksempel .
SÄ, hva er BGP? BGP er en protokoll for dynamisk ruting, og den er den eneste EGP (External Gateway Protocol) protokollen. Denne protokollen brukes til Ä bygge ruting pÄ internett. La oss se pÄ hvordan nabolaget mellom to BGP-rutere bygges.
Vi ser pÄ naboer mellom Router1 og Router3. La oss konfigurere dem med fÞlgende kommandoer:
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 10Nabolag innenfor samme autonome system â AS 10. Etter Ă„ ha angitt dataene pĂ„ ruteren, for eksempel pĂ„ Router1, vil denne ruteren prĂžve Ă„ opprette naboforhold med ruteren Router3. Den fĂžrste tilstanden, nĂ„r ingenting skjer, kalles Idle. NĂ„r BGP er konfigurert pĂ„ Router1, begynner den Ă„ lytte pĂ„ TCP-port 179 â den gĂ„r inn i tilstanden Connect, og nĂ„r den prĂžver Ă„ Ă„pne en sesjon med Router3, gĂ„r den inn i tilstanden Aktiv.
NÄr sesjonen er opprettet mellom Router1 og Router3, skjer det en utveksling av Open-meldinger. NÄr denne meldingen sendes fra Router1, vil denne tilstanden bli kalt Open Sent. NÄr den mottar Open-meldingen fra Router3, vil den gÄ inn i tilstanden Open Confirm. La oss se nÊrmere pÄ Open-meldingen:
Denne meldingen inneholder informasjon om BGP-protokollen som ruteren benytter. Ved utveksling av Open-meldinger informerer Router1 og Router3 hverandre om sine innstillinger. FĂžlgende parametere overfĂžres:
- Version: dette inkluderer BGP-versjonen som ruteren bruker. Den nÄvÊrende versjonen av BGP er versjon 4, som er beskrevet i RFC 4271. To BGP-rutere vil prÞve Ä forhandle en kompatibel versjon; dersom det er en mismatch, vil det ikke bli noen BGP-sesjon.
- My AS: dette inkluderer AS-nummeret til BGP-ruteren, rutere mÄ bli enige om AS-nummeret(e), og det definerer ogsÄ om de skal kjÞre iBGP eller eBGP.
- Hold Time: hvis BGP ikke mottar noen keepalive- eller oppdateringsmeldinger fra den andre siden i lÞpet av holdetiden, vil det erklÊre den andre siden som 'dÞd', og det vil avslutte BGP-sesjonen. Som standard er holdetiden satt til 180 sekunder pÄ Cisco IOS-rutere, keepalive-meldingen sendes hvert 60. sekund. Begge rutere mÄ bli enige om holdetiden, ellers vil det ikke bli noen BGP-sesjon.
- BGP Identifier: dette er den lokale BGP-ruter-ID som velges pÄ samme mÄte som OSPF gjÞr:
- Bruk router-ID som ble konfigurert manuelt med bgp router-id-kommandoen.
- Bruk den hÞyeste IP-adressen pÄ en loopback-grensesnitt.
- Bruk den hÞyeste IP-adressen pÄ et fysisk grensesnitt.
- Valgfrie parametere: her vil du finne noen valgfrie funksjoner av BGP-ruteren. Dette feltet har blitt lagt til slik at nye funksjoner kan legges til i BGP uten Ä mÄtte lage en ny versjon. Ting du kan finne her er:
- stĂžtte for MP-BGP (Multi Protocol BGP).
- stĂžtte for Route Refresh.
- stĂžtte for 4-octet AS-numre.
For Ä etablere naboer mÄ fÞlgende betingelser oppfylles:
- Versjonsnummer. NĂ„vĂŠrende versjon 4.
- AS-nummeret mÄ samsvare med det du har konfigurert neighbor 192.168.13.3 remote-as 10.
- Router-ID mÄ vÊre forskjellig fra naboens.
Hvis noen av parameterne ikke tilfredsstiller disse betingelsene, vil ruteren sende Varsling en melding som angir feilen. Etter sending og mottak av Open-meldinger, gÄr naboforholdet over i en tilstand ESTABLISHED. Etter dette kan rutere begynne Ä utveksle ruteinformasjon, og gjÞr det ved hjelp av Update meldinger. Slik ser en Update-melding ut som Router1 sender til Router3:
Her angis nettene som Router1 rapporterer om og Path attributes, som tilsvarer metrikker. Vi vil gĂ„ nĂŠrmere inn pĂ„ Path attributes. OgsĂ„ innenfor TCP-Ăžkten sendes Keepalive-meldinger. De sendes, som standard, hver 60. sekund. Dette er Keepalive Timer. Hvis Keepalive-meldingen ikke mottas innen Hold Timer, vil det bety tap av forbindelsen med naboen. Som standard er dette lik â 180 sekunder.
Nyttig tabell:
Vi ser ut til Ä ha forstÄtt hvordan rutere overfÞrer informasjon til hverandre, nÄ vil vi forsÞke Ä forstÄ logikken bak BGP-protokollen.
For Ä annonsere en rute i BGP-tabellen, brukes kommandoen network, som i IGP-protokoller, men logikken er annerledes. Hvis i IGP, etter angivelse av ruten i network-kommandoen, ser IGP pÄ hvilke grensesnitt som tilhÞrer det aktuelle subnettet og inkluderer dem i sin tabell, ser network-kommandoen i BGP i rutetabellen og sÞker etter nÞyaktig overensstemmelse med ruten i network-kommandoen. Ved funn av slike, vil disse rutene havne i BGP-tabellen.
Se etter en rute i ruterens nÄvÊrende IP-rutetabell som nÞyaktig samsvarer med parameterne i network-kommandoen; hvis IP-ruten eksisterer, sett inn den tilsvarende NLRI i den lokale BGP-tabellen.
NĂ„ lĂžfter vi BGP pĂ„ alle de gjenvĂŠrende og ser hvordan rutevalget skjer innen en enkelt AS. Etter at BGP-ruteren har mottatt ruter fra naboen, begynner valget av optimal rute. Her mĂ„ vi forstĂ„ hvilken type naboer som kan vĂŠre â interne og eksterne. Ruteren forstĂ„r fra konfigurasjonen om den konfigurerte naboen er intern eller ekstern? Hvis i kommandoen:
neighbor 192.168.13.3 remote-as 10 Som parameter er remote-as angitt AS, som er konfigurert pÄ selve rutereren i kommandoen router bgp 10. Ruter, som kommer fra en intern AS, betraktes som interne, mens rutene fra en ekstern AS naturligvis er eksterne. Det finnes ulik logikk for mottak og sending av data for hver av dem. La oss se pÄ en slik topologi:
PĂ„ hver ruter er det konfigurert en loopback-grensesnitt med ip: x.x.x.x 255.255.255.0 â hvor x er ruterens nummer. PĂ„ Router9 har vi et loopback-grensesnitt med adressen â 9.9.9.9 255.255.255.0. Denne vil vi annonsere via BGP og se hvordan den sprer seg. Denne ruten vil bli sendt til Router8 og Router12. Fra Router8 vil denne ruten komme til Router6, men pĂ„ Router5 vil den ikke finnes i rutetabellen. PĂ„ samme mĂ„te vil denne ruten komme inn i rutetabellen pĂ„ Router12, men den vil heller ikke vĂŠre tilgjengelig pĂ„ Router11. Vi skal prĂžve Ă„ forstĂ„ dette. La oss se pĂ„ hvilke data og parametere Router9 sender til sine naboer for Ă„ informere om denne ruten. Pakken nedenfor vil bli sendt fra Router9 til Router8.
Informasjonen om ruten bestÄr av vei-attributter (Path attributes).
Vei-attributter er delt opp i 4 kategorier:
- Well-known mandatory â alle rutere som opererer med BGP-protokollen mĂ„ gjenkjenne disse attributtene. De mĂ„ vĂŠre til stede i alle oppdateringer (update).
- Well-known discretionary â alle rutere som opererer med BGP-protokollen mĂ„ gjenkjenne disse attributtene. De kan vĂŠre til stede i oppdateringer (update), men deres tilstedevĂŠrelse er ikke obligatorisk.
- Optional transitive â kan hende ikke gjenkjennes av alle implementeringer av BGP. Hvis ruteren ikke gjenkjenner attributtet, markerer den oppdateringen som delvis (partial) og sender den videre til nabolagene, mens det ikke gjenkjente attributtet beholdes.
- Optional non-transitive â kan hende ikke gjenkjennes av alle implementeringer av BGP. Hvis ruteren ikke gjenkjenner attributtet, ignoreres attributtet og kassere ved videresending til naboene.
Eksempler pÄ BGP-attributter:
- Well-known mandatory:
- Autonomous system path
- Next-hop
- Origin
- Well-known discretionary:
- Local preference
- Atomic aggregate
- Optional transitive:
- Aggregator
- Communities
- Optional non-transitive:
- Multi-exit discriminator (MED)
- Originator ID
- Cluster list
I dette tilfellet vil vi for Ăžyeblikket vĂŠre interessert i Origin, Next-hop, AS Path. Siden ruten overfĂžres mellom Router8 og Router9, som er innenfor samme AS, betraktes den som intern, og vi vil merke oss Origin.
Attributten Origin â indikerer hvordan ruten ble mottatt i oppdateringen. Mulige verdier for attributten er:
- 0 â IGP: NLRI mottatt innen den opprinnelige autonome systemet;
- 1 â EGP: NLRI er lĂŠrt gjennom protokollen Exterior Gateway Protocol (EGP). ForlĂžperen til BGP, som ikke er i bruk.
- 2 â Incomplete: NLRI ble lĂŠrt pĂ„ en annen mĂ„te.
I vĂ„rt tilfelle, som det fremgĂ„r av pakken, er lik 0. NĂ„r denne ruten skal overfĂžres til Router12, vil denne koden fĂ„ koden â 1.
Videre, Next-hop. Attributtet Next-hop.
- Dette er IP-adressen til eBGP-ruteren, gjennom hvilken veien gÄr til mÄlnettverket.
- Attributtet endres nÄr prefikset overfÞres til en annen AS.
I tilfelle av iBGP, dvs. innenfor Ă©n AS, vil Next-hop vĂŠre den som lĂŠrte eller rapporterte om denne ruten. I vĂ„rt tilfelle vil dette vĂŠre 192.168.89.9. Men nĂ„r denne ruten overfĂžres fra Router8 til Router6, vil Router8 endre den og erstatte med sin egen. Neste hop vil vĂŠre â 192.168.68.8. Dette fĂžrer oss til to regler:
- Hvis ruteren overfĂžrer en rute til sin interne nabo, endrer den ikke Next-hop-parameteren.
- Hvis ruteren overfĂžrer en rute til sin eksterne nabo, endres Next-hop til IP-adressen til grensesnittet som denne ruteren overfĂžrer fra.
Dette fĂžrer oss til forstĂ„elsen av det fĂžrste problemet â Hvorfor det ikke vil vĂŠre en rute i rutetabellen pĂ„ Router5 og Router11. La oss se nĂŠrmere pĂ„ det. SĂ„, Router6 mottok informasjon om ruten 9.9.9.0/24 og la den vellykket til i rutetabellen:
Router6#show ip route bgp
Koder: L - lokal, C - tilkoblet, S - statisk, R - RIP, M - mobil, B - BGP
D - EIGRP, EX - EIGRP ekstern, O - OSPF, IA - OSPF mellom områder
N1 - OSPF NSSA ekstern type 1, N2 - OSPF NSSA ekstern type 2
E1 - OSPF ekstern type 1, E2 - OSPF ekstern type 2
i - IS-IS, su - IS-IS oppsummering, L1 - IS-IS nivå-1, L2 - IS-IS nivå-2
ia - IS-IS mellom områder, * - kandidatstandard, U - per-bruker statisk rute
o - ODR, P - periodisk lastet statisk rute, H - NHRP, l - LISP
a - applikasjonsrute
+ - replikert rute, % - neste hopp overstyring, p - overstyringer fra PfR
Ingen gateway for siste utvei er satt
9.0.0.0/24 er subnettet, 1 subnett
B 9.9.9.0 [20/0] via 192.168.68.8, 00:38:25<source>
Nå har Router6 overført ruten til Router5 og endret ikke første reglen for neste hopp. Det vil si at Router5 må legge til <b>9.9.9.0 [20/0] via 192.168.68.8</b> , men den har ingen rute til 192.168.68.8 og derfor vil ikke denne ruten bli lagt til, selv om informasjon om denne ruten vil bli lagret i BGP-tabellen:
<source><b>Router5#show ip bgp
BGP-tabellversjon er 1, lokal router-ID er 5.5.5.5
Status koder: s undertrykt, d dempet, h historikk, * gyldig, > best, i - intern,
r RIB-feil, S gammel, m multipath, b backup-path, f RT-filter,
x best-ekstern, a tilleggsti, c RIB-komprimert,
Opprinnelseskoder: i - IGP, e - EGP, ? - ufullstendig
RPKI-valideringskoder: V gyldig, I ugyldig, N Ikke funnet
Nettverk Neste Hopp Metode LokPrf Vekt Sti
* i 9.9.9.0/24 192.168.68.8 0 100 0 45 i</b>Den samme situasjonen vil oppstÄ mellom Router11-Router12. For Ä unngÄ en slik situasjon mÄ vi konfigurere at Router6 eller Router12, nÄr de overfÞrer ruten til sine interne naboer, setter sitt egne IP-adresse som Next-hop. Dette gjÞres med kommandoen:
neighbor 192.168.56.5 next-hop-self.Etter denne kommandoen vil Router6 sende et Update-melding, der for rutene vil IP-adressen til Gi0/0-grensesnittet pĂ„ Router6 â 192.168.56.6 bli oppgitt som Next-hop, hvoretter denne ruten allerede vil komme inn i rutetabellen.
La oss gÄ videre og se om denne ruten vil vises pÄ Router7 og Router10. Den vil ikke vÊre i rutetabellen, og vi kunne ha tenkt at problemet ligger som i det fÞrste med Next-hop-parameteren, men dersom vi ser pÄ utdataene fra kommandoen show ip bgp, vil vi se at ruten ikke ble mottatt selv med feil Next-hop, noe som betyr at ruten ikke engang ble overfÞrt. Dette fÞrer oss til et nytt regel:
Ruter mottatt fra interne naboer blir ikke overfĂžrt til andre interne naboer.
Siden Router5 mottok ruten fra Router6, vil den ikke bli videresendt til sin interne nabo. For at videresendingen skal skje, mÄ funksjonen konfigureres. , eller konfigurere fullstendig nabolag (Full Mesh), det vil si at Router5-7 hver vil vÊre nabo med hverandre. I dette tilfellet vil vi bruke Rute-Reflektor. PÄ Router5 mÄ vi bruke denne kommandoen:
neighbor 192.168.57.7 route-reflector-clientRute-Reflektor endrer BGP-adferden ved videresending av ruten til en intern nabo. Hvis den interne naboen er angitt som route-reflector-client, vil ruter bli annonsert til disse klientene.
Er ikke ruten synlig pÄ Router7? Ikke glem ogsÄ Next-hop. Etter disse manipuleringene skulle ruten vises pÄ Router7, men dette skjer ikke. Dette fÞrer oss til en annen regel:
Next-hop-regelen fungerer bare for eksterne ruter. For interne ruter skjer det ingen erstatning av next-hop-attributtet.
Og vi fĂ„r en situasjon der vi mĂ„ opprette et miljĂž ved hjelp av statisk ruting eller IGP-protokoller for Ă„ informere rutere om alle rutene innen AS. Vi vil skrive inn statiske ruter pĂ„ Router6 og Router7, og deretter fĂ„ den nĂždvendige ruten i ruteren sin tabell. I AS 678 vil vi gjĂžre noe annet â vi angir statiske ruter for 192.168.112.0/24 pĂ„ Router10 og 192.168.110.0/24 pĂ„ Router12. Deretter vil vi etablere nabo-forhold mellom Router10 og Router12. Vi vil ogsĂ„ konfigurere Router12 til Ă„ sende sin next-hop til Router10:
neighbor 192.168.110.10 next-hop-selfResultatet vil vÊre at Router10 vil motta ruten 9.9.9.0/24, den vil bli mottatt bÄde fra Router7 og Router12. La oss se hvilket valg Router10 gjÞr:
Router10#show ip bgp
BGP-tabellversjon er 3, lokal ruter-ID er 6.6.6.6
Statuskoder: s undertrykt, d dempet, h historikk, * gyldig, > best, i - intern,
r RIB-feil, S Stale, m multipath, b backup-path, f RT-Filter,
x best-external, a additional-path, c RIB-komprimert,
Opprinnelskoder: i - IGP, e - EGP, ? - ufullstendig
RPKI-valideringskoder: V gyldig, I ugyldig, N Ikke funnet
Nettverk Next Hop Metode LocPrf Vekt Sti
* >i 9.9.9.0/24 192.168.112.12 0 100 0 45 i
192.168.107.7 0 123 45 i Som vi ser, to ruter og pilen (>) angir at ruten valgt er gjennom 192.168.112.12.
La oss se hvordan prosessen med valg av rute skjer:
- FÞrst ved mottak av ruten, sjekkes tilgjengeligheten av dens Next-hop. Det er nettopp derfor, nÄr vi mottok ruten pÄ Router5 uten Ä konfigurere Next-hop-self, ble ruten ikke videresendt til behandling.
- Neste er parameteren Weight. Denne parameteren er ikke et Attributt for Path (PA) og overfÞres ikke i BGP-meldinger. Den konfigureres lokalt pÄ hver ruter og brukes kun til Ä manipulere rutevalget pÄ selve ruteren. La oss se pÄ et eksempel. Litt hÞyere vises det at Router10 valgte ruten for 9.9.9.0/24 via Router12 (192.168.112.12). For Ä endre parameteren Weight kan man bruke route-map for Ä angi den for bestemte ruter, eller tilordne en vekt til nabon ved hjelp av kommandoen:
neighbor 192.168.107.7 weight 200NĂ„ vil alle ruter fra denne nabon ha denne vekten. La oss se hvordan rutevalget endres etter denne manĂžveren:
Router10#show bgp *Mar 2 11:58:13.956: %SYS-5-CONFIG_I: Konfigurert fra konsoll av konsoll BGP-tabellversjon er 2, lokal ruter-ID er 6.6.6.6 Statuskoder: s undertrykt, d dempet, h historie, * gyldig, > best, i - intern, r RIB-feil, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-komprimert, Opprinnelseskoder: i - IGP, e - EGP, ? - ufullstendig RPKI valideringskoder: V gyldig, I ugyldig, N Ikke funnet Nettverk Neste Hopp Metrisk LocPrf Vekt Sti * > 9.9.9.0/24 192.168.107.7 200 123 45 i * i 192.168.112.12 0 100 0 45 iSom dere ser, er nÄ ruten valgt gjennom Router7, men dette vil ikke ha noen effekt pÄ de andre rutene.
- PĂ„ tredje plass har vi â Local Preference. Denne parameteren er et Well-known discretionary attributt, som betyr at dens tilstedevĂŠrelse ikke er obligatorisk. Denne parameteren har kun gyldighet innenfor en AS og pĂ„virker rutevalget kun for interne naboer. Det er derfor den kun overfĂžres i Update-meldinger beregnet for interne naboer. I Update-meldinger for eksterne naboer er den fravĂŠrende. Derfor er den klassifisert som Well-known discretionary. La oss prĂžve Ă„ bruke den pĂ„ Router5. PĂ„ Router5 skal vi ha to ruter for 9.9.9.0/24 â en via Router6 og den andre via Router7.
La oss se:
Router5#show bgp BGP-tabellversjon er 2, lokal ruter-ID er 5.5.5.5 Statuskoder: s undertrykt, d dempet, h historie, * gyldig, > best, i - intern, r RIB-feil, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-komprimert, Opprinnelseskoder: i - IGP, e - EGP, ? - ufullstendig RPKI valideringskoder: V gyldig, I ugyldig, N Ikke funnet Nettverk Neste Hopp Metrisk LocPrf Vekt Sti * > i 9.9.9.0/24 192.168.56.6 0 100 0 45 iMen som vi ser er det én rute gjennom Router6. Hvor er ruten gjennom Router7? Kanskje den ikke finnes pÄ Router7 heller? La oss se:
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 iDet er merkelig, alt ser ut til Ă„ vĂŠre i orden. Hvorfor overfĂžres det ikke til Router5? Ă rsaken er at BGP har en regel:
Ruteren sender bare de rutene som den bruker selv.
Router7 bruker ruten gjennom Router5, derfor vil ikke ruten gjennom Router10 bli sendt. La oss gÄ tilbake til Local Preference. La oss sette Local Preference pÄ Router7 og se hvordan Router5 reagerer:
rute-kart BGP tillat 10 match ip-adresse 10 sett lokal-preferanse 250 tilgangsliste 10 tillat alle ruter bgp 123 nabo 192.168.107.10 rute-kart BGP inn</b>SÄ vi har opprettet en route-map som tar med alle rutene og instruert Router7 om Ä endre parameteren Local Preference til 250, som standard er 100. La oss se hva som skjedde pÄ 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 iSom vi ser, foretrekker Router5 nÄ ruten gjennom Router7. Den samme situasjonen vil ogsÄ vÊre pÄ Router6, selv om det ville vÊrt mer fordelaktig for den Ä velge ruten gjennom Router8. La oss ogsÄ nevne at endringen av denne parameteren krever en omstart av nabolaget for at endringen skal tre i kraft. Les videre. . Vi er nÄ ferdige med Local Preference. La oss gÄ videre til neste parameter.
- Ruteprioritet med parameteren Next-hop 0.0.0.0, det vil si lokale eller aggregerte ruter. Disse rutene fÄr automatisk parameteren Weight som er lik maksimum - 32678, nÄr man skriver inn kommandoen network:
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 - Den korteste veien gjennom AS. Den korteste parameteren AS_Path velges. Jo fÊrre AS ruten passerer gjennom, jo bedre er den. La oss se pÄ ruten til 9.9.9.0/24 pÄ Router10:
Router10#show bgp BGP-tabellen er versjon 2, den lokale ruteren har ID 6.6.6.6 Statuskoder: s undertrykt, d dempet, h historikk, * gyldig, > beste, i - intern, r RIB-feil, S foreldet, m multipath, b backup-path, f RT-Filter, x beste-ekstern, a ekstra-vei, c RIB-komprimert, Opprinnelseskoder: i - IGP, e - EGP, ? - ufullstendig RPKI-valideringskoder: V gyldig, I ugyldig, N ikke funnet Nettverk Neste Hopp Meter LocPrf Vekt Sti * 9.9.9.0/24 192.168.107.7 0 123 45 i *>i 192.168.112.12 0 100 0 45 iSom du kan se, valgte Router10 ruten via 192.168.112.12 fordi AS_Path-parameteren for denne ruten kun inneholder 45, mens det i et annet tilfelle er 123 og 45. Dette er intuitivt.
- Den neste parameteren er Opprinnelse. IGP (ruten er oppnÄdd ved hjelp av BGP) er bedre enn EGP (ruten er oppnÄdd ved hjelp av en forgjenger til BGP, som nÄ ikke er i bruk), og EGP er bedre enn Incomplete? (oppnÄdd pÄ en annen mÄte, for eksempel gjennom redistribusjon).
- Den neste parameteren er MED. Vi hadde Weight, som bare fungerte lokalt pÄ ruteren. Det var Local Preference, som fungerte bare innenfor det samme autonome systemet. Som lett kan gjette, er MED en parameter som vil bli overfÞrt mellom autonome systemer. om denne parameteren.
Flere attributter vil ikke bli brukt, men hvis to ruter har de samme, gjelder fĂžlgende regler:
- Velg vei gjennom nĂŠrmeste IGP-nabo.
- Velg den eldste ruten for eBGP-vei.
- Velg vei gjennom naboen med lavest BGP-ruter ID.
- Velg vei gjennom naboen med lavest IP-adresse.
La oss nÄ se pÄ BGP-sammenkoblingsspÞrsmÄlet.
La oss se hva som skjer hvis vi antar at Router6 mister ruten 9.9.9.0/24 gjennom Router9. Vi slÄr av grensesnittet Gi0/1 pÄ Router6, som umiddelbart forstÄr at BGP-Þkten med Router8 er brutt og naboen har forsvunnet, noe som betyr at ruten mottatt fra ham ikke lenger er gyldig. Router6 sender umiddelbart oppdateringsmeldinger der den angir nettverket 9.9.9.0/24 i feltet Tilbaketrukne Ruter. SÄ snart Router5 mottar en slik melding, vil den sende den videre til Router7. Men siden Router7 har en rute gjennom Router10, vil den umiddelbart sende oppdateringen med den nye ruten som svar. Hvis det ikke er mulig Ä oppdage nedgangen til naboen via grensesnittets tilstand, mÄ vi vente pÄ at Hold Timer skal utlÞses.
Konfederasjon.
Husker du, at vi talte om, at det ofte er nĂždvendigt at bruge en fuldt forbundet topologi? Med mange routere i Ă©n AS kan det skabe store problemer, sĂ„ for at undgĂ„ dette er det nĂždvendigt at bruge konfĂžderationer. Ăn AS opdeles i flere sub-AS, hvilket gĂžr det muligt for dem at fungere uden krav om en fuldt forbundet topologi.
Her er linket til denne , men konfiguration for GNS3.
For eksempel, med en sÄdan topologi ville vi vÊre nÞdt til at forbinde alle routere i AS 2345 sammen, men ved at bruge konfÞderationer kan vi oprette naboskabsrelationer kun mellem routere, der er direkte tilsluttet hinanden. Lad os tale nÊrmere om det. Hvis vi kun havde AS 2345, ville laForge fÄ ruten fra Picard fortalt det til sine routere Data og Worf, men de ville ikke have fortalt det til routeren Crusher . Desuden ville ruterne, som routeren selv annoncerer, laForgeikke blive transmitteret Crusher hverken Worf-en, eller Data.
Vi ville vÊre nÞdt til at konfigurere Route-Reflector eller fuldt forbundne naboskabsforhold. Ved at opdele én AS 2345 i 4 sub-AS (2, 3, 4, 5) for hver router, fÄr vi til sidst en anden logik for operation. Alt er fremragende beskrevet .
Kilder:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- Nettside
- Nettside .
Kilde: habr.com
Russian
Italian
German
Polish
Estonian
Albanian
Bulgarian
Croatian
Czech
Danish
Dutch
English
French
Hungarian
Latvian
Norwegian
Portuguese
Romanian
Slovak
Slovenian
Spanish
Swedish