Bod přesunu dat: od počátků k vytvoření vlastní IX

„Navázali jsme telefonní spojení mezi námi a kluky ze SRI...“, řekl Kleinrock v rozhovoru:
„Napsali jsme L a na telefonu se ptali: ‚Vidíte L?‘“
„Ano, vidíme L,“ přišla odpověď.
„Napsali jsme O a ptali jsme se: ‚Vidíte O?‘“
„Ano, vidíme O.“
„Pak jsme napsali G, a systém se zhroutil“...

Ale revoluce již začala...

Začátek internetu.

Ahoj všichni!

Jmenuji se Alexander, jsem síťový inženýr ve společnosti Linxdatacenter. V dnešním článku se budu zabývat body výměny dat (Internet Exchange Point, IXP): co předcházelo jejich vzniku, jaké úkoly řeší a jak jsou budovány. Také ukážu princip fungování IXP pomocí platformy EVE-NG a softwarového routeru BIRD, abychom pochopili, jak to funguje 'pod pokličkou'.

Trocha historie

Pokud se podíváte tady, můžete si všimnout, že prudký růst počtu bodů výměny dat začal v roce 1993. Bylo to dáno tím, že většina datového provozu existujících operátorů se v té době odbavila přes páteřní síť USA. Například, když datový provoz šel od operátora ve Francii k operátorovi v Německu, nejprve putoval do USA a teprve poté z USA do Německa. Páteřní síť sloužila v tomto případě jako tranzit mezi Francií a Německem. Dokonce i provoz uvnitř jedné země často neprocházel přímo, ale přes páteřní sítě amerických operátorů.

Tento stav věcí ovlivňoval nejen náklady na dodání tranzitního datového provozu, ale i kvalitu kanálů a latenci. Počet uživatelů internetu rostl, objevovali se noví operátoři, objem datového provozu se zvyšoval, internet dospíval. Operátoři po celém světě začali chápat, že potřebují racionálnější přístup k uspořádání interoperačního jednání. „Proč bych měl, jako operátor A, platit za tranzit přes jinou zemi, abych dodal provoz operátorovi B, který sídlí na sousední ulici?“ Takovou otázku si kladli operátoři v té době. Tak začaly v různých částech světa vznikat body výměny dat na místech koncentrace operátorů:

• 1994 - LINX v Londýně,
• 1995 - DE-CIX ve Frankfurtu,
• 1995 - MSK-IX v Moskvě atd.

Internet a současnost

Konceptuálně architektura moderního internetu představuje množství autonomních systémů (autonomous system, AS) a množství spojení mezi nimi, jak fyzických, tak logických, které určují cestu průchodu dat od jednoho AS k druhému.

AS obvykle zahrnují poskytovatele telekomunikačních služeb, internetové poskytovatele, CDN, datová centra a společnosti v segmentu enterprise. AS organizují logická spojení (peering) mezi sebou, obvykle prostřednictvím protokolu BGP.

To, jak autonomní systémy organizují tato spojení, závisí na několika faktorech:

• geografických,
• ekonomických,
• politických,
• dohodách a společných zájmech mezi vlastníky AS,
• atd.

Samozřejmě, v tomto schématu existuje určitá struktura a hierarchie. Takže operátoři se dělí na tier-1, tier-2 a tier-3, a pokud klienty místního internetového poskytovatele (tier-3) obvykle tvoří běžní uživatelé, pak pro operátory úrovně tier-1 jsou klienty jiní operátoři. Operátoři tier-3 agregují provoz svých abonentů, operátoři tier-2 zase agregují provoz operátorů tier-3, a tier-1 – veškerý internetový provoz.

Schématicky to můžeme představit takto:

Na tomto obrázku je vidět, že provoz se agreguje zdola nahoru, tj. od koncových uživatelů k operátorům tier-1. Také se odehrává horizontální výměna provozu mezi zhruba rovnocennými AS.

Neodmyslitelnou součástí a zároveň nedostatkem tohoto schématu je určitá neuspořádanost spojení mezi autonomními systémy, které se nacházejí blíže k koncovému uživateli, v rámci geografické zóny. Podívejme se na obrázek níže:

Předpokládejme, že ve velkém městě je přítomno 5 poskytovatelů telekomunikačních služeb, jejichž peering je z různých důvodů organizován tak, jak je uvedeno výše.

Pokud se uživatel Petya, připojený k internetovému poskytovateli Go, pokusí získat přístup k serveru připojenému k poskytovateli ASM, musel by provoz mezi nimi projít přes 5 autonomních systémů. Tím se zvyšuje zpoždění, protože se zvyšuje počet síťových zařízení, přes které provoz projde, a také objem tranzitního provozu na autonomních systémech mezi Go a ASM.

Jak snížit počet tranzitních AS, kterými musí provoz projít? Správně - bod výměny provozu.

