Verkeersuitwisselingspunt: van oorsprong tot het creëren van uw eigen IX

"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 het internet.

Hallo iedereen!

Mijn naam is Alexander en ik ben netwerkengineer bij Linxdatacenter. In het artikel van vandaag bespreken we Internet Exchange Points (IXP): wat eraan voorafging, welke taken ze uitvoeren en hoe ze zijn opgebouwd. In dit artikel demonstreer ik ook het principe van IXP-werking 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 hierOpgemerkt kan worden dat de snelle groei van het aantal verkeersknooppunten in 1993 begon. Dit komt doordat het grootste deel van het verkeer van de toen bestaande telecomoperators via het Amerikaanse backbonenetwerk liep. Wanneer bijvoorbeeld verkeer 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 backbonenetwerk fungeerde in dit geval als transit tussen Frankrijk en Duitsland. Zelfs verkeer binnen één land verliep vaak indirect, maar via de backbonenetwerken van Amerikaanse operators.

Deze situatie had niet alleen gevolgen voor de kosten van het doorgaande verkeer, maar ook voor de kwaliteit van de kanalen en de vertragingen. Het aantal internetgebruikers nam toe, er kwamen nieuwe operators, het verkeersvolume nam toe en het internet ontwikkelde zich. Operators over de hele wereld begonnen te beseffen dat een rationelere aanpak voor de organisatie van de interactie tussen operators nodig was. "Waarom zou ik, operator A, moeten betalen voor doorvoer door een ander land om verkeer te leveren aan operator B, die zich in de volgende straat bevindt?" Dit is ongeveer de vraag die telecomoperators zich destijds stelden. Zo ontstonden er in verschillende delen van de wereld verkeersknooppunten op plekken waar de operatoren zich concentreerden:

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

Het internet en onze tijd

Conceptueel gezien bestaat de architectuur van het moderne internet uit een geheel van autonome systemen (AS) en een geheel van verbindingen daartussen, zowel fysiek als logisch, die het pad van het verkeer van het ene AS naar het andere bepalen.

AS'en zijn doorgaans telecomoperatoren, internetproviders, CDN's, datacenters en bedrijven in het enterprisesegment. AS'en organiseren logische verbindingen (peering) onderling, doorgaans via het BGP-protocol.

Hoe autonome systemen deze verbindingen organiseren, wordt bepaald door een aantal factoren:

• geografisch,
• economisch,
• politiek,
• overeenkomsten en gemeenschappelijke belangen tussen de eigenaren van AS,
• etc.

Natuurlijk is er een zekere structuur en hiërarchie in dit schema. Zo worden operators onderverdeeld in tier-1, tier-2 en tier-3. Als de klanten van een lokale internetprovider (tier-3) in de regel gewone gebruikers zijn, dan zijn voor tier-1-operators bijvoorbeeld andere operators klanten. Tier-3-operators aggregeren het verkeer van hun abonnees, tier-2-operators aggregeren op hun beurt het verkeer van tier-3-operators, en tier-1 aggregeert al het internetverkeer.

Schematisch kan dit als volgt worden weergegeven:

Deze afbeelding laat zien dat het verkeer van onder naar boven wordt geaggregeerd, d.w.z. van eindgebruikers naar tier-1-operators. Er is ook horizontale verkeersuitwisseling tussen ongeveer gelijkwaardige AS'en.

Een integraal onderdeel en tegelijkertijd een nadeel van dit systeem is een zekere wanorde in de verbindingen tussen autonome systemen die zich binnen een geografisch gebied dichter bij de eindgebruiker bevinden. Zie de onderstaande afbeelding:

Stel dat er in een grote stad vijf telecomoperatoren zijn en dat de peering tussen deze operators, om de een of andere reden, op de hierboven weergegeven manier is georganiseerd.

