Bod výmeny dopravy: od počiatkov k vytvoreniu vlastného IX

„Nadviazal sme telefónne spojenie medzi nami a chlapcami zo SRI…“, povedal Kleinrock v rozhovore:
„Napísali sme L a spýtali sme sa po telefóne: „Vidíte L?““
„Áno, vidíme L,“ prišla odpoveď.
„Napísali sme O a spýtali sme sa: „Vidíte O?““
„Áno, vidíme O.“
„Potom sme napísali G, a systém sa zrútil“...

Ale revolúcia sa už začala...

Začiatok internetu.

Ahojte všetci!

Volám sa Alexander, som sieťový inžinier v spoločnosti Linxdatacenter. V dnešnom článku sa budeme zaoberať bodmi výmeny prevádzky (Internet Exchange Point, IXP): čo predchádzalo ich vzniku, aké úlohy plnia a ako sú postavené. Taktiež v tomto článku ukážem princíp fungovania IXP pomocou platformy EVE-NG a softvérového routera BIRD, aby bolo jasné, ako to funguje „pod pokrievkou“.

Trochu histórie

Ak sa pozrieme sem, môžeme si všimnúť, že prudký rast počtu bodov výmeny prevádzky sa začal v roku 1993. To súviselo s tým, že väčšina prevádzky existujúcich operátorov v tej dobe prechádzala cez backbone sieť USA. Tak, napríklad, keď prevádzka išla od operátora vo Francúzsku k operátorovi v Nemecku, najprv sa dostala do USA a až potom z USA do Nemecka. Backbone sieť v tomto prípade slúžila ako tranzit medzi Francúzskom a Nemeckom. Dokonca aj prevádzka v rámci jednej krajiny často neprechádzala priamo, ale cez oporné siete amerických operátorov.

Tento stav vecí mal vplyv nielen na náklady na dodanie tranzitnej prevádzky, ale aj na kvalitu kanálov a latenciu. Počet používateľov siete Internet rástol, objavili sa noví operátori, objem prevádzky sa zvyšoval, internet dozrieval. Operátori po celom svete začali chápať, že potrebujú rozumnejší prístup k organizácii medzioperátorského vyžitia. „Prečo by som, operátor A, mal platiť za tranzit cez iné krajiny, aby som dostal prevádzku k operátorovi B, ktorý sa nachádza na vedľajšej ulici?“ Presne takúto otázku si vtedy kládli operátori. Tak, v rôznych častiach sveta, na miestach koncentrácie operátorov, začali vzniknúť body výmeny prevádzky:

• 1994 – LINX v Londýne,
• 1995 – DE-CIX vo Frankfurte,
• 1995 – MSK-IX v Moskve, atď.

Internet a naše dni

Konceptuálna architektúra moderného internetu pozostáva z množstva autonómnych systémov (autonomous system, AS) a rôznych spojení medzi nimi, ako fyzických, tak aj logických, ktoré určujú cestu prechodu dopravy z jedného AS do druhého.

Ako AS obvykle vystupujú operátori spojenia, internetoví poskytovatelia, CDN, dátové centrá a spoločnosti zo segmentu podnikovej sféry. AS organizujú logické spojenia (peering) medzi sebou, zvyčajne prostredníctvom protokolu BGP.

To, ako autonómne systémy organizujú tieto spojenia, je definované radom faktorov:

• geografickými,
• ekonomickými,
• politickými,
• dohodami a spoločnými záujmami medzi vlastníkmi AS,
• a pod.

Samozrejme, v tejto schéme existuje určitá štruktúra a hierarchia. Operátori sú rozdelení na tier-1, tier-2 a tier-3, a ak sú klientmi pre miestneho internetového poskytovateľa (tier-3) zvyčajne obyčajní používatelia, tak pre operátorov úrovne tier-1 sú klientmi iní operátori. Operátori tier-3 agregujú na sebe dopravu svojich predplatiteľov, operátori tier-2 zase agregujú dopravu operátorov tier-3, a tier-1 – celú internetovú dopravu.

Schématicky to môžeme predstaviť takto:

