| TCP/IP-protokollfamilie |
|---|
| påføringslag |
| transportlag |
| internettlag |
| lenkelag |
| IPv6 overgangsmekanismer |
|
Innen telekommunikasjon er Border Gateway Protocol eller BGP ( Border Gateway Protocol ) [ 1 ] en protokoll der rutinginformasjon utveksles mellom autonome systemer . For eksempel er registrerte tjenesteleverandører på Internett ofte bygd opp av flere autonome systemer, og for dette tilfellet er en protokoll som BGP nødvendig.
Rutetabeller utveksles mellom autonome systemer til Internett- leverandører gjennom BGP-protokollen. Denne utvekslingen av ruteinformasjon gjøres mellom de eksterne ruterne til hvert autonome system, som må være kompatibel med BGP. Dette er den mest brukte protokollen for nettverk som har til hensikt å sette opp en Exterior Gateway Protocol .
Måten å konfigurere og avgrense informasjonen som BGP-protokollen inneholder og utveksler på, er ved å lage det som er kjent som et autonomt system eller AS. Hver vil ha interne (iBGP) tilkoblinger eller økter, så vel som eksterne (eBGP) økter.
Border Gateway Protocol (BGP) er et eksempel på en Exterior Gateway Protocol (EGP). BGP utveksler ruteinformasjon mellom autonome systemer samtidig som den sikrer sløyfefritt rutevalg. Det er den primære ruteannonseringsprotokollen som brukes av de store ISP -selskapene på Internett . BGP4 er den første versjonen som støtter klasseløs inter - domene ruting (CIDR) og ruteaggregering. I motsetning til interne gateway-protokoller ( IGPs ), som RIP , OSPF og EIGRP , bruker den ikke beregninger som hopptelling, båndbredde eller forsinkelse. I stedet tar BGP rutingbeslutninger basert på nettverkspolicyer, eller regler som bruker ulike BGP-ruteattributter.
BGP spiller en kritisk rolle i kommunikasjon på Internett. [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ 6 ] [ 7 ] Tilrettelegger for utveksling av informasjon på IP -nettverk og kommunikasjon mellom autonome systemer (AS). Derfor er BGP en interdomene (mellom autonome systemer) og intradomene (innenfor samme autonome system) protokoll.
BGP-protokollen brukes til å utveksle informasjon ved å etablere en kommunikasjonsøkt mellom grenseruterene til de autonome systemene. For å oppnå pålitelig levering av informasjon, brukes en TCP -basert kommunikasjonsøkt på portnummer 179. Denne økten må holdes aktiv fordi begge ender av kommunikasjonen periodisk utveksler og oppdaterer informasjon. Til å begynne med sender hver ruter all sin ruteinformasjon til naboen, og deretter vil bare tidligere overførte nye ruter, oppdateringer eller fjerning av ruter bli sendt. I tillegg sendes meldinger med jevne mellomrom for å garantere tilkobling.
Når en TCP-forbindelse av en eller annen grunn avbrytes, blir hver ende av kommunikasjonen tvunget til å slutte å bruke informasjonen den har mottatt fra den andre enden. Med andre ord, TCP-økten fungerer som en virtuell kobling mellom to tilstøtende autonome systemer, og når det er mangel på kommunikasjonsutveksling, indikerer det at den virtuelle koblingen er nede. Det skal bemerkes at den virtuelle koblingen vil ha mer enn én fysisk kobling som forbinder de to grenseruterene, men hvis en virtuell tilkobling går ned, betyr det ikke nødvendigvis at den fysiske tilkoblingen har gått ned.
Fra topologiens synspunkt kan den betraktes som en forbindelsesgraf av autonome systemer koblet sammen med virtuelle lenker. I figuren nedenfor kan du se fire autonome systemer kalt AS1, AS2, AS3 og AS4 koblet sammen med virtuelle lenker. Det vil si at de opprettholder BGP-økter over TCP for kommunikasjon mellom autonome systemer. Hvert autonomt system inneholder ett eller flere nettverk som ble identifisert som N1, N2 og N3 i AS1, og så videre. Bare ved å se på figuren kan det vises at det er mer enn én mulig rute mellom to gitte autonome systemer. Ettersom det også er mulig å ha en eller flere grenseruter i samme autonome system.
For implementering av det forrige nettverket, må det leveres en ruteutvekslingsmekanisme som gjør at begge systemene kan kommunisere riktig. BGP-protokollen bruker Path vector-protokollen for utveksling av rutinginformasjon i nettverket . En liste blir overført med identifikasjon av AS-ene som kunngjøringen går gjennom. På denne måten vil det være mulig å vite hvordan man når en hvilken som helst adresse til det propagerte prefikset, samt å være forberedt på å sende trafikk for enhver adresse til prefikset.
Før man uttaler mekanikken for rutevalg, bør de to fremgangsmåtene introduseres når det er et scenario for å implementere BGP. Det må skilles mellom ekstern BGP (eBGP) og intern BGP (iBGP) avhengig av om informasjonen utveksles innenfor et AS eller mellom to AS. Det kan sees i forrige figur at det autonome systemet AS1 må forplante tre IP-prefikser (N1, N2 og N3) slik at de er tilgjengelige fra utstyret til andre autonome systemer. I tillegg må disse tre nettverkene etablere en viss rutebeslutningspolitikk overfor andre autonome systemer. IBGP danner en virtuell mesh-topologi slik at alle ruterne til et autonomt system er koblet sammen slik at utvekslingen av ruter er direkte fra ruteren som kunngjøringen kommer til, mot alle ruterne i det autonome systemet.
BGP-naboer, kalt peers, etableres ved manuell konfigurasjon mellom rutere for å opprette en TCP-sesjon på port 179. En BGP-høyttaler sender 19-byte meldinger hvert 30. sekund (protokollstandard, justerbar) for å opprettholde forbindelsen. [5] Blant rutingprotokoller er BGP unik i sin bruk av TCP som transportprotokoll.
Når BGP kjører mellom to jevnaldrende i samme autonome system (AS), er det kjent som intern BGP (iBGP eller Interior Border Gateway Protocol). Når du kjører mellom ulike autonome systemer, kalles det External BGP (eBGP eller Exterior Border Gateway Protocol). Rutere på kanten av et AS som utveksler informasjon med et annet AS kalles edge- eller border-rutere eller rett og slett eBGP-peers og er vanligvis direkte koblet sammen, mens iBGP-peers kan kobles sammen gjennom andre mellomrutere. Andre distribusjonstopologier er også mulige, for eksempel å kjøre eBGP-peering i en VPN-tunnel, slik at to eksterne nettsteder kan utveksle rutinginformasjon på en sikker og isolert måte.
Hovedforskjellen mellom iBGP og eBGP-peering er måten ruter mottatt fra én peer normalt spres som standard til andre peer:
Nye ruter som er lært fra en eBGP-peer, annonseres på nytt til alle iBGP- og eBGP-peer. Nye ruter som er lært fra en iBGP-felle, annonseres kun på nytt til alle eBGP-feller. Disse ruteutbredelsesreglene krever effektivt at alle iBGP-peers i et AS er sammenkoblet i en full mesh med iBGP-økter.
Hvordan ruter forplantes kan kontrolleres i detalj gjennom rutekartleggingsmekanismen. Denne mekanismen består av et sett med regler. Hver regel beskriver, for ruter som samsvarer med noen gitte kriterier, hva som skal gjøres. Handlingen kan være å droppe ruten, eller det kan være å endre noen attributter for ruten før du setter den inn i rutetabellen.
Relasjonene som eksisterer mellom ulike autonome systemer er hovedsakelig frivillig sammenkobling ( peering ) og transitt. I utgangspunktet er et transittforhold det mellom en leverandør og en klient, slik at klienten betaler for Internett-ressursene som leverandøren deres kan tilby. Peering- relasjoner betales vanligvis ikke og består av en kobling for å kommunisere mellom to autonome systemer for å redusere kostnader, ventetid, pakketap og oppnå redundante veier. Peering gjøres vanligvis med potensielt lignende autonome systemer når det gjelder størrelse. Derfor gjøres det ingen peering med en potensiell klient siden ett av de to autonome systemene vil være til nytte.
Figuren viser en nettverkstopologi med ulike typer relasjoner. Nivå 1-leverandører ( nivå 1) er de som per definisjon ikke betaler andre leverandører og tilbyr svært langdistansetjenester og tilkobling. Alle andre viste tilbydere betaler minst transitt med nivå 1. Kunder betaler tilbydere som de har transittforbindelse med.
BGP tillater også ruteaggregering slik at rutene som håndteres av en bestemt ruter er så få som mulig.
Et ofte gjentatt scenario er et som kalles multiconnection , multi-ISP eller multihoming . Dette begrepet refererer til en klient som ansetter to transittleverandører, noe som innebærer at det er to utfartsruter, slik at det må tas en avgjørelse mellom en eller annen rute avhengig av visse spesifikasjoner, behov eller enkle retningslinjer som er pålagt i det autonome systemet. Et eksempel kan sees i figuren som tar hensyn til Klient A. Spesifikasjonene kan være å balansere trafikken, å sette en lenke som foretrukket foran en annen (for eksempel fordi den har mer hastighet), for feiltoleranse osv. Styringen av disse prioriteringene er det som kalles trafikkteknikk og oppnås takket være BGP-attributtene som er definert i protokollen.
Det er fire typer BGP-meldinger som er som følger:
ÅPEN: den brukes til å etablere en BGP-sesjon når TCP-forbindelsen er etablert. Enkelte parametere som kjennetegner den økten blir vanligvis forhandlet. For eksempel er det godt mulig at medlemmene av økten ikke har samme versjon av BGP, så det er viktig å angi versjonsnummeret i denne meldingen.
OPPDATERING: det er en oppdateringsmelding, av stor betydning i BGP-operasjoner siden den inneholder kunngjøringer om nye prefikser. Oppdateringsmeldinger vil bli generert hver gang en ny beste rute bestemmes for en bestemt destinasjon eller det er en modifikasjon av en eksisterende.
KEEPALIVE: når BGP-økten er aktiv, sendes det med jevne mellomrom en melding for å holde forbindelsen i live eller KEEPALIVE for å bekrefte at den andre enden fortsatt er aktiv i BGP-økten. En maksimal tidsavbrudd avtales vanligvis under den første utvekslingen av OPEN -meldinger . KEEPALIVE er vanligvis omtrent en gang hver tredje av holdetiden, men ikke mer enn en gang hvert sekund . KEEPALIVE- meldinger bør ikke genereres hvis tidsavbruddet er null, siden økten i så fall antas å være fullstendig pålitelig.
VARSEL: Det sendes når du lukker en BGP-sesjon, og dette skjer når det oppstår en feil som krever at den lukkes. Så det er en melding som lar deg rapportere hva som helst.
BGP-pakker har en 19-byte header, som består av følgende felt:
• Et 16-byte markørfelt: for å oppdage tap av synkronisering eller autentisering av innkommende BGP-meldinger,
• Et 2-byte felt med pakkelengde (lengde): som spesifiserer lengden på BGP-meldingen i byte (lengden kan ikke være mindre enn 19 byte av overskriften uten data eller større enn 4096), og
• Et 1-byte Type-felt: angir meldingstypen.
Dataene etter pakkehodet kan være fra 0 til 4077 byte, for å gi en maksimal mulig lengde på 4096.
Trafikkteknikk i BGP er måten nettverket administreres på basert på attributtene som nevnte protokoll har for å tilfredsstille visse egenskaper eller pålegg i et BGP-scenario.
Karakteristikker er definert for utgående og inngående trafikk, sistnevnte er noe vanskeligere å kontrollere. Så denne nettverksadministrasjonen gjøres fra utvalget av rutene som enhver ruter skal forplante i et nettverk og rutene den kommer til å velge som foretrukne og alternative.
For dette er det et sett med attributter som gir informasjon for beslutningstaking for å filtrere eller velge ruter. Disse attributtene er definert nedenfor:
Identifiserer mekanismen som IP-prefikset først ble annonsert med. Det kan spesifiseres som IGP (0), EGP (1) eller UFULLSTENDIG (2). IGP indikerer at IP-prefikset ble lært av en protokoll inne i det autonome systemet, for eksempel OSPF. EGP indikerer at IP-prefikset ble lært av en ekstern protokoll som BGP, for eksempel kan det være fordi aggregering er utført. Enhver annen rute som ikke faller inn under IGP eller EGP, faller inn under UFULLSTENDIG, siden opprinnelsesinformasjonen er ufullstendig, og derfor ikke er kjent hvor den kommer fra.
Generelt, hvis opprinnelsen er UFULLSTENDIG, er det fordi den har blitt lært statisk. Hvis du ønsker å bestemme et utvalg ruter basert på dette prefikset, velges den med den laveste ORIGIN-verdien, så rutene som læres av IGP foretrekkes fremfor EGP og sistnevnte før UFULLSTENDIG.
AS-PATH-attributtet lagrer en sekvens av AS-numre som identifiserer banen til AS-er som annonsen har passert. Hver gang en grenseruter forplanter en rute til en annen side, legger den til AS-nummeret til dette attributtet, og utgjør dermed listen over AS som den hadde til hensikt å ha. Listen forblir intakt hvis IBGP brukes, det vil si hvis det autonome systemet ikke er igjen.
Hvis du ønsket å bruke AS-PATH som en rutevalgmetode, ville du velge den med den minste AS-PATH-listen. Dette er en måte å måle at det er færre hopp til destinasjonen, selv om dette ikke akkurat er tilfelle fordi mulige hopp på grunn av rutere innenfor et autonomt system ikke er tatt i betraktning.
NEXT-HOP eller neste hopp identifiserer IP-adressen til ruteren som tilsvarer neste hopp til destinasjonen. Det må tas i betraktning at et IP-prefiks annonseres utenfor et autonomt system, så neste hopp er destinasjonen som er kjent og som trafikken til brukere som ønsker å nå en endelig destinasjon må sendes til.
NEXT-HOP-informasjonen behandles med IP-rutingstabelldata. Nå vil det være en IP-tabell (som tidligere var tilgjengelig) og en BGP-tabell som vil inneholde neste hopp for hver destinasjon. En rute til BGP-destinasjonen vil bli oppnådd ved å gå gjennom hoppene angitt av IP-rutingstabellen.
Hvis du ønsket å velge en rute med denne attributten, ville du velge den som medfører lavest kostnad til neste hopp, det vil si færrest antall hopp til neste hopp.
Det er en indikator designet for å brukes når det er flere koblinger til det samme autonome systemet fra et autonomt system. Det kan sees lettere i figuren under.
Som man kan se, er to koblinger til et annet autonomt system laget fra det samme autonome systemet. Dette attributtet kan brukes til lastbalansering, slik at det mot noen prefikser er en MED-verdi som gjør et bestemt prefiks å foretrekke og mot andre prefikser er et annet å foretrekke. Denne metrikken er lokal mellom to autonome systemer, den forplanter seg ikke utenfor dette omfanget. Hvis du ønsker å velge en rute ved hjelp av dette attributtet, vil den med lavere MED-verdi bli ansett som foretrukket.
Denne attributten er nyttig i et scenario der et autonomt system har tilkobling til flere autonome systemer, slik at det kan være flere stier til samme destinasjon. Dette attributtet vil gi preferanse til å sende trafikk gjennom en spesifikk lenke, derfor vil det bare gi mening innenfor det samme autonome systemet, så blir det bare overført av iBGP.
Sending av data via lenken som har en høyere LOCAL-PREF vil bli valgt, LOCAL-PREF er standardverdien på 100.
Det denne attributten gjør er å indikere at den tilsvarende ruten er oppnådd ved å aggregere andre mer presise ruter.
Du kan administrere distribusjonen av ruteinformasjon til en gruppe mottakere som danner et fellesskap (COMMUNITY). Tanken er at når en gruppe mottakere har blitt abonnert, kan en spesifikk rutingpolicy brukes på dem. På denne måten forenkles arbeidet ved å legge til ruteinformasjon samt gi et verktøy for å få et mer overvåket miljø i nettverket.
Det oppnås ved hjelp av et tall som fungerer som et merke som kvalifiserer ruten.
Alle disse attributtene kan brukes sammen for rutevalg, men det må pålegges en preferanserekkefølge slik at dersom det er flere ruter som kan foretrekkes, velges kun én. Følgende liste vil bli krysset og rutene som ikke stemmer overens med den beste verdien av hvert av kriteriene vil bli eliminert. Merk at rutingbeslutningskriterier som inkluderer tiebreaker gjelder for hvert destinasjons-IP-prefiks eller sett med IP-prefikser.
De to siste oppføringene i listen er en form for noe vilkårlig rutevalg, da de ikke indikerer en policy regulert som sådan av en administrator. Det er imidlertid en måte som BGP legger slik at i tilfelle det ikke kan avgjøres, velges en rute.
Gjennom sin historie har Border Gateway Protocol presentert en rekke hendelser, [ 8 ] hvorav de viktigste har vært følgende:
BGP4 er standard for Internett-ruting, og de fleste Internett-leverandører (ISP) er pålagt å etablere ruting med hverandre. Svært store private IP-nettverk bruker BGP internt. Et eksempel er sammenføyningen av en serie store Open Shortest Path First-nettverk (OSPF), når OSPF alene ikke skaleres til den nødvendige størrelsen. En annen grunn til å bruke BGP er å multihome et nettverk for bedre redundans, enten til flere tilgangspunkter fra en enkelt ISP eller til flere ISPer.
En utvidelse av BGP er bruken av multipathing: dette krever generelt identisk MED, vekt, kilde og as-path, selv om noen implementeringer gir muligheten til å slappe av AS-banesjekken for å bare forvente en lik banelengde i stedet for den faktiske AS tall på ruten som forventes å stemme også. Dette kan utvides ytterligere med funksjoner som Ciscos dmzlink-bw, som muliggjør et peering-forhold basert på konfigurerte båndbreddeverdier på individuelle lenker.
Multiprotocol Extensions for BGP (MBGP), noen ganger kalt Multiprotocol BGP eller Multicast BGP og definert i IETF RFC 4760 , er en utvidelse til (BGP) som gjør at forskjellige typer adresser (kjent som adressefamilier) kan distribueres parallelt. Mens standard BGP bare støtter IPv4 unicast-adresser, støtter multiprotokoll BGP både IPv4- og IPv6-adresser og støtter både unicast- og multicast-varianter av hver. Multiprotocol BGP lar topologiinformasjonen til IP multicast-kompatible rutere utveksles separat fra topologien til vanlige IPv4 unicast-rutere. Derfor tillater den en multicast-rutingstopologi som er forskjellig fra unicast-rutingstopologien. Selv om MBGP tillater utveksling av multicast-rutingsinformasjon mellom domener, trengs andre protokoller, for eksempel den protokolluavhengige multicast-familien, for å bygge trær og videresende multicast-trafikk.
Multiprotocol BGP er også mye implementert når det gjelder MPLS L3 VPN, for å utveksle innlærte VPN-etiketter for ruter for kunders nettsteder gjennom MPLS-nettverket, for å skille mellom ulike kundesider når trafikk fra andre kundesider når leverandørens kantruter (PE-ruter) ) for ruting.