Vandaag bespreken we het BGP-protocol. We zullen niet te lang stilstaan bij de vraag waarom het wordt gebruikt als het enige protocol. Er is genoeg informatie over beschikbaar, bijvoorbeeld .
Dus, wat is BGP? BGP is een dynamisch routeringsprotocol en is het enige EGP (External Gateway Protocol) protocol. Dit protocol wordt gebruikt voor het opzetten van routering op het internet. Laten we bekijken hoe de burenrelatie tussen twee BGP-routers wordt opgebouwd.
Laten we de burenrelatie tussen Router1 en Router3 bekijken. We configureren ze met de volgende commando's:
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 10Burenrelatie binnen één autonoom systeem — AS 10. Nadat de gegevens op de router zijn ingevoerd, bijvoorbeeld op Router1, probeert deze router de burenrelatie met router Router3 in te stellen. De beginstatus, wanneer er niets gebeurt, wordt genoemd Idle. Zodra BGP op Router1 is ingesteld, begint hij te luisteren naar TCP-poort 179 — hij zal overgaan naar de status Verbinden, en wanneer hij probeert een sessie met Router3 te openen, zal hij overgaan naar de status Actief.
Nadat de sessie tussen Router1 en Router3 is opgezet, vindt er een uitwisseling van Open-berichten plaats. Wanneer dit bericht door Router1 wordt verzonden, wordt deze status genoemd Open Sent. En wanneer het Open-bericht van Router3 wordt ontvangen, dan zal het overgaan naar de status Open Confirm. Laten we het Open-bericht meer in detail bekijken:
In dit bericht wordt informatie over het BGP-protocol dat door de router wordt gebruikt, verzonden. Door Open-berichten uit te wisselen, geven Router1 en Router3 elkaar informatie over hun configuraties. De volgende parameters worden verzonden:
- Versie: dit omvat de BGP-versie die de router gebruikt. De huidige versie van BGP is versie 4, zoals beschreven in RFC 4271. Twee BGP-routers zullen proberen een compatibele versie te onderhandelen; als er een mismatch is, zal er geen BGP-sessie zijn.
- Mijn AS: dit is het AS-nummer van de BGP-router, de routers moeten het AS-nummer(s) overeenkomen en het definieert ook of ze iBGP of eBGP gaan draaien.
- Hold Time: als BGP geen keepalive- of updateberichten van de andere kant ontvangt gedurende de hold-tijd, zal het de andere kant 'dood' verklaren en de BGP-sessie beëindigen. Standaard is de hold-tijd ingesteld op 180 seconden op Cisco IOS-routers; het keepalive-bericht wordt elke 60 seconden verzonden. Beide routers moeten het eens zijn over de hold-tijd, anders is er geen BGP-sessie.
- BGP Identifier: dit is de lokale BGP-router-ID die wordt gekozen zoals dit ook bij OSPF gebeurt:
- Gebruik de router-ID die handmatig is geconfigureerd met het bgp router-id-commando.
- Gebruik het hoogste IP-adres op een loopback-interface.
- Gebruik het hoogste IP-adres op een fysieke interface.
- Optionele Parameters: hier vind je enkele optionele mogelijkheden van de BGP-router. Dit veld is toegevoegd zodat nieuwe functies aan BGP kunnen worden toegevoegd zonder een nieuwe versie te hoeven maken. Dingen die je hier zou kunnen vinden zijn:
- ondersteuning voor MP-BGP (Multi Protocol BGP).
- ondersteuning voor Route Refresh.
- ondersteuning voor 4-octet AS-nummers.
Om een buurrelatie tot stand te brengen, moeten aan de volgende voorwaarden worden voldaan:
- Versienummer. De huidige versie is 4.
- Het AS-nummer moet overeenkomen met wat je hebt ingesteld. neighbor 192.168.13.3 remote-as 10.
- Router-ID moet anders zijn dan die van de buur.
Als een van deze parameters niet aan de voorwaarden voldoet, zal de router een Notification bericht sturen waarin de fout staat aangegeven. Na het verzenden en ontvangen van Open-berichten, gaat de buurrelatie naar de staat ESTABLISHED. Daarna kunnen de routers informatie over routes uitwisselen en doen dit via Bijwerken berichten. Zo'n Update-bericht stuurt Router1 naar Router3:
Hier worden de netwerken aangegeven waarover Router1 rapporteert en de Pad-attributen, die een equivalent zijn van metriek. Over Pad-attributen zullen we uitgebreider praten. Ook binnen de TCP-sessie worden Keepalive-berichten verzonden. Deze worden standaard elke 60 seconden verzonden. Dit is de Keepalive Timer. Als er tijdens de Hold Timer geen Keepalive-bericht wordt ontvangen, betekent dit dat de verbinding met de buur is verloren. Standaard is dit 180 seconden.
Nuttige tabel:
Het lijkt erop dat we begrijpen hoe routers informatie aan elkaar doorgeven, laten we nu proberen de logica van het BGP-protocol te begrijpen.
Om een route aan te kondigen in de BGP-tabel, wordt net als in IGP-protocollen het commando network gebruikt, maar de logica werkt anders. In IGP, na het opgeven van de route in het commando network, kijkt IGP welke interfaces tot dit subnet behoren en voegt deze toe aan zijn tabel, terwijl het commando network in BGP kijkt in de routeringtabel en zoekt naar een exacte overeenkomst met de route in het commando network. Bij het vinden van dergelijke routes, worden deze toegevoegd aan de BGP-tabel.
Zoek naar een route in de huidige IP-routeringtabel van de router die exact overeenkomt met de parameters van het netwerkcommando; als de IP-route bestaat, voeg de equivalente NLRI toe aan de lokale BGP-tabel.
Laten we nu BGP op alle resterende activeren en kijken hoe de routerselectie binnen een AS plaatsvindt. Nadat de BGP-router routes van de buur heeft ontvangen, begint de selectie van de optimale route. Hier moet je begrijpen wat voor soort buren er kunnen zijn - interne en externe. De router begrijpt op basis van de configuratie of de geconfigureerde buur intern of extern is. Als in het commando:
neighbor 192.168.13.3 remote-as 10 Als parameter remote-as is AS opgegeven, dat is geconfigureerd op de router in de opdracht router bgp 10. Routes die uit een interne AS komen, worden als intern beschouwd, terwijl routes uit externe AS's als extern worden gezien. Ten aanzien van elk werkt er een andere logica voor het ontvangen en verzenden. Laten we zo'n topologie bekijken:
Op elke router is een loopback-interface ingesteld met ip: x.x.x.x 255.255.255.0 — waar x het nummer van de router is. Op Router9 hebben we een loopback-interface met het adres — 9.9.9.9 255.255.255.0. Deze zullen we aankondigen via BGP en bekijken hoe deze zich verspreidt. Deze route zal worden doorgegeven aan Router8 en Router12. Van Router8 komt deze route op Router6, maar op Router5 zal deze niet in de routetabel staan. Evenzo zal deze route op Router12 de tabel bereiken, maar op Router11 zal deze ook niet zijn. Laten we hier eens naar kijken. Laten we onderzoeken welke gegevens en parameters Router9 naar zijn buren verzendt om deze route aan te geven. Het onderstaande pakket zal van Router9 naar Router8 worden verzonden.
Informatie over de route bestaat uit padattributen (Path attributes).
Padattributen zijn onderverdeeld in 4 categorieën:
- Well-known mandatory — alle routers die werken volgens het BGP-protocol moeten deze attributen herkennen. Ze moeten aanwezig zijn in alle updates.
- Well-known discretionary — alle routers die werken volgens het BGP-protocol moeten deze attributen herkennen. Ze kunnen aanwezig zijn in updates, maar hun aanwezigheid is niet verplicht.
- Optional transitive — hoeven niet door alle BGP-implementaties te worden herkend. Als een router het attribuut niet herkent, markeert deze de update als partieel (partial) en verzendt deze verder naar buren, waarbij het niet-herkende attribuut behouden blijft.
- Optional non-transitive — hoeven niet door alle BGP-implementaties te worden herkend. Als een router het attribuut niet herkent, wordt het attribuut genegeerd en bij het doorsturen naar buren weggelaten.
Voorbeelden van BGP-attributen:
- 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
In dit geval zijn we voorlopig geïnteresseerd in Origin, Next-hop, AS Path. Aangezien de route tussen Router8 en Router9 wordt overgedragen, dat wil zeggen binnen dezelfde AS, wordt deze als intern beschouwd en we zullen ons richten op Origin.
Attribuut Origin — geeft aan op welke manier de route in de update is verkregen. Mogelijke waarden van het attribuut zijn:
- 0 — IGP: NLRI is verkregen binnen de oorspronkelijke autonome systeem;
- 1 — EGP: NLRI is geleerd via het Exterior Gateway Protocol (EGP). Dit is de voorganger van BGP en wordt niet meer gebruikt.
- 2 — Incomplete: NLRI is op een andere manier geleerd.
In ons geval, zoals te zien is, is de waarde 0. Wanneer deze route aan Router12 wordt doorgegeven, zal de code 1 hebben.
Vervolgens, Next-hop. Attribuut Next-hop.
- Dit is het IP-adres van de eBGP-router waarmee je naar het bestemmingsnetwerk gaat.
- Het attribuut verandert wanneer de prefix naar een andere AS wordt overgedragen.
In het geval van iBGP, dat wil zeggen binnen één AS, zal Next-hop degene zijn die deze route heeft geleerd of verteld. In ons geval is dit 192.168.89.9. Maar wanneer deze route van Router8 naar Router6 wordt doorgegeven, zal Router8 het wijzigen en vervangen door zijn eigen adres. Next-hop wordt dan 192.168.68.8. Dit leidt ons tot twee regels:
- Als de router de route aan zijn interne buur doorgeeft, verandert hij de parameter Next-hop niet.
- Als de router de route aan zijn externe buur doorgeeft, verandert hij Next-hop naar het IP-adres van de interface waarlangs deze router de route doorgeeft.
Dit leidt ons naar het begrip van het eerste probleem — waarom er geen route in de routeringstabel van Router5 en Router11 zal zijn. Laten we dit in detail bekijken. Router6 ontving informatie over de route 9.9.9.0/24 en voegde deze succesvol toe aan de routeringstabel:
Router6#show ip route bgp
Codes: L - lokaal, C - verbonden, S - statisch, R - RIP, M - mobiel, B - BGP
D - EIGRP, EX - EIGRP extern, O - OSPF, IA - OSPF inter gebied
N1 - OSPF NSSA extern type 1, N2 - OSPF NSSA extern type 2
E1 - OSPF extern type 1, E2 - OSPF extern type 2
i - IS-IS, su - IS-IS samenvatting, L1 - IS-IS niveau-1, L2 - IS-IS niveau-2
ia - IS-IS inter gebied, * - kandidaat standaard, U - per gebruiker statische route
o - ODR, P - periodiek gedownloade statische route, H - NHRP, l - LISP
a - applicatieroute
+ - gerepliceerde route, % - volgende hop overschrijven, p - overschrijvingen van PfR
Gateway van laatste redmiddel is niet ingesteld
9.0.0.0/24 is subnetted, 1 subnetten
B 9.9.9.0 [20/0] via 192.168.68.8, 00:38:25<source>
Nu heeft Router6 de route naar Router5 doorgegeven en heeft de eerste Next-hop regel niet gewijzigd. Dat wil zeggen dat Router5 moet toevoegen <b>9.9.9.0 [20/0] via 192.168.68.8</b> , maar hij heeft geen route naar 192.168.68.8 en daarom zal deze route niet worden toegevoegd, hoewel de informatie over deze route in de BGP-tabel zal worden opgeslagen:
<source><b>Router5#show ip bgp
BGP-tabelversie is 1, lokale router ID is 5.5.5.5
Statuscodes: s onderdrukt, d gedempt, h geschiedenis, * geldig, > beste, i - intern,
r RIB-fout, S Achterstallig, m multipad, b reserve-pad, f RT-Filter,
x beste-extern, a aanvullende-pad, c RIB-gecomprimeerd,
Herkomstcodes: i - IGP, e - EGP, ? - incompleet
RPKI validatiecodes: V geldig, I ongeldig, N Niet gevonden
Netwerk Volgende Hop Metric LocPrf Gewicht Pad
* i 9.9.9.0/24 192.168.68.8 0 100 0 45 i</b>Eenzelfde situatie zal zich voordoen tussen Router11 en Router12. Om deze situatie te voorkomen, is het nodig om te configureren dat Router6 of Router12, wanneer zij routes aan hun interne buren doorgeven, hun eigen IP-adres als Next-hop invullen. Dit gebeurt met de volgende commando:
neighbor 192.168.56.5 next-hop-selfNa dit commando zal Router6 een Update-bericht verzenden, waarin voor de routes het IP-adres van de Gi0/0-interface van Router6 — 192.168.56.6 — als Next-hop wordt vermeld, waarna deze route in de routeringstabel zal komen.
Laten we verder gaan en kijken of deze route zichtbaar wordt op Router7 en Router10. Het zal niet in de routeringstabel verschijnen en we zouden kunnen denken dat het probleem zoals bij de eerste met de Next-hop parameter is, maar als we de uitvoer van de show ip bgp-commando bekijken, zullen we zien dat de route daar zelfs niet is ontvangen, zelfs niet met een verkeerde Next-hop, wat betekent dat de route zelfs niet is doorgegeven. Dit leidt ons naar het bestaan van nog een regel:
Routes die van interne buren zijn ontvangen, worden niet doorgegeven aan andere interne buren.
Aangezien Router5 een route van Router6 heeft ontvangen, zal deze niet aan zijn andere interne buur worden doorgegeven. Om de overdracht te laten plaatsvinden, moet de functie worden ingesteld. , of een volledige mesh-relatie tussen buren (Full Mesh) instellen, wat betekent dat Router5-7 elke buur van elkaar zal zijn. In dit geval zullen we gebruikmaken van de Route Reflector. Op Router5 moet deze opdracht worden gebruikt:
neighbor 192.168.57.7 route-reflector-clientDe Route Reflector verandert het gedrag van BGP bij het doorgeven van een route aan een interne buur. Als de interne buur is aangeduid als route-reflector-client, dan zullen deze clients interne routes worden aangekondigd.
Is de route niet verschenen op Router7? Vergeet ook de Next-hop niet. Na deze handelingen zou de route ook op Router7 moeten zijn, maar dit gebeurt niet. Dit brengt ons bij nog een regel:
De next-hop regel werkt alleen voor externe routes. Voor interne routes vindt er geen vervanging van het next-hop-attribuut plaats.
En we krijgen een situatie waarin het noodzakelijk is om een omgeving te creëren met statische routering of IGP-protocollen om routers te informeren over alle routes binnen het AS. We zullen statische routes op Router6 en Router7 instellen en daarna de gewenste route in de routertabel verkrijgen. In AS 678 zullen we het iets anders aanpakken — we stellen statische routes in voor 192.168.112.0/24 op Router10 en 192.168.110.0/24 op Router12. Vervolgens zullen we burenrelaties instellen tussen Router10 en Router12. Ook stellen we op Router12 de verzending van zijn own next-hop voor Router10 in:
neighbor 192.168.110.10 next-hop-selfHet resultaat zal zijn dat Router10 de route 9.9.9.0/24 zal ontvangen, deze zal zowel van Router7 als van Router12 komen. Laten we eens kijken welke keuze Router10 zal maken:
Router10#show ip bgp
BGP-tabelversie is 3, lokale router-ID is 6.6.6.6
Statuscodes: 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,
Oorsprongs codes: i - IGP, e - EGP, ? - incompleet
RPKI validatiecodes: V valid, I invalid, N Niet gevonden
Netwerk Next Hop Metric LocPrf Weight Pad
* >i 9.9.9.0/24 192.168.112.12 0 100 0 45 i
192.168.107.7 0 123 45 i Zoals we zien, zijn er twee routes en de pijl ( > ) betekent dat de route via 192.168.112.12 is geselecteerd.
Laten we eens kijken hoe het proces van het kiezen van een route verloopt:
- Bij het ontvangen van een route wordt als eerste gecontroleerd of de Next-hop beschikbaar is. Daarom, wanneer we de route op Router5 ontvingen zonder de Next-hop-self in te stellen, werd deze route verder niet doorgegeven voor verwerking.
- Daarna komt de parameter Weight. Deze parameter is geen padattribuut (PA) en wordt niet doorgestuurd in BGP-berichten. Hij wordt lokaal op elke router ingesteld en wordt alleen gebruikt voor het manipuleren van de routekeuze op diezelfde router. Laten we een voorbeeld bekijken. Hierboven is te zien dat Router10 de route voor 9.9.9.0/24 heeft gekozen via Router12 (192.168.112.12). Om de parameter Weight te wijzigen, kan een route-map worden gebruikt om deze voor bepaalde routes in te stellen, of zijn gewicht kan worden toegewezen aan de buur met het commando:
neighbor 192.168.107.7 weight 200Nu zullen alle routes van deze buur dat gewicht hebben. Laten we bekijken hoe de routekeuze verandert na deze manipulatie:
Router10#show bgp *Mar 2 11:58:13.956: %SYS-5-CONFIG_I: Geconfigureerd vanaf console door console BGP tabelversie is 2, lokale router-ID is 6.6.6.6 Statuscodes: 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 validatiecodes: V valid, I invalid, N Not found Netwerk Volgende Hop Metric LocPrf Weight Pad * > 9.9.9.0/24 192.168.107.7 200 123 45 i * i 192.168.112.12 0 100 0 45 iZoals je kunt zien, is de geselecteerde route nu via Router7, maar dit heeft geen effect op de andere routers.
- Op de derde positie hebben we — Local Preference. Deze parameter is een well-known discretionary attribuut, wat betekent dat aanwezigheid ervan niet verplicht is. Deze parameter heeft alleen kracht binnen één AS en beïnvloedt de keuze van de route alleen voor interne buren. Daarom wordt deze alleen verzonden in Update-berichten bedoeld voor interne buren. In Update-berichten voor externe buren ontbreekt hij. Daarom is hij geclassificeerd als well-known discretionary. Laten we proberen deze toe te passen op Router5. Op Router5 zouden we twee routes voor 9.9.9.0/24 moeten hebben — één via Router6 en de andere via Router7.
Laten we kijken:
Router5#show bgp BGP tabelversie is 2, lokale router-ID is 5.5.5.5 Statuscodes: 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 validatiecodes: V valid, I invalid, N Not found Netwerk Volgende Hop Metric LocPrf Weight Pad * >i 9.9.9.0/24 192.168.56.6 0 100 0 45 iMaar zoals we zien, is er één route via Router6. Waar is de route via Router7? Misschien is die ook niet op Router7?
Router#show bgp BGP-tabelversie is 10, lokale router ID is 7.7.7.7 Statuscodes: s onderdrukt, d gedempt, h geschiedenis, * geldig, > beste, i - intern, r RIB-fout, S Verouderd, m multipad, b back-up pad, f RT-Filter, x beste-externe, a aanvullende pad, c RIB-gecomprimeerd, Oorsprongscodes: i - IGP, e - EGP, ? - onvolledig RPKI validatiecodes: V geldig, I ongeldig, N Niet gevonden Netwerk Volgende Hop Metric LocPrf Gewicht Pad *>i 9.9.9.0/24 192.168.56.6 0 100 0 45 i 192.168.107.10 0 678 45 iVreemd, alles lijkt in orde. Waarom wordt het niet doorgegeven aan Router5? Het probleem is dat BGP een regel heeft:
De router geeft alleen de routes door die hij zelf gebruikt.
Router7 gebruikt de route via Router5, daarom wordt de route via Router10 niet doorgegeven. Laten we teruggaan naar Local Preference. Laten we Local Preference instellen op Router7 en kijken hoe Router5 hierop reageert:
route-map BGP toestaan 10 match ip adres 10 set lokale-voorkeur 250 toegangslijst 10 toestaan iedereen router bgp 123 buur 192.168.107.10 route-map BGP binnen</b>Dus, we hebben een route-map gemaakt die alle routes omvat en we hebben Router7 gezegd om bij ontvangst de parameter Local Preference op 250 te wijzigen, standaard is deze 100. Laten we kijken wat er is gebeurd op Router5:
Router5#show bgp BGP-tabelversie is 8, lokale router ID is 5.5.5.5 Statuscodes: s onderdrukt, d gedempt, h geschiedenis, * geldig, > beste, i - intern, r RIB-fout, S Verouderd, m multipad, b back-up pad, f RT-Filter, x beste-externe, a aanvullende pad, c RIB-gecomprimeerd, Oorsprongscodes: i - IGP, e - EGP, ? - onvolledig RPKI validatiecodes: V geldig, I ongeldig, N Niet gevonden Netwerk Volgende Hop Metric LocPrf Gewicht Pad *>i 9.9.9.0/24 192.168.57.7 0 250 0 678 45 iZoals we nu zien, geeft Router5 de voorkeur aan de route via Router7. Eenzelfde situatie zal ook op Router6 zijn, hoewel het voordeliger voor hem is om de route via Router8 te kiezen. We voegen ook toe dat het wijzigen van deze parameter een herstart van de buurrelatie vereist, zodat de wijziging effectief wordt. . We hebben het over Local Preference gehad. Laten we doorgaan naar de volgende parameter.
- De voorkeur van de route met de parameter Next-hop 0.0.0.0, dat wil zeggen lokale of geaggregeerde routes. Deze routes krijgen automatisch, na het invoeren van de opdracht network, de parameter Weight toegewezen, die maximaal is — 32678:
Router#show bgp BGP-tabelversie is 2, lokale router ID is 9.9.9.9 Statuscodes: s onderdrukt, d gedempt, h geschiedenis, * geldig, > beste, i - intern, r RIB-fout, S Verouderd, m multipad, b back-up pad, f RT-Filter, x beste-externe, a aanvullende pad, c RIB-gecomprimeerd, Oorsprongscodes: i - IGP, e - EGP, ? - onvolledig RPKI validatiecodes: V geldig, I ongeldig, N Niet gevonden Netwerk Volgende Hop Metric LocPrf Gewicht Pad *> 9.9.9.0/24 0.0.0.0 0 32768 i - De kortste route via AS. De kortste AS_Path parameter wordt gekozen. Hoe minder AS het pad doorloopt, hoe beter het is. Laten we de route naar 9.9.9.0/24 op Router10 bekijken:
Router10#show bgp BGP-tafelversie is 2, lokale router-ID is 6.6.6.6 Statuscodes: s onderdrukt, d gedempt, h historie, * geldig, > best, i - intern, r RIB-failure, S Stale, m multipad, b backup-pad, f RT-Filter, x best-external, a additional-path, c RIB-gecomprimeerd, Oorsprongcodes: i - IGP, e - EGP, ? - incompleet RPKI validatiecodes: V geldig, I ongeldig, N Niet gevonden Netwerk Volgende Hop Metric LocPrf Gewicht Pad * 9.9.9.0/24 192.168.107.7 0 123 45 i *>i 192.168.112.12 0 100 0 45 iZoals u kunt zien, heeft Router10 de route via 192.168.112.12 gekozen, omdat de AS_Path-parameter voor deze route alleen 45 bevat, terwijl in het andere geval 123 en 45 waren. Dit is intuïtief begrijpelijk.
- De volgende parameter is Origin. IGP (de route verkregen via BGP) is beter dan EGP (de route verkregen via de voorganger van BGP, die niet meer in gebruik is), en EGP is beter dan Incomplete? (verkregen op een andere manier, bijvoorbeeld herverdeling).
- De volgende parameter is MED. We hadden Weight, dat alleen lokaal op de router werkte. Er was Local Preference, dat alleen binnen één autonome systeem werkte. Zoals je kon raden, is MED een parameter die tussen autonome systemen wordt doorgegeven. Heel goed. over deze parameter.
Er zullen geen meer attributen worden gebruikt, maar als twee routes dezelfde hebben, worden de volgende regels gebruikt:
- Kies de pad via de dichtstbijzijnde IGP-buur.
- Kies de oudste route voor de eBGP-pad.
- Kies de pad via de buur met het laagste BGP-router ID.
- Kies de pad via de buur met het laagste IP-adres.
Laten we nu de kwestie van BGP-convergentie bekijken.
Laten we eens kijken wat er gebeurt als Router6 de route 9.9.9.0/24 verliest via Router9. We schakelen de interface Gi0/1 van Router6 uit, die meteen zal begrijpen dat de BGP-sessie met Router8 is verbroken en de buur verdwenen is, wat betekent dat de route die van hem is ontvangen ongeldig is. Router6 verzendt onmiddellijk Update-berichten, waarin het netwerk 9.9.9.0/24 in het veld Withdrawn Routes wordt opgegeven. Zodra Router5 zo'n bericht ontvangt, stuurt hij het door naar Router7. Maar omdat Router7 een route heeft via Router10, zal hij onmiddellijk een Update met de nieuwe route terugsturen. Als het detecteren van een buurverlies op basis van de status van de interface niet mogelijk is, moeten we wachten op de activering van de Hold Timer.
Confederatie.
Als je het je herinnert, hebben we het gehad over het feit dat we vaak een full-mesh topologie moeten gebruiken. Met een groot aantal routers in één AS kan dit problemen opleveren; om dit te vermijden, moeten we confederaties gebruiken. Eén AS wordt opgesplitst in meerdere sub-AS'en, wat het mogelijk maakt om zonder de vereiste full-mesh topologie te werken.
Hier is de link naar deze , met behulp van 1 bit, gelijk aan 0, configuratie voor GNS3.
Bijvoorbeeld, met een dergelijke topologie zouden we alle routers in AS 2345 met elkaar moeten verbinden, maar door Confederation te gebruiken, kunnen we alleen burenrelaties opzetten tussen routers die direct met elkaar zijn verbonden. Laten we dit in detail bespreken. Als we alleen AS 2345 hadden gehad, dan laForge zou de route ontvangen van Picard hem aan zijn routers vertellen Data en Worf, maar zij zouden het niet aan router Crusher . Evenzo, de routes die de router zelf verspreidt laForge, zouden niet doorgegeven zijn aan Crusher of Worf-en, noch aan Data.
We zouden een Route-Reflector of full-mesh burenrelaties moeten configureren. Door AS 2345 op te splitsen in 4 sub-AS'en (2, 3, 4, 5) voor elke router, krijgen we uiteindelijk een andere werkwijze. Alles is uitstekend beschreven .
Bronnen:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- Website
- Website .
Bron: habr.com
