"Vi oprettede en telefonforbindelse mellem os og fyrene på SRI...", sagde Kleinrock... i et interview:
"Vi skrev L'et, og vi spurgte i telefonen: "Ser du L'et?"
"Ja, vi ser L'et," lød svaret.
"Vi skrev O'et, og vi spurgte: "Ser du O'et."
"Ja, vi ser O'en."
"Så skrev vi G, og systemet styrtede ned"...Alligevel var en revolution begyndt...
Begyndelsen af internettet.
Hej alle!
Mit navn er Alexander, jeg er netværksingeniør hos Linxdatacenter. I dagens artikel vil vi tale om trafikudvekslingspunkter (Internet Exchange Points, IXP): hvad gik forud for deres udseende, hvilke opgaver de løser, og hvordan de er bygget. Også i denne artikel vil jeg demonstrere princippet om drift af IXP ved hjælp af EVE-NG-platformen og BIRD-softwarerouteren, så du har en forståelse for, hvordan det fungerer "under motorhjelmen".
Lidt historie
Hvis du ser , så kan du se, at den hurtige vækst i antallet af trafikudvekslingspunkter begyndte i 1993. Det skyldes, at størstedelen af den trafik fra teleoperatørerne, der eksisterede på det tidspunkt, gik gennem det amerikanske backbone-netværk. Så når trafikken for eksempel gik fra en operatør i Frankrig til en operatør i Tyskland, gik den først fra Frankrig til USA, og først derefter fra USA til Tyskland. Rygradsnettet fungerede i dette tilfælde som en transit mellem Frankrig og Tyskland. Selv trafik inden for et land passerede ofte ikke direkte, men gennem de amerikanske operatørers rygradsnetværk.
Denne situation påvirkede ikke kun omkostningerne ved at levere transittrafik, men også kvaliteten af kanaler og forsinkelser. Antallet af internetbrugere steg, nye operatører dukkede op, trafikmængden steg, og internettet modnedes. Operatører rundt om i verden begyndte at indse, at en mere rationel tilgang til at organisere inter-operator interaktion var nødvendig. "Hvorfor skal jeg, operatør A, betale for transit gennem et andet land for at levere trafik til operatør B, som er placeret på den næste gade?" Det er nogenlunde det spørgsmål, teleoperatørerne stillede sig selv dengang. Således begyndte trafikudvekslingspunkter at dukke op i forskellige dele af verden ved operatørkoncentrationspunkter:
- 1994 – LINX i London,
- 1995 – DE-CIX i Frankfurt,
- 1995 – MSK-IX, i Moskva osv.
Internettet og vores dage
Konceptuelt består arkitekturen af det moderne internet af mange autonome systemer (AS) og mange forbindelser mellem dem, både fysiske og logiske, som bestemmer trafikkens vej fra et AS til et andet.
AS'er er normalt teleoperatører, internetudbydere, CDN'er, datacentre og virksomhedssegmenter. AS'er organiserer logiske forbindelser (peering) indbyrdes, normalt ved hjælp af BGP-protokollen.
Hvordan autonome systemer organiserer disse forbindelser bestemmes af en række faktorer:
- geografiske,
- økonomisk,
- politisk,
- aftaler og fælles interesser mellem AS-ejere,
- etc.
Selvfølgelig har denne ordning en vis struktur og hierarki. Operatører er således opdelt i tier-1, tier-2 og tier-3, og hvis klienterne for en lokal internetudbyder (tier-3) som udgangspunkt er almindelige brugere, så er f.eks. tier-1 niveauoperatører klienterne er andre operatører. Tier-3-operatører aggregerer trafikken fra deres abonnenter, Tier-2-teleoperatører aggregerer til gengæld trafikken fra Tier-3-operatører og Tier-1 – al internettrafik.
Skematisk kan det repræsenteres således:
Dette billede viser, at trafikken er aggregeret fra bund til top, dvs. fra slutbrugere til tier-1-operatører. Der er også en horisontal udveksling af trafik mellem AS'er, der omtrent svarer til hinanden.
En integreret del og samtidig en ulempe ved denne ordning er en vis forvirring af forbindelser mellem autonome systemer placeret tættere på slutbrugeren inden for et geografisk område. Overvej billedet nedenfor:
Lad os antage, at der i en stor by er 5 teleoperatører, som peering imellem, af en eller anden grund, er organiseret som vist ovenfor.
Hvis brugeren Petya, der er forbundet til Go ISP, ønsker at få adgang til en server, der er forbundet til ASM-udbyderen, vil trafikken mellem dem blive tvunget til at passere gennem 5 autonome systemer. Dette øger forsinkelsen pga antallet af netværksenheder, som trafikken vil gå igennem, stiger, såvel som mængden af transittrafik på autonome systemer mellem Go og ASM.
Hvordan reducerer man antallet af transit-AS'er, som trafikken er tvunget til at passere igennem? Det er rigtigt - trafikudvekslingspunkt.
I dag er fremkomsten af nye IXP'er drevet af de samme behov som i begyndelsen af 90'erne-2000'erne, kun i mindre skala, som reaktion på det stigende antal teleoperatører, brugere og trafik, den voksende mængde indhold genereret af CDN-netværk og datacentre.
Hvad er et byttepunkt?
Et trafikudvekslingspunkt er et sted med en særlig netværksinfrastruktur, hvor deltagere, der er interesseret i gensidig trafikudveksling, organiserer gensidig peering. De vigtigste deltagere i trafikudvekslingspunkter: teleoperatører, internetudbydere, indholdsudbydere og datacentre. Ved trafikudvekslingspunkter forbinder deltagerne sig direkte med hinanden. Dette giver dig mulighed for at løse følgende problemer:
- reducere latens,
- reducere mængden af transittrafik,
- optimere routing mellem AS.
I betragtning af at IXP'er er til stede i mange store byer rundt om i verden, har alt dette en gavnlig effekt på internettet som helhed.
Hvis ovenstående situation med Petya løses ved hjælp af IXP, vil det vise sig noget som dette:
Hvordan fungerer et trafikudvekslingspunkt?
Som regel er en IXP et separat AS med sin egen blok af offentlige IPv4/IPv6-adresser.
IXP-netværket består oftest af et kontinuerligt L2-domæne. Nogle gange er dette simpelthen et VLAN, der er vært for alle IXP-klienter. Når det kommer til større, geografisk distribuerede IXP'er, kan teknologier som MPLS, VXLAN osv. bruges til at organisere et L2-domæne.
IXP elementer
- SKS. Der er ikke noget usædvanligt her: stativer, optiske krydsforbindelser, patchpaneler.
- Afbrydere – grundlaget for IXP. Switch-porten er indgangspunktet til IXP-netværket. Switchene udfører også en del af sikkerhedsfunktionerne - de filtrerer uønsket trafik, der ikke burde være til stede på IXP-netværket. Som regel vælges switches ud fra funktionelle krav - pålidelighed, understøttede porthastigheder, sikkerhedsfunktioner, sFlow-understøttelse osv.
- Ruteserver (RS) – en integreret og nødvendig del af ethvert moderne trafikudvekslingspunkt. Funktionsprincippet minder meget om rutereflektoren i iBGP eller den udpegede router i OSPF og løser de samme problemer. I takt med at antallet af deltagere i et trafikudvekslingspunkt vokser, stiger antallet af BGP-sessioner, som hver deltager skal støtte, dvs. dette minder om den klassiske full-mesh topologi i iBGP. RS løser problemet på følgende måde: det etablerer en BGP-session med hver interesseret IXP-deltager, og denne deltager bliver en RS-klient. Når RS modtager en BGP-opdatering fra en af sine klienter, sender RS denne opdatering til alle sine andre klienter, naturligvis med undtagelse af den, hvorfra denne opdatering blev modtaget. Således eliminerer RS behovet for at etablere en fuld mesh mellem alle IXP-medlemmer og løser elegant skalerbarhedsproblemet. Det er værd at bemærke, at ruteserveren transparent transmitterer ruter fra et AS til et andet uden at foretage ændringer i de attributter, der transmitteres af BGP, f.eks. tilføjer den ikke nummeret i sin AS til AS-stien. Også på RS er der grundlæggende filtrering af ruter: for eksempel accepterer RS ikke Martians netværk og præfikserne for selve IXP.
En open source-softwarerouter, BIRD (bird internet routing daemon), bruges ofte som en ruteserverløsning. Det gode ved det er, at det er gratis, implementeres hurtigt på de fleste Linux-distributioner, har en fleksibel mekanisme til opsætning af routing-/filtreringspolitikker og ikke kræver computerressourcer. Desuden kan en hardware/virtuel router fra Cisco, Juniper osv. vælges som RS.
- Sikkerhed. Da et IXP-netværk er en koncentration af et stort antal AS'er, skal sikkerhedspolitikken, som alle deltagere skal følge, være velskrevet. Generelt gælder alle de samme mekanismer, der gælder, når der etableres en BGP-adjacency mellem to separate BGP-peers uden for en IXP, plus nogle yderligere sikkerhedsfunktioner.
For eksempel er det god praksis kun at tillade trafik fra en specifik mac-adresse på IXP-deltageren, som er forhandlet på forhånd. Afvisning af trafik med andre ethertype-felter end 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP); dette gøres for at bortfiltrere trafik, der ikke hører hjemme i BGP-peering. Mekanismer som GTSM, RPKI osv. kan også bruges.
Måske er ovenstående hovedkomponenter i enhver IXP, uanset skala. Selvfølgelig kan større IXP'er have yderligere teknologier og løsninger på plads.
Det sker, at IXP også giver sine deltagere yderligere tjenester:
- placeret på IXP TLD DNS-serveren,
- installere hardware NTP-servere, så deltagerne kan synkronisere tid nøjagtigt,
- yde beskyttelse mod DDoS-angreb mv.
Virkemåde
Lad os se på princippet om drift af et trafikudvekslingspunkt ved at bruge eksemplet på en simpel IXP, modelleret ved hjælp af EVE-NG, og derefter overveje den grundlæggende opsætning af en BIRD-softwarerouter. For at forenkle diagrammet vil vi udelade sådanne vigtige ting som redundans og fejltolerance.
Netværkstopologien er vist i figuren nedenfor.
Lad os antage, at vi administrerer et lille udvekslingspunkt og tilbyder følgende peering-muligheder:
- offentlig peering,
- privat peering,
- peering via ruteserver.
Vores AS-nummer er 555, vi ejer en blok af IPv4-adresser – 50.50.50.0/24, hvorfra vi udsteder IP-adresser til dem, der ønsker at oprette forbindelse til vores netværk.
50.50.50.254 – IP-adresse konfigureret på ruteservergrænsefladen, med denne vil IP-klienter etablere en BGP-session i tilfælde af peering via RS.
Til peering via RS har vi også udviklet en simpel routingpolitik baseret på BGP-fællesskabet, som giver IXP-deltagere mulighed for at regulere, til hvem og hvilke ruter der skal sendes:
BGP-fællesskab
beskrivelse
LOCAL_AS:PEER_AS
Send kun præfikser til PEER_AS
LOCAL_AS:IXP_AS
Overfør præfikser til alle IXP-deltagere
3 klienter ønsker at oprette forbindelse til vores IXP og udveksle trafik; Lad os sige, at det er internetudbydere. De ønsker alle at organisere peering gennem en ruteserver. Nedenfor er et diagram med klientforbindelsesparametre:
Kunde
Kundens AS-nummer
Kunden annoncerede præfikser
IP-adresse udstedt til klienten for at oprette forbindelse 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
Grundlæggende BGP-opsætning på klientrouteren:
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 værd at bemærke indstillingen no bgp enforce-first-as her. Som standard kræver BGP, at as-stien til en modtaget BGP-opdatering indeholder as bgp-nummeret på den peer, hvorfra opdateringen blev modtaget. Men da ruteserveren ikke foretager ændringer i as-stien, vil dens nummer ikke være i as-stien, og opdateringen vil blive kasseret. Denne indstilling bruges til at få routeren til at ignorere denne regel.
Vi ser også, at klienten har sat bgp community 555:555 til dette præfiks, hvilket ifølge vores politik betyder, at klienten ønsker at annoncere dette præfiks til alle andre deltagere.
For andre klienters routere vil indstillingerne være ens, med undtagelse af deres unikke parametre.
Eksempel på BIRD-konfiguration:
define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];
template bgp RS_CLIENT {
local as ixp_as;
rs client;
}
Det følgende beskriver et filter, der ikke accepterer præfikser fra martianere, såvel som præfikserne for 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 funktion implementerer den routingpolitik, 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, anvender passende filtre og politikker.
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 værd at bemærke, at det på en ruteserver er god praksis at lægge ruter fra forskellige peers ind i forskellige RIB'er. BIRD giver dig mulighed for at gøre dette. I vores eksempel bliver alle opdateringer modtaget fra alle klienter for nemheds skyld tilføjet til én fælles RIB.
Så lad os tjekke, hvad vi har.
På ruteserveren ser vi, at der er etableret en BGP-session med alle tre klienter:
Vi ser, at vi modtager præfikser fra alle kunder:
På as 100-routeren ser vi, at hvis der kun er én BGP-session med ruteserveren, modtager vi præfikser fra både som 200 og som 300, mens BGP-attributterne ikke har ændret sig, som om peering mellem klienter blev udført direkte:
Således ser vi, at tilstedeværelsen af en ruteserver i høj grad forenkler tilrettelæggelsen af peering på IXP.
Jeg håber, at denne demonstration hjalp dig med bedre at forstå, hvordan IXP'er fungerer, og hvordan ruteserveren fungerer på en IXP.
Linxdatacenter IX
Hos Linxdatacenter byggede vi vores egen IXP baseret på en fejltolerant infrastruktur med 2 switches og 2 ruteservere. Vores IXP kører nu i testtilstand, og vi inviterer alle til at oprette forbindelse til Linxdatacenter IX og deltage i test. Når du er tilsluttet, vil du blive forsynet med en port med en båndbredde på 1 Gbit/s, mulighed for at peere gennem vores ruteservere, samt adgang til din personlige konto på IX-portalen, tilgængelig på .
Skriv i kommentarer eller private beskeder for at få adgang til test.
Output
Trafikudvekslingspunkter opstod ved internettets begyndelse som et værktøj til at løse problemet med suboptimal trafikstrøm mellem teleoperatører. Nu, med fremkomsten af nye globale tjenester og en stigning i mængden af CDN-trafik, fortsætter udvekslingspunkter med at optimere driften af det globale netværk. Stigningen i antallet af IXP'er i verden kommer både slutbrugeren af tjenesten og teleoperatører, indholdsoperatører mv. For IXP-deltagere kommer fordelen til udtryk i at reducere omkostningerne ved at organisere ekstern peering, reducere mængden af trafik, som operatører på højere niveau skal betale for, optimere routing og muligheden for at have en direkte grænseflade med indholdsoperatører.
Nyttige links
- Se et kort over placeringen af trafikudvekslingspunkter:
- Se detaljerede statistikker om BGP-peering, inklusive tilstedeværelse på IXP:
Kilde: www.habr.com