“We hebben een telefoonverbinding opgezet tussen ons en de jongens van SRI...”, zei Kleinrock... in een interview:
“We typten de L en vroegen aan de telefoon: “Zie je de L?”
“Ja, we zien de L”, was het antwoord.
"We typten de O en vroegen:" Zie je de O. ""
"Ja, we zien de O."
“Toen typten we de G, en het systeem crashte”...Toch was er een revolutie begonnen...
Het begin van internet.
Hallo iedereen!
Mijn naam is Alexander, ik ben netwerkingenieur bij Linxdatacenter. In het artikel van vandaag zullen we het hebben over verkeersuitwisselingspunten (Internet Exchange Points, IXP): wat aan hun verschijning voorafging, welke taken ze oplossen en hoe ze zijn gebouwd. Ook in dit artikel zal ik het werkingsprincipe van IXP demonstreren met behulp van het EVE-NG-platform en de BIRD-softwarerouter, zodat u begrijpt hoe het “onder de motorkap” werkt.
Een beetje geschiedenis
Als je kijkt , dan kun je zien dat de snelle groei van het aantal verkeersknooppunten in 1993 begon. Dit komt door het feit dat het grootste deel van het verkeer van de toenmalige telecomoperatoren via het Amerikaanse backbone-netwerk verliep. Wanneer het verkeer bijvoorbeeld van een operator in Frankrijk naar een operator in Duitsland ging, ging het eerst van Frankrijk naar de VS, en pas daarna van de VS naar Duitsland. Het backbone-netwerk fungeerde in dit geval als doorvoer tussen Frankrijk en Duitsland. Zelfs verkeer binnen één land verliep vaak niet rechtstreeks, maar via de backbone-netwerken van Amerikaanse operators.
Deze stand van zaken had niet alleen gevolgen voor de kosten voor het leveren van transitverkeer, maar ook voor de kwaliteit van de kanalen en vertragingen. Het aantal internetgebruikers nam toe, er verschenen nieuwe operators, het verkeersvolume nam toe en het internet werd volwassen. Operators over de hele wereld begonnen te beseffen dat er een meer rationele benadering nodig was voor het organiseren van interactie tussen operators. “Waarom zou ik, operator A, betalen voor doorvoer door een ander land om verkeer te bezorgen bij operator B, die zich in de volgende straat bevindt?” Dit is ongeveer de vraag die telecomoperatoren zich destijds stelden. Zo begonnen verkeersuitwisselingspunten in verschillende delen van de wereld te verschijnen op operatorconcentratiepunten:
- 1994 – LINX in Londen,
- 1995 – DE-CIX in Frankfurt,
- 1995 – MSK-IX, in Moskou, enz.
Internet en onze dagen
Conceptueel gezien bestaat de architectuur van het moderne internet uit veel autonome systemen (AS) en veel verbindingen daartussen, zowel fysiek als logisch, die het pad van verkeer van het ene AS naar het andere bepalen.
AS's zijn doorgaans telecomoperatoren, internetproviders, CDN's, datacenters en bedrijven uit het ondernemingssegment. AS's organiseren onderling logische verbindingen (peering), meestal met behulp van het BGP-protocol.
Hoe autonome systemen deze verbindingen organiseren, wordt bepaald door een aantal factoren:
- geografisch,
- economisch,
- politiek,
- overeenkomsten en gemeenschappelijke belangen tussen AS-eigenaren,
- etc.
Natuurlijk heeft dit schema een bepaalde structuur en hiërarchie. Operators zijn dus verdeeld in Tier-1, Tier-2 en Tier-3, en als de klanten voor een lokale internetprovider (Tier-3) in de regel gewone gebruikers zijn, dan bijvoorbeeld voor Tier-1 niveau-operatoren De clients zijn andere operators. Tier-3-operatoren aggregeren het verkeer van hun abonnees, Tier-2-telecomoperatoren aggregeren op hun beurt het verkeer van Tier-3-operatoren, en Tier-1 – al het internetverkeer.
Schematisch kan het als volgt worden weergegeven:
Deze afbeelding laat zien dat het verkeer van onder naar boven wordt geaggregeerd, d.w.z. van eindgebruikers tot tier-1 operators. Er is ook een horizontale uitwisseling van verkeer tussen AS's die ongeveer gelijkwaardig aan elkaar zijn.
Een integraal onderdeel en tegelijkertijd een nadeel van dit schema is een zekere verwarring van verbindingen tussen autonome systemen die zich dichter bij de eindgebruiker bevinden, binnen een geografisch gebied. Beschouw de onderstaande afbeelding:
Laten we aannemen dat er in een grote stad vijf telecomoperatoren zijn, waartussen, om de een of andere reden, is georganiseerd zoals hierboven weergegeven.
Als de gebruiker Petya, verbonden met de Go ISP, toegang wil krijgen tot een server die is verbonden met de ASM-provider, wordt het verkeer tussen hen gedwongen om via 5 autonome systemen te gaan. Dit vergroot de vertraging omdat het aantal netwerkapparaten waar het verkeer doorheen gaat neemt toe, evenals het volume van het transitverkeer op autonome systemen tussen Go en ASM.
Hoe kan het aantal transit-AS's waar het verkeer doorheen moet, worden verminderd? Dat klopt - verkeersuitwisselingspunt.
Tegenwoordig wordt de opkomst van nieuwe IXP’s gedreven door dezelfde behoeften als in het begin van de jaren 90 en 2000, alleen op kleinere schaal, als reactie op het toenemende aantal telecomoperatoren, gebruikers en verkeer, de groeiende hoeveelheid inhoud die door CDN-netwerken wordt gegenereerd en datacentra.
Wat is een wisselpunt?
Een verkeersuitwisselingspunt is een plaats met een speciale netwerkinfrastructuur waar deelnemers die geïnteresseerd zijn in onderlinge verkeersuitwisseling onderlinge peering organiseren. De belangrijkste deelnemers aan verkeersuitwisselingspunten: telecomoperatoren, internetproviders, contentproviders en datacentra. Op verkeersuitwisselingspunten komen deelnemers rechtstreeks met elkaar in contact. Hiermee kunt u de volgende problemen oplossen:
- de latentie verminderen,
- de hoeveelheid transitverkeer verminderen,
- optimaliseer de routering tussen AS.
Gezien het feit dat IXP's in veel grote steden over de hele wereld aanwezig zijn, heeft dit allemaal een gunstig effect op het internet als geheel.
Als de bovenstaande situatie met Petya wordt opgelost met IXP, zal het ongeveer zo zijn:
Hoe werkt een verkeersuitwisselingspunt?
In de regel is een IXP een afzonderlijke AS met een eigen blok openbare IPv4/IPv6-adressen.
Het IXP-netwerk bestaat meestal uit een continu L2-domein. Soms is dit gewoon een VLAN die alle IXP-clients host. Als het gaat om grotere, geografisch verspreide IXP's, kunnen technologieën zoals MPLS, VXLAN, enz. worden gebruikt om een L2-domein te organiseren.
IXP-elementen
- SKS. Er is hier niets ongewoons: racks, optische cross-connects, patchpanelen.
- schakelaars – de basis van IXP. De switchpoort is het toegangspunt tot het IXP-netwerk. De switches voeren ook een deel van de beveiligingsfuncties uit: ze filteren junkverkeer dat niet op het IXP-netwerk aanwezig zou mogen zijn. In de regel worden switches geselecteerd op basis van functionele vereisten: betrouwbaarheid, ondersteunde poortsnelheden, beveiligingsfuncties, sFlow-ondersteuning, enz.
- Routeserver (RS) – een integraal en noodzakelijk onderdeel van elk modern verkeersuitwisselingspunt. Het werkingsprincipe lijkt sterk op de routereflector in iBGP of de aangewezen router in OSPF en lost dezelfde problemen op. Naarmate het aantal deelnemers aan een verkeersuitwisselingspunt groeit, neemt het aantal BGP-sessies dat elke deelnemer moet ondersteunen toe. dit doet denken aan de klassieke full-mesh topologie in iBGP. RS lost het probleem op de volgende manier op: het brengt een BGP-sessie tot stand met elke geïnteresseerde IXP-deelnemer, en die deelnemer wordt een RS-klant. Als RS een BGP-update ontvangt van een van haar klanten, stuurt zij deze update uiteraard naar al haar andere klanten, met uitzondering van degene waarvan deze update is ontvangen. RS elimineert dus de noodzaak om een volledig netwerk tussen alle IXP-leden tot stand te brengen en lost op elegante wijze het schaalbaarheidsprobleem op. Het is vermeldenswaard dat de routeserver op transparante wijze routes van de ene AS naar de andere verzendt zonder wijzigingen aan te brengen in de attributen die door BGP worden verzonden. Hij voegt bijvoorbeeld niet het nummer in zijn AS toe aan het AS-pad. Ook op RS is er een basisfiltering van routes: RS accepteert bijvoorbeeld geen marsmannetjesnetwerken en de voorvoegsels van de IXP zelf.
Een open source softwarerouter, BIRD (bird internet routing daemon), wordt vaak gebruikt als routeserveroplossing. Het goede eraan is dat het gratis is, snel kan worden geïmplementeerd op de meeste Linux-distributies, een flexibel mechanisme heeft voor het opzetten van routerings-/filterbeleid, en geen veeleisend is voor computerbronnen. Ook kan een hardware/virtuele router van Cisco, Juniper etc. als RS worden geselecteerd.
- Beveiliging. Omdat een IXP-netwerk een concentratie is van een groot aantal AS's, moet het beveiligingsbeleid dat alle deelnemers moeten volgen goed geschreven zijn. Over het algemeen zijn hier dezelfde mechanismen van toepassing die van toepassing zijn bij het tot stand brengen van een BGP-aangrenzendheid tussen twee afzonderlijke BGP-peers buiten een IXP, plus enkele extra beveiligingsfuncties.
Het is bijvoorbeeld een goede gewoonte om alleen verkeer toe te staan vanaf een specifiek mac-adres van de IXP-deelnemer, waarover vooraf wordt onderhandeld. Verkeer weigeren met andere ethertypevelden dan 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP); dit wordt gedaan om verkeer weg te filteren dat niet thuishoort in BGP-peering. Mechanismen zoals GTSM, RPKI, etc. kunnen ook worden gebruikt.
Misschien zijn bovenstaande de belangrijkste componenten van elke IXP, ongeacht de schaal. Uiteraard kunnen grotere IXP's over aanvullende technologieën en oplossingen beschikken.
Het komt voor dat IXP haar deelnemers ook aanvullende diensten levert:
- geplaatst op de IXP TLD DNS-server,
- hardware NTP-servers installeren, zodat deelnemers de tijd nauwkeurig kunnen synchroniseren,
- bescherming bieden tegen DDoS-aanvallen, enz.
Werking
Laten we eens kijken naar het werkingsprincipe van een verkeersuitwisselingspunt met behulp van het voorbeeld van een eenvoudige IXP, gemodelleerd met behulp van EVE-NG, en vervolgens kijken naar de basisconfiguratie van een BIRD-softwarerouter. Om het diagram te vereenvoudigen laten we belangrijke zaken als redundantie en fouttolerantie achterwege.
De netwerktopologie wordt weergegeven in de onderstaande afbeelding.
Laten we aannemen dat we een klein uitwisselingspunt beheren en de volgende peering-opties bieden:
- publiekelijk peeren,
- privé-peering,
- peering via routeserver.
Ons AS-nummer is 555, we bezitten een blok IPv4-adressen – 50.50.50.0/24, van waaruit we IP-adressen uitgeven voor degenen die verbinding willen maken met ons netwerk.
50.50.50.254 – IP-adres geconfigureerd op de routeserverinterface, met deze IP-clients zullen een BGP-sessie tot stand worden gebracht in geval van peering via RS.
Ook voor peering via RS hebben we een eenvoudig routeringsbeleid ontwikkeld, gebaseerd op de BGP-gemeenschap, waarmee IXP-deelnemers kunnen regelen naar wie en welke routes ze moeten sturen:
BGP-gemeenschap
beschrijving
LOCAL_AS:PEER_AS
Stuur voorvoegsels alleen naar PEER_AS
LOCAL_AS:IXP_AS
Geef voorvoegsels door aan alle IXP-deelnemers
3 klanten willen verbinding maken met onze IXP en verkeer uitwisselen; Laten we zeggen dat dit internetproviders zijn. Ze willen allemaal peering via een routeserver organiseren. Hieronder ziet u een diagram met clientverbindingsparameters:
klant
Klant AS-nummer
Door de klant geadverteerde voorvoegsels
IP-adres uitgegeven aan de client om verbinding te maken met de IXP
ISP nr. 1
AS 100
1.1.0.0/16
50.50.50.10/24
ISP nr. 2
AS 200
2.2.0.0/16
50.50.50.20/24
ISP nr. 3
AS 300
3.3.0.0/16
50.50.50.30/24
Basis BGP-installatie op de clientrouter:
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
Het is de moeite waard om hier de instelling no bgp forceren-eerst-as op te merken. Standaard vereist BGP dat het as-path van een ontvangen BGP-update het as bgp-nummer bevat van de peer waarvan de update is ontvangen. Maar aangezien de routeserver geen wijzigingen aanbrengt in het as-pad, zal het nummer ervan niet in het as-pad staan en zal de update worden weggegooid. Deze instelling wordt gebruikt om de router deze regel te laten negeren.
We zien ook dat de klant bgp community 555:555 op dit voorvoegsel heeft ingesteld, wat volgens ons beleid betekent dat de klant dit voorvoegsel aan alle andere deelnemers wil adverteren.
Voor de routers van andere klanten zullen de instellingen vergelijkbaar zijn, met uitzondering van hun unieke parameters.
Voorbeeld BIRD-configuratie:
define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];
template bgp RS_CLIENT {
local as ixp_as;
rs client;
}
Het volgende beschrijft een filter dat geen voorvoegsels van marsmannetjes accepteert, evenals de voorvoegsels van de IXP zelf:
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;
}
Deze functie implementeert het routeringsbeleid dat we eerder hebben beschreven.
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;
}
We configureren peering, passen passende filters en beleid toe.
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;
}
}
Het is vermeldenswaard dat het op een routeserver een goede gewoonte is om routes van verschillende peers in verschillende RIB's te plaatsen. Met BIRD kunt u dit doen. In ons voorbeeld worden voor de eenvoud alle updates die van alle klanten worden ontvangen, toegevoegd aan één gemeenschappelijke RIB.
Laten we dus eens kijken wat we hebben.
Op de routeserver zien we dat er met alle drie de clients een BGP-sessie tot stand is gebracht:
We zien dat we van alle clients voorvoegsels ontvangen:
Op de as 100-router zien we dat als er slechts één BGP-sessie met de routeserver is, we voorvoegsels ontvangen van zowel 200 als 300, terwijl de BGP-attributen niet zijn gewijzigd, alsof peering tussen clients rechtstreeks is uitgevoerd:
We zien dus dat de aanwezigheid van een routeserver de organisatie van peering op de IXP aanzienlijk vereenvoudigt.
Ik hoop dat deze demonstratie je heeft geholpen beter te begrijpen hoe IXP's werken en hoe de routeserver op een IXP werkt.
Linxdatacenter IX
Bij Linxdatacenter hebben we onze eigen IXP gebouwd op basis van een fouttolerante infrastructuur van 2 switches en 2 routeservers. Onze IXP draait nu in testmodus en we nodigen iedereen uit om verbinding te maken met Linxdatacenter IX en deel te nemen aan het testen. Wanneer u verbonden bent, krijgt u een poort met een bandbreedte van 1 Gbit/s, de mogelijkheid om via onze routeservers te peeren, evenals toegang tot uw persoonlijke account van de IX-portal, beschikbaar op .
Schrijf in opmerkingen of privéberichten om toegang te krijgen tot testen.
Uitgang
Verkeersuitwisselingspunten ontstonden aan het begin van het internet als een instrument voor het oplossen van het probleem van de suboptimale verkeersstroom tussen telecomoperatoren. Nu, met de komst van nieuwe mondiale diensten en een toename van de hoeveelheid CDN-verkeer, blijven uitwisselingspunten de werking van het mondiale netwerk optimaliseren. De toename van het aantal IXP’s in de wereld komt zowel de eindgebruiker van de dienst als telecomoperatoren, contentoperatoren, enz. ten goede. Voor IXP-deelnemers komt het voordeel tot uiting in het verlagen van de kosten van het organiseren van externe peering, het verminderen van de hoeveelheid verkeer waarvoor operators op een hoger niveau moeten betalen, het optimaliseren van de routering en de mogelijkheid om een directe interface te hebben met contentoperators.
Nuttige links
- Bekijk een kaart met de locatie van verkeerswisselpunten:
- Bekijk gedetailleerde statistieken over BGP-peering, inclusief aanwezigheid op IXP:
Bron: www.habr.com