Na tejto obrázku je vidieť, že doprava sa agreguje zdola nahor, t.j. od konečných používateľov k operátorom tier-1. Tiež prebieha horizontálna výmena dopravy medzi zhruba rovnocennými AS.

Neoddeliteľnou súčasťou a zároveň nedostatkom tejto schémy je akási neusporiadanosť spojení medzi autonómnymi systémami nachádzajúcimi sa bližšie k koncovému používateľovi, v rámci geografickej zóny. Pozrime sa na obrázok nižšie:

Predpokladajme, že v veľkom meste je 5 operátorov spojenia, medzi ktorými je peering usporiadaný z rôznych dôvodov, ako je zobrazené vyššie.

Ak sa používateľ Petya, pripojený k internetovému poskytovateľovi Go, pokúsi získať prístup k serveru pripojenému k poskytovateľovi ASM, doprava medzi nimi bude nútená prejsť cez 5 autonómnych systémov. Tým sa zvyšuje oneskorenie, pretože sa zvyšuje počet sieťových zariadení, cez ktoré prejde doprava, ako aj objem tranzitnej dopravy na autonómnych systémoch medzi Go a ASM.

Ako znížiť počet tranzitných AS, ktoré musí prechádzať prevádzka? Správne – bod výmeny prevádzky.

V súčasnosti vznikajú nové IXP z rovnakých dôvodov ako na začiatku 90. rokov a 2000-tych, len v menšom meradle, v reakcii na rastúci počet poskytovateľov telekomunikačných služieb, používateľov a prevádzky, ako aj na narastajúce množstvo obsahu generovaného CDN sieťami a dátovými centrami.

Čo je to bod výmeny prevádzky?

Bod výmeny prevádzky je miesto so špeciálnou sieťovou infraštruktúrou, kde účastníci, ktorí majú záujem o vzájomnú výmenu prevádzky, organizujú vzájomný peering. Hlavní účastníci bodov výmeny prevádzky sú: poskytovatelia telekomunikačných služieb, internetoví poskytovatelia, poskytovatelia obsahu a dátové centrá. V bodoch výmeny prevádzky sa účastníci spájajú medzi sebou priamo. To umožňuje vyriešiť nasledujúce úlohy:

• znížiť oneskorenie,
• skrátiť množstvo tranzitnej prevádzky,
• optimalizovať smerovanie medzi AS.

Vzhľadom na to, že IXP sú prítomné v mnohých veľkých mestách sveta, má to všetko priaznivý vplyv aj na sieť Internetu ako celku.

Ak sa vyššie opísaná situácia s Petrom rieši pomocou IXP, vyzerá to približne takto:

Ako je zriadený bod výmeny prevádzky?

IXP sú spravidla samostatnou AS so svojím blokom verejných IPv4/IPv6 adries.

Sieť IXP najčastejšie predstavuje súvislý L2 domén. Niekedy ide o jednoducho VLAN, v ktorom sú umiestnení všetci klienti IXP. Ak sa však jedná o väčšie, geograficky rozšírené IXP, na organizáciu L2 domény môžu byť použité technológie ako MPLS, VXLAN a podobne.

Prvky IXP

