I dag skal vi se på BGP-protokollen. Vi vil ikke snakke lenge om hvorfor det er og hvorfor det brukes som den eneste protokollen. Det er ganske mye informasjon om dette emnet, for eksempel .
Så hva er BGP? BGP er en dynamisk rutingprotokoll og er den eneste EGP-protokollen (External Gateway Protocol). Denne protokollen brukes til å bygge ruting på Internett. La oss se på hvordan et nabolag bygges mellom to BGP-rutere.
Vurder nabolaget mellom Router1 og Router3. La oss konfigurere dem ved å bruke 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 et enkelt autonomt system er AS 10. Etter å ha lagt inn informasjon om en ruter, for eksempel Router1, forsøker ruteren å sette opp et tilstøtende forhold til Router3. Starttilstanden når ingenting skjer kalles Idle. Så snart bgp er konfigurert på Router1, vil den begynne å lytte til TCP-port 179 - den vil gå inn i tilstanden Koble, og når den prøver å åpne en økt med Router3, vil den gå inn i tilstanden Aktiv.
Etter at økten er etablert mellom ruter1 og ruter3, utveksles åpne meldinger. Når denne meldingen sendes av ruter1, vil denne tilstanden bli kalt Åpne Sendt. Og når den mottar en Åpen-melding fra Router3, vil den gå inn i tilstanden Åpne Bekreft. La oss se nærmere på Åpen-meldingen:
Denne meldingen formidler informasjon om selve BGP-protokollen, som ruteren bruker. Ved å utveksle åpne meldinger, kommuniserer Router1 og Router3 informasjon om innstillingene sine til hverandre. Følgende parametere sendes:
- Versjon: 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 frem en kompatibel versjon, når det er en mismatch vil det ikke være noen BGP-økt.
- Mitt AS: dette inkluderer AS-nummeret til BGP-ruteren, ruterne må bli enige om AS-nummeret(e) og det definerer også om de skal kjøre iBGP eller eBGP.
- Hold tid: hvis BGP ikke mottar noen keepalive eller oppdateringsmeldinger fra den andre siden i løpet av ventetiden, vil den erklære den andre siden "død", og den vil rive ned BGP-økten. Holdetiden er som standard satt til 180 sekunder på Cisco IOS-rutere, keepalive-meldingen sendes hvert 60. sekund. Begge ruterne må bli enige om ventetiden, ellers blir det ikke en BGP-økt.
- BGP-identifikator: dette er den lokale BGP-ruter-IDen som velges akkurat som OSPF gjør:
- Bruk ruter-IDen som ble konfigurert manuelt med kommandoen bgp router-id.
- Bruk den høyeste IP-adressen på et loopback-grensesnitt.
- Bruk den høyeste IP-adressen på et fysisk grensesnitt.
- Valgfrie parametere: her finner du noen valgfrie funksjoner til BGP-ruteren. Dette feltet er lagt til slik at nye funksjoner kan legges til BGP uten å måtte opprette 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-oktett AS-nummer.
For å etablere et nabolag må følgende betingelser være oppfylt:
- Versjonsnummer. Den nåværende versjonen er 4.
- AS-nummeret må samsvare med det du har konfigurert nabo 192.168.13.3 fjernkontroll-as 10.
- Ruter-ID må være forskjellig fra naboen.
Hvis noen av parameterne ikke tilfredsstiller disse betingelsene, vil ruteren sende Varsling melding som indikerer feilen. Etter å ha sendt og mottatt åpne meldinger går naboforholdet inn i staten OPPRETTET. Etter dette kan rutere utveksle informasjon om ruter og gjøre dette ved hjelp av Oppdater meldinger. Dette er oppdateringsmeldingen sendt av Router1 til Router3:
Her kan du se nettverkene rapportert av Router1 og Path-attributter, som er analoge med beregninger. Vi vil snakke om baneattributter mer detaljert. Keepalive-meldinger sendes også i en TCP-økt. De sendes som standard hvert 60. sekund. Dette er en Keepalive-timer. Hvis en Keepalive-melding ikke mottas under Hold-timeren, vil dette bety tap av kommunikasjon med naboen. Som standard er det lik 180 sekunder.
Nyttig tegn:
Det ser ut til at vi har funnet ut hvordan rutere overfører informasjon til hverandre, la oss nå prøve å forstå logikken til BGP-protokollen.
For å annonsere en rute til BGP-tabellen, som i IGP-protokollene, brukes nettverkskommandoen, men driftslogikken er annerledes. Hvis i IGP, etter å ha spesifisert ruten i nettverkskommandoen, ser IGP på hvilke grensesnitt som tilhører dette undernettet og inkluderer dem i tabellen, så ser nettverkskommandoen i BGP på rutetabellen og ser etter presis samsvarer med ruten i nettverkskommandoen. Hvis slike blir funnet, vil disse rutene vises i BGP-tabellen.
Se etter en rute i ruterens gjeldende IP-rutingstabell som nøyaktig samsvarer med parametrene til nettverkskommandoen; hvis IP-ruten eksisterer, legg tilsvarende NLRI inn i den lokale BGP-tabellen.
La oss nå heve BGP til alle de gjenværende og se hvordan ruten velges innenfor ett AS. Etter at BGP-ruteren mottar ruter fra naboen, begynner den å velge den optimale ruten. Her må du forstå hvilken type naboer det kan være - interne og eksterne. Forstår ruteren ved konfigurasjon om den konfigurerte naboen er intern eller ekstern? Hvis på et lag:
neighbor 192.168.13.3 remote-as 10 remote-as-parameteren spesifiserer AS, som er konfigurert på selve ruteren i ruterkommandoen bgp 10. Ruter som kommer fra det interne AS regnes som interne, og ruter fra det eksterne AS regnes som eksterne. Og for hver fungerer en annen logikk for mottak og sending. Tenk på denne topologien:
Hver ruter har et loopback-grensesnitt konfigurert med ip: xxxx 255.255.255.0 - hvor x er ruternummeret. På Router9 har vi et loopback-grensesnitt med adressen - 9.9.9.9 255.255.255.0. Vi vil kunngjøre det via BGP og se hvordan det sprer seg. Denne ruten vil bli overført til Router8 og Router12. Fra Router8 vil denne ruten gå til Router6, men til Router5 vil den ikke være i rutetabellen. Også på Router12 vil denne ruten vises i tabellen, men på Router11 vil den heller ikke være der. La oss prøve å finne ut av dette. La oss vurdere hvilke data og parametere Router9 sender til sine naboer, og rapporterer denne ruten. Pakken nedenfor vil bli sendt fra Router9 til Router8.
Ruteinformasjon består av baneattributter.
Baneattributter er delt inn i 4 kategorier:
- Velkjent obligatorisk - Alle rutere som kjører BGP må gjenkjenne disse attributtene. Må være til stede i alle oppdateringer.
- Velkjent skjønn - Alle rutere som kjører BGP må gjenkjenne disse attributtene. De kan være til stede i oppdateringer, men deres tilstedeværelse er ikke nødvendig.
- Valgfri transitiv - gjenkjennes kanskje ikke av alle BGP-implementeringer. Hvis ruteren ikke gjenkjenner attributtet, merker den oppdateringen som delvis og videresender den til naboene, og lagrer det ukjente attributtet.
- Valgfri ikke-transitiv - gjenkjennes kanskje ikke av alle BGP-implementeringer. Hvis ruteren ikke gjenkjenner attributtet, blir attributtet ignorert og forkastet når det sendes videre til naboer.
Eksempler på BGP-attributter:
- Velkjent obligatorisk:
- Autonom systemvei
- Neste hopp
- Origin
- Velkjent skjønn:
- Lokal preferanse
- Atomaggregat
- Valgfri transitiv:
- aggregator
- Communities
- Valgfri ikke-transitiv:
- Multi-exit diskriminator (MED)
- Opphavsmann-ID
- Klyngeliste
I dette tilfellet vil vi foreløpig være interessert i Origin, Next-hop, AS Path. Siden ruten sender mellom Router8 og Router9, det vil si innenfor ett AS, regnes den som intern og vi vil ta hensyn til Origin.
Opprinnelsesattributt - indikerer hvordan ruten i oppdateringen ble hentet. Mulige attributtverdier:
- 0 - IGP: NLRI mottatt innenfor det opprinnelige autonome systemet;
- 1 - EGP: NLRI læres ved hjelp av Exterior Gateway Protocol (EGP). Forgjenger til BGP, ikke brukt
- 2 - Ufullstendig: NLRI ble lært på en annen måte
I vårt tilfelle, som det fremgår av pakken, er den lik 0. Når denne ruten overføres til Router12 vil denne koden ha en kode på 1.
Neste, Next-hop. Neste-hopp-attributt
- Dette er IP-adressen til eBGP-ruteren som banen til destinasjonsnettverket går gjennom.
- Attributtet endres når prefikset sendes til et annet AS.
Når det gjelder iBGP, det vil si innenfor ett AS, vil Next-hop bli indikert av den som har lært eller fortalt om denne ruten. I vårt tilfelle vil det være 192.168.89.9. Men når denne ruten overføres fra Router8 til Router6, vil Router8 endre den og erstatte den med sin egen. Neste hopp vil være 192.168.68.8. Dette leder oss til to regler:
- Hvis en ruter videresender en rute til sin interne nabo, endrer den ikke Next-hop-parameteren.
- Hvis en ruter sender en rute til sin eksterne nabo, endrer den Next-hop til ip-en til grensesnittet denne ruteren sender fra.
Dette fører til at vi forstår det første problemet - hvorfor det ikke vil være noen rute i rutetabellen på Router5 og Router11. La oss ta en nærmere titt. Så, Router6 mottok informasjon om rute 9.9.9.0/24 og la den til i rutetabellen:
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>Den samme situasjonen vil skje mellom Router11-Router12. For å unngå denne situasjonen, må du konfigurere Router6 eller Router12, når du sender ruten til deres interne naboer, for å erstatte deres IP-adresse som Next-hop. Dette gjøres ved å bruke kommandoen:
neighbor 192.168.56.5 next-hop-selfEtter denne kommandoen vil Router6 sende en oppdateringsmelding, hvor ip-en til grensesnitt Gi0/0 Router6 vil bli spesifisert som Next-hop for ruter - 192.168.56.6, hvoretter denne ruten allerede vil være inkludert i rutingtabellen.
La oss gå videre og se om denne ruten vises på Router7 og Router10. Det vil ikke være i rutetabellen, og vi tror kanskje at problemet er det samme som i den første med Next-hop-parameteren, men hvis vi ser på utdataene til show ip bgp-kommandoen, vil vi se at ruten ble ikke mottatt der selv med feil Next-hop, noe som betyr at ruten ikke en gang ble overført. Og dette vil føre oss til eksistensen av en annen regel:
Traséer mottatt fra interne naboer forplantes ikke til andre interne naboer.
Siden Router5 mottok ruten fra Router6, vil den ikke bli overført til den andre interne naboen. For at overføringen skal skje, må du konfigurere funksjonen , eller konfigurer fullstendig tilkoblede nabolagsforhold (Full Mesh), det vil si at Router5-7 vil alle være naboer for alle. I dette tilfellet vil vi bruke rutereflektor. På Router5 må du bruke denne kommandoen:
neighbor 192.168.57.7 route-reflector-clientRoute-Reflector endrer oppførselen til BGP når den passerer en rute til en intern nabo. Dersom intern nabo er angitt som rute-reflektor-klient, vil interne ruter bli annonsert til disse kundene.
Ruten dukket ikke opp på Router7? Ikke glem Next-hop heller. Etter disse manipulasjonene skal ruten også gå til Router7, men dette skjer ikke. Dette bringer oss til en annen regel:
Neste-hopp-regelen fungerer bare for eksterne ruter. For interne ruter erstattes ikke neste-hopp-attributtet.
Og vi får en situasjon der det er nødvendig å lage et miljø ved hjelp av statisk ruting eller IGP-protokoller for å informere rutere om alle rutene i AS. La oss registrere statiske ruter på Router6 og Router7 og etter det får vi ønsket rute i rutertabellen. I AS 678 vil vi gjøre det litt annerledes - vi vil registrere statiske ruter for 192.168.112.0/24 på Router10 og 192.168.110.0/24 på Router12. Deretter vil vi etablere nabolagsforholdet mellom Router10 og Router12. Vi vil også konfigurere Router12 til å sende neste hopp til Router10:
neighbor 192.168.110.10 next-hop-selfResultatet blir at Router10 vil motta rute 9.9.9.0/24, den vil mottas fra både Router7 og Router12. La oss se hvilket valg Router10 gjør:
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
Som vi kan se betyr to ruter og en pil (>) at ruten via 192.168.112.12 er valgt.
La oss se hvordan rutevalgsprosessen fungerer:
- Det første trinnet når du mottar en rute er å sjekke tilgjengeligheten til Next-hop. Det er derfor, når vi mottok en rute på Router5 uten å sette Next-hop-self, ble ikke denne ruten videre behandlet.
- Deretter kommer vektparameteren. Denne parameteren er ikke et Path Attribute (PA) og sendes ikke i BGP-meldinger. Den er konfigurert lokalt på hver ruter og brukes kun til å manipulere rutevalg på selve ruteren. La oss se på et eksempel. Rett over kan du se at Router10 har valgt en rute for 9.9.9.0/24 via Router12 (192.168.112.12). For å endre parameteren Wiight kan du bruke rutekart til å angi spesifikke ruter, eller tilordne en vekt til naboen ved å bruke kommandoen:
neighbor 192.168.107.7 weight 200Nå vil alle ruter fra denne naboen ha denne vekten. La oss se hvordan valget av rute endres etter denne manipulasjonen:
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 iSom du ser er ruten gjennom Router7 nå valgt, men dette vil ikke ha noen effekt på de andre ruterne.
- I tredje posisjon har vi Local Preference. Denne parameteren er et velkjent skjønnsmessig attributt, som betyr at tilstedeværelsen er valgfri. Denne parameteren er kun gyldig innenfor ett AS og påvirker valget av vei kun for interne naboer. Det er derfor det overføres kun i Oppdateringsmeldinger beregnet på den interne naboen. Det finnes ikke i Oppdater meldinger for eksterne naboer. Derfor ble den klassifisert som Velkjent skjønnsmessig. La oss prøve å bruke den på Router5. På Router5 bør vi ha to ruter for 9.9.9.0/24 – en gjennom Router6 og den andre gjennom Router7.
Vi ser:
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 iMen som vi ser én rute gjennom Router6. Hvor er ruten gjennom Router7? Kanskje Router7 ikke har det 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 iRart, alt ser ut til å være bra. Hvorfor overføres det ikke til Router5? Saken er at BGP har en regel:
Ruteren overfører bare de rutene den bruker.
Router7 bruker en rute gjennom Router5, så ruten gjennom Router10 vil ikke bli overført. La oss gå tilbake til Lokale preferanser. La oss angi Local Preference på Router7 og se hvordan Router5 reagerer på dette:
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>Så vi laget et rutekart som inneholder alle rutene og ba Router7 endre Local Preference-parameteren til 250 når den ble mottatt, standarden 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 kan se nå foretrekker Router5 ruten gjennom Router7. Det samme bildet vil være på Router6, selv om det er mer lønnsomt for ham å velge en rute gjennom Router8. Vi legger også til at endring av denne parameteren krever en omstart av nabolaget for at endringen skal tre i kraft. Lese . Vi har sortert ut lokale preferanser. La oss gå videre til neste parameter.
- Foretrekk ruten med Next-hop-parameteren 0.0.0.0, det vil si lokale eller aggregerte ruter. Disse rutene blir automatisk tildelt en vektparameter som er lik maksimum—32678—etter å ha skrevet inn nettverkskommandoen:
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 - Korteste vei gjennom AS. Den korteste AS_Path-parameteren er valgt. Jo færre AS-er en rute går gjennom, jo bedre er den. Tenk på ruten til 9.9.9.0/24 på 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 iSom du kan se, valgte Router10 ruten via 192.168.112.12 fordi for denne ruten inneholder AS_Path-parameteren bare 45, og i et annet tilfelle 123 og 45. Intuitivt tydelig.
- Den neste parameteren er Origin. IGP (rute oppnådd ved bruk av BGP) er bedre enn EGP (rute oppnådd ved bruk av BGPs forgjenger, ikke lenger i bruk), og EGP er bedre enn Incomplete? (oppnådd ved en annen metode, for eksempel ved omfordeling).
- Den neste parameteren er MED. Vi hadde Wiight som bare fungerte lokalt på ruteren. Det var Local Preference, som bare fungerte innenfor ett autonomt system. Som du kanskje gjetter, er MED en parameter som vil bli overført mellom autonome systemer. Veldig bra om denne parameteren.
Ingen flere attributter vil bli brukt, men hvis to ruter har de samme attributtene, brukes følgende regler:
- Velg stien gjennom nærmeste IGP-nabo.
- Velg den eldste ruten for eBGP-banen.
- Velg stien gjennom naboen med den minste BGP-ruter-IDen.
- Velg en vei gjennom naboen med den laveste IP-adressen.
La oss nå se på spørsmålet om BGP-konvergens.
La oss se hva som skjer hvis Router6 mister rute 9.9.9.0/24 gjennom Router9. La oss deaktivere grensesnitt Gi0/1 til Router6, som umiddelbart vil forstå at BGP-økten med Router8 er avsluttet og naboen har forsvunnet, noe som betyr at ruten mottatt fra den ikke er gyldig. Router6 sender umiddelbart oppdateringsmeldinger, der den indikerer nettverket 9.9.9.0/24 i feltet Tilbaketrukket ruter. Så snart Router5 mottar en slik melding, vil den sende den til Router7. Men siden Router7 har en rute gjennom Router10, vil den umiddelbart svare med en oppdatering med en ny rute. Hvis det ikke er mulig å oppdage fallet til en nabo basert på tilstanden til grensesnittet, må du vente på at Hold-timeren utløses.
Konføderasjon.
Hvis du husker, snakket vi om det faktum at du ofte må bruke en fullstendig koblet topologi. Med et stort antall rutere i ett AS kan dette skape store problemer, for å unngå dette må du bruke konføderasjoner. Ett AS er delt inn i flere sub-AS, noe som gjør at de kan operere uten krav om en fullt tilkoblet topologi.
Her er en link til dette Og konfigurasjon for GNS3.
For eksempel, med denne topologien må vi koble alle ruterne i AS 2345 til hverandre, men ved å bruke Confederation kan vi kun etablere tilgrensende relasjoner mellom rutere som er direkte koblet til hverandre. La oss snakke om dette i detalj. Hvis vi bare hadde AS 2345, da laForge etter å ha mottatt en marsj fra Picard ville fortelle det til ruterne Data и Worf, men de ville ikke fortelle ruteren om det Crusher . Også ruter distribuert av ruteren selv laForge, ville ikke blitt overført Crusher eller Worf-å nei Data.
Du må konfigurere en rutereflektor eller et fullstendig tilkoblet nabolagsforhold. Ved å dele en AS 2345 i 4 sub-AS (2,3,4,5) for hver ruter, ender vi opp med en annen driftslogikk. Alt er perfekt beskrevet .
Kilder:
- CCIE Routing and Switching v5.0 offisiell sertifiseringsveiledning, bind 2, femte utgave, Narbik Kocharians, Terry Vinson.
- Området
- Området .
Kilde: www.habr.com