«Vi etablerade en telefonkontakt mellan oss och killarna pĂ„ SRIâŠÂ», sade Kleinrock i en intervju:
«Vi skrev L och frĂ„gade i telefonen, âSer ni L?â»
«Ja, vi ser L,» kom svaret.
«Vi skrev O, och vi frĂ„gade, âSer ni O?â»
«Ja, vi ser O.»
«Sedan skrev vi G, och systemet kraschade»âŠĂndĂ„ hade en revolution börjatâŠ
Begynnelsen av internet.
Hej alla!
Jag heter Alexander, jag Ă€r nĂ€tverksingenjör pĂ„ Linxdatacenter. I dagens artikel kommer vi att prata om trafikbytespunkter (Internet Exchange Point, IXP): vad som föregick deras uppkomst, vilka problem de löser och hur de byggs. Jag kommer ocksĂ„ att visa principen för hur IXP fungerar med hjĂ€lp av plattformen EVE-NG och mjukvaruroutern BIRD, för att ge en förstĂ„else för hur det fungerar âunder huvenâ.
Lite historia
Om man ser pĂ„ , kan man mĂ€rka att den snabba tillvĂ€xten av trafikbytespunkter började 1993. Detta beror pĂ„ att den mesta trafiken frĂ„n dĂ„varande teleoperatörer passerade genom USA:s backbone-nĂ€t. SĂ„ nĂ€r till exempel trafiken gick frĂ„n en operatör i Frankrike till en operatör i Tyskland, gick den först frĂ„n Frankrike till USA, och sedan frĂ„n USA till Tyskland. Backbone-nĂ€tet fungerade i detta fall som en transit mellan Frankrike och Tyskland. Ăven trafiken inom ett och samma land passerade ofta inte direkt, utan via de amerikanska operatörernas backbone-nĂ€t.
Denna situation pÄverkade inte bara kostnaden för att leverera transittrafik, utan ocksÄ kvaliteten pÄ kanalerna och fördröjningen. Antalet anvÀndare av internet ökade, nya operatörer kom till, trafikvolymerna vÀxte, och internet blev mer moget. Operatörer vÀrlden över började förstÄ att det behövdes en mer rationell metod för att organisera samarbetet mellan operatörer. «Varför skulle jag, operatör A, betala för transit genom ett annat land för att leverera trafik till operatör B, som ligger pÄ grannen gatan?». Detta var en frÄga som teleoperatörer stÀllde sig sjÀlva pÄ den tiden. DÀrför började trafikbytespunkter dyka upp i stadsdelar vÀrlden över dÀr operatörer koncentrerades:
- 1994 â LINX i London,
- 1995 â DE-CIX i Frankfurt,
- 1995 â MSK-IX, i Moskva, etc.
Internet och vÄra dagar
Konceptuellt bestÄr arkitekturen för det moderna internet av mÄnga autonoma system (autonomous system, AS) och mÄnga kopplingar mellan dem, bÄde fysiska och logiska, som definierar trafikrouten frÄn ett AS till ett annat.
Normalt representeras AS av telekommunikationsoperatörer, internetleverantörer, CDN, datacenter och företag inom enterprise-segmentet. AS organiserar logiska kopplingar (peering) mellan varandra, oftast genom protokollet BGP.
Hur de autonoma systemen organiserar dessa kopplingar bestÀms av flera faktorer:
- geografiska,
- ekonomiska,
- politiska,
- överenskommelser och gemensamma intressen mellan Àgarna av AS,
- och sÄ vidare.
Naturligtvis finns det en viss struktur och hierarki i detta schema. SÄledes delas operatörerna in i tier-1, tier-2 och tier-3, och om kunderna för en lokal internetleverantör (tier-3) i regel Àr vanliga anvÀndare, sÄ Àr kunderna för tier-1 operatörer andra operatörer. Tier-3 operatörerna aggregerar trafiken frÄn sina abonnenter, tier-2 operatörerna aggregerar i sin tur trafiken frÄn tier-3 operatörerna, och tier-1 aggregerar all internettrafik.
Schematisk kan detta presenteras sÄ hÀr:
PÄ denna bild syns att trafiken aggregeras uppifrÄn och ner, dvs. frÄn slutkunder till tier-1 operatörerna. Det finns ocksÄ en horisontell trafiköverföring mellan ungefÀr likvÀrdiga AS.
En obskÀlig del och samtidigt en nackdel med detta schema Àr en viss oordning i kopplingarna mellan de autonoma systemen som ligger nÀrmare slutkunden inom det geografiska omrÄdet. LÄt oss titta pÄ bilden nedan:
Anta att det finns 5 telekommunikationsoperatörer i en stor stad, dÀr peeringen mellan dem av olika skÀl Àr organiserad som beskrivits ovan.
Om anvÀndaren Petja, som Àr ansluten till internetleverantören Go, vill fÄ tillgÄng till en server som Àr ansluten till leverantören ASM, kommer trafiken mellan dem att behöva passera genom 5 autonoma system. Detta ökar fördröjningen, eftersom antalet nÀtverksenheter genom vilka trafiken passerar ökar, liksom volymen av transittrafik pÄ de autonoma systemen mellan Go och ASM.
Hur kan man minska antalet transit AS som trafiken mĂ„ste passera? RĂ€tt svar Ă€r â en trafikutbytespunkt.
I dagens lÀge uppstÄr nya IXP fortfarande av samma behov som i början av 90-talet till 2000-talet, men pÄ en mindre skala, som ett svar pÄ det ökande antalet telekommunikationsoperatörer, anvÀndare och trafik, samt den vÀxande mÀngden innehÄll som genereras av CDN-nÀtverk och datacenter.
Vad Àr en trafikutbytespunkt?
En trafikutbytespunkt Àr en plats med speciell nÀtverksinfrastruktur dÀr intressenter som vill byta trafik organiserar peer-to-peer-anslutningar. De viktigaste deltagarna i trafikutbytespunkter Àr telekommunikationsoperatörer, internetleverantörer, innehÄllsleverantörer och datacenter. I trafikutbytespunkter kopplas deltagarna direkt samman. Detta möjliggör att lösa följande uppgifter:
- minska latens,
- minska mÀngden transittrafik,
- optimera routingen mellan AS.
Med tanke pÄ att IXP finns i mÄnga stora stÀder runt om i vÀrlden, sÄ har detta en positiv inverkan pÄ internetnÀtverket i stort.
Om man hanterar situationen med Petya ovan genom IXP, ser det ut ungefÀr sÄ hÀr:
Hur fungerar en trafikutbytespunkt?
IXP Àr vanligtvis ett separat AS med sitt eget block av offentliga IPv4/IPv6-adresser.
NÀtverket för IXP Àr oftast en sammanhÀngande L2-domÀn. Ibland Àr det helt enkelt ett VLAN dÀr alla IXP-kunder placeras. NÀr det handlar om större, geografiskt spridda IXP, kan sÄdana teknologier som MPLS, VXLAN etc. anvÀndas för att organisera L2-domÀnen.
Element i IXP
- SCS. HÀr Àr inget ovanligt: skÄp, optiska kopplingar, patchpaneler.
- Switchar â grunden för IXP. Switchporten Ă€r en ingĂ„ngspunkt till IXP-nĂ€tverket. Switchar utför ocksĂ„ vissa sĂ€kerhetsfunktioner â de filtrerar bort skrĂ€ppakett som inte bör finnas i IXP-nĂ€tverket. Vanligtvis vĂ€ljs switchar baserat pĂ„ funktionalitetskraven â tillförlitlighet, stöd för porthastigheter, sĂ€kerhetsfunktioner, stöd för sFlow, etc.
- Route server (RS) â en oersĂ€ttlig och nödvĂ€ndig del av varje modern trafikbytespunkt. Den fungerar pĂ„ ett sĂ€tt som liknar route reflector i iBGP eller designated router i OSPF och löser samma problem. NĂ€r antalet deltagare i trafikbytespunkten ökar, ökar Ă€ven antalet BGP-sessioner som varje deltagare mĂ„ste stödja, vilket pĂ„minner om den klassiska full-mesh-topologin i iBGP. RS löser problemet pĂ„ följande sĂ€tt: den upprĂ€ttar en BGP-session med varje intresserad deltagare i IXP, och denne blir klient till RS. NĂ€r RS tar emot en BGP-update frĂ„n en av sina klienter, skickar den denna update till alla övriga klienter, naturligtvis med undantag för den som uppdateringen mottogs ifrĂ„n. PĂ„ sĂ„ sĂ€tt frigör RS deltagarna frĂ„n behovet av att skapa en full-mesh mellan alla IXP-deltagare och löser elegant skalbarhetsproblemet. Det Ă€r vĂ€rt att notera att ruteren transparent vidarebefordrar rutter frĂ„n en AS till en annan, utan att göra nĂ„gra förĂ€ndringar i de överförda BGP-attributen, till exempel lĂ€gger den inte till sitt eget AS-nummer i AS-path. Dessutom sker grundlĂ€ggande filtrering av rutter pĂ„ RS: till exempel tar RS inte emot martians networks och prefixen som tillhör IXP.
Som lösning anvĂ€nds ofta en programvarurouter med öppen kĂ€llkod â BIRD (bird internet routing daemon). Den Ă€r bra pĂ„ sĂ„ sĂ€tt att den Ă€r gratis, snabbt kan sĂ€ttas upp pĂ„ de flesta Linux-distributioner, har en flexibel mekanism för konfiguration av routnings-/filtreringspolicyer och Ă€r inte resurskrĂ€vande. Dessutom kan en hĂ„rdvaru-/virtuell router frĂ„n Cisco, Juniper etc. ocksĂ„ vĂ€ljas som RS.
- SÀkerhet. Eftersom IXP-nÀtverket Àr en koncentration av ett stort antal AS, mÄste sÀkerhetspolicyn som alla deltagare följer vara vÀl definierad. I allmÀnhet tillÀmpas alla de mekanismer som anvÀnds vid etablering av BGP-grannskap mellan tvÄ separata BGP-peer utanför IXP Àven hÀr, samt vissa ytterligare skyddsmedel.
Till exempel Àr det en god praxis att bara slÀppa trafik frÄn en viss MAC-adress för en IXP-deltagare, vilket avtalas i förvÀg. Blockera trafik med ethertype-fÀlt som skiljer sig frÄn 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP); detta görs för att filtrera bort trafik som inte har nÄgon plats vid BGP-pirring. Mekanismer som GTSM, RPKI, etc. kan ocksÄ tillÀmpas.
Detta Àr sannolikt de grundlÀggande komponenterna i varje IXP oavsett skala. SjÀlvklart kan större IXP tillÀmpa ytterligare teknologier och lösningar.
Det hÀnder att IXP ocksÄ erbjuder sina deltagare ytterligare tjÀnster:
- placera TLD DNS-servrar pÄ IXP,
- installera hÄrdvaru-NTP-servrar för att ge deltagarna möjlighet att exakt synkronisera tiden,
- tillhandahÄlla skydd mot DDoS-attacker, etc.
Arbetsprincip.
LÄt oss gÄ igenom funktionen hos en trafikbytespunkt med exemplet av en enklaste IXP, som modelleras med hjÀlp av EVE-NG, och sedan gÄ igenom grundkonfigurationen av mjukvaruroutern BIRD. För att förenkla schemat kommer vi att utelÀmna viktiga aspekter som redundans och felövervakning.
NĂ€tverks topologin presenteras i bilden nedan.
Anta att vi administrerar en liten trafikbytespunkt och erbjuder följande möjligheter för pirring:
- offentlig pirring,
- privat pirring,
- pirring via route server.
Numret pĂ„ vĂ„r AS Ă€r 555, vi Ă€ger en block av IPv4-adresser â 50.50.50.0/24, frĂ„n vilken vi tilldelar IP-adresser till de som vill ansluta till vĂ„rt nĂ€tverk.
50.50.50.254 Àr IP-adressen som Àr konfigurerad pÄ interface för route-servern, med denna IP kommer kunderna att etablera BGP-sessioner vid pirring via RS.
För pirring via RS har vi ocksÄ utvecklat en enkel routingpolicy baserad pÄ BGP-community, som gör det möjligt för deltagarna i IXP att reglera vem och vilka rutter som ska skickas:
BGP-community
Beskrivning
LOCAL_AS:PEER_AS
Skicka prefix endast till PEER_AS
LOCAL_AS:IXP_AS
Skicka prefix till alla deltagare i IXP
Tre kunder vill ansluta sig till vÄrt IXP och utbyta trafik; lÄt oss sÀga att detta Àr internetleverantörer. Alla vill organisera pirring via route server. Nedan presenteras schemat med parametrarna för kundernas anslutning:
Klient
Kundens AS-nummer
Prefix som kunden annonserar
IP-adress tilldelad kunden för att ansluta till 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
Grundkonfiguration av BGP pÄ kundens router:
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
HÀr ska vi nÀmna instÀllningen no bgp enforce-first-as. Som standard krÀver BGP att nummer pÄ as-path för den mottagna BGP-uppdateringen inkluderar BGP-peerens as-nummer, frÄn vilken uppdateringen mottogs. Eftersom route-servern inte gör nÄgra förÀndringar i as-path, kommer dess nummer att saknas i as-path vilket leder till att uppdateringen avvisas. Denna instÀllning tillÀmpas för att routern ska börja ignorera denna regel.
Vi ser ocksÄ att kunden har angett BGP-communityn 555:555 för denna prefix, vilket enligt vÄr policy innebÀr att kunden vill annonsera denna prefix till alla andra deltagare.
För routrarna hos andra kunder kommer instÀllningen att vara liknande, med undantag för deras unika parametrar.
Exempel 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;
}
Nedan beskrivs en filter som inte accepterar martians-prefixer samt prefixerna frÄn sjÀlva 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;
}
Denna funktion implementerar den routingpolicy som vi beskrev tidigare.
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 konfigurerar peeringen, tillÀmpar motsvarande filter och 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 Àr vÀrt att nÀmna att det Àr god sed pÄ route servern att lagra rutter frÄn olika peers i olika RIB:ar. BIRD gör detta möjligt. I vÄrt exempel, för enkelhetens skull, lagras alla uppdateringar som mottas frÄn alla kunder i en gemensam RIB.
SÄ, lÄt oss kontrollera vad vi har Ästadkommit.
PÄ route-servern ser vi att det finns en BGP-session upprÀttad med alla tre kunder:
Vi ser att vi fÄr prefix frÄn alla kunder:
PÄ routern med as 100 ser vi att med endast en BGP-session med route-servern fÄr vi prefix frÄn bÄde as 200 och as 300, och BGP-attributen har inte Àndrats, precis som om peeringen mellan kunderna hade skett direkt:
SÄledes ser vi att nÀrvaron av route-servern avsevÀrt förenklar organiseringen av peeringen pÄ IXP.
Jag hoppas att denna demonstration har hjÀlpt dig att bÀttre förstÄ hur trafikbytespunkter Àr uppbyggda och hur en route-server fungerar pÄ IXP.
Linxdatacenter IX
PÄ Linxdatacenter har vi byggt vÄr egen IXP baserad pÄ en redundans-infrastruktur med 2 switchar och 2 route-servrar. Just nu körs vÄr IXP i testlÀge och vi bjuder in alla intresserade att ansluta sig till Linxdatacenter IX och delta i testningen. Vid anslutning fÄr ni en port med en kapacitet pÄ 1 Gbit/s, möjlighet till peerning via vÄra route-servrar, samt tillgÄng till personlig profil pÄ IX-portalen, tillgÀnglig pÄ adressen .
Skriv i kommentarerna eller skicka meddelanden för att fÄ tillgÄng till testningen.
Utdata
Trafikbytespunkter uppstod i internets tidiga dagar som ett verktyg för att lösa problemet med icke-optimal trafikflöde mellan telekommunikationsoperatörer. Nu, med nya globala tjĂ€nster och en ökning av CDN-trafiken, fortsĂ€tter trafikbytespunkterna att optimera den globala nĂ€tverksdriften. Ăkningen av antalet IXP i vĂ€rlden gynnar bĂ„de slutanvĂ€ndarna av tjĂ€nsterna och telekommunikationsoperatörerna, innehĂ„llsoperatörerna, etc. För deltagarna i IXP yttrar sig vinsten i lĂ€gre kostnader för organisation av externa peerningar, minskning av mĂ€ngden trafik som mĂ„ste betalas för av högre liggande operatörer, optimering av ruttning och möjligheten att ha direktanslutning till innehĂ„llsoperatörerna.
Nyttiga lÀnkar
- Se kartan över lÀget för trafikbytespunkter:
- Se detaljerad statistik för BGP-peering, inklusive nÀrvaro pÄ IXP:
KĂ€lla: habr.com
