I dag vil vi se på BGP-protokollen. Vi vil ikke tale i lang tid om, hvorfor det er, og hvorfor det bruges som den eneste protokol. Der er ret meget information om dette emne, f.eks .
Så hvad er BGP? BGP er en dynamisk routingprotokol og er den eneste EGP (External Gateway Protocol) protokol. Denne protokol bruges til at bygge routing på internettet. Lad os se på, hvordan et kvarter er bygget mellem to BGP-routere.
Overvej kvarteret mellem Router1 og Router3. Lad os konfigurere dem ved hjælp af 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 10Naboskab inden for et enkelt autonomt system er AS 10. Efter at have indtastet oplysninger på en router, såsom Router1, forsøger denne router at oprette et naboforhold til Router3. Starttilstanden, når der ikke sker noget, kaldes tomgang. Så snart bgp er konfigureret på Router1, begynder den at lytte til TCP-port 179 - den går i tilstanden Tilslut, og når den forsøger at åbne en session med Router3, går den ind i tilstanden Aktiv .
Efter sessionen er etableret mellem Router1 og Router3, udveksles åbne beskeder. Når denne besked sendes af Router1, kaldes denne tilstand Åbn Sendt. Og når den modtager en Åben besked fra Router3, vil den gå ind i tilstanden Åbn Bekræft. Lad os se nærmere på den åbne besked:
Denne besked formidler information om selve BGP-protokollen, som routeren bruger. Ved at udveksle åbne beskeder kommunikerer Router1 og Router3 information om deres indstillinger til hinanden. Følgende parametre er overført:
- Udgave: 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 sig frem til en kompatibel version, når der er en uoverensstemmelse, vil der ikke være nogen BGP-session.
- Mit AS: dette inkluderer AS-nummeret på BGP-routeren, routerne skal blive enige om AS-nummeret/-numrene, og det definerer også, om de skal køre iBGP eller eBGP.
- Hold tid: hvis BGP ikke modtager nogen keepalive eller opdatere beskeder fra den anden side i varigheden af ventetiden, vil den erklære den anden side 'død', og den vil rive BGP sessionen ned. Holdetiden er som standard indstillet til 180 sekunder på Cisco IOS-routere, keepalive-meddelelsen sendes hvert 60. sekund. Begge routere skal blive enige om ventetiden, ellers vil der ikke være en BGP-session.
- BGP-identifikator: dette er det lokale BGP-router-id, som er valgt ligesom OSPF gør:
- Brug router-id'et, der blev konfigureret manuelt med kommandoen bgp router-id.
- Brug den højeste IP-adresse på en loopback-grænseflade.
- Brug den højeste IP-adresse på en fysisk grænseflade.
- Valgfri parametre: her finder du nogle valgfrie muligheder for BGP-routeren. Dette felt er blevet tilføjet, så nye funktioner kan føjes til BGP uden at skulle oprette en ny version. Ting, du kan finde her, er:
- understøttelse af MP-BGP (Multi Protocol BGP).
- understøttelse af Route Refresh.
- understøttelse af 4-oktet AS-numre.
For at etablere et kvarter skal følgende betingelser være opfyldt:
- Versionsnummer. Den nuværende version er 4.
- AS-nummeret skal svare til det, du har konfigureret nabo 192.168.13.3 fjernbetjening-som 10.
- Router-id skal være forskellig fra naboen.
Hvis nogen af parametrene ikke opfylder disse betingelser, sender routeren Anmeldelse meddelelse, der angiver fejlen. Efter at have sendt og modtaget åbne beskeder går naboforholdet ind i staten NEDSAT. Herefter kan routere udveksle information om ruter og gøre dette vha Opdatering Beskeder. Dette er opdateringsmeddelelsen sendt af Router1 til Router3:
Her kan du se netværkene rapporteret af Router1 og Path attributter, som er analoge med metrics. Vi vil tale om Sti-attributter mere detaljeret. Keepalive-beskeder sendes også inden for en TCP-session. De sendes som standard hvert 60. sekund. Dette er en Keepalive Timer. Hvis en Keepalive-besked ikke modtages under Hold-timeren, vil det betyde tab af kommunikation med naboen. Som standard er det lig med 180 sekunder.
Nyttigt tegn:
Det ser ud til, at vi har fundet ud af, hvordan routere transmitterer information til hinanden, lad os nu prøve at forstå logikken i BGP-protokollen.
For at annoncere en rute til BGP-tabellen, som i IGP-protokollerne, bruges netværkskommandoen, men driftslogikken er anderledes. Hvis IGP i IGP, efter at have specificeret ruten i netværkskommandoen, ser IGP på hvilke grænseflader der hører til dette undernet og inkluderer dem i dets tabel, så ser netværkskommandoen i BGP på routingtabellen og leder efter точное matcher ruten i netværkskommandoen. Hvis sådanne findes, vil disse ruter blive vist i BGP-tabellen.
Se efter en rute i routerens aktuelle IP-routingtabel, der nøjagtigt matcher parametrene for netværkskommandoen; hvis IP-ruten findes, skal du placere den tilsvarende NLRI i den lokale BGP-tabel.
Lad os nu hæve BGP til alle de resterende og se, hvordan ruten er valgt inden for et AS. Efter at BGP-routeren har modtaget ruter fra sin nabo, begynder den at vælge den optimale rute. Her skal du forstå, hvilken type naboer der kan være - interne og eksterne. Forstår routeren ved konfiguration, om den konfigurerede nabo er intern eller ekstern? Hvis på et hold:
neighbor 192.168.13.3 remote-as 10 parameteren remote-as specificerer AS, som er konfigureret på selve routeren i kommandoen router bgp 10. Ruter, der kommer fra det interne AS, betragtes som interne, og ruter fra det eksterne AS betragtes som eksterne. Og for hver af dem fungerer en anden logik med at modtage og sende. Overvej denne topologi:
Hver router har et loopback-interface konfigureret med ip: xxxx 255.255.255.0 - hvor x er routernummeret. På Router9 har vi et loopback-interface med adressen - 9.9.9.9 255.255.255.0. Vi vil annoncere det via BGP og se, hvordan det spreder sig. Denne rute vil blive transmitteret til Router8 og Router12. Fra Router8 vil denne rute gå til Router6, men til Router5 vil den ikke være i rutetabellen. Også på Router12 vil denne rute fremgå af tabellen, men på Router11 vil den heller ikke være der. Lad os prøve at finde ud af det. Lad os overveje, hvilke data og parametre Router9 sender til sine naboer og rapporterer denne rute. Pakken nedenfor vil blive sendt fra Router9 til Router8.
Ruteoplysninger består af stiattributter.
Stiattributter er opdelt i 4 kategorier:
- Velkendt obligatorisk - Alle routere, der kører BGP, skal genkende disse attributter. Skal være til stede i alle opdateringer.
- Velkendt skøn - Alle routere, der kører BGP, skal genkende disse attributter. De kan være til stede i opdateringer, men deres tilstedeværelse er ikke påkrævet.
- Valgfri transitiv - genkendes muligvis ikke af alle BGP-implementeringer. Hvis routeren ikke genkender attributten, markerer den opdateringen som delvis og videresender den til sine naboer og gemmer den ikke-genkendte attribut.
- Valgfri ikke-transitiv - genkendes muligvis ikke af alle BGP-implementeringer. Hvis routeren ikke genkender attributten, ignoreres attributten og kasseres, når den videregives til naboer.
Eksempler på BGP-attributter:
- Velkendt obligatorisk:
- Autonom systemvej
- Næste hop
- Oprindelse
- Velkendt skøn:
- Lokal præference
- Atomaggregat
- Valgfri transitiv:
- aggregator
- Fællesskaber
- Valgfri ikke-transitiv:
- Multi-exit diskriminator (MED)
- Ophavsmands-id
- Klyngeliste
I dette tilfælde vil vi indtil videre være interesserede i Origin, Next-hop, AS Path. Da ruten transmitterer mellem Router8 og Router9, det vil sige inden for et AS, betragtes den som intern, og vi vil være opmærksomme på Origin.
Oprindelsesattribut - angiver, hvordan ruten i opdateringen blev opnået. Mulige attributværdier:
- 0 - IGP: NLRI modtaget inden for det oprindelige autonome system;
- 1 - EGP: NLRI læres ved hjælp af Exterior Gateway Protocol (EGP). Forgænger til BGP, ikke brugt
- 2 - Ufuldstændig: NLRI blev lært på en anden måde
I vores tilfælde er det, som det kan ses af pakken, lig med 0. Når denne rute sendes til Router12, vil denne kode have en kode på 1.
Næste-hop. Næste-hop-attribut
- Dette er IP-adressen på eBGP-routeren, som stien til destinationsnetværket går igennem.
- Attributten ændres, når præfikset sendes til et andet AS.
I tilfælde af iBGP, det vil sige inden for et AS, vil Next-hop blive angivet af den, der lærte eller fortalte om 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. Næste hop vil være 192.168.68.8. Dette leder os til to regler:
- Hvis en router videresender en rute til sin interne nabo, ændrer den ikke Next-hop-parameteren.
- Hvis en router transmitterer en rute til sin eksterne nabo, ændrer den Next-hop til ip'en på den grænseflade, hvorfra denne router sender.
Dette får os til at forstå det første problem - hvorfor der ikke vil være nogen rute i routingtabellen på Router5 og Router11. Lad os se nærmere. Så Router6 modtog information om rute 9.9.9.0/24 og tilføjede den med succes til routingtabellen:
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 situation vil ske mellem Router11-Router12. For at undgå denne situation skal du konfigurere Router6 eller Router12, når ruten videregives til deres interne naboer, til at erstatte deres IP-adresse med Next-hop. Dette gøres ved hjælp af kommandoen:
neighbor 192.168.56.5 next-hop-selfEfter denne kommando vil Router6 sende en opdateringsmeddelelse, hvor ip'en af interface Gi0/0 Router6 vil blive angivet som Next-hop for ruter - 192.168.56.6, hvorefter denne rute allerede vil være inkluderet i routingtabellen.
Lad os gå videre og se, om denne rute vises på Router7 og Router10. Det vil ikke være i routingtabellen, og vi tror måske, at problemet er det samme som i det første med Next-hop-parameteren, men hvis vi ser på outputtet af kommandoen show ip bgp, vil vi se, at ruten blev ikke modtaget der, selv med det forkerte Next-hop, hvilket betyder, at ruten ikke engang blev transmitteret. Og dette vil føre os til eksistensen af en anden regel:
Ruter modtaget fra interne naboer forplantes ikke til andre interne naboer.
Da Router5 modtog ruten fra Router6, vil den ikke blive transmitteret til dens anden interne nabo. For at overførslen kan finde sted, skal du konfigurere funktionen , eller konfigurer fuldt forbundne naboskabsforhold (Full Mesh), det vil sige, at Router5-7 vil alle være naboer for alle. I dette tilfælde vil vi bruge Route Reflector. På Router5 skal du bruge denne kommando:
neighbor 192.168.57.7 route-reflector-clientRoute-Reflector ændrer adfærden for BGP, når en rute videresendes til en intern nabo. Hvis den indvendige nabo er angivet som rute-reflektor-klient, så vil interne ruter blive annonceret til disse kunder.
Ruten dukkede ikke op på Router7? Glem heller ikke Next-hop. Efter disse manipulationer skulle ruten også gå til Router7, men det sker ikke. Dette bringer os til en anden regel:
Næste-hop-reglen virker kun for eksterne ruter. For interne ruter erstattes næste-hop-attributten ikke.
Og vi får en situation, hvor det er nødvendigt at skabe et miljø ved hjælp af statisk routing eller IGP-protokoller for at informere routere om alle ruterne i AS. Lad os registrere statiske ruter på Router6 og Router7 og derefter får vi den ønskede rute i routertabellen. I AS 678 vil vi gøre det lidt anderledes - vi vil registrere statiske ruter for 192.168.112.0/24 på Router10 og 192.168.110.0/24 på Router12. Dernæst vil vi etablere naboskabsforholdet mellem Router10 og Router12. Vi vil også konfigurere Router12 til at sende dens næste hop til Router10:
neighbor 192.168.110.10 next-hop-selfResultatet bliver, at Router10 vil modtage rute 9.9.9.0/24, den vil blive modtaget fra både Router7 og Router12. Lad os se, hvilket valg Router10 træffer:
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 betyder to ruter og en pil (>) at ruten via 192.168.112.12 er valgt.
Lad os se, hvordan rutevalgsprocessen fungerer:
- Det første trin, når du modtager en rute, er at kontrollere tilgængeligheden af dens Next-hop. Det er derfor, da vi modtog en rute på Router5 uden at indstille Next-hop-self, blev denne rute ikke viderebehandlet.
- Dernæst kommer vægtparameteren. Denne parameter er ikke en Path Attribute (PA) og sendes ikke i BGP-meddelelser. Den er konfigureret lokalt på hver router og bruges kun til at manipulere rutevalg på selve routeren. Lad os se på et eksempel. Lige ovenfor kan du se, at Router10 har valgt en rute til 9.9.9.0/24 via Router12 (192.168.112.12). For at ændre parameteren Wiight kan du bruge rutekort til at indstille specifikke ruter eller tildele en vægt til naboen 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 valget af rute ændres efter denne manipulation:
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 kan se, er ruten gennem Router7 nu valgt, men det vil ikke have nogen effekt på de andre routere.
- I tredje position har vi lokal præference. Denne parameter er en velkendt skønsmæssig egenskab, hvilket betyder, at dens tilstedeværelse er valgfri. Denne parameter er kun gyldig inden for et AS og påvirker kun valget af sti for interne naboer. Derfor sendes det kun i opdateringsmeddelelser beregnet til den interne nabo. Det er ikke til stede i Opdater beskeder for eksterne naboer. Derfor blev det klassificeret som Velkendt skønsmæssigt. Lad os prøve at anvende det på Router5. På Router5 skulle vi have to ruter til 9.9.9.0/24 - en gennem Router6 og den anden gennem 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 en rute gennem Router6. Hvor er ruten gennem Router7? Måske har Router7 det heller ikke? Lad os 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 iMærkeligt, alt ser ud til at være i orden. Hvorfor sendes det ikke til Router5? Sagen er, at BGP har en regel:
Routeren sender kun de ruter, den bruger.
Router7 bruger en rute gennem Router5, så ruten gennem Router10 vil ikke blive transmitteret. Lad os vende tilbage til Lokal præference. Lad os indstille 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 oprettede et rutekort, der indeholder alle ruterne og fortalte Router7 at ændre parameteren Local Preference til 250, når den blev modtaget, standarden er 100. Lad os se, hvad der skete 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 nu foretrækker Router5 ruten gennem Router7. Det samme billede vil være på Router6, selvom det er mere rentabelt for ham at vælge en rute gennem Router8. Vi tilføjer også, at ændring af denne parameter kræver en genstart af nabolaget, før ændringen træder i kraft. Læs . Vi har sorteret lokale præferencer fra. Lad os gå videre til næste parameter.
- Foretrække ruten med Next-hop-parameteren 0.0.0.0, det vil sige lokale eller aggregerede ruter. Disse ruter tildeles automatisk en vægtparameter svarende til maksimum - 32678 - efter indtastning af netværkskommandoen:
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 vej gennem AS. Den korteste AS_Path-parameter er valgt. Jo færre AS'er en rute går igennem, jo bedre er den. Overvej 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 AS_Path-parameteren for denne rute kun indeholder 45, og i et andet tilfælde 123 og 45. Intuitivt overskuelig.
- Den næste parameter er Origin. IGP (rute opnået ved hjælp af BGP) er bedre end EGP (rute opnået ved brug af BGP's forgænger, ikke længere i brug), og EGP er bedre end Incomplete? (opnået ved en anden metode, f.eks. ved omfordeling).
- Den næste parameter er MED. Vi havde Wiight som kun fungerede lokalt på routeren. Der var Local Preference, som kun fungerede inden for ét autonomt system. Som du måske kan gætte, er MED en parameter, der vil blive transmitteret mellem autonome systemer. Meget godt om denne parameter.
Der vil ikke blive brugt flere attributter, men hvis to ruter har de samme attributter, anvendes følgende regler:
- Vælg stien gennem den nærmeste IGP-nabo.
- Vælg den ældste rute for eBGP-stien.
- Vælg stien gennem naboen med det mindste BGP-router-id.
- Vælg en vej 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 rute 9.9.9.0/24 gennem Router9. Lad os deaktivere interface Gi0/1 af Router6, som straks vil forstå, at BGP-sessionen med Router8 er blevet afsluttet, og naboen er forsvundet, hvilket betyder, at ruten modtaget fra den ikke er gyldig. Router6 sender straks opdateringsbeskeder, hvor den angiver netværket 9.9.9.0/24 i feltet Tilbagetrukket ruter. 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 reagere med en opdatering med en ny rute. Hvis det ikke er muligt at registrere en nabos fald baseret på grænsefladens tilstand, så bliver du nødt til at vente på, at Hold-timeren udløses.
Konføderation.
Hvis du husker det, talte vi om, at du ofte skal bruge en fuldt forbundet topologi. Med et stort antal routere i et AS kan dette give store problemer, for at undgå dette skal du bruge konføderationer. Ét AS er opdelt i flere sub-AS, hvilket giver dem mulighed for at fungere uden krav om en fuldt forbundet topologi.
Her er et link til dette Og konfiguration til GNS3.
For eksempel, med denne topologi ville vi være nødt til at forbinde alle routere i AS 2345 til hinanden, men ved at bruge Confederation kan vi kun etablere naboforhold mellem routere, der er direkte forbundet med hinanden. Lad os tale om dette i detaljer. Hvis vi kun havde AS 2345, så laForge have modtaget en march fra Picard ville fortælle det til routerne data и Worf, men de ville ikke fortælle routeren om det Crusher . Også ruter distribueret af routeren selv laForge, ville ikke være blevet overført Crusher eller Worf-Åh nej data.
Du skal konfigurere en rutereflektor eller et fuldt forbundet naboskabsforhold. Ved at opdele én AS 2345 i 4 sub-AS (2,3,4,5) for hver router, ender vi med en anden driftslogik. Alt er perfekt beskrevet .
Kilder:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- Site
- Site .
Kilde: www.habr.com