«Vi oprettede en telefonforbindelse mellem os og drengene fra SRI…», sagde Kleinrock i et interview:
«Vi indtastede L, og vi spurgte i telefonen, „Ser I L?“»
«Ja, vi ser L,» kom svaret.
«Vi indtastede O, og vi spurgte, „Ser I O?“»
«Ja, vi ser O.»
«Så indtastede vi G, og systemet crashede»…Alligevel var en revolution begyndt…
Begyndelsen på internettet.
Hej alle sammen!
Mit navn er Alexander, jeg er netværksingeniør hos Linxdatacenter. I dagens artikel vil jeg tale om internetudvekslingspunkter (Internet Exchange Point, IXP): hvad der gik forud for deres fremkomst, hvilke opgaver de løser, og hvordan de bygges. Jeg vil også demonstrere princippet i IXP ved hjælp af platformen EVE-NG og software routeren BIRD, så man får en forståelse af, hvordan det fungerer «under motorhjelmen».
Lidt historie
Hvis vi ser på , kan vi bemærke, at den kraftige vækst i antallet af internetudvekslingspunkter begyndte i 1993. Dette skyldes, at størstedelen af trafikken fra de eksisterende telekommunikationsoperatører på det tidspunkt gik gennem backbone-netværket i USA. For eksempel, når trafikken gik fra en operatør i Frankrig til en operatør i Tyskland, kom den fra Frankrig til USA, og derefter fra USA til Tyskland. Backbone-netværket fungerede her som transit mellem Frankrig og Tyskland. Selv trafikken inden for et enkelt land gik ofte ikke direkte, men derimod via de amerikanske operatørers kerne-netværk.
Denne situation påvirkede ikke kun omkostningerne ved transittrafik, men også kvaliteten af kanalerne og forsinkelsen. Antallet af brugere af internettet steg, nye operatører kom til, trafikvolumen voksede, og internettet blev mere modent. Operatører over hele verden begyndte at indse, at der var behov for en mere rationel tilgang til organiseringen af interoperatør-interaktion. „Hvorfor skulle jeg, operatør A, betale for transit gennem et andet land for at levere trafik til operatør B, som ligger på den nærliggende gade?“ Sådan et spørgsmål stillede telekommunikationsoperatørerne sig selv på det tidspunkt. Derfor begyndte der at dukke sig internetudvekslingspunkter op i forskellige dele af verden ved punkter, hvor operatørerne koncentrerede sig:
- 1994 – LINX i London,
- 1995 – DE-CIX i Frankfurt,
- 1995 – MSK-IX, i Moskva osv.
Internettet og vore dage
Konceptuelt repræsenterer arkitekturen af det moderne internet mange autonome systemer (autonomous system, AS) og mange forbindelser imellem dem, både fysiske og logiske, som definerer ruten for trafik fra et AS til et andet.
Som AS fungerer typisk telekommunikationsoperatører, internetudbydere, CDN, datacentre og virksomheder i enterprise-segmentet. AS organiserer logiske forbindelser (peering) imellem hinanden, som regel ved hjælp af BGP-protokollen.
Hvordan de autonome systemer organiserer disse forbindelser, bestemmes af en række faktorer:
- geografiske,
- økonomiske,
- politiske,
- aftaler og fælles interesser mellem ejerne af AS,
- osv.
Selvfølgelig er der en vis struktur og hierarki i denne skema. Således opdeles operatørerne i tier-1, tier-2 og tier-3, og hvis kunderne for den lokale internetudbyder (tier-3) typisk er almindelige brugere, så er kunderne for tier-1 operatører f.eks. andre operatører. Tier-3 operatører aggregerer trafikken fra deres abonnenter, tier-2 operatører aggregerer i sin tur traffiken fra tier-3 operatører, mens tier-1 aggregerer al internettrafik.
Schematic set kan dette præsenteres sådan:
På billedet nedenfor kan man se, at trafikken aggregeres oppefra og ned, dvs. fra slutbrugerne til tier-1 operatørerne. Derudover finder der også horisontal trafikudveksling sted mellem omtrent ligestillede AS.
En uadskillelig del og samtidig en ulempe ved denne skema er en vis uorden i forbindelserne mellem de autonome systemer, der ligger tættere på slutbrugeren inden for det geografiske område. Lad os se på billedet nedenfor:
Antag, at der er 5 telekommunikationsoperatører i en storby, hvor peering mellem dem er organiseret, som vist ovenfor, af årsagerne her til.
Hvis brugeren Petya, der er tilsluttet internetudbyderen Go, ønsker adgang til en server tilsluttet udbyderen ASM, så må trafikken imellem dem passere gennem 5 autonome systemer. Dette øger forsinkelsen, da antallet af netværksenheder, som trafikken skal passere gennem, stiger, og også mængden af transittrafik på de autonome systemer mellem Go og ASM.
Hvordan kan man reducere antallet af transit-AS, som trafikken tvinges til at passere? Rigtigt – et trafikbyttepunkt.
I dag er fremkomsten af nye IXP stadig drevet af de samme behov som i begyndelsen af 90'erne til 2000'erne, men i en mindre skala som svar på det stigende antal telekommunikationsoperatører, brugere og trafik, samt den voksende mængde indhold genereret af CDN-netværk og datacentre.
Hvad er et traffic exchange point?
Et traffic exchange point er et sted med en specialiseret netværksinfrastruktur, hvor interesserede parter, der ønsker at udveksle trafik, organiserer gensidig peering. Hoveddeltagerne i traffic exchange points er telekommunikationsoperatører, internetudbydere, indholdsudbydere og datacentre. På traffic exchange points forbinder deltagerne sig direkte med hinanden. Dette gør det muligt at løse følgende opgaver:
- reducere latenstid,
- minimere transit trafik,
- optimere routing mellem AS.
Da IXP er til stede i mange store byer verden over, påvirker dette også internettet positivt som helhed.
Hvis vi skulle løse den tidligere nævnte situation med Petya ved hjælp af IXP, ville det se omtrent sådan ud:
Hvordan er et traffic exchange point opbygget?
Som regel er IXP en separat AS med sin egen blok af offentlige IPv4/IPv6 adresser.
Netværket IXP består oftest af et sammenhængende L2-domæne. Nogle gange er det bare et VLAN, hvor alle IXP-kunder placeres. Når det drejer sig om større, geografisk distribuerede IXP, kan teknologier som MPLS, VXLAN osv. anvendes til at organisere L2-domænet.
Elementer af IXP
- SKS. Her er der ikke noget usædvanligt: reoler, optiske krydskoblinger, patch-paneler.
- Switchene – grundlaget for IXP. Switch-porten er indgangspunktet til IXP-netværket. Switche udfører også nogle sikkerhedsfunktioner – de filtrerer uønsket trafik, som ikke må være til stede på IXP-netværket. Som regel vælges switches baseret på funktionalitetskrav – pålidelighed, understøttede porte hastigheder, sikkerhedsfunktioner, støtte til sFlow osv.
- Route server (RS) – en uundgåelig og nødvendig del af ethvert moderne trafikudvekslingspunkt. Funktionelt minder det meget om en route reflector i iBGP eller en designated router i OSPF og løser de samme problemer. Efterhånden som antallet af deltagere i trafikudvekslingspunktet vokser, stiger mængden af BGP-sessioner, som hver deltager skal opretholde, hvilket minder om den klassiske full-mesh topologi i iBGP. RS løser problemet på følgende måde: den opretter en BGP-session med hver interesseret deltager IXP, og denne deltager bliver klient af RS. Når RS modtager en BGP-update fra en af sine klienter, sender den denne opdatering videre til alle sine andre klienter, naturligvis med undtagelse af den, som denne update blev modtaget fra. På den måde slipper RS for at oprette et full-mesh mellem alle deltagere i IXP og løser elegant skalerbarhedsproblemet. Det skal bemærkes, at route serveren transparent videregiver ruter fra én AS til en anden uden at ændre de overførte BGP-attributter, for eksempel tilføjer den ikke sit eget AS-nummer i AS-path. Desuden foregår der grundlæggende filtrering af ruter på RS: eksempelvis accepterer RS ikke martians networks eller præfiksene for selve IXP.
Som løsning anvendes der ofte en software-router med åbent kildekode – BIRD (bird internet routing daemon). Det er godt, fordi det er gratis, hurtigt kan implementeres på de fleste Linux-distributioner, har en fleksibel mekanisme til opsætning af routing-/filtreringspolitikker og er ikke krævende med hensyn til computerressourcer. Derudover kan også en hardware-/virtuelt router fra Cisco, Juniper osv. vælges som RS.
- Sikkerhed. Da IXP-netværket er en koncentration af et stort antal AS, skal de sikkerhedspolitikker, som alle deltagere skal følge, være velbeskrevne. Generelt gælder de samme mekanismer, som anvendes ved oprettelse af BGP-naboer mellem to separate BGP-peers uden for IXP, også her, og der anvendes nogle yderligere beskyttelsesmidler.
For example, a good practice is to allow traffic only from a specific MAC address of the IXP participant, which is agreed upon in advance. Banning traffic with ethertype fields differing from 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP); this is done to filter out traffic that has no place during BGP peering. Mechanisms such as GTSM, RPKI, etc., can also be used.
Certainly, the aforementioned are the main components of any IXP regardless of its scale. Of course, larger IXPs may employ additional technologies and solutions.
Sometimes, IXPs also provide their participants with additional services:
- hosting TLD DNS servers at the IXP,
- installing hardware NTP servers, allowing participants to synchronize time accurately,
- providing protection against DDoS attacks, etc.
Arbejdets princip
Let's break down the functioning of a traffic exchange point using an example of a simple IXP simulated using EVE-NG, and then we will look at the basic configuration of the BIRD software router. To simplify the scheme, we will skip important aspects such as redundancy and fault tolerance.
The network topology is shown in the figure below.
Assuming we administer a small traffic exchange point and provide the following peering options:
- public peering,
- private peering,
- peering through a route server.
Our AS number is 555, we own a block of IPv4 addresses – 50.50.50.0/24, from which we distribute IP addresses to those wishing to connect to our network.
50.50.50.254 is the IP address configured on the route server interface, with this IP the clients will establish a BGP session in case of peering through RS.
Also, for peering through RS, we developed a simple routing policy based on BGP community, which allows IXP participants to control to whom and which routes to send:
BGP community
Description
LOCAL_AS:PEER_AS
Transmit prefixes only to PEER_AS
LOCAL_AS:IXP_AS
Transmit prefixes to all IXP participants
Three clients want to connect to our IXP and exchange traffic; let's assume they are Internet service providers. All of them want to organize peering through the route server. Below is a diagram with the connection parameters of the clients:
Kunde
Client AS number
Prefixes announced by the client
IP address assigned to the client for connecting to the 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
Basic BGP configuration on the client's 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
Det er værd at bemærke konfigurationen no bgp enforce-first-as. Som standard kræver BGP, at AS-nummeret for den BGP-peer, der har sendt opdateringen, er til stede i AS-stien. Men da rute-serveren ikke ændrer AS-stien, vil dens nummer mangle i AS-stien, og opdateringen vil blive forkastet. Denne indstilling anvendes for at få routeren til at ignorere denne regel.
Vi ser også, at klienten har indstillet BGP-community 555:555 for dette præfiks, hvilket ifølge vores politik betyder, at klienten ønsker at annoncere dette præfiks til alle andre deltagere.
For routerne hos de andre klienter vil konfigurationen være analog, dog med 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;
}
Derefter beskrives en filter, der ikke accepterer martians-præfikser samt IXP-præfikserne:
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 routing-politik, som vi tidligere har beskrevet.
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 de 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 er god stil på rute-serveren at opbevare ruter fra forskellige peers i forskellige RIB. BIRD tillader dette. I vores eksempel opbevares alle opdateringer fra alle klienter i en fælles RIB for enkelhedens skyld.
Lad os tjekke, hvad vi har fået.
På route-serveren ser vi, at der er etableret en BGP-session med alle tre kunder:
Vi ser, at vi modtager præfikser fra alle kunder:
På routeren AS 100 ser vi, at med kun én BGP-session med route-serveren, får vi præfikser fra både AS 200 og AS 300, samtidig med at BGP-attributterne er forblevet uændrede, som hvis peering mellem kunderne var sket direkte:
Dermed ser vi, at tilstedeværelsen af en route-server væsentligt forenkler organiseringen af peering på IXP.
Jeg håber, at denne demonstration har hjulpet dig med at forstå bedre, hvordan trafikbyttepunkter fungerer, og hvordan arbejdet med route-servere implementeres på IXP.
Linxdatacenter IX
Hos Linxdatacenter har vi oprettet vores eget IXP baseret på en fejltolerant infrastruktur af 2 switches og 2 route-servere. Vores IXP er nu i testdrift, og vi inviterer alle interesserede til at tilslutte sig Linxdatacenter IX og deltage i testen. Ved tilslutning får du en port med en båndbredde på 1 Gbit/s, mulighed for peering via vores route-servere samt adgang til det private IX-portal, som er tilgængeligt på adressen .
Skriv i kommentarerne eller direkte meddelelser for at få adgang til testen.
Output
Trafikbyttepunkter opstod i internettets spæde begyndelse som værktøjer til at løse problemet med suboptimal trafikflytning mellem telekommunikationsoperatører. I takt med at nye globale tjenester og mængden af CDN-trafik er steget, optimerer trafikbyttepunkter stadig arbejdet i det globale netværk. Stigningen af IXP i verden er gavnlig for både slutbrugerne af tjenesten samt telekommunikationsoperatører, indholdsoperatører osv. For deltagerne i IXP manifesterer gevinsten sig i form af reducerede omkostninger for etablering af eksterne peerings, en reduktion i mængden af trafik, som der skal betales til overliggende operatører, optimering af routingen og mulighed for at have direkte forbindelser til indholdsoperatører.
Nyttige links
- Se kortet over placeringen af trafikbyttepunkter:
- Se detaljeret statistik om BGP-peering, inklusive tilstedeværelse på IXP:
Kilde: habr.com