Als gebruiker Petya, verbonden met de Go ISP, toegang wil tot een server die verbonden is met de ASM ISP, wordt het verkeer tussen hen gedwongen om via 5 autonome systemen te gaan. Dit vergroot de vertraging, aangezien het aantal netwerkapparaten waar het verkeer doorheen gaat toeneemt, evenals de hoeveelheid transitverkeer op autonome systemen tussen Go en ASM.

Hoe kunnen we het aantal transit-AS'en waar het verkeer doorheen moet, verminderen? Juist, een verkeersknooppunt.

Tegenwoordig worden nieuwe IXP's aangestuurd door dezelfde behoeften als in de vroege jaren 90-2000, maar dan op kleinere schaal. Ze zijn een 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 plek met een speciale netwerkinfrastructuur waar deelnemers die geïnteresseerd zijn in wederzijdse verkeersuitwisseling, wederzijdse peering organiseren. De belangrijkste deelnemers aan verkeersuitwisselingspunten zijn telecomoperators, internetproviders, contentproviders en datacenters. Op verkeersuitwisselingspunten maken deelnemers rechtstreeks verbinding met elkaar. Dit maakt het mogelijk om de volgende problemen op te lossen:

• latentie verminderen,
• het verminderen van het aantal doorgaande auto's,
• Optimaliseer de routering tussen AS.

Gezien het feit dat IXP's in veel grote steden over de hele wereld aanwezig zijn, heeft dit een positief effect op het internet als geheel.

Als we de hierboven beschreven situatie met Petya oplossen met behulp van IXP, dan ziet het er ongeveer zo uit:

Hoe werkt een verkeersuitwisselingspunt?

Normaal gesproken is een IXP een afzonderlijk AS met een eigen blok openbare IPv4/IPv6-adressen.

Een IXP-netwerk is meestal een doorlopend L2-domein. Soms is het slechts een VLAN waarin alle IXP-clients zich bevinden. Bij grotere, geografisch verspreide IXP's kunnen technologieën zoals MPLS, VXLAN, enz. worden gebruikt om het L2-domein te organiseren.

IXP-elementen

• SKS. Hier is niets ongewoons te zien: rekken, optische kruisen, patchpanels.
• schakelaars – de basis van IXP. De switchpoort is het toegangspunt tot het IXP-netwerk. Switches voeren ook enkele beveiligingsfuncties uit: ze filteren ongewenste data die niet op het IXP-netwerk aanwezig mag zijn. Switches worden doorgaans geselecteerd op basis van functionaliteitsvereisten: betrouwbaarheid, ondersteunde poortsnelheid, beveiligingsfuncties, sFlow-ondersteuning, enzovoort.
• Routeserver (RS) – een integraal en noodzakelijk onderdeel van elk modern verkeersuitwisselingspunt. In principe is het zeer vergelijkbaar met een routereflector in iBGP of een aangewezen router in OSPF en lost het dezelfde problemen op. Naarmate het aantal deelnemers aan het verkeersuitwisselingspunt toeneemt, neemt ook het aantal BGP-sessies dat elke deelnemer moet ondersteunen toe, d.w.z. het lijkt op de klassieke full-mesh topologie in iBGP. RS lost het probleem als volgt op: het zet een BGP-sessie op met elke geïnteresseerde IXP-deelnemer, en die deelnemer wordt een RS-client. Nadat RS een BGP-update van een van zijn clients heeft ontvangen, stuurt het deze update uiteraard naar al zijn andere clients, behalve degene waarvan deze update is ontvangen. RS elimineert zo de noodzaak om een ​​full-mesh tussen alle IXP-deelnemers op te zetten en lost het schaalbaarheidsprobleem elegant op. Het is vermeldenswaard dat de routeserver routes transparant van het ene AS naar het andere verzendt, zonder wijzigingen aan te brengen in de verzonden BGP-attributen; het voegt bijvoorbeeld het nummer in zijn AS niet toe aan het AS-pad. RS voert ook basisroutefiltering uit: RS accepteert bijvoorbeeld geen Mars-netwerken en prefixen van de IXP zelf.

  Een open-source softwarerouter, BIRD (Bird Internet Routing Daemon), wordt vaak gebruikt als routeserveroplossing. Het is een goede keuze omdat het gratis is, snel te implementeren op de meeste Linux-distributies, een flexibel mechanisme heeft voor het configureren van routerings-/filterbeleid en niet veel rekenkracht vergt. Ook een hardwarematige/virtuele router van Cisco, Juniper, enz. kan als RS worden geselecteerd.

