Verkeer-uitwisselingspunt: van bronnen naar het creëren van een eigen IX

«We hebben een telefoonverbinding opgezet tussen ons en de jongens van SRI…», zei Kleinrock in een interview:
«We typeten de L en vroegen via de telefoon: „Zie je de L?“»
«Ja, we zien de L,» was het antwoord.
«We typeten de O en vroegen: „Zie je de O?“»
«Ja, we zien de O.»
«Toen typeten we de G, en het systeem crashte»…

Toch was er een revolutie begonnen…

Het begin van het internet.

Hallo allemaal!

Mijn naam is Alexander, ik ben netwerkingenieur bij Linxdatacenter. In dit artikel zal ik het hebben over Internet Exchange Points (IXP): wat eraan voorafging, welke problemen ze oplossen en hoe ze zijn opgebouwd. Ook zal ik met behulp van de EVE-NG-platform en de software-router BIRD het principe van de werking van IXP demonstreren, zodat duidelijk is hoe het ‘onder de motorkap’ werkt.

Een beetje geschiedenis

Als we kijken hierheen, dan kunnen we zien dat de snelle groei van het aantal Internet Exchange Points begon in 1993. Dit had te maken met het feit dat het merendeel van het verkeer van de toen bestaande telecomoperators via het backbone-netwerk van de VS liep. Toen bijvoorbeeld het verkeer van een operator in Frankrijk naar een operator in Duitsland ging, kwam het eerst in de VS terecht voordat het van de VS naar Duitsland ging. Het backbone-netwerk fungeerde in dit geval als transit tussen Frankrijk en Duitsland. Zelfs verkeer binnen hetzelfde land ging vaak niet rechtstreeks, maar via de backbone-netwerken van Amerikaanse operators.

Deze situatie had invloed op zowel de kosten voor het verzenden van transitverkeer als op de kwaliteit van de verbindingen en de vertraging. Het aantal internetgebruikers nam toe, nieuwe operators verschenen, het verkeersvolume groeide, en het internet volwassen werd. Operators over de hele wereld begonnen te begrijpen dat een rationelere benadering van inter-operator interconnectie nodig was. „Waarom zou ik, operator A, betalen voor transit door een ander land om verkeer naar operator B te sturen, die zich op de buurstraat bevindt?“. Dit soort vragen stelden telecomoperators zich in die tijd. Zo begonnen in verschillende delen van de wereld, op locaties waar operators zich concentreerden, Internet Exchange Points te ontstaan:

• 1994 – LINX in Londen,
• 1995 – DE-CIX in Frankfurt,
• 1995 – MSK-IX, in Moskou, enz.

Het internet en onze dagen

Conceptueel vertegenwoordigt de architectuur van het moderne internet een aantal autonome systemen (autonomous system, AS) en vele verbindingen ertussen, zowel fysiek als logisch, die de route van het verkeer van de ene AS naar de andere bepalen.

Als AS fungeren meestal telecomoperators, internetproviders, CDN's, datacenters en bedrijven in het enterprise-segment. AS organiseren logische verbindingen (peering) tussen elkaar, doorgaans via het BGP-protocol.

De manier waarop autonome systemen deze verbindingen organiseren, wordt bepaald door verschillende factoren:

• geografische,
• economische,
• politieke,
• overeenkomsten en gezamenlijke belangen tussen de eigenaren van AS,
• enzovoorts.

Zeker, in dit schema is er een bepaalde structuur en hiërarchie. Operators worden ingedeeld in tier-1, tier-2 en tier-3, en terwijl de klanten van een lokale internetprovider (tier-3) doorgaans gewone gebruikers zijn, zijn de klanten van tier-1 operators andere operators. Tier-3 operators aggregeren het verkeer van hun abonnees, tier-2 operators aggregateren op hun beurt het verkeer van tier-3 operators, en tier-1 - al het internetverkeer.

Schematisch kan dit als volgt worden weergegeven:

In de afbeelding hiernaast is te zien dat het verkeer van onder naar boven wordt geaggregeerd, dat wil zeggen van eindgebruikers naar tier-1 operators. Er is ook een horizontale uitwisseling van verkeer tussen AS die ongeveer gelijkwaardig zijn.

