Trafikkutvekslingspunkt: fra opprinnelse til å lage din egen IX

«Vi opprettet en telefonforbindelse mellom oss og gutta på SRI...», sa Kleinrock... i et intervju:
«Vi skrev L-en og spurte på telefonen: «Ser dere L-en?»
«Ja, vi ser L-en», kom svaret.
«Vi skrev O-en, og spurte: «Ser du O-en?»»
"Ja, vi ser O-en."
«Så skrev vi G-en, og systemet krasjet»...

Likevel hadde en revolusjon begynt …

Internettets begynnelse.

Hei!

Jeg heter Alexander, og jeg er nettverksingeniør hos Linxdatacenter. I dagens artikkel skal jeg snakke om Internet Exchange Points (IXP-er): deres opprinnelse, oppgavene de løser og hvordan de er bygget. Jeg skal også demonstrere hvordan en IXP fungerer ved hjelp av EVE-NG-plattformen og BIRD-programvareruteren, slik at du kan forstå hvordan den fungerer «under panseret».

En bit av historien

Hvis du ser her, kan vi se at den raske veksten i antall trafikkutvekslingspunkter startet i 1993. Dette skyldes at mesteparten av trafikken til teleoperatørene som eksisterte på den tiden gikk gjennom det amerikanske stamnettet. For eksempel, når trafikk gikk fra en operatør i Frankrike til en operatør i Tyskland, gikk den først fra Frankrike til USA, og først deretter fra USA til Tyskland. Stamnettet fungerte i dette tilfellet som et transittpunkt mellom Frankrike og Tyskland. Selv trafikk innenfor et enkelt land gikk ofte indirekte, gjennom stamnettene til amerikanske operatører.

Denne situasjonen påvirket ikke bare kostnadene for levering av transitttrafikk, men også kvaliteten på kanaler og latens. Antall internettbrukere vokste, nye operatører dukket opp, trafikkvolumet økte, og internett modnet. Operatører over hele verden begynte å innse at det var behov for en mer rasjonell tilnærming til å organisere interaksjoner mellom operatører. «Hvorfor skal jeg, operatør A, betale for transitt gjennom et annet land for å levere trafikk til operatør B, som ligger like nede i gaten?» Dette var omtrent spørsmålet teleoperatørene stilte seg selv på den tiden. Dermed begynte trafikkutvekslingspunkter å dukke opp i forskjellige deler av verden på punkter der operatørene var konsentrert:

• 1994 – LINX i London,
• 1995 – DE-CIX i Frankfurt,
• 1995 – MSK-IX, i Moskva, etc.

Internett og nåtiden

Konseptuelt sett er arkitekturen til det moderne internett et sett med autonome systemer (AS) og et sett med forbindelser mellom dem, både fysiske og logiske, som bestemmer trafikkveien fra ett AS til et annet.

AS-er inkluderer vanligvis teleoperatører, internettleverandører, CDN-er, datasentre og bedrifter. AS-er etablerer vanligvis logiske peering-forhold med hverandre ved hjelp av Border Gateway Protocol (BGP).

Hvordan autonome systemer organiserer disse forbindelsene bestemmes av en rekke faktorer:

• geografisk,
• økonomisk,
• politisk,
• avtaler og felles interesser mellom eierne av AS,
• etc.

Selvfølgelig er det en viss struktur og et hierarki i denne ordningen. Operatører er delt inn i nivå 1, nivå 2 og nivå 3. Mens klienter hos en lokal internettleverandør (nivå 3) vanligvis er vanlige brukere, er nivå 1-operatørers klienter for eksempel andre operatører. Nivå 3-operatører aggregerer abonnentenes trafikk, nivå 2-operatører aggregerer igjen trafikken til nivå 3-operatører, og nivå 1-operatører aggregerer all internettrafikk.

Skjematisk kan det representeres slik:

Dette bildet viser at trafikken aggregeres nedenfra og opp, dvs. fra sluttbrukere til nivå 1-operatører. Det er også horisontal trafikkutveksling mellom AS-er av omtrent like stor betydning.

En integrert del, og samtidig en ulempe, med denne ordningen er den noe uorganiserte naturen til forbindelsene mellom autonome systemer som ligger nærmere sluttbrukeren innenfor et geografisk område. Se på bildet nedenfor:

La oss anta at det i en storby er 5 teleoperatører, som av en eller annen grunn er organisert mellom peering som vist ovenfor.