• Beveiliging. Omdat een IXP-netwerk een concentratie is van een groot aantal AS'en, moet het beveiligingsbeleid dat alle deelnemers moeten volgen, goed gedefinieerd zijn. Doorgaans worden hier dezelfde mechanismen gebruikt die worden gebruikt om een ​​BGP-nabijheid tussen twee afzonderlijke BGP-peers buiten een IXP tot stand te brengen, plus enkele aanvullende beveiligingsmaatregelen.

  Het is bijvoorbeeld een goede gewoonte om alleen verkeer toe te staan ​​van het MAC-adres van een specifiek IXP-lid, waarover vooraf wordt onderhandeld. Het weigeren van verkeer met andere ethertype-velden dan 0x0800 (IPv4), 0x08dd (IPv6) en 0x0806 (ARP) wordt gedaan om verkeer uit te filteren dat niet in BGP-peering thuishoort. Mechanismen zoals GTSM en RPKI kunnen ook worden gebruikt.

Dit zijn waarschijnlijk de basiscomponenten van elk IXP, ongeacht de schaal. Grotere IXP's kunnen uiteraard aanvullende technologieën en oplossingen gebruiken.
Het komt voor dat IXP haar leden ook aanvullende diensten aanbiedt:

• host DNS-servers op IXP TLD's,
• hardwarematige NTP-servers installeren, zodat deelnemers de tijd nauwkeurig kunnen synchroniseren,
• bescherming bieden tegen DDoS-aanvallen, etc.

Werking

Laten we het werkingsprincipe van een verkeersuitwisselingspunt bekijken aan de hand van een eenvoudige IXP, gemodelleerd door EVE-NG, en vervolgens de basisconfiguratie van de BIRD-softwarerouter bekijken. Om het schema te vereenvoudigen, laten we belangrijke zaken zoals redundantie en fouttolerantie achterwege.

De netwerktopologie wordt weergegeven in de onderstaande afbeelding.

Laten we aannemen dat we een klein internetknooppunt beheren en de volgende peeringopties aanbieden:

• openbare peering,
• privé-peering,
• peering via routeserver.

Ons AS-nummer is 555, we beschikken over een blok IPv4-adressen – 50.50.50.0/24 – waaruit we IP-adressen uitgeven aan degenen die verbinding willen maken met ons netwerk.

50.50.50.254 – IP-adres geconfigureerd op de route-serverinterface. Met dit IP-adres kunnen clients een BGP-sessie tot stand brengen in geval van peering via RS.

Ook voor peering via RS hebben we een eenvoudig routeringsbeleid ontwikkeld op basis van de BGP-community, waarmee IXP-deelnemers kunnen regelen wie en welke routes er worden verzonden:

BGP-gemeenschap
beschrijving

LOKAAL_ALS:PEER_ALS
Geef alleen prefixen door aan PEER_AS

LOKALE_AS:IXP_AS
Voorvoegsels overdragen aan alle IXP-deelnemers

Drie clients willen verbinding maken met onze IXP en verkeer uitwisselen; laten we zeggen dat dit internetproviders zijn. Ze willen allemaal peering organiseren via een routeserver. Hieronder ziet u een diagram met de parameters van de clientverbindingen:

klant
AS-klantnummer
Door de klant aangekondigde prefixen
IP-adres dat aan de client is uitgegeven voor verbinding met de IXP

Internetprovider #1
AS 100
1.1.0.0/16
50.50.50.10/24