Een onlosmakelijk onderdeel en tegelijkertijd een nadeel van dit schema is een zekere chaos in de verbindingen tussen autonome systemen die zich dichter bij de eindgebruiker bevinden binnen een geografisch gebied. Laten we de afbeelding hieronder bekijken:

Stel je voor dat er in een grote stad 5 telecomoperators aanwezig zijn, waarvan de peering om diverse redenen is georganiseerd, zoals hierboven weergegeven.

Als gebruiker Petya, aangesloten bij internetprovider Go, toegang wil krijgen tot een server die aangesloten is bij provider ASM, zal het verkeer tussen hen gedwongen zijn om via 5 autonome systemen te gaan. Dit verhoogt de latentie, omdat het aantal netwerkapparaten toeneemt waar het verkeer doorheen moet, evenals het volume van het transitverkeer op de autonome systemen tussen Go en ASM.

Hoe kan het aantal transit-AS verminderd worden dat het verkeer moet doorlopen? Juist – een verkeersuitwisselpunt.

Tegenwoordig wordt de oprichting van nieuwe IXP's nog steeds gedreven door dezelfde behoeften als in de vroege jaren '90 en 2000, maar op een kleinere schaal, in reactie op het toenemende aantal telecomoperators, gebruikers en verkeer, en de groeiende hoeveelheid content die wordt gegenereerd door CDN-netwerken en datacenters.

Wat is een verkeersuitwisselingspunt?

Een verkeersuitwisselingspunt is een locatie met een speciale netwerkstructuur waar deelnemers, die geïnteresseerd zijn in wederzijdse verkeersuitwisseling, directe peering organiseren. De belangrijkste deelnemers aan verkeersuitwisselingspunten zijn telecomoperators, internetproviders, contentproviders en datacenters. Bij verkeersuitwisselingspunten verbinden de deelnemers zich rechtstreeks met elkaar. Dit lost de volgende taken op:

• de latency verminderen,
• de hoeveelheid transitverkeer verminderen,
• de routing tussen AS optimaliseren.

Aangezien IXP's in veel grote steden wereldwijd aanwezig zijn, heeft dit ook een positieve invloed op het internet als geheel.

Als we de bovenstaande situatie met Petya met behulp van IXP's zouden aanpakken, zou het ongeveer als volgt zijn:

Hoe is een verkeersuitwisselingspunt ingericht?

Over het algemeen is een IXP een aparte AS met zijn eigen blok publieke IPv4/IPv6-adressen.

Het netwerk van een IXP bestaat meestal uit een pure L2-domein. Soms is dit gewoon een VLAN waarin alle IXP-klanten zijn ondergebracht. Wanneer het gaat om grotere, geografisch verspreide IXP's, kunnen technologieën zoals MPLS, VXLAN enzovoort worden gebruikt om een L2-domein te organiseren.

Elementen van IXP

• Systeem van kabels. Hier is niets ongewoons: rekken, optische aansluitingen, patchpanelen.
• Switches – de basis van de IXP. Een switchport is de toegangspunt tot het IXP-netwerk. Switches vervullen ook een aantal beveiligingsfuncties – zij filteren ongewenst verkeer dat niet aanwezig zou moeten zijn op het IXP-netwerk. Over het algemeen worden switches gekozen op basis van functionele vereisten – betrouwbaarheid, ondersteunde poortsnelheden, beveiligingsfuncties, ondersteuning voor sFlow, enzovoort.
• Route server (RS) is een essentieel en noodzakelijk onderdeel van elk modern verkeersuitwisselingspunt. Wat betreft de werking lijkt het sterk op een route reflector in iBGP of een designated router in OSPF en lost het dezelfde problemen op. Naarmate het aantal deelnemers aan het verkeersuitwisselingspunt toeneemt, neemt ook het aantal BGP-sessies toe dat elke deelnemer moet onderhouden, wat doet denken aan de klassieke full-mesh topologie in iBGP. RS lost het probleem als volgt op: het stelt een BGP-sessie in met elke geïnteresseerde deelnemer aan de IXP, die dan client wordt van RS. Wanneer RS een BGP-update van een van zijn clients ontvangt, verspreidt RS deze update naar al zijn andere clients, uiteraard met uitzondering van degene van wie de update afkomstig was. Op deze manier voorkomt RS dat er een full-mesh tussen alle deelnemers aan de IXP wordt opgezet en lost het het schaalbaarheidsprobleem elegant op. Het is ook vermeldenswaard dat de route server transparant routes van de ene AS naar de andere doorgeeft, zonder wijzigingen aan te brengen in de doorgegeven BGP-attributen, bijvoorbeeld voegt het geen nummer van zijn eigen AS toe aan de AS-path. De RS voert bovendien een basisfiltering van routes uit: bijvoorbeeld, de RS accepteert geen martians networks en prefixen van de IXP.

  Als oplossing wordt vaak een software router met open source gebruikt – BIRD (bird internet routing daemon). Het voordeel is dat het gratis is, snel kan worden uitgerold op de meeste Linux-distributies, een flexibele configuratiemechanisme biedt voor routerings-/filteringbeleid en niet veel computermiddelen vereist. Daarnaast kan een hardware-/virtuele router van Cisco, Juniper, enz. ook als RS worden gekozen.