• SKS. Tu nie je nič neobvyklé: stojany, optické krosy, patch panely.
• Prepínače sú základom IXP. Port prepínača je vstupný bod do siete IXP. Prepínače tiež vykonávajú časť funkcií bezpečnosti – filtrujú odpadovú prevádzku, ktorá by nemala byť v sieti IXP. Spravidla sa prepínače vyberajú na základe požiadaviek na funkčnosť – spoľahlivosť, podporovaná rýchlosť portov, funkcie bezpečnosti, podpora sFlow atď.
• Route server (RS) – neoddeliteľná a nevyhnutná súčasť každej modernej výmennice prevádzky. Z hľadiska fungovania veľmi pripomína route reflector v iBGP alebo designated router v OSPF a rieši tie isté problémy. S rastom počtu účastníkov výmennice prevádzky sa zvyšuje aj počet BGP relácií, ktoré musia všetci účastníci udržiavať, čo pripomína klasickú full-mesh topológiu v iBGP. RS problém rieši nasledujúcim spôsobom: nastaví BGP reláciu s každým zainteresovaným účastníkom IXP, ktorý sa tak stáva klientom RS. Pri prijímaní BGP aktualizácie od jedného zo svojich klientov RS túto aktualizáciu rozosiela všetkým ostatným svojim klientom, samozrejme s výnimkou toho, od ktorého bola táto aktualizácia prijatá. Týmto spôsobom RS eliminuje potrebu nastaviť full-mesh medzi všetkými účastníkmi IXP a elegantne rieši problém škálovateľnosti. Je potrebné poznamenať, že server trás transparentne prenáša trasy z jednej AS do druhej, bez toho, aby menil prenášané BGP atribúty, napríklad do svojej AS cesty nepridáva číslo svojej AS. Rovnako na RS prebieha základná filtrácia trás: napríklad RS neprijíma martians networks a prefixy samotného IXP.

  Ako riešenie sa často používa route server softvérový smerovač s otvoreným kódom – BIRD (bird internet routing daemon). Je dobrý tým, že je bezplatný, rýchlo sa nasádza na väčšine linuxových distribúcií, má flexibilný mechanizmus nastavenia politiky smerovania/filtrácie a nie je náročný na výpočtové zdroje. Taktiež môžu byť ako RS zvolené aj hardvérové/virtuálne smerovače Cisco, Juniper a podobne.

• Bezpečnosť. Keďže sieť IXP predstavuje koncentráciu veľkého množstva AS, politika zabezpečenia, ktorou sa musia všetci účastníci riadiť, musí byť dobre vypracovaná. Zvyčajne sa používajú rovnaké mechanizmy, ktoré sa aplikujú pri zriaďovaní BGP susedstva medzi dvoma samostatnými BGP peerami mimo IXP, a taktiež sú nasadené niektoré dodatočné bezpečnostné prostriedky.

  Napríklad dobrým zvykom je povolenie prenosu iba z určitej MAC adresy účastníka IXP, o ktorej sa dohodne vopred. Zákaz prenosu s poliami ethertype, ktoré sú odlišné od 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP); to sa robí na filtrovanie prenosu, ktorému nie je miesto pri BGP peeringu. Môžu sa tiež použiť mechanizmy ako GTSM, RPKI atď.

Azda vyššie uvedené sú základné komponenty akéhokoľvek IXP bez ohľadu na jeho rozsah. Samozrejme, u veľkých IXP môžu byť použité dodatočné technológie a riešenia.
Niekedy IXP poskytuje svojim účastníkom aj dodatočné služby:

• umiestňuje na IXP TLD DNS servery,
• inštaluje hardvérové NTP servery, umožňujúc účastníkom presne synchronizovať čas,
• poskytuje ochranu pred DDoS útokmi atď.

Princíp fungovania

Prejdime k princípu fungovania bodu výmeny prenosu na príklade najjednoduchšieho IXP, modelovaného prostriedkami EVE-NG, a potom sa pozrieme na základnú konfiguráciu softvérového smerovača BIRD. Na zjednodušenie schémy vynecháme také dôležité veci ako rezervovanie a odolnosť voči poruchám.

Topológia siete je zobrazená na obrázku nižšie.

Predpokladajme, že spravujeme malý bod výmeny prenosu a poskytujeme nasledujúce možnosti peerovania:

• verejné peerovanie,
• súkromné peerovanie,
• peerovanie cez route server.

Číslo našej AS je 555, vlastníme blok IPv4 adries – 50.50.50.0/24, z ktorého vydávame IP adresy tým, ktorí sa chcú pripojiť k našej sieti.

50.50.50.254 – IP adresa nastavená na rozhraní route servera, s touto IP adresou budú klienti vytvárať BGP spojenie v prípade peerovania cez RS.

Taktiež sme pre peerovanie cez RS vypracovali najjednoduchšiu politiku smerovania na základe BGP community, ktorá umožňuje účastníkom IXP regulovať, komu a aké trasy posielať:

BGP community
Popis

LOCAL_AS:PEER_AS
Preniesť prefixy iba PEER_AS

LOCAL_AS:IXP_AS
Preniesť prefixy všetkým účastníkom IXP

Na našu IXP sa chcú pripojiť a vymieňať si prenos traja klienti; predpokladajme, že to sú internetoví poskytovatelia. Všetci chcú zorganizovať peerovanie cez route server. Nižšie sú uvedené schémy s parametrami pripojenia klientov:

