"Vi opprettet en telefonforbindelse mellom oss og gutta på SRI ...", sa Kleinrock ... i et intervju:
"Vi skrev L og vi spurte på telefonen: "Ser du L?
"Ja, vi ser L," kom svaret.
"Vi skrev O, og vi spurte: "Ser du O'en."
"Ja, vi ser O."
"Så skrev vi G, og systemet krasjet"...Likevel hadde en revolusjon begynt...
Begynnelsen på internett.
Hei!
Jeg heter Alexander, jeg er nettverksingeniør ved Linxdatacenter. I dagens artikkel vil vi snakke om trafikkutvekslingspunkter (Internet Exchange Points, IXP): hva gikk foran utseendet deres, hvilke oppgaver de løser og hvordan de er bygget. Også i denne artikkelen vil jeg demonstrere prinsippet for drift av IXP ved å bruke EVE-NG-plattformen og BIRD-programvareruteren, slik at du har en forståelse av hvordan det fungerer "under panseret".
En bit av historien
Hvis du ser , så kan du se at den raske veksten i antall trafikkutvekslingspunkter begynte i 1993. Dette skyldes at det meste av trafikken til teleoperatørene som eksisterte på den tiden gikk gjennom det amerikanske stamnettet. Så, for eksempel, når trafikken 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 en transitt mellom Frankrike og Tyskland. Selv trafikk i ett land gikk ofte ikke direkte, men gjennom ryggradsnettverkene til amerikanske operatører.
Denne tilstanden påvirket ikke bare kostnadene ved å levere transittrafikk, men også kvaliteten på kanalene og forsinkelser. Antallet Internett-brukere økte, nye operatører dukket opp, trafikkvolumet økte og Internett modnet. Operatører over hele verden begynte å innse at det var nødvendig med en mer rasjonell tilnærming til organisering av interoperatorinteraksjon. "Hvorfor skal jeg, operatør A, betale for transitt gjennom et annet land for å levere trafikk til operatør B, som befinner seg i neste gate?" Dette er omtrent det spørsmålet teleoperatørene stilte seg selv på den tiden. Dermed begynte trafikkutvekslingspunkter å dukke opp i forskjellige deler av verden ved operatørkonsentrasjonspunkter:
- 1994 – LINX i London,
- 1995 – DE-CIX i Frankfurt,
- 1995 – MSK-IX, i Moskva, etc.
Internett og våre dager
Konseptuelt består arkitekturen til det moderne Internett av mange autonome systemer (AS) og mange forbindelser mellom dem, både fysiske og logiske, som bestemmer trafikkveien fra et AS til et annet.
AS er vanligvis telekomoperatører, Internett-leverandører, CDN-er, datasentre og bedriftssegmentselskaper. ASer organiserer logiske forbindelser (peering) seg imellom, vanligvis ved å bruke BGP-protokollen.
Hvordan autonome systemer organiserer disse forbindelsene bestemmes av en rekke faktorer:
- geografiske,
- økonomisk,
- politisk,
- avtaler og felles interesser mellom AS-eiere,
- etc.
Selvfølgelig har denne ordningen en viss struktur og hierarki. Dermed er operatører delt inn i tier-1, tier-2 og tier-3, og hvis klientene for en lokal internettleverandør (tier-3) som regel er vanlige brukere, så er for eksempel tier-1 nivåoperatører klientene er andre operatører. Tier-3-operatører aggregerer trafikken til sine abonnenter, tier-2-telekomoperatører, på sin side, aggregerer trafikken til tier-3-operatører, og tier-1 – all Internett-trafikk.
Skjematisk kan det representeres slik:
Dette bildet viser at trafikken er aggregert fra bunn til topp, dvs. fra sluttbrukere til tier-1-operatører. Det er også en horisontal utveksling av trafikk mellom AS som er tilnærmet likeverdige med hverandre.
En integrert del og samtidig en ulempe med denne ordningen er en viss forvirring av forbindelser mellom autonome systemer som ligger nærmere sluttbrukeren, innenfor et geografisk område. Tenk på bildet nedenfor:
La oss anta at det i en stor by er 5 teleoperatører, som av en eller annen grunn er organisert som vist ovenfor.
Hvis brukeren Petya, koblet til Go ISP, ønsker å få tilgang til en server koblet til ASM-leverandøren, vil trafikken mellom dem bli tvunget til å passere gjennom 5 autonome systemer. Dette øker forsinkelsen pga antall nettverksenheter som trafikk vil gå gjennom øker, samt volumet av transittrafikk på autonome systemer mellom Go og ASM.
Hvordan redusere antall transitt AS som trafikken er tvunget til å passere gjennom? Det stemmer – trafikkutvekslingspunkt.
I dag er fremveksten av nye IXP-er drevet av de samme behovene som på begynnelsen av 90-2000-tallet, bare i mindre skala, som svar på det økende antallet teleoperatører, brukere og trafikk, den økende mengden innhold generert av CDN-nettverk og datasentre.
Hva er et byttepunkt?
Et trafikkutvekslingspunkt er et sted med en spesiell nettverksinfrastruktur der deltakere som er interessert i gjensidig trafikkutveksling organiserer gjensidig peering. De viktigste deltakerne i trafikkutvekslingspunkter: teleoperatører, Internett-leverandører, innholdsleverandører og datasentre. Ved trafikkutvekslingspunkter kobles deltakerne direkte med hverandre. Dette lar deg løse følgende problemer:
- redusere latens,
- redusere mengden transittrafikk,
- optimalisere ruting mellom AS.
Tatt i betraktning at IXP-er finnes i mange store byer rundt om i verden, har alt dette en gunstig effekt på Internett som helhet.
Hvis situasjonen ovenfor med Petya løses ved hjelp av IXP, vil det vise seg noe slikt:
Hvordan fungerer et trafikkutvekslingspunkt?
Som regel er en IXP et eget AS med sin egen blokk med offentlige IPv4/IPv6-adresser.
IXP-nettverket består oftest av et kontinuerlig L2-domene. Noen ganger er dette ganske enkelt et VLAN som er vert for alle IXP-klientene. Når det gjelder større, geografisk distribuerte IXP-er, kan teknologier som MPLS, VXLAN osv. brukes til å organisere et L2-domene.
IXP-elementer
- SKS. Det er ikke noe uvanlig her: stativer, optiske krysskoblinger, patchpaneler.
- Brytere – grunnlaget for IXP. Svitsjporten er inngangspunktet til IXP-nettverket. Svitsjene utfører også en del av sikkerhetsfunksjonene – de filtrerer søppeltrafikk som ikke skal være tilstede på IXP-nettverket. Som regel velges brytere basert på funksjonelle krav - pålitelighet, støttede porthastigheter, sikkerhetsfunksjoner, sFlow-støtte, etc.
- Ruteserver (RS) – en integrert og nødvendig del av ethvert moderne trafikkutvekslingspunkt. Driftsprinsippet er veldig likt rutereflektoren i iBGP eller den utpekte ruteren i OSPF og løser de samme problemene. Etter hvert som antall deltakere i et trafikkutvekslingspunkt vokser, øker antallet BGP-økter som hver deltaker trenger å støtte, d.v.s. dette minner om den klassiske fullmesh-topologien i iBGP. RS løser problemet på følgende måte: det etablerer en BGP-sesjon med hver interesserte IXP-deltaker, og den deltakeren blir en RS-klient. Ved å motta en BGP-oppdatering fra en av sine klienter, sender RS denne oppdateringen til alle sine andre klienter, selvfølgelig, med unntak av den som denne oppdateringen ble mottatt fra. Dermed eliminerer RS behovet for å etablere en full mesh mellom alle IXP-medlemmer og løser skalerbarhetsproblemet elegant. Det er verdt å merke seg at ruteserveren transparent overfører ruter fra et AS til et annet uten å gjøre endringer i attributtene som sendes av BGP, for eksempel legger den ikke nummeret i AS til AS-banen. Også på RS er det grunnleggende filtrering av ruter: for eksempel aksepterer ikke RS Martians nettverk og prefiksene til selve IXP.
En åpen kildekode-programvareruter, BIRD (bird internet routing daemon), brukes ofte som ruteserverløsning. Det som er bra med det er at det er gratis, distribueres raskt på de fleste Linux-distribusjoner, har en fleksibel mekanisme for å sette opp ruting-/filtreringspolicyer og ikke krever dataressurser. Dessuten kan en hardware/virtuell ruter fra Cisco, Juniper, etc. velges som RS.
- Sikkerhet. Siden et IXP-nettverk er en konsentrasjon av et stort antall ASer, må sikkerhetspolicyen som alle deltakere må følge være godt skrevet. Generelt gjelder alle de samme mekanismene som gjelder når du etablerer en BGP-tilknytning mellom to separate BGP-kolleger utenfor en IXP, pluss noen ekstra sikkerhetsfunksjoner.
For eksempel er det god praksis å tillate trafikk kun fra en spesifikk mac-adresse til IXP-deltakeren, som er forhandlet på forhånd. nekte trafikk med andre ethertype-felter enn 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP); dette gjøres for å filtrere ut trafikk som ikke hører hjemme i BGP-peering. Mekanismer som GTSM, RPKI osv. kan også brukes.
Kanskje de ovennevnte er hovedkomponentene i enhver IXP, uavhengig av skala. Selvfølgelig kan større IXP-er ha flere teknologier og løsninger på plass.
Det hender at IXP også gir sine deltakere tilleggstjenester:
- plassert på IXP TLD DNS-serveren,
- installer maskinvare NTP-servere, slik at deltakerne kan synkronisere tid nøyaktig,
- gi beskyttelse mot DDoS-angrep, etc.
Prinsippet om drift
La oss se på prinsippet for drift av et trafikkutvekslingspunkt ved å bruke eksemplet på en enkel IXP, modellert med EVE-NG, og deretter vurdere det grunnleggende oppsettet til en BIRD-programvareruter. For å forenkle diagrammet vil vi utelate slike viktige ting som redundans og feiltoleranse.
Nettverkstopologien er vist i figuren nedenfor.
La oss anta at vi administrerer et lite utvekslingspunkt og tilbyr følgende peering-alternativer:
- offentlig peering,
- privat peering,
- peering via ruteserver.
AS-nummeret vårt er 555, vi eier en blokk med IPv4-adresser – 50.50.50.0/24, hvorfra vi utsteder IP-adresser for de som ønsker å koble til nettverket vårt.
50.50.50.254 – IP-adresse konfigurert på ruteservergrensesnittet, med dette vil IP-klienter etablere en BGP-sesjon i tilfelle peering via RS.
For peering via RS har vi også utviklet en enkel rutingpolicy basert på BGP-fellesskapet, som lar IXP-deltakere regulere til hvem og hvilke ruter som skal sendes:
BGP fellesskap
beskrivelse
LOCAL_AS:PEER_AS
Send prefikser bare til PEER_AS
LOCAL_AS:IXP_AS
Overfør prefikser til alle IXP-deltakere
3 klienter ønsker å koble til vår IXP og utveksle trafikk; La oss si at dette er Internett-leverandører. De ønsker alle å organisere peering gjennom en ruteserver. Nedenfor er et diagram med parametere for klienttilkobling:
kunde
Kunde AS-nummer
Kunden annonserte prefikser
IP-adresse utstedt til klienten for å koble til IXP
ISP #1
AS 100
1.1.0.0/16
50.50.50.10/24
ISP #2
AS 200
2.2.0.0/16
50.50.50.20/24
ISP #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
Det er verdt å merke seg innstillingen no bgp enforce-first-as her. Som standard krever BGP at as-banen til en mottatt BGP-oppdatering inneholder as bgp-nummeret til peeren som oppdateringen ble mottatt fra. Men siden ruteserveren ikke gjør endringer i as-path, vil nummeret ikke være i as-path og oppdateringen vil bli forkastet. Denne innstillingen brukes til å få 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 andre klienters rutere vil innstillingene være like, med unntak av 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 aksepterer prefikser for martianere, så vel som prefiksene til selve IXP:
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 som 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, bruker passende filtre og retningslinjer.
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 på en ruteserver er det god praksis å sette ruter fra forskjellige peers inn i forskjellige RIB-er. BIRD lar deg gjøre dette. I vårt eksempel, for enkelhets skyld, blir alle oppdateringer mottatt fra alle klienter lagt til en felles RIB.
Så la oss sjekke hva vi har.
På ruteserveren ser vi at det er etablert en BGP-sesjon med alle tre klientene:
Vi ser at vi mottar prefikser fra alle klienter:
På as 100-ruteren ser vi at hvis det bare er én BGP-sesjon 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 i stor grad forenkler organiseringen av peering på IXP.
Jeg håper at denne demonstrasjonen hjalp deg med å forstå hvordan IXP-er fungerer og hvordan ruteserveren fungerer på en IXP.
Linxdatacenter IX
Hos Linxdatacenter bygde vi vår egen IXP basert på en feiltolerant infrastruktur med 2 svitsjer og 2 ruteservere. Vår IXP kjører nå i testmodus, og vi inviterer alle til å koble seg til Linxdatacenter IX og delta i testing. Når du er tilkoblet, vil du bli utstyrt med en port med en båndbredde på 1 Gbit/s, muligheten til å peere gjennom ruteserverne våre, samt tilgang til din personlige konto for IX-portalen, tilgjengelig på .
Skriv i kommentarer eller private meldinger for å få tilgang til testing.
Utgang
Trafikkutvekslingspunkter oppsto ved begynnelsen av Internett som et verktøy for å løse problemet med suboptimal trafikkflyt mellom teleoperatører. Nå, med fremveksten av nye globale tjenester og en økning i mengden CDN-trafikk, fortsetter utvekslingspunkter å optimalisere driften av det globale nettverket. Økningen i antall IXP-er i verden kommer både sluttbrukeren av tjenesten til gode og teleoperatører, innholdsoperatører osv. For IXP-deltakere er fordelen uttrykt i å redusere kostnadene ved å organisere ekstern peering, redusere mengden trafikk som operatører på høyere nivå må betale for, optimalisere ruting og muligheten til å ha et direkte grensesnitt med innholdsoperatører.
Nyttige lenker
- Se et kart over plasseringen av trafikkutvekslingspunktene:
- Se detaljert statistikk om BGP-peering, inkludert tilstedeværelse på IXP:
Kilde: www.habr.com