• Beveiliging. Aangezien het IXP-netwerk een concentratie is van een groot aantal AS, moet het beveiligingsbeleid dat alle deelnemers volgen goed geformuleerd zijn. Over het algemeen worden dezelfde mechanismen die worden toegepast bij het tot stand brengen van BGP-buurtschap tussen twee afzonderlijke BGP-peers buiten de IXP ook hier toegepast, evenals enkele aanvullende beschermingsmaatregelen.

  Bijvoorbeeld, het is een goede praktijk om verkeer alleen toe te laten van een specifieke mac-adres van de deelnemer aan de IXP, dat van tevoren wordt afgesproken. Verkeer met ethertype-velden die verschillen van 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP) wordt geblokkeerd; dit gebeurt om verkeer te filteren dat geen plaats heeft bij BGP-peering. Mechanismen zoals GTSM, RPKI, enz. kunnen ook worden toegepast.

Waarschijnlijk zijn de bovenstaande elementen de belangrijkste componenten van elke IXP, ongeacht de schaal. Uiteraard kunnen grotere IXP aanvullende technologieën en oplossingen toepassen.
Het komt voor dat IXP ook extra diensten aan zijn deelnemers biedt:

• hosting TLD DNS-servers op de IXP,
• het installeren van hardware NTP-servers, zodat deelnemers de tijd nauwkeurig kunnen synchroniseren,
• bescherming bieden tegen DDoS-aanvallen, enz.

Werking principe

Laten we het principe van een traffic exchange point verkennen aan de hand van een eenvoudig IXP-model gemaakt met behulp van EVE-NG, en daarna kijken we naar de basisconfiguratie van de software-router BIRD. Om de diagram vereenvoudigen, laten we belangrijke zaken zoals redundantie en fouttolerantie achterwege.

De netwerktopologie is weergegeven in de onderstaande afbeelding.

Stel dat we een klein traffic exchange point beheren en de volgende peering-opties bieden:

• open peering,
• privé peering,
• peering via een route server.

Het nummer van onze AS is 555, we bezitten een block van IPv4-adressen – 50.50.50.0/24, waarvan we IP-adressen verstrekken aan degenen die zich willen aansluiten op ons netwerk.

50.50.50.254 is het IP-adres dat is ingesteld op de interface van de route server; met dit IP zullen klanten een BGP-sessie opzetten in het geval van peering via RS.

Ook hebben we voor peering via RS een eenvoudige routeringspolitiek ontwikkeld op basis van BGP community, die deelnemers aan de IXP in staat stelt te regelen naar wie en welke routes ze verzenden:

BGP community
Omschrijving

LOCAL_AS:PEER_AS
Verzend alleen prefixes naar PEER_AS

LOCAL_AS:IXP_AS
Verzend prefixes naar alle deelnemers van de IXP

Drie klanten willen zich aansluiten bij onze IXP en verkeer uitwisselen; stel dat dit internetproviders zijn. Allen willen peering organiseren via de route server. Hieronder is het schema met de verbindingsparameters van de klanten:

