I dag vil vi se på BGP-protokollen. Vi vil ikke bruge lang tid på at forklare, hvorfor den anvendes som den eneste protokol. Der er meget information om dette emne, for eksempel .
Så hvad er BGP? BGP er en protokol for dynamisk routing, der er den eneste EGP (External Gateway Protocol) protokol. Denne protokol anvendes til at opbygge routing i internettet. Lad os se på, hvordan naboforholdet mellem to BGP-routere dannes.
Vi ser på naboforholdet mellem Router1 og Router3. Lad os 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 10Naboforholdet inden for den samme autonome system — AS 10. Når dataene er indtastet på routeren, for eksempel på Router1, forsøger denne router at etablere naboforhold med routeren Router3. Den indledende tilstand, hvor intet sker, kaldes Idle. Så snart BGP er konfigureret på Router1, vil den begynde at lytte til TCP-port 179 — den vil skifte til tilstanden Forbind, og når den forsøger at åbne en session med Router3, vil den skifte til tilstanden Aktiv.
Når sessionen er etableret mellem Router1 og Router3, sker der en udveksling af Open-beskeder. Når denne besked sendes af Router1, vil denne tilstand blive kaldt Open Sent. Når den modtager Open-beskeden fra Router3, vil den skifte til tilstanden Open Confirm. Lad os se nærmere på Open-beskeden:
I denne besked overføres oplysninger om selve BGP-protokollen, som routeren anvender. Ved at udveksle Open-beskeder informerer Router1 og Router3 hinanden om deres indstillinger. Følgende parametre overføres:
- Version: dette inkluderer den BGP-version, som routeren bruger. Den nuværende version af BGP er version 4, som er beskrevet i RFC 4271. To BGP-routere vil forsøge at forhandle en kompatibel version; når der er en uoverensstemmelse, vil der ikke være nogen BGP-session.
- Mit AS: dette inkluderer AS-nummeret for BGP-routeren, routerne skal være enige om AS-nummeret/numrene, og det definerer også, om de vil køre iBGP eller eBGP.
- Holdtid: hvis BGP ikke modtager nogen keepalive- eller opdateringsbeskeder fra den anden side i løbet af holdtiden, vil det erklære den anden side for 'død', og det vil nedlægge BGP-sessionen. Som standard er holdtiden indstillet til 180 sekunder på Cisco IOS-routere, og keepalive-beskeden sendes hvert 60. sekund. Begge routere skal være enige om holdtiden, ellers vil der ikke være nogen BGP-session.
- BGP-identifier: dette er den lokale BGP-router-ID, der vælges ligesom OSPF gør:
- Brug router-ID, der blev konfigureret manuelt med bgp router-id-kommandoen.
- Brug den højeste IP-adresse på en loopback-grænseflade.
- Brug den højeste IP-adresse på en fysisk grænseflade.
- Valgfrie parametre: her finder du nogle valgfrie funktioner til BGP-routeren. Dette felt er blevet tilføjet, så nye funktioner kan tilføjes til BGP uden at skulle oprette en ny version. Ting, du måske finder her, er:
- understøttelse af MP-BGP (Multi Protocol BGP).
- understøttelse af Route Refresh.
- understøttelse af 4-octet AS-numre.
For at etablere et naboskab skal følgende betingelser opfyldes:
- Versionsnummer. Den nuværende version er 4.
- AS-nummeret skal matche det, du har konfigureret. neighbor 192.168.13.3 remote-as 10.
- Router ID skal være forskellig fra naboen.
Hvis nogen af parametrene ikke tilfredsstiller disse betingelser, vil routeren sende Notification en besked, der angiver fejlen. Når Open-beskederne er sendt og modtaget, ændres naboskabsforholdet til tilstanden ESTABLISHED. Derefter kan routerne allerede udveksle ruteinformation, og det sker ved hjælp af Opdater beskeder. Sådan en Update-besked sender Router1 til Router3:
Her angives netværk, som Router1 rapporterer om, og Path attributes, der fungerer som metrikker. Vi vil tale mere detaljeret om Path attributes. Også indenfor TCP-sessioner sendes Keepalive-beskeder. De sendes som standard hver 60. sekund. Dette er Keepalive Timer. Hvis der ikke modtages en Keepalive-besked inden for Hold Timer-perioden, vil det betyde, at forbindelsen til naboen er tabt. Som standard er det 180 sekunder.
Nyttigt skema:
Det ser ud til, at vi har forstået, hvordan routerne udveksler information med hinanden, nu vil vi forsøge at forstå logikken bag BGP-protokollen.
For at annoncere en rute i BGP-tabellen, som i IGP-protokoller, bruges kommandoen network, men logikken er forskellig. Hvis IGP, efter at have angivet ruten i network-kommandoen, ser på, hvilke interfaces der tilhører det specifikke subnet, og inkluderer dem i sin tabel, ser BGP's network-kommando i routing-tabellen og søger efter et præcist match med ruten i network-kommandoen. Når sådanne findes, vil disse ruter komme ind i BGP-tabellen.
Søg efter en rute i routerens nuværende IP-routingtabel, der præcist matcher parametrene i network-kommandoen; hvis IP-ruten eksisterer, indsæt den tilsvarende NLRI i den lokale BGP-tabel.
Lad os nu aktivere BGP på alle de resterende og se, hvordan rutevalget foregår inden for en AS. Når BGP-routeren modtager ruter fra naboen, starter udvælgelsen af den optimale rute. Her skal man forstå, hvad slags naboer der kan være — interne og eksterne. Routeren forstår ud fra konfigurationen, om den konfigurerede nabo er intern eller ekstern? Hvis i kommandoen:
neighbor 192.168.13.3 remote-as 10 Som parameter er remote-as angivet AS, som er konfigureret på selve routeren i kommandoen router bgp 10. Ruter, der kommer fra et internt AS, betragtes som interne, mens ruter fra eksterne AS betragtes som eksterne. Og der anvendes forskellige logikker til at hente og sende i forhold til hver af dem. Lad os se på følgende topologi:
På hver router er der konfigureret en loopback-interface med ip: x.x.x.x 255.255.255.0 — hvor x er nummeret på routeren. På Router9 har vi en loopback-interface med adressen — 9.9.9.9 255.255.255.0. Denne vil vi annoncere via BGP og se, hvordan den spredes. Denne rute vil blive sendt til Router8 og Router12. Fra Router8 vil denne rute komme til Router6, men den vil ikke være tilgængelig på Router5's routingtabel. Ligeledes vil denne rute komme ind i tabellen på Router12, men den vil også ikke være tilgængelig på Router11. Lad os finde ud af, hvad der sker. Lad os se på, hvilke data og parametre Router9 sender til sine naboer, når den meddelser denne rute. Pakken nedenfor vil blive sendt fra Router9 til Router8.
Informationen om ruten består af vejatributter (Path attributes).
Vejatributter er opdelt i 4 kategorier:
- Almindeligt kendte obligatoriske — alle routere, der arbejder med BGP-protokollen, skal genkende disse attributter. De skal være til stede i alle opdateringer (update).
- Almindeligt kendte valgfrie — alle routere, der arbejder med BGP-protokollen, skal genkende disse attributter. De kan være til stede i opdateringer (update), men det er ikke obligatorisk.
- Valgfri transitive — de behøver ikke at blive genkendt af alle BGP-implementeringer. Hvis en router ikke genkender en attribut, markerer den opdateringen som delvis (partial) og sender den videre til naboerne, idet den bevarer den ikke-genkendte attribut.
- Valgfri ikke-transitive — de behøver ikke at blive genkendt af alle BGP-implementeringer. Hvis en router ikke genkender en attribut, ignoreres attributten og kasseres ved overførsel til naboerne.
Eksempler på BGP-attributter:
- Almindeligt kendte obligatoriske:
- Autonomous system path
- Next-hop
- Origin
- Almindeligt kendte valgfrie:
- Local preference
- Atomic aggregate
- Valgfri transitive:
- Aggregator
- Communities
- Valgfri ikke-transitive:
- Multi-exit discriminator (MED)
- Originator ID
- Cluster list
I dette tilfælde vil vi primært fokusere på Origin, Next-hop, AS Path. Da ruten overføres mellem Router8 og Router9, som ligger inden for det samme AS, betragtes den som intern, og lad os derfor fokusere på Origin.
Attributten Origin — angiver, hvordan ruten blev modtaget i opdateringen. Mulige værdier for attributten:
- 0 — IGP: NLRI modtaget inden for det oprindelige autonome system;
- 1 — EGP: NLRI er læres gennem protokollen Exterior Gateway Protocol (EGP). Forløberen for BGP, som ikke længere anvendes.
- 2 — Incomplete: NLRI blev lært på en anden måde.
I vores tilfælde, som det ses fra pakken, er lig med 0. Når denne rute skal overføres til Router12, vil denne kode have koden — 1.
Derefter, Next-hop. Attributten Next-hop.
- Det er IP-adressen på eBGP-routeren, som vejen til destinationsnetværket går gennem.
- Attributten ændres, når præfikset overføres til en anden AS.
I tilfælde af iBGP, altså inden for samme AS, vil Next-hop være den, som opdagede eller rapporterede denne rute. I vores tilfælde vil det være 192.168.89.9. Men når denne rute overføres fra Router8 til Router6, vil Router8 ændre den og erstatte den med sin egen. Next-hop vil være — 192.168.68.8. Dette fører os til to regler:
- Hvis routeren overfører ruten til sin interne nabo, ændres Next-hop ikke.
- Hvis routeren overfører ruten til sin eksterne nabo, ændres Next-hop til IP-adressen på den grænseflade, som denne router overfører ruten fra.
Dette fører os til den første problemstilling — hvorfor der ikke vil være en rute i routingtabellen på Router5 og Router11. Lad os se nærmere på det. Så, Router6 modtog information om ruten 9.9.9.0/24 og tilføjede den succesfuldt til routingtabellen:
Router6#show ip route bgp
Koder: L - lokal, C - tilsluttet, S - statisk, R - RIP, M - mobil, B - BGP
D - EIGRP, EX - EIGRP ekstern, O - OSPF, IA - OSPF inter område
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 sammenfatning, L1 - IS-IS niveau-1, L2 - IS-IS niveau-2
ia - IS-IS inter område, * - kandidat standard, U - per-bruger statisk rute
o - ODR, P - periodisk downloadet statisk rute, H - NHRP, l - LISP
a - applikationsrute
+ - replikeret rute, % - næste hop overskrivning, p - overskrivninger fra PfR
Gateway for sidste resort er ikke indstillet
9.0.0.0/24 er subnettet, 1 subnet
B 9.9.9.0 [20/0] via 192.168.68.8, 00:38:25<source>
Nu har Router6 overført ruten til Router5, og den første regel Next-hop er ikke ændret. Det vil sige, Router5 skal tilføje <b>9.9.9.0 [20/0] via 192.168.68.8</b> , men den har ikke ruten til 192.168.68.8, og derfor vil denne rute ikke blive tilføjet, selvom informationen om denne rute vil blive opbevaret i BGP-tabellen:
<source><b>Router5#show ip bgp
BGP tabelversion er 1, lokal router ID er 5.5.5.5
Statuskoder: s undertrykt, d dæmpe, h historie, * gyldig, > bedst, i - intern,
r RIB-fejl, S Gammel, m multipath, b backup-sti, f RT-Filter,
x bedste-ekstern, a yderligere-sti, c RIB-komprimeret,
Oprindelseskoder: i - IGP, e - EGP, ? - ufuldstændig
RPKI valideringskoder: V gyldig, I ugyldig, N ikke fundet
Netværk Næste hop Metode LocPrf Vægt Sti
* i 9.9.9.0/24 192.168.68.8 0 100 0 45 i</b>Den samme situation vil ske mellem Router11-Router12. For at undgå en sådan situation er det nødvendigt at konfigurere, så Router6 eller Router12, når de overfører en rute til deres interne naboer, indsætter deres egen IP-adresse som Next-hop. Dette gøres med kommandoen:
neighbor 192.168.56.5 next-hop-selfEfter denne kommando vil Router6 sende en Update-besked, hvor IP-adressen på grænsefladen Gi0/0 Router6 — 192.168.56.6 angives som Next-hop for ruterne, hvorefter denne rute vil blive tilføjet til routingtabellen.
Lad os gå videre og se, om denne rute dukker op på Router7 og Router10. Den vil ikke findes i routingtabellen, og vi kunne have tænkt, at problemet var det samme som før med Next-hop, men hvis vi ser output fra kommandoen show ip bgp, vil vi se, at ruten ikke blev modtaget selv med en forkert Next-hop, hvilket betyder, at ruten endda ikke blev overført. Dette fører os til en anden regel:
Ruter, der er modtaget fra interne naboer, overføres ikke til andre interne naboer.
Da Router5 har modtaget en rute fra Router6, vil den ikke blive overført til sin anden interne nabo. For at overføre den er det nødvendigt at konfigurere funktionen , eller konfigurere fuldt koblede naboskaber (Full Mesh), hvilket betyder, at Router5-7 hver især vil være nabo til hinanden. I dette tilfælde vil vi bruge Route Reflector. På Router5 skal følgende kommando bruges:
neighbor 192.168.57.7 route-reflector-clientRoute Reflector ændrer BGP's adfærd ved overførsel af ruten til en intern nabo. Hvis den interne nabo er angivet som route-reflector-client, vil disse klienter få annonceret interne ruter.
Er ruten ikke dukket op på Router7? Glem ikke også Next-hop. Efter disse manipulationer skal ruten også være på Router7, men det sker ikke. Dette bringer os til en anden regel:
Next-hop reglen gælder kun for eksterne ruter. For interne ruter sker der ingen ændring af next-hop attributten.
Og vi havner i en situation, hvor det er nødvendigt at oprette et miljø ved hjælp af statisk routning eller IGP-protokoller informere routerne om alle ruter inden for AS. Vi vil skrive statiske ruter på Router6 og Router7, og derefter få den ønskede rute i routerens tabel. I AS 678 vil vi dog gøre lidt anderledes — vi vil skrive statiske ruter for 192.168.112.0/24 på Router10 og 192.168.110.0/24 på Router12. Dernæst vil vi etablere naboskaber mellem Router10 og Router12. Vi vil også konfigurere Router12 til at sende sin next-hop til Router10:
neighbor 192.168.110.10 next-hop-selfResultatet vil være, at Router10 vil modtage ruten 9.9.9.0/24, som vil blive modtaget både fra Router7 og Router12. Lad os se, hvilket valg Router10 vil træffe:
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, er der to ruter, og arrowen ( > ) indikerer, at ruten gennem 192.168.112.12 er valgt.
Lad os se, hvordan rutevalgsprocessen foregår:
- Først og fremmest, når ruten modtages, kontrolleres tilgængeligheden af dens Next-hop. Derfor blev ruten på Router5 ikke vidergivet til behandling uden konfiguration af Next-hop-self.
- Næste parameter er Weight. Denne parameter er ikke en Path Attribute (PA) og overføres ikke i BGP-meldinger. Den konfigureres lokalt på hver router og bruges kun til at manipulere rutevalget på selve routeren. Lad os se på et eksempel. Lidt tidligere blev det vist, at Router10 valgte ruten til 9.9.9.0/24 via Router12 (192.168.112.12). For at ændre Weight-parameteren kan man bruge route-map til at angive for bestemte ruter, eller tildele naboen en vægt ved hjælp af kommandoen:
neighbor 192.168.107.7 weight 200Nu vil alle ruter fra denne nabo have denne vægt. Lad os se, hvordan rutevalget ændres efter denne manipulation:
Router10#show bgp *Mar 2 11:58:13.956: %SYS-5-CONFIG_I: Konfigureret fra konsol af konsol BGP-tabelversion er 2, lokal router-ID er 6.6.6.6 Statuskoder: 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 koder: i - IGP, e - EGP, ? - incomplete RPKI valideringskoder: V valid, I invalid, N Not found Netværk Næste 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 kan se, er ruten nu valgt gennem Router7, men dette vil ikke have nogen effekt på de andre routere.
- På tredje position har vi - Local Preference. Denne parameter er en Well-known discretionary attribute, hvilket betyder, at dens tilstedeværelse ikke er obligatorisk. Denne parameter har kraft kun inden for én AS og påvirker rutevalget kun for interne naboer. Derfor overføres den kun i Update-beskeder beregnet til interne naboer. I Update-meldinger for eksterne naboer er den fraværende. Derfor er den blevet klassificeret som Well-known discretionary. Lad os forsøge at anvende den på Router5. På Router5 skal vi have to ruter til 9.9.9.0/24 - en gennem Router6 og den anden gennem Router7.
Lad os se:
Router5#show bgp BGP-tabelversion er 2, lokal router-ID er 5.5.5.5 Statuskoder: 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 koder: i - IGP, e - EGP, ? - incomplete RPKI valideringskoder: V valid, I invalid, N Not found Netværk Næste Hop Metric LocPrf Weight Path * >i 9.9.9.0/24 192.168.56.6 0 100 0 45 iMen som vi kan se, er der én rute gennem Router6. Hvor er ruten gennem Router7? Måske er den ikke på Router7? Lad os se:
Router#show bgp BGP-tabelversion er 10, lokal router-ID er 7.7.7.7 Statuskoder: s undertrykt, d dæmpet, h historik, * gyldig, > bedst, i - intern, r RIB-fejl, S forældet, m multipath, b backup-path, f RT-Filter, x bedst-ekstern, a yderligere-sti, c RIB-komprimeret, Oprindelseskoder: i - IGP, e - EGP, ? - ufuldstændig RPKI valideringskoder: V gyldig, I ugyldig, N Ikke fundet Netværk Næste hop Metrik LocPrf Vægt Sti * >i 9.9.9.0/24 192.168.56.6 0 100 0 45 i 192.168.107.10 0 678 45 iMærkeligt, alt ser ud til at være i orden. Hvorfor bliver det ikke sendt til Router5? Det hele handler om, at BGP har en regel:
Routeren sender kun de ruter, som den selv bruger.
Router7 bruger ruten gennem Router5, derfor vil ruten gennem Router10 ikke blive sendt. Lad os vende tilbage til Local Preference. Lad os sætte Local Preference på Router7 og se, hvordan Router5 reagerer:
route-map BGP tillad 10 match ip adresse 10 set local-præference 250 access-list 10 tillad enhver router bgp 123 nabo 192.168.107.10 route-map BGP ind</b>Så, vi har oprettet en route-map, der fanger alle ruter og har sagt til Router7, at når den modtager, skal den ændre parameteren Local Preference til 250, som som standard er 100. Lad os se, hvad der skete på Router5:
Router5#show bgp BGP-tabelversion er 8, lokal router-ID er 5.5.5.5 Statuskoder: s undertrykt, d dæmpet, h historik, * gyldig, > bedst, i - intern, r RIB-fejl, S forældet, m multipath, b backup-path, f RT-Filter, x bedst-ekstern, a yderligere-sti, c RIB-komprimeret, Oprindelseskoder: i - IGP, e - EGP, ? - ufuldstændig RPKI valideringskoder: V gyldig, I ugyldig, N Ikke fundet Netværk Næste hop Metrik LocPrf Vægt Sti * >i 9.9.9.0/24 192.168.57.7 0 250 0 678 45 iSom vi kan se, foretrækker Router5 nu ruten gennem Router7. Den samme situation vil gælde for Router6, selvom det ville være mere fordelagtigt for den at vælge ruten gennem Router8. Lad os også tilføje, at ændringen af denne parameter kræver genstart af naboen, for at ændringen træder i kraft. Læs . Vi har forstået Local Preference. Lad os gå videre til den næste parameter.
- Præferencen for ruten med parameteren Next-hop 0.0.0.0, det vil sige lokale eller aggregerede ruter. Disse ruter tildeles automatisk efter indtastning af kommandoen network parameteren Weight lig med maksimalt - 32678:
Router#show bgp BGP-tabelversion er 2, lokal router-ID er 9.9.9.9 Statuskoder: s undertrykt, d dæmpet, h historik, * gyldig, > bedst, i - intern, r RIB-fejl, S forældet, m multipath, b backup-path, f RT-Filter, x bedst-ekstern, a yderligere-sti, c RIB-komprimeret, Oprindelseskoder: i - IGP, e - EGP, ? - ufuldstændig RPKI valideringskoder: V gyldig, I ugyldig, N Ikke fundet Netværk Næste hop Metrik LocPrf Vægt Sti * > 9.9.9.0/24 0.0.0.0 0 32768 i - Den korteste vej gennem AS. Den korteste parameter AS_Path vælges. Jo færre AS ruten passerer gennem, jo bedre er den. Lad os se ruten til 9.9.9.0/24 på Router10:
Router10#show bgp BGP tabel version er 2, lokal router ID er 6.6.6.6 Statuskoder: s undertrykt, d dempet, h historie, * gyldig, > bedst, i - intern, r RIB-fejl, S forældet, m multipath, b backup-sti, f RT-Filter, x bedst-extern, a yderligere-sti, c RIB-komprimeret, Oprindelseskoder: i - IGP, e - EGP, ? - ufuldstændig RPKI valideringskoder: V gyldig, I ugyldig, N ikke fundet Netværk Næste Hop Metric LocPrf Vægt 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 gennem 192.168.112.12, fordi AS_Path parameteren for denne rute kun indeholder 45, mens den anden indeholder 123 og 45. Det er intuitivt forståeligt.
- Det næste parameter er Origin. IGP (ruten er opnået ved hjælp af BGP) er bedre end EGP (ruten er opnået ved hjælp af det forløbne BGP, som ikke længere er i brug), og EGP er bedre end Incomplete? (opnået på en anden måde, f.eks. gennem redistribuering).
- Det næste parameter er MED. Vi har haft Weight, som kun fungerede lokalt på routeren. Der var Local Preference, som kun fungerede inden for et autonomt system. Som forventet er MED et parameter, der vil blive overført mellem autonome systemer. Meget nyttigt. om dette parameter.
Flere attributter vil ikke blive brugt, men hvis to ruter har de samme, benyttes følgende regler:
- Vælg ruten gennem den nærmeste IGP-nabo.
- Vælg den ældste rute for eBGP-ruten.
- Vælg ruten gennem naboen med det mindste BGP router ID.
- Vælg ruten gennem naboen med den laveste IP-adresse.
Lad os nu se på spørgsmålet om BGP-konvergens.
Lad os se, hvad der sker, hvis Router6 mister ruten 9.9.9.0/24 gennem Router9. Vi slukker for Gi0/1-interface på Router6, som straks vil indse, at BGP-sessionen med Router8 er blevet afbrudt, og naboen er forsvundet, hvilket betyder, at ruten modtaget fra ham ikke er gyldig. Router6 sender straks Update-beskeder, hvori den angiver netværket 9.9.9.0/24 i feltet Withdrawn Routes. Så snart Router5 modtager en sådan besked, vil den sende den til Router7. Men da Router7 har en rute gennem Router10, vil den straks sende et Update med den nye rute som svar. Hvis det ikke er muligt at opdage naboens fald ved interface-tilstanden, er man nødt til at vente på, at Hold Timeren aktiveres.
Konfederation.
Hvis du husker, sagde vi, at vi ofte skal bruge en fuldt sammenkoblet topologi. Med mange routere i én AS kan dette skabe store problemer, og for at undgå dette er det nødvendigt at bruge konfederationer. Én AS opdeles i flere sub-AS, hvilket gør det muligt for dem at arbejde uden krav om fuldt sammenkoblet topologi.
Her er et link til denne , og konfiguration til GNS3.
For eksempel, med en sådan topologi ville vi skulle forbinde alle routere i AS 2345 med hinanden, men ved at bruge konfederation kan vi etablere naboskab kun mellem de routere, der er direkte forbundet. Lad os tale om dette i detaljer. Hvis vi kun havde AS 2345, så laForge ville have givet ruten fra Picard til hans routere Data og Worf, men de ville ikke have fortalt det til routeren Crusher . Desuden ville ruterne, som routeren selv annoncerer laForge, ikke blive overført Crusher eller Worftil -en, hverken Data.
Det ville være nødvendigt at konfigurere en Route-Reflector eller fuldt sammenkoblede naboskaber. Ved at opdele én AS 2345 i 4 sub-AS (2, 3, 4, 5) for hver router, ender vi med en anden logik til arbejdet. Alt er godt beskrevet .
Kilder:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- Webstedet
- Webstedet .
Kilde: habr.com