Hvis brukeren Petya, som er koblet til internettleverandøren Go, ønsker å få tilgang til en server som er koblet til ASM-leverandøren, vil trafikken mellom dem bli tvunget til å gå gjennom fem autonome systemer. Dette øker latensen, ettersom antallet nettverksenheter trafikken må passere gjennom øker, i likhet med volumet av transitttrafikk på de autonome systemene mellom Go og ASM.

Hvordan kan vi redusere antallet transitt-AS-er som trafikken må krysse? Svaret er et trafikkutvekslingspunkt.

I dag er fremveksten av nye IXP-er drevet av de samme behovene som tidlig på 90-tallet og 2000-tallet, bare i mindre skala, som svar på det økende antallet teleoperatører, brukere og trafikk, og den økende mengden innhold generert av CDN-nettverk og datasentre.

Hva er et trafikkutvekslingspunkt?

Et trafikkutvekslingspunkt (TIP) er et sted med en dedikert nettverksinfrastruktur der parter som er interessert i å utveksle trafikk etablerer peering-forhold. Hoveddeltakerne på TIP-er inkluderer teleoperatører, internettleverandører, innholdsleverandører og datasentre. På TIP-er kobler partene seg direkte til hverandre. Dette gjør det mulig å utføre følgende oppgaver:

• redusere latens,
• redusere mengden kollektivtrafikk,
• optimalisere rutingen mellom AS.

Med tanke på at IXP-er finnes i mange større byer rundt om i verden, har dette en positiv effekt på internett som helhet.

Hvis vi løser den ovenfor beskrevne situasjonen med Petya ved hjelp av IXP, vil det se omtrent slik ut:

Hvordan fungerer et trafikkutvekslingspunkt?

Vanligvis er en IXP et separat AS med sin egen blokk med offentlige IPv4/IPv6-adresser.

Et IXP-nettverk består oftest av et enkelt lag 2-domene. Noen ganger er dette rett og slett et VLAN som inneholder alle IXP-klienter. For større, geografisk distribuerte IXP-er kan imidlertid teknologier som MPLS, VXLAN og andre brukes til å organisere lag 2-domenet.

IXP-elementer

• SKS. Det er ingenting uvanlig her: stativer, optiske kryss, patchpaneler.
• Brytere – grunnlaget for en IXP. En svitsjport er inngangspunktet til IXP-nettverket. Svitsjer utfører også noen sikkerhetsfunksjoner, og filtrerer uønsket trafikk som ikke skal være tilstede på IXP-nettverket. Svitsjer velges vanligvis basert på funksjonelle krav, for eksempel pålitelighet, støttede porthastigheter, sikkerhetsfunksjoner, sFlow-støtte osv.
• Ruteserver (RS) En RS er en integrert og nødvendig komponent i ethvert moderne trafikkutvekslingspunkt. Driftsprinsippet er veldig likt en rutereflektor i iBGP eller en dedikert ruter i OSPF, og den løser de samme problemene. Etter hvert som antallet deltakere i trafikkutvekslingspunktet vokser, øker antallet BGP-økter som hver deltaker må støtte, noe som ligner en klassisk full-mesh-topologi i iBGP. RS løser dette problemet på følgende måte: den etablerer en BGP-økt med hver interessert IXP-deltaker, og den deltakeren blir en RS-klient. Når RS mottar en BGP-oppdatering fra en av klientene sine, distribuerer den denne oppdateringen til alle sine andre klienter, bortsett fra, selvfølgelig, den som oppdateringen ble mottatt fra. Dermed eliminerer RS ​​behovet for å etablere en full-mesh mellom alle IXP-deltakere og løser elegant skalerbarhetsproblemet. Det er verdt å merke seg at ruteserveren transparent forplanter ruter fra ett AS til et annet, uten å endre de overførte BGP-attributtene; for eksempel legger den ikke til sitt AS-nummer til AS-banen. RS utfører også grunnleggende rutefiltrering: for eksempel godtar ikke RS marsiske nettverk eller prefikser for selve IXP-en.

  Programvareruteren BIRD (bird internet routing daemon) med åpen kildekode brukes ofte som en ruteserverløsning. Fordelene inkluderer at den er gratis, raskt utrullerbar på de fleste Linux-distribusjoner, fleksibel konfigurasjon av ruting-/filtreringspolicyer og lavt ressursforbruk. En maskinvare- eller virtuell ruter fra Cisco, Juniper eller lignende leverandører kan også brukes som en ruteserver.