Klant
Klanten AS-nummer
Door de klant geannonceerde prefixes
IP-adres dat aan de klant is verstrekt voor aansluiting op de 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

Basisconfiguratie BGP op de router van de klant:

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

Hier moet de instelling no bgp enforce-first-as worden opgemerkt. Standaard vereist BGP dat het AS-nummer van de BGP-peer, van wie de update is ontvangen, aanwezig is in het AS-pad van de ontvangen BGP-update. Aangezien de route server echter geen wijzigingen aanbrengt in het AS-pad, zal zijn nummer ontbreken in het AS-pad en zal de update worden verworpen. Deze instelling wordt toegepast, zodat de router deze regel negeert.

Ook zien we dat de klant de BGP-community 555:555 op deze prefix heeft ingesteld, wat volgens ons beleid betekent dat de klant deze prefix aan alle andere deelnemers wil aankondigen.

Voor de routers van andere klanten zal de configuratie vergelijkbaar zijn, met uitzondering van hun unieke parameters.

Voorbeeldconfiguratie BIRD:

define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];

template bgp RS_CLIENT {
  local as ixp_as;
  rs client;
}

Hier wordt een filter beschreven dat geen martians-prefixen en ook de prefixen van de IXP accepteert:

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 de juiste 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 route server goed is om routes van verschillende peers in verschillende RIB's te groeperen. BIRD maakt dit mogelijk. In ons voorbeeld worden, ter vereenvoudiging, alle updates die van alle klanten zijn ontvangen in één algemene RIB opgeslagen.

Laten we eens kijken naar wat we hebben bereikt.

Op de route server zien we dat er met alle drie de klanten een BGP-sessie is ingesteld:

We zien dat we prefixes van alle klanten ontvangen:

Op de router as 100 zien we dat, ondanks het feit dat er maar één BGP-sessie met de route server is, we zowel prefixes van as 200 als as 300 ontvangen, terwijl de BGP-attributen onveranderd zijn, alsof de peering direct tussen de klanten plaatsvond:

Daarom zien we dat het hebben van een route server het opzetten van peering op de IXP aanzienlijk vereenvoudigt.

Ik hoop dat deze demonstratie je heeft geholpen beter te begrijpen hoe verkeersuitwisselingspunten zijn opgebouwd en hoe de werking van een route server op de IXP wordt gerealiseerd.

Linxdatacenter IX

Bij Linxdatacenter hebben we onze eigen IXP opgebouwd op basis van een redundante infrastructuur van 2 switches en 2 route servers. Onze IXP draait momenteel in testmodus en we nodigen iedereen uit om zich aan te sluiten bij Linxdatacenter IX en deel te nemen aan de testfase. Bij aansluiting krijg je een poort met een bandbreedte van 1 Gbit/s, de mogelijkheid om te peeren via onze route servers en toegang tot het persoonlijke account van het IX-portaal, bereikbaar op ix.linxdatacenter.com.

Stuur een bericht in de reacties of persoonlijk voor toegang tot de testfase.

Uitslag

Verkeersuitwisselingspunten zijn ontstaan in de vroege dagen van het internet als een middel om het probleem van suboptimale verkeersdoorvoer tussen telecomoperators op te lossen. Nu, met de opkomst van nieuwe wereldwijde diensten en de toename van CDN-verkeer, blijven verkeersuitwisselingspunten nog steeds de werking van het globale netwerk optimaliseren. De toename van het aantal IXP wereldwijd is zowel voordelig voor de eindgebruikers van de diensten als voor telecomoperators, contentproviders, enzovoort. Voor deelnemers aan de IXP uit zich de winst in lagere kosten voor het opzetten van externe peerings, een vermindering van de hoeveelheid verkeer waarvoor betaald moet worden aan hogere operators, optimalisatie van de routering en de mogelijkheid om een directe verbinding met contentproviders te hebben.

Nuttige links

• Bekijk de kaart van de locaties van verkeersuitwisselingspunten: www.internetexchangemap.com
• Bekijk gedetailleerde statistieken over BGP-peering, inclusief de aanwezigheid op IXP: www.peeringdb.com

Bron: habr.com