Idag ska vi titta på BGP-protokollet. Vi kommer inte att prata länge om varför det är och varför det används som det enda protokollet. Det finns ganska mycket information om detta ämne, till exempel .
Så vad är BGP? BGP är ett dynamiskt routingprotokoll och är det enda EGP-protokollet (External Gateway Protocol). Detta protokoll används för att bygga routing på Internet. Låt oss titta på hur ett område är byggt mellan två BGP-routrar.
Tänk på grannskapet mellan Router1 och Router3. Låt oss konfigurera dem med följande kommandon:
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 10Grannskap inom ett enskilt autonomt system är AS 10. Efter att ha angett information om en router, såsom Router1, försöker den routern skapa en närliggande relation med Router3. Det initiala tillståndet när ingenting händer kallas Idle. Så fort bgp är konfigurerat på Router1 kommer den att börja lyssna på TCP-port 179 - den går in i tillståndet Kontakta, och när den försöker öppna en session med Router3, kommer den att gå in i tillståndet Aktiva.
Efter att sessionen har upprättats mellan Router1 och Router3 utbyts Öppna meddelanden. När detta meddelande skickas av Router1 kommer detta tillstånd att anropas Öppna Skickat. Och när den får ett Open-meddelande från Router3, kommer den att gå in i tillståndet Öppna Bekräfta. Låt oss ta en närmare titt på det öppna meddelandet:
Detta meddelande förmedlar information om själva BGP-protokollet som routern använder. Genom att utbyta Öppna meddelanden kommunicerar Router1 och Router3 information om sina inställningar till varandra. Följande parametrar skickas:
- version: detta inkluderar BGP-versionen som routern använder. Den aktuella versionen av BGP är version 4 som beskrivs i RFC 4271. Två BGP-routrar kommer att försöka förhandla fram en kompatibel version, när det finns en missmatchning blir det ingen BGP-session.
- Mitt AS: detta inkluderar AS-numret för BGP-routern, routrarna måste komma överens om AS-numren och det definierar också om de kommer att köra iBGP eller eBGP.
- Håll tid: om BGP inte tar emot några keepalive- eller uppdateringsmeddelanden från den andra sidan under hålltiden, kommer den att förklara den andra sidan "död" och den kommer att riva ner BGP-sessionen. Som standard är hålltiden inställd på 180 sekunder på Cisco IOS-routrar, keepalive-meddelandet skickas var 60:e sekund. Båda routrarna måste komma överens om hålltiden annars blir det ingen BGP-session.
- BGP-identifierare: detta är det lokala BGP-router-ID som väljs precis som OSPF gör:
- Använd router-ID som konfigurerades manuellt med kommandot bgp router-id.
- Använd den högsta IP-adressen på ett loopback-gränssnitt.
- Använd den högsta IP-adressen på ett fysiskt gränssnitt.
- Valfria parametrar: här hittar du några valfria funktioner för BGP-routern. Det här fältet har lagts till så att nya funktioner kan läggas till i BGP utan att behöva skapa en ny version. Saker du kan hitta här är:
- stöd för MP-BGP (Multi Protocol BGP).
- stöd för Route Refresh.
- stöd för 4-oktett AS-nummer.
För att etablera en stadsdel måste följande villkor vara uppfyllda:
- Versionsnummer. Den nuvarande versionen är 4.
- AS-numret måste matcha det du har konfigurerat granne 192.168.13.3 fjärr-som 10.
- Router-ID måste skilja sig från grannen.
Om någon av parametrarna inte uppfyller dessa villkor kommer routern att skicka Anmälan meddelande som indikerar felet. Efter att ha skickat och tagit emot Öppna meddelanden går grannskapsrelationen in i staten ETABLERADE. Efter detta kan routrar utbyta information om rutter och göra detta med hjälp av Uppdatering meddelanden. Detta är uppdateringsmeddelandet som skickas av Router1 till Router3:
Här kan du se nätverken som rapporteras av Router1 och Path-attribut, som är analoga med mätvärden. Vi kommer att prata om sökvägsattribut mer i detalj. Keepalive-meddelanden skickas också inom en TCP-session. De sänds som standard var 60:e sekund. Detta är en Keepalive Timer. Om ett Keepalive-meddelande inte tas emot under hålltimern kommer detta att innebära att kommunikationen med grannen förloras. Som standard är det lika med 180 sekunder.
Användbart tecken:
Det verkar som att vi har räknat ut hur routrar överför information till varandra, låt oss nu försöka förstå logiken i BGP-protokollet.
För att annonsera en rutt till BGP-tabellen, som i IGP-protokollen, används nätverkskommandot, men driftlogiken är annorlunda. Om i IGP, efter att ha angett rutten i nätverkskommandot, IGP tittar på vilka gränssnitt som hör till detta subnät och inkluderar dem i dess tabell, så tittar nätverkskommandot i BGP på routingtabellen och letar efter exakt matchar rutten i nätverkskommandot. Om sådana hittas kommer dessa rutter att visas i BGP-tabellen.
Leta efter en rutt i routerns aktuella IP-routingtabell som exakt matchar parametrarna för nätverkskommandot; om IP-rutten finns, placera motsvarande NLRI i den lokala BGP-tabellen.
Låt oss nu höja BGP till alla återstående och se hur rutten väljs inom ett AS. Efter att BGP-routern tagit emot rutter från sin granne, börjar den välja den optimala rutten. Här måste du förstå vilken typ av grannar det kan finnas - internt och externt. Förstår routern genom konfiguration om den konfigurerade grannen är intern eller extern? Om i ett lag:
neighbor 192.168.13.3 remote-as 10 parametern remote-as anger AS, som konfigureras på själva routern i routerns bgp 10-kommando. Rutter som kommer från det interna AS anses vara interna och rutter från det externa AS anses vara externa. Och för var och en fungerar en annan logik för att ta emot och skicka. Tänk på denna topologi:
Varje router har ett loopback-gränssnitt konfigurerat med ip: xxxx 255.255.255.0 - där x är routerns nummer. På Router9 har vi ett loopback-gränssnitt med adressen - 9.9.9.9 255.255.255.0. Vi kommer att meddela det via BGP och se hur det sprider sig. Denna rutt kommer att överföras till Router8 och Router12. Från Router8 kommer den här rutten att gå till Router6, men till Router5 kommer den inte att finnas i routingtabellen. Även på Router12 kommer denna rutt att visas i tabellen, men på Router11 kommer den inte att finnas där heller. Låt oss försöka reda ut det här. Låt oss överväga vilka data och parametrar Router9 sänder till sina grannar och rapporterar denna rutt. Paketet nedan kommer att skickas från Router9 till Router8.
Ruttinformation består av sökvägsattribut.
Sökvägsattribut är indelade i fyra kategorier:
- Välkänt obligatoriskt - Alla routrar som kör BGP måste känna igen dessa attribut. Måste finnas med i alla uppdateringar.
- Välkänd diskretionär - Alla routrar som kör BGP måste känna igen dessa attribut. De kan vara närvarande i uppdateringar, men deras närvaro krävs inte.
- Valfri transitiv - kanske inte känns igen av alla BGP-implementeringar. Om routern inte känner igen attributet, markerar den uppdateringen som partiell och vidarebefordrar den till sina grannar och lagrar det okända attributet.
- Valfri icke-transitiv - kanske inte känns igen av alla BGP-implementeringar. Om routern inte känner igen attributet ignoreras attributet och kasseras när det skickas vidare till grannar.
Exempel på BGP-attribut:
- Välkänt obligatoriskt:
- Autonom systemväg
- Nästa hopp
- Ursprung
- Välkänd diskretionär:
- Lokal preferens
- Atomaggregat
- Valfri transitiv:
- Aggregator
- samhällen
- Valfri icke-transitiv:
- Multi-exit diskriminator (MED)
- Upphovsman-ID
- Klusterlista
I det här fallet kommer vi för närvarande att vara intresserade av Origin, Next-hop, AS Path. Eftersom rutten sänder mellan Router8 och Router9, det vill säga inom ett AS, anses den vara intern och vi kommer att uppmärksamma Origin.
Ursprungsattribut - anger hur rutten i uppdateringen erhölls. Möjliga attributvärden:
- 0 - IGP: NLRI mottagits inom det ursprungliga autonoma systemet;
- 1 - EGP: NLRI lärs in med hjälp av Exterior Gateway Protocol (EGP). Föregångare till BGP, ej använd
- 2 - Ofullständig: NLRI lärdes in på något annat sätt
I vårt fall, som kan ses av paketet, är det lika med 0. När denna rutt sänds till Router12 kommer denna kod att ha koden 1.
Nästa, Next-hop. Next-hop-attribut
- Detta är IP-adressen för eBGP-routern genom vilken vägen till destinationsnätverket går.
- Attributet ändras när prefixet skickas till ett annat AS.
I fallet med iBGP, det vill säga inom ett AS, kommer Next-hop att indikeras av den som lärde sig eller berättade om denna rutt. I vårt fall blir det 192.168.89.9. Men när denna rutt sänds från Router8 till Router6 kommer Router8 att ändra den och ersätta den med sin egen. Nästa hopp blir 192.168.68.8. Detta leder oss till två regler:
- Om en router vidarebefordrar en rutt till sin interna granne, ändrar den inte Next-hop-parametern.
- Om en router sänder en rutt till sin externa granne, ändrar den Next-hop till ip-adressen för gränssnittet som denna router sänder från.
Detta leder till att vi förstår det första problemet - varför det inte kommer att finnas någon rutt i routingtabellen på Router5 och Router11. Låt oss ta en närmare titt. Så, Router6 fick information om rutt 9.9.9.0/24 och lade till den framgångsrikt i 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>Samma situation kommer att hända mellan Router11-Router12. För att undvika denna situation måste du konfigurera Router6 eller Router12, när du skickar rutten till sina interna grannar, för att ersätta deras IP-adress med Next-hop. Detta görs med kommandot:
neighbor 192.168.56.5 next-hop-selfEfter detta kommando kommer Router6 att skicka ett uppdateringsmeddelande, där ip:n för gränssnittet Gi0/0 Router6 kommer att anges som Next-hop för rutter - 192.168.56.6, varefter denna rutt redan kommer att inkluderas i routingtabellen.
Låt oss gå vidare och se om den här rutten visas på Router7 och Router10. Det kommer inte att finnas i routingtabellen och vi kanske tror att problemet är detsamma som i det första med Next-hop-parametern, men om vi tittar på utdata från kommandot show ip bgp kommer vi att se att rutten togs inte emot där även med fel Next-hop, vilket betyder att rutten inte ens sändes. Och detta kommer att leda oss till existensen av en annan regel:
Rutter som tas emot från interna grannar sprids inte till andra interna grannar.
Eftersom Router5 tog emot rutten från Router6 kommer den inte att överföras till sin andra interna granne. För att överföringen ska kunna ske måste du konfigurera funktionen , eller konfigurera helt anslutna grannskapsrelationer (Full Mesh), det vill säga Router5-7 kommer alla att vara granne med alla. I det här fallet kommer vi att använda Route Reflector. På Router5 måste du använda detta kommando:
neighbor 192.168.57.7 route-reflector-clientRoute-Reflector ändrar beteendet hos BGP när den passerar en rutt till en intern granne. Om den inre granne anges som rutt-reflektor-klient, kommer interna rutter att annonseras för dessa kunder.
Rutten syntes inte på Router7? Glöm inte heller Next-hop. Efter dessa manipulationer ska rutten också gå till Router7, men detta händer inte. Detta för oss till en annan regel:
Next-hop-regeln fungerar bara för externa rutter. För interna rutter ersätts inte next-hop-attributet.
Och vi får en situation där det är nödvändigt att skapa en miljö med statisk routing eller IGP-protokoll för att informera routrar om alla rutter inom AS. Låt oss registrera statiska rutter på Router6 och Router7 och efter det kommer vi att få önskad rutt i routertabellen. I AS 678 kommer vi att göra det lite annorlunda - vi kommer att registrera statiska rutter för 192.168.112.0/24 på Router10 och 192.168.110.0/24 på Router12. Därefter kommer vi att fastställa grannskapsrelationen mellan Router10 och Router12. Vi kommer också att konfigurera Router12 för att skicka nästa hopp till Router10:
neighbor 192.168.110.10 next-hop-selfResultatet blir att Router10 kommer att få rutt 9.9.9.0/24, den kommer att tas emot från både Router7 och Router12. Låt oss se vilket val Router10 gö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 betyder två rutter och en pil (>) att rutten via 192.168.112.12 är vald.
Låt oss se hur vägvalsprocessen fungerar:
- Det första steget när du tar emot en rutt är att kontrollera tillgängligheten för dess Next-hop. Det är därför, när vi fick en rutt på Router5 utan att ställa in Next-hop-self, bearbetades inte denna rutt ytterligare.
- Därefter kommer viktparametern. Den här parametern är inte ett sökvägsattribut (PA) och skickas inte i BGP-meddelanden. Den konfigureras lokalt på varje router och används endast för att manipulera ruttval på själva routern. Låt oss titta på ett exempel. Strax ovanför kan du se att Router10 har valt en rutt för 9.9.9.0/24 via Router12 (192.168.112.12). För att ändra parametern Weight kan du använda ruttkarta för att ställa in specifika rutter, eller tilldela en vikt till sin granne med kommandot:
neighbor 192.168.107.7 weight 200Nu kommer alla rutter från denna granne att ha denna vikt. Låt oss se hur valet av rutt ändras efter denna 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 är rutten genom Router7 nu vald, men detta kommer inte att ha någon effekt på de andra routrarna.
- På tredje plats har vi Local Preference. Denna parameter är ett välkänt diskretionärt attribut, vilket betyder att dess närvaro är valfri. Denna parameter är endast giltig inom ett AS och påverkar valet av väg endast för interna grannar. Det är därför det bara sänds i Uppdatera meddelanden avsedda för den interna grannen. Det finns inte i Uppdatera meddelanden för externa grannar. Därför klassades den som välkänd diskretionär. Låt oss försöka använda det på Router5. På Router5 bör vi ha två rutter för 9.9.9.0/24 - en genom Router6 och den andra genom 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 rutt genom Router6. Var är rutten genom Router7? Kanske inte Router7 har det heller? Vi kollar:
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 iKonstigt, allt verkar vara bra. Varför överförs det inte till Router5? Saken är att BGP har en regel:
Routern sänder endast de rutter som den använder.
Router7 använder en rutt genom Router5, så rutten genom Router10 kommer inte att sändas. Låt oss återgå till Lokala preferenser. Låt oss ställa in Local Preference på Router7 och se hur Router5 reagerar på detta:
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 skapade en ruttkarta som innehåller alla rutter och sa till Router7 att ändra parametern Local Preference till 250 när den tas emot, standard är 100. Låt oss se vad som hände 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 föredrar Router5 rutten genom Router7. Samma bild kommer att finnas på Router6, även om det är mer lönsamt för honom att välja en rutt genom Router8. Vi tillägger också att ändring av denna parameter kräver en omstart av grannskapet för att ändringen ska träda i kraft. Läsa . Vi har sorterat ut lokala preferenser. Låt oss gå vidare till nästa parameter.
- Föredra rutten med Next-hop-parametern 0.0.0.0, det vill säga lokala eller aggregerade rutter. Dessa rutter tilldelas automatiskt en viktparameter lika med maximum—32678—efter att ha angett nätverkskommandot:
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 - Kortaste vägen genom AS. Den kortaste AS_Path-parametern är vald. Ju färre AS en rutt går igenom, desto bättre är den. Tänk på rutten till 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 valde Router10 rutten via 192.168.112.12 eftersom AS_Path-parametern endast innehåller 45 och i ett annat fall 123 och 45 för denna rutt. Intuitivt tydlig.
- Nästa parameter är Ursprung. IGP (rutt erhållen med BGP) är bättre än EGP (rutt erhållen med BGPs föregångare, används inte längre), och EGP är bättre än Incomplete? (erhållen med någon annan metod, till exempel genom omfördelning).
- Nästa parameter är MED. Vi hade Wiight som bara fungerade lokalt på routern. Det fanns Local Preference, som bara fungerade inom ett autonomt system. Som du kanske kan gissa är MED en parameter som kommer att överföras mellan autonoma system. Mycket bra om denna parameter.
Inga fler attribut kommer att användas, men om två rutter har samma attribut används följande regler:
- Välj vägen genom närmaste IGP-granne.
- Välj den äldsta rutten för eBGP-sökvägen.
- Välj vägen genom grannen med det minsta BGP-router-ID.
- Välj en väg genom grannen med lägst IP-adress.
Låt oss nu titta på frågan om BGP-konvergens.
Låt oss se vad som händer om Router6 tappar väg 9.9.9.0/24 genom Router9. Låt oss inaktivera gränssnittet Gi0/1 för Router6, som omedelbart kommer att förstå att BGP-sessionen med Router8 har avslutats och grannen har försvunnit, vilket betyder att rutten som tas emot från den inte är giltig. Router6 skickar omedelbart uppdateringsmeddelanden, där den indikerar nätverket 9.9.9.0/24 i fältet Återkallade rutter. Så snart Router5 tar emot ett sådant meddelande kommer det att skickas till Router7. Men eftersom Router7 har en rutt genom Router10 kommer den omedelbart att svara med en uppdatering med en ny rutt. Om det inte är möjligt att upptäcka en grannes fall baserat på gränssnittets tillstånd, måste du vänta på att hålltimern utlöses.
Konfederation.
Om du kommer ihåg så pratade vi om att man ofta måste använda en helt uppkopplad topologi. Med ett stort antal routrar i ett AS kan detta orsaka stora problem, för att undvika detta måste du använda konfederationer. Ett AS är uppdelat i flera sub-AS, vilket gör att de kan fungera utan krav på en helt ansluten topologi.
Här är en länk till detta Och konfiguration för GNS3.
Till exempel, med denna topologi skulle vi behöva ansluta alla routrar i AS 2345 till varandra, men med Confederation kan vi upprätta närliggande relationer endast mellan routrar som är direkt anslutna till varandra. Låt oss prata om detta i detalj. Om vi bara hade AS 2345, alltså laForge efter att ha fått en marsch från Picard skulle berätta det för routrarna Data и Worf, men de skulle inte berätta för routern om det Kross . Även rutter distribuerade av routern själv laForge, inte skulle ha överförts Kross eller Worf-Å nej Data.
Du skulle behöva konfigurera en ruttreflektor eller en helt ansluten grannskapsrelation. Genom att dela upp en AS 2345 i 4 sub-AS (2,3,4,5) för varje router får vi en annan driftlogik. Allt är perfekt beskrivet .
Källor:
- CCIE Routing and Switching v5.0 Official Cert Guide, Volume 2, Fifth Edition, Narbik Kocharians, Terry Vinson.
- webbplats
- webbplats .
Källa: will.com