Klienta
Číslo AS klienta
Ankonceované prefixy klientom
IP adresa pridelená klientovi na pripojenie k 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

Základná konfigurácia BGP na smerovači klienta:

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

Tu je potrebné poznamenať nastavenie no bgp enforce-first-as. Podľa predvolenia BGP vyžaduje, aby v as-path prijatého BGP updatu bol prítomný číslo as bgp peer, od ktorého bol daný update prijatý. Keďže však route server nezasahuje do as-path, jeho číslo v as-path nebude prítomné a update bude zamietnutý. Toto nastavenie sa používa na to, aby router začal ignorovať túto pravidlo.

Taktiež vidíme, že klient nastavil bgp community 555:555 na tento prefix, čo podľa našich politík znamená, že klient chce tento prefix oznámiť všetkým ostatným účastníkom.

Pre routery ostatných klientov bude nastavenie podobné, s výnimkou ich jedinečných parametrov.

Príklad konfigurácie BIRD:

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

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

Ďalej sa popisuje filter, ktorý neprijíma martians prefixy, ako aj prefixy samotnej 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;
}

Táto funkcia implementuje politiku smerovania, ktorú sme popísali skôr.

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;


}

Nastavujeme peering, aplikujeme príslušné filtre a politiky.

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;
  }
}

Je potrebné poznamenať, že na route serveri je dobrým zvykom ukladať trasy od rôznych peerov do rôznych RIB. BIRD to umožňuje. V našom príklade, pre jednoduchosť, sa všetky aktualizácie prijaté od všetkých klientov ukladajú do jednej spoločnej RIB.

Takže si skontrolujeme, čo sme dosiahli.

Na route serveri vidíme, že s tromi klientmi je nastavená BGP relácia:

Vidíme, že dostávame prefixy od všetkých klientov:

Na smerovači as 100 vidíme, že pri jedinej BGP relácii so serverom smerovania dostávame prefixy aj od as 200 a as 300, pričom BGP atribúty sa nezmenili, ako keby došlo k priamemu prepojeniu medzi klientmi:

Tak vidíme, že prítomnosť servera smerovania značne zjednodušuje organizáciu peeringu na IXP.

Dúfam, že táto ukážka vám pomohla lepšie pochopiť, ako fungujú body výmeny toku a ako funguje server smerovania na IXP.

Linxdatacenter IX

V Linxdatacenter sme vybudovali vlastný IXP na základe redundantnej infraštruktúry pozostávajúcej z dvoch prepínačov a dvoch route serverov. Naša IXP je teraz spustená v testovacom režime a pozývame všetkých, ktorí majú záujem, pripojiť sa k Linxdatacenter IX a zúčastniť sa testovania. Pri pripojení vám bude poskytnutý port s prenosovou kapacitou 1 Gbit/s, možnosť peeringu prostredníctvom našich route serverov a aj prístup do osobného účtu IX portálu, ktorý je dostupný na adrese ix.linxdatacenter.com.

Napíšte do komentárov alebo súkromných správ pre prístup k testovaniu.

Záver

Body výmeny toku vznikli na začiatku internetu ako nástroj na riešenie problémov s neoptimálnym prechodom toku medzi operátorom služieb. V súčasnosti, s príchodom nových globálnych služieb a zvyšovaním objemu CDN toku, body výmeny stále optimalizujú fungovanie globálnej siete. Zvyšovanie počtu IXP na svete prináša výhody pre koncových používateľov služieb, operátorov služieb, poskytovateľov obsahu atď. Pre účastníkov IXP sa výhoda prejavuje v znižovaní nákladov na organizáciu externého peeringu, znižovaní množstva toku, za ktorý treba platiť vyšším operátorom, optimalizácii smerovania a možnosti mať priamy spojenie s poskytovateľmi obsahu.

Užitočné odkazy

• Pozrite si mapu umiestnenia bodov výmeny toku: www.internetexchangemap.com
• Pozrite si podrobné štatistiky o BGP peeringu, vrátane prítomnosti na IXP: www.peeringdb.com

Zdroj: habr.com