• Sikkerhet. Siden et IXP-nettverk er en konsentrasjon av et stort antall AS-er, må sikkerhetspolicyen som alle deltakere må følge være veldefinert. Vanligvis brukes de samme mekanismene som brukes for å etablere BGP-naboforhold mellom to separate BGP-peer utenfor en IXP også her, sammen med noen ekstra sikkerhetstiltak.

  For eksempel er det god praksis å kun tillate trafikk fra en spesifikk MAC-adresse til et IXP-medlem, som er forhandlet på forhånd. Det anbefales også å nekte trafikk med andre ethertype-felt enn 0x0800 (IPv4), 0x08dd (IPv6) eller 0x0806 (ARP). Dette gjøres for å filtrere ut trafikk som ikke hører hjemme i BGP-peering. Mekanismer som GTSM, RPKI og andre kan også brukes.

Ovennevnte er uten tvil kjernekomponentene i enhver IXP, uavhengig av størrelse. Større IXP-er kan selvsagt benytte seg av ytterligere teknologier og løsninger.
Noen ganger tilbyr IXP-er også medlemmene sine tilleggstjenester:

• være vert for DNS-servere på IXP TLD-er,
• installere maskinvarebaserte NTP-servere, slik at deltakerne nøyaktig kan synkronisere tid,
• gi beskyttelse mot DDoS-angrep, etc.

Prinsippet om drift

Vi skal utforske driftsprinsippet til et trafikkutvekslingspunkt ved hjelp av en enkel IXP modellert med EVE-NG, og deretter dekke den grunnleggende konfigurasjonen av BIRD-programvareruteren. For å forenkle diagrammet utelater vi viktige aspekter som redundans og feiltoleranse.

Nettverkstopologien er vist i figuren nedenfor.

La oss anta at vi administrerer et lite Internett-utvekslingspunkt og tilbyr følgende peering-alternativer:

• offentlig kikking,
• privat peering,
• peering via ruteserver.

AS-nummeret vårt er 555, vi eier en blokk med IPv4-adresser - 50.50.50.0/24, som vi bruker til å utstede IP-adresser til de som ønsker å koble seg til nettverket vårt.

50.50.50.254 – IP-adresse konfigurert på ruteservergrensesnittet; klienter vil opprette en BGP-økt med denne IP-adressen ved peering via RS.

Vi utviklet også en enkel BGP-fellesskapsbasert rutingspolicy for RS-peering, som lar IXP-deltakere kontrollere hvilke ruter som sendes til hvem:

BGP-fellesskapet
beskrivelse

LOKAL_AS:PEER_AS
Send prefikser kun til PEER_AS

LOKAL_AS:IXP_AS
Overfør prefikser til alle IXP-deltakere

Tre klienter, la oss si internettleverandører, ønsker å koble til vår IXP og utveksle trafikk. Alle ønsker å etablere peering via en ruteserver. Nedenfor er et diagram som viser klienttilkoblingsparameterne:

kunde
Klient AS-nummer
Klientannonserte prefikser
IP-adressen som er tildelt klienten for tilkobling til IXP

Internettleverandør nr. 1
AS 100
1.1.0.0/16
50.50.50.10/24

Internettleverandør nr. 2
AS 200
2.2.0.0/16
50.50.50.20/24

Internettleverandør nr. 3
AS 300
3.3.0.0/16
50.50.50.30/24

Grunnleggende BGP-oppsett på klientruteren:

router bgp 100
 no bgp enforce-first-as
 bgp log-neighbor-changes
 neighbor 50.50.50.254 remote-as 555
address-family ipv4
  network 1.1.0.0 mask 255.255.0.0
  neighbor 50.50.50.254 activate
  neighbor 50.50.50.254 send-community both
  neighbor 50.50.50.254 soft-reconfiguration inbound
  neighbor 50.50.50.254 route-map ixp-out out
 exit-address-family

ip prefix-list as100-prefixes seq 5 permit 1.1.0.0/16
route-map bgp-out permit 10
 match ip address prefix-list as100-prefixes
 set community 555:555

Innstillingen «no bgp enforce-first-as» er verdt å merke seg her. Som standard krever BGP at as-banen til en mottatt BGP-oppdatering inkluderer as-banens nummer til bgp-motparten som oppdateringen ble mottatt fra. Men siden ruteserveren ikke endrer as-banen, vil nummeret mangle i as-banen, og oppdateringen vil bli forkastet. Denne innstillingen brukes til å tvinge ruteren til å ignorere denne regelen.

Vi ser også at klienten har satt bgp community 555:555 til dette prefikset, som i henhold til vår policy betyr at klienten ønsker å annonsere dette prefikset til alle andre deltakere.

For de andre klientenes rutere vil konfigurasjonen være lik, bortsett fra deres unike parametere.

Eksempel på BIRD-konfigurasjon:

define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];