V dnešní době vznik nových IXP vychází ze stejných potřeb jako na začátku 90. let a 2000, pouze v menším měřítku, v reakci na rostoucí počet poskytovatelů služeb, uživatelů a provozu, rostoucí množství obsahu generovaného sítěmi CDN a datovými centry.

Co je to bod výměny provozu?

Bod výměny provozu je místo se speciální síťovou infrastrukturou, kde zainteresované strany, které se chtějí vzájemně vyměnit provozem, organizují vzájemný peering. Hlavními účastníky bodů výměny provozu jsou: operátoři telekomunikací, poskytovatelé Internetu, poskytovatelé obsahu a datová centra. Na místech výměny provozu se účastníci připojují přímo. To umožňuje řešit následující úkoly:

• snížit latenci,
• snížit množství tranzitního provozu,
• optimalizovat směrování mezi AS.

Vzhledem k tomu, že IXP jsou přítomny ve velkých městech po celém světě, má to příznivý dopad také na síť Internetu jako celek.

Pokud bychom výše popsanou situaci s Petrou řešili pomocí IXP, dopadalo by to přibližně takto:

Jak funguje bod výměny provozu?

IXP je obvykle samostatná AS se svým blokem veřejných IPv4/IPv6 adres.

Síť IXP se obvykle skládá z čistého L2 domény. Někdy to je jednoduše VLAN, ve které jsou umístěni všichni klienti IXP. Když se mluví o větších, geograficky rozptýlených IXP, mohou být pro vytváření L2 domény použity technologie jako MPLS, VXLAN a další.

Prvky IXP

• SCS. Není v tom nic zvláštního: racky, optické křížení, patch panely.
• Přepínače – základ IXP. Port přepínače je vstupním bodem do sítě IXP. Přepínače též vykonávají část bezpečnostních funkcí – filtrují nežádoucí provoz, který by na síti IXP neměl být. Obvykle se přepínače vybírají na základě požadavků na funkčnost – spolehlivost, podporovaná rychlost portů, bezpečnostní funkce, podpora sFlow atd.
• Route server (RS) Je neodmyslitelná a nezbytná součást každého moderního místa výměny provozu. Po principu fungování se velmi podobá route reflector v iBGP nebo designated router v OSPF a řeší stejné problémy. S růstem počtu účastníků místa výměny provozu také roste počet BGP session, které musí každý účastník udržovat, což připomíná klasickou full-mesh topologii v iBGP. RS problém řeší následujícím způsobem: navazuje BGP session s každým zainteresovaným účastníkem IXP a ten se stává klientem RS. Při zpracování BGP update od jednoho ze svých klientů RS tento update rozesílá všem ostatním svým klientům, samozřejmě s výjimkou toho, od kterého byl tento update přijat. Tímto způsobem RS zbavuje nutnosti navazovat full-mesh mezi všemi účastníky IXP a elegantně řeší problém škálovatelnosti. Je třeba poznamenat, že server trasování transparentně předává trasy z jedné AS do druhé, aniž by měnil přenášené BGP atributy, například nepřidává číslo své AS do AS-path. Také na RS dochází k základní filtraci tras: například RS nepřijímá martians networks a prefixy samotného IXP.

  Jako řešení se často používá software s otevřeným zdrojovým kódem – BIRD (bird internet routing daemon). Je dobrý tím, že je zdarma, rychle se nasazuje na většině linuxových distribucí, má flexibilní mechanismus nastavení politik trasování/filterace a nevytěžuje příliš mnoho výpočetních zdrojů. Jako RS může být také vybrán hardwarový/virtuální router Cisco, Juniper atd.

• Bezpečnost. Jelikož síť IXP je koncentrací velkého počtu AS, musí být politika zabezpečení, kterou musí všichni účastníci dodržovat, dobře popsána. Obvykle se zde uplatňují stejné mechanismy, které se používají při navazování BGP sousedství mezi dvěma jednotlivými BGP peer mimo IXP, a také jsou zde používány některé další ochranné prostředky.

  Například dobrým postupem je propustit provoz pouze z určitého MAC adresu účastníka IXP, který je dohodnut předem. Zákaz provozu s poli ethertype, které se liší od 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP); to se dělá za účelem filtrování provozu, kterému není místo při BGP peeringu. Mohou být také použity takové mechanismy jako GTSM, RPKI atd.

Snad, výše uvedené – jsou to hlavní složky jakéhokoli IXP bez ohledu na jeho velikost. Samozřejmě, u větších IXP mohou být použity další technologie a řešení.
Někdy IXP také poskytuje svým účastníkům další služby:

• umísťování TLD DNS serverů na IXP,
• instalaci hardwarových NTP serverů, umožňující účastníkům přesně synchronizovat čas,
• poskytování ochrany proti DDoS útokům atd.

Princip práce

Podívejme se na princip fungování bodu výměny provozu na příkladu nejjednoduššího IXP, který byl modelován pomocí EVE-NG, a poté prozkoumejme základní konfiguraci softwarového routeru BIRD. Pro zjednodušení schématu vynecháme takové důležité věci jako je zálohování a odolnost vůči poruchám.