Internetprovider #2
AS 200
2.2.0.0/16
50.50.50.20/24

Internetprovider #3
AS 300
3.3.0.0/16
50.50.50.30/24

Basis BGP-configuratie 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 belangrijk om hier de instelling 'no bgp enforce-first-as' te vermelden. Standaard vereist BGP dat het as-pad van de ontvangen BGP-update het as-bgp-peernummer bevat waarvan de update is ontvangen. Omdat de routeserver echter geen wijzigingen aanbrengt in het as-pad, ontbreekt dit nummer in het as-pad en wordt de update verwijderd. Deze instelling zorgt ervoor dat de router deze regel negeert.

We zien ook dat de client bgp community 555:555 op dit voorvoegsel heeft ingesteld. Volgens ons beleid betekent dit dat de client dit voorvoegsel aan alle andere deelnemers wil bekendmaken.

Voor de routers van de overige clients zijn de instellingen vergelijkbaar, afgezien van de 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;
}

Hieronder wordt een filter beschreven dat geen martiaanse voorvoegsels accepteert, noch 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;


}

Wij stellen peering in en 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 belangrijk om te weten dat het op de routeserver een goede gewoonte is om routes van verschillende peers in verschillende RIB's te plaatsen. BIRD maakt dit mogelijk. In ons voorbeeld worden, voor de eenvoud, alle updates die van alle clients worden ontvangen in één gemeenschappelijke RIB geplaatst.

Laten we eens kijken wat we hebben.

Op de route-server zien we dat er een BGP-sessie tot stand is gebracht met alle drie de clients:

We zien dat we prefixen ontvangen van alle clients:

Op de router zien we als 100 dat we met slechts één BGP-sessie met de routeserver prefixen ontvangen van zowel 200 als 300, terwijl de BGP-kenmerken niet zijn gewijzigd, alsof peering tussen clients rechtstreeks wordt uitgevoerd:

Hieruit blijkt dat het hebben van een route-server de organisatie van peering op IXP's aanzienlijk vereenvoudigt.

Ik hoop dat deze demonstratie u heeft geholpen om beter te begrijpen hoe IXP's werken en hoe de route-server op een IXP is geïmplementeerd.

Linxdatacenter IX

Bij Linxdatacenter hebben we onze eigen IXP gebouwd op basis van een fouttolerante infrastructuur van twee switches en twee routeservers. Onze IXP draait momenteel in testmodus en we nodigen iedereen uit om verbinding te maken met Linxdatacenter IX en deel te nemen aan de tests. Wanneer u verbinding maakt, krijgt u een poort met een doorvoersnelheid van 2 Gbit/s, de mogelijkheid om via onze routeservers te peeren en toegang tot het persoonlijke account van de IX-portal, beschikbaar op ix.linxdatacenter.com.

Schrijf in de reacties of privéberichten om toegang te krijgen tot de test.

Uitgang

Verkeersknooppunten ontstonden aan het begin van het internet als hulpmiddel om het probleem van niet-optimale verkeersstromen tussen telecomoperatoren op te lossen. Nu, met de opkomst van nieuwe wereldwijde diensten en de toename van de hoeveelheid CDN-verkeer, blijven knooppunten de werking van het wereldwijde netwerk optimaliseren. De toename van het aantal IXP's wereldwijd is gunstig voor zowel de eindgebruiker van de dienst als voor telecomoperatoren, contentoperatoren, enz. Voor IXP-deelnemers komt het voordeel tot uiting in de verlaging van de kosten voor het organiseren van externe peerings, een vermindering van de hoeveelheid verkeer waarvoor upstream operators moeten betalen, optimalisatie van de routering en de mogelijkheid om een ​​directe verbinding met contentoperatoren te hebben.

Nuttige links

• Bekijk de kaart met verkeersknooppunten: www.internetexchangemap.com
• Bekijk gedetailleerde BGP-peeringstatistieken, inclusief IXP-aanwezigheid: www.peeringdb.com

Bron: www.habr.com