template bgp RS_CLIENT {
  local as ixp_as;
  rs client;
}

Følgende beskriver et filter som ikke godtar prefikser fra marsboere, samt prefikser fra selve IXP-en:

function catch_martians_and_ixp()
prefix set martians;
prefix set ixp_prefixes;
{
  martians = [ 
  0.0.0.0/8+,
  10.0.0.0/8+,
  100.64.0.0/10+,
  127.0.0.0/8+,
  169.254.0.0/16+,
  172.16.0.0/12+,
  192.0.0.0/24+,
  192.0.2.0/24+,
  192.168.0.0/16+,
  198.18.0.0/15+,
  198.51.100.0/24+,
  203.0.113.0/24+,
  224.0.0.0/4+,
  240.0.0.0/4+ ];

  if net ~ martians || net ~ ixp_prefixes then return false;

  return true;
}

Denne funksjonen implementerer rutingspolicyen vi beskrev tidligere.

function bgp_ixp_policy(int peer_as)
{
  if (ixp_as, ixp_as) ~ bgp_community then return true;
  if (ixp_as, peer_as) ~ bgp_community then return true;

  return false;
}

filter reject_martians_and_ixp
{
  if catch_martians_and_ixp() then reject;
  if ( net ~ [0.0.0.0/0{25,32} ] ) then {
    reject;
  }
  accept;


}

Vi konfigurerer peering og bruker passende filtre og policyer.

protocol as_100 from RS_CLIENT {
  neighbor 50.50.50.10 as 100;
  ipv4 {
    export where bgp_ixp_policy(100);
    import filter reject_martians_and_ixp;
  }
}

protocol as_200 from RS_CLIENT {
  neighbor 50.50.50.20 as 200;
  ipv4 {
    export where bgp_ixp_policy(200);
    import filter reject_martians_and_ixp;
  }
}

protocol as_300 from RS_CLIENT {
  neighbor 50.50.50.30 as 300;
  ipv4 {
    export where bgp_ixp_policy(300);
    import filter reject_martians_and_ixp;
  }
}

Det er verdt å merke seg at det er vanlig praksis for en ruteserver å kombinere ruter fra forskjellige peer-servere til separate RIB-er. BIRD tillater dette. I vårt eksempel kombineres alle oppdateringer mottatt fra alle klienter for enkelhets skyld til én delt RIB.

Så, la oss sjekke hva vi har.

På ruteserveren ser vi at en BGP-økt er opprettet med alle tre klientene:

Vi ser at vi mottar prefikser fra alle klienter:

På ruter som 100 ser vi at med bare én BGP-økt med ruteserveren, mottar vi prefikser fra både som 200 og som 300, mens BGP-attributtene ikke har endret seg, som om peering mellom klienter ble utført direkte:

Dermed ser vi at tilstedeværelsen av en ruteserver forenkler organiseringen av peering på IXP-er betydelig.

Jeg håper denne demonstrasjonen har hjulpet deg med å bedre forstå hvordan IXP-er fungerer og hvordan ruteserveren fungerer på en IXP.

Linxdatasenter IX

Hos Linxdatacenter har vi bygget vår egen IXP basert på en feiltolerant infrastruktur som består av to svitsjer og to ruteservere. Vår IXP kjører for øyeblikket i testmodus, og vi inviterer alle til å koble til Linxdatacenter IX og delta i testing. Ved tilkobling vil du få en 1 Gbps-port, peering-muligheter gjennom våre ruteservere og tilgang til din IX-portalkonto, tilgjengelig på ix.linxdatacenter.com.

Skriv i kommentarfeltet eller send private meldinger for å få tilgang til testingen.

Utgang

Trafikkutvekslingspunkter dukket opp ved internettets begynnelse som en løsning på problemet med suboptimal trafikkflyt mellom teleoperatører. I dag, med fremveksten av nye globale tjenester og den økende mengden CDN-trafikk, fortsetter utvekslingspunkter å optimalisere den globale nettverksytelsen. Det økende antallet IXP-er over hele verden kommer både sluttbrukere og teleoperatører, innholdsleverandører og andre til gode. For IXP-deltakerne inkluderer fordelene reduserte kostnader for å sette opp ekstern peering, reduserte trafikkostnader som oppstrømsoperatører må betale for, optimalisert ruting og muligheten til å koble seg direkte til innholdsleverandører.

Nyttige lenker

• Se kart over trafikkutvekslingspunkter: www.internetexchangemap.com
• Se detaljert BGP-peeringstatistikk, inkludert IXP-tilstedeværelse: www.peeringdb.com

Kilde: www.habr.com