Topologie sítě je znázorněna na obrázku níže.

Předpokládejme, že spravujeme malý bod výměny provozu a nabízíme následující možnosti peeringu:

• veřejný peering,
• soukromý peering,
• peering přes route server.

Číslo naší AS je 555, vlastníme blok IPv4 adres – 50.50.50.0/24, ze kterého vydáváme IP adresy těm, kteří se chtějí připojit k naší síti.

50.50.50.254 – IP adresa nastavená na rozhraní route serveru, s touto IP klienti budou vytvářet BGP relaci v případě peeringu přes RS.

Také pro peering přes RS jsme vyvinuli nejjednodušší politiku směrování na základě BGP community, která umožňuje účastníkům IXP regulovat, komu a jaké trasy posílat:

BGP community
Popis

LOCAL_AS:PEER_AS
Přesunout prefixy pouze PEER_AS

LOCAL_AS:IXP_AS
Přesunout prefixy všem účastníkům IXP

K naší IXP se chtějí připojit a vyměnit si provoz 3 klienti; předpokládejme, že to jsou poskytovatelé internetu. Všichni chtějí organizovat peering přes route server. Níže je uvedeno schéma s parametry připojení klientů:

Zákazník
Číslo AS klienta
Inzerované prefixy klienta
IP adresa přidělená klientovi pro připojení 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í konfigurace BGP na routeru 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

Je třeba poznamenat konfiguraci no bgp enforce-first-as. Ve výchozím nastavení BGP vyžaduje, aby v as-path přijaté BGP aktualizace byl číslo AS BGP peer, ze kterého byla tato aktualizace přijata. Ale protože route server neprovádí změny v as-path, jeho číslo v as-path nebude, a aktualizace bude zamítnuta. Tento nastavení se používá k tomu, aby router začal toto pravidlo ignorovat.

Také vidíme, že klient nastavil BGP komunitu 555:555 na tento prefix, což podle naší politiky znamená, že klient chce tento prefix oznámit všem ostatním účastníkům.

Pro routery ostatních klientů bude nastavení obdobné, s výjimkou jejich jedinečných parametrů.

Příklad konfigurace BIRD:

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

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

Dále je popsán filtr, který nepřijímá martians prefixy, stejně jako prefixy samotné 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;
}

Tato funkce implementuje pravidla směrování, která jsme popsali dříve.

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 odpovídající filtry 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 třeba poznamenat, že na route serveru je dobrým tónem ukládat trasy od různých peerů do různých RIB. BIRD to umožňuje. V našem příkladu se však pro jednoduchost všechny aktualizace přijaté od všech klientů ukládají do jedné společné RIB.

Takže se podívejme, co jsme vytvořili.

Na serveru route vidíme, že se všemi třemi klienty je nastavena BGP relace:

Vidíme, že dostáváme prefixy od všech klientů:

Na směrovači as 100 vidíme, že při jediné BGP relaci se serverem směrování dostáváme prefixy jak od as 200, tak od as 300, přičemž BGP atributy zůstaly nezměněny, jako by bylo přímé peering mezi klienty:

Tímto způsobem vidíme, že přítomnost serveru směrování značně usnadňuje organizaci peerování na IXP.

Doufám, že tato ukázka vám pomohla lépe pochopit, jak fungují body výměny provozu a jak funguje server směrování na IXP.

Linxdatacenter IX

V Linxdatacenter jsme postavili vlastní IXP na bázi spolehlivé infrastruktury ze 2 přepínačů a 2 route serverů. Naše IXP je nyní spuštěna v testovacím režimu a zveme všechny zájemce, aby se připojili k Linxdatacenter IX a účastnili se testování. Při připojení obdržíte port s propustností 1 Gbit/s, možnost peeringu přes naše route servery a také přístup do osobního účtu IX portálu, dostupného na adrese ix.linxdatacenter.com.

Napište do komentářů nebo osobních zpráv pro získání přístupu k testování.

Výstup

Body výměny provozu vznikly na počátku internetu jako nástroj k řešení problému suboptimálního průchodu provozu mezi telekomunikačními operátory. Nyní s nástupem nových globálních služeb a zvýšením množství CDN provozu body výměny stále optimalizují práci globální sítě. Zvyšující se počet IXP na světě přináší užitek jak pro koncového uživatele služby, tak pro telekomunikační operátory, poskytovatele obsahu atd. Pro účastníky IXP se přínos projevuje ve snížení nákladů na organizaci externího peeringu, snížení objemu provozu, za který se platí nadřazeným operátorům, optimalizaci směrování a možnosti mít přímé spojení s poskytovateli obsahu.

Užitečné odkazy

• Zobrazit mapu umístění bodů výměny provozu: www.internetexchangemap.com
• Zobrazit podrobné statistiky o BGP peerování, včetně přítomnosti na IXP: www.peeringdb.com

Zdroj: habr.com