„Telefonkapcsolatot hoztunk létre köztünk és az SRI srácai között…” – mondta Kleinrock... egy interjúban:
„Beírtuk az L-t, és megkérdeztük telefonon: „Látod az L-t?”
„Igen, látjuk az L-t” – hangzott a válasz.
„Beírtuk az O-t, és megkérdeztük: „Látod az O-t?”
– Igen, látjuk az O-t.
"Aztán beírtuk a G-t, és a rendszer összeomlott"...Mégis forradalom kezdődött…
Az internet kezdete.
Hello!
A nevem Alexander, hálózati mérnök vagyok a Linxdatacenternél. Mai cikkünkben a forgalmi cserepontokról (Internet Exchange Points, IXP) lesz szó: mi előzte meg megjelenésüket, milyen feladatokat oldanak meg és hogyan épülnek fel. Ebben a cikkben is bemutatom az IXP működési elvét az EVE-NG platform és a BIRD szoftver útválasztó használatával, hogy megértse, hogyan működik „a motorháztető alatt”.
Egy kis történelem
Ha megnézed , akkor látható, hogy a forgalmi cserepontok számának rohamos növekedése 1993-ban kezdődött. Ez annak köszönhető, hogy az akkori távközlési szolgáltatók forgalmának nagy része az amerikai gerinchálózaton haladt keresztül. Így például amikor a forgalom egy franciaországi operátortól egy németországi üzemeltetőhöz ment, először Franciaországból az USA-ba, és csak azután az USA-ból Németországba. A gerinchálózat ebben az esetben tranzitként működött Franciaország és Németország között. Még az egy országon belüli forgalom is gyakran nem közvetlenül, hanem az amerikai szolgáltatók gerinchálózatain keresztül haladt.
Ez az állapot nemcsak a tranzitforgalom lebonyolításának költségeire volt hatással, hanem a csatornák minőségére és a késésekre is. Nőtt az internetezők száma, új szolgáltatók jelentek meg, nőtt a forgalom volumene, az internet érett. Az üzemeltetők szerte a világon kezdték felismerni, hogy racionálisabb megközelítésre van szükség az operátorok közötti interakció megszervezéséhez. „Miért kellene nekem, A szolgáltatónak, fizetni egy másik országon keresztüli tranzitért, hogy a forgalmat a következő utcában található B szolgáltatóhoz irányíthassam?” Nagyjából ezt a kérdést tették fel maguknak annak idején a távközlési szolgáltatók. Így forgalmi cserepontok kezdtek megjelenni a világ különböző részein a kezelői koncentrációs pontokon:
- 1994 – LINX Londonban,
- 1995 – DE-CIX Frankfurtban,
- 1995 – MSK-IX, Moszkvában stb.
Internet és napjaink
Koncepcionálisan a modern Internet architektúrája számos autonóm rendszerből (AS) és köztük számos fizikai és logikai kapcsolatból áll, amelyek meghatározzák az egyik AS-től a másikig tartó forgalom útvonalát.
Az AS-ek általában távközlési szolgáltatók, internetszolgáltatók, CDN-ek, adatközpontok és nagyvállalati szegmensbeli vállalatok. Az AS-ek logikai kapcsolatokat (peering) szerveznek egymás között, általában a BGP protokoll használatával.
Az, hogy az autonóm rendszerek hogyan szervezik meg ezeket a kapcsolatokat, számos tényezőtől függ:
- földrajzi,
- gazdasági,
- politikai,
- az AS tulajdonosok közötti megállapodások és közös érdekek,
- stb
Természetesen ennek a sémának van egy bizonyos szerkezete és hierarchiája. Így az üzemeltetőket 1., 2. és 3. rétegre osztják, és ha a helyi internetszolgáltató (3. szint) ügyfelei általában hétköznapi felhasználók, akkor például az 1. szintű operátorok az ügyfelek más operátorok. A 3-as szintű szolgáltatók összesítik előfizetőik forgalmát, a 2-es szintű távközlési szolgáltatók pedig a 3-as szintű szolgáltatók forgalmát, a tier-1 pedig az összes internetes forgalmat.
Sematikusan a következőképpen ábrázolható:
Ezen a képen látható, hogy a forgalom alulról felfelé összesítve, azaz. a végfelhasználóktól az 1. szintű operátorokig. A forgalom horizontális cseréje is zajlik az egymással megközelítőleg egyenértékű AS-ek között.
Ennek a sémának szerves része és egyben hátránya a végfelhasználóhoz közelebb, egy földrajzi területen belül elhelyezkedő autonóm rendszerek közötti kapcsolatok bizonyos zavara. Tekintsük az alábbi képet:
Tegyük fel, hogy egy nagyvárosban 5 távközlési szolgáltató működik, amelyek között valamilyen okból a fent látható módon szerveződnek.
Ha a Go ISP-hez csatlakozott Petya felhasználó egy ASM szolgáltatóhoz kapcsolódó szerverhez szeretne hozzáférni, akkor a köztük lévő forgalom 5 autonóm rendszeren kénytelen áthaladni. Ez növeli a késést, mert nő azoknak a hálózati eszközöknek a száma, amelyeken keresztül a forgalom halad, valamint a Go és az ASM közötti autonóm rendszerek tranzitforgalmának volumene.
Hogyan csökkenthető a tranzit AS-ek száma, amelyeken a forgalom kénytelen áthaladni? Így van - forgalmi cserepont.
Ma az új IXP-k megjelenését ugyanazok az igények vezérlik, mint a 90-es-2000-es évek elején, csak kisebb léptékben, válaszul a távközlési szolgáltatók, felhasználók és forgalom növekedésére, a CDN-hálózatok által generált tartalom növekedésére. és adatközpontok.
Mi az a cserepont?
A forgalomcsere pont egy speciális hálózati infrastruktúrával rendelkező hely, ahol a kölcsönös forgalomcserében érdekelt résztvevők kölcsönös peering-et szerveznek. A forgalmi cserepontok fő szereplői: távközlési szolgáltatók, internetszolgáltatók, tartalomszolgáltatók és adatközpontok. A forgalmi cserepontokon a résztvevők közvetlenül kapcsolódnak egymáshoz. Ez lehetővé teszi a következő problémák megoldását:
- csökkenti a késleltetést,
- csökkenti a tranzit forgalom mértékét,
- optimalizálja az AS közötti útválasztást.
Figyelembe véve, hogy az IXP-k a világ számos nagyvárosában jelen vannak, mindez jótékony hatással van az internet egészére.
Ha a fenti helyzet Petyával megoldódik IXP segítségével, akkor valami ilyesmi lesz:
Hogyan működik egy forgalmi cserepont?
Általános szabály, hogy az IXP egy különálló AS, saját nyilvános IPv4/IPv6-címekkel.
Az IXP hálózat leggyakrabban egy folyamatos L2 tartományból áll. Néha ez egyszerűen egy VLAN, amely az összes IXP-klienst tárolja. Ha nagyobb, földrajzilag elosztott IXP-kről van szó, az olyan technológiák, mint az MPLS, VXLAN stb., használhatók egy L2 tartomány szervezésére.
IXP elemek
- SKS. Nincs itt semmi szokatlan: állványok, optikai keresztkapcsolatok, patch panelek.
- Kapcsolók – az IXP alapja. A kapcsolóport a belépési pont az IXP hálózatba. A kapcsolók a biztonsági funkciók egy részét is ellátják - kiszűrik a levélszemét-forgalmat, amelynek nem kellene jelen lennie az IXP hálózaton. A kapcsolókat általában a funkcionális követelmények alapján választják ki - megbízhatóság, támogatott portsebesség, biztonsági funkciók, sFlow támogatás stb.
- Útvonalszerver (RS) – minden modern forgalmi cserepont szerves és szükséges része. A működési elv nagyon hasonló az iBGP-ben lévő útvonal-reflektorhoz vagy az OSPF-ben kijelölt útválasztóhoz, és ugyanazokat a problémákat oldja meg. Ahogy a forgalmi cserepont résztvevőinek száma növekszik, úgy növekszik azon BGP munkamenetek száma, amelyeket minden résztvevőnek támogatnia kell, pl. ez az iBGP klasszikus full-mesh topológiájára emlékeztet. Az RS a következő módon oldja meg a problémát: minden érdeklődő IXP-résztvevővel BGP-munkamenetet hoz létre, és ez a résztvevő RS-klienssé válik. Egyik kliensétől BGP-frissítést kapva az RS ezt a frissítést elküldi az összes többi kliensének, természetesen annak kivételével, amelyiktől ezt a frissítést kapta. Így az RS szükségtelenné teszi a teljes háló létrehozását az összes IXP-tag között, és elegánsan megoldja a méretezhetőségi problémát. Érdemes megjegyezni, hogy az útvonalszerver transzparensen továbbítja az útvonalakat egyik AS-ből a másikba anélkül, hogy módosítaná a BGP által továbbított attribútumokat, például nem adja hozzá az AS-ben lévő számot az AS-útvonalhoz. Az RS-en is van az útvonalak alapvető szűrése: például az RS nem fogadja el a marslakói hálózatokat és magának az IXP-nek az előtagjait.
A nyílt forráskódú szoftveres útválasztót, a BIRD-t (bird internet routing démon) gyakran használják útvonalkiszolgáló megoldásként. Az a jó benne, hogy ingyenes, gyorsan telepíthető a legtöbb Linux disztribúcióra, rugalmas mechanizmussal rendelkezik az útválasztási/szűrési házirendek beállításához, és nem igényel számítási erőforrásokat. Ezenkívül egy Cisco, Juniper stb. hardveres/virtuális útválasztója választható RS-ként.
- Biztonság. Mivel egy IXP-hálózat nagyszámú AS-ből áll, a biztonsági szabályzatot, amelyet minden résztvevőnek követnie kell, jól meg kell írni. Általánosságban elmondható, hogy itt is érvényesek mindazok a mechanizmusok, amelyek az IXP-n kívüli két különálló BGP-társ közötti BGP-szomszédság létesítésekor érvényesek, valamint néhány további biztonsági funkció.
Például jó gyakorlat, ha csak az IXP-résztvevő meghatározott mac-címéről engedélyezi a forgalmat, amelyről előzetesen egyeztetnek. Forgalom tiltása 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP) ethertype mezőkkel; Ez azért történik, hogy kiszűrjük a BGP-társkapcsolatba nem tartozó forgalmat. Olyan mechanizmusok is használhatók, mint a GTSM, RPKI stb.
Talán a fentiek a fő összetevői bármely IXP-nek, mérettől függetlenül. Természetesen a nagyobb IXP-k további technológiákkal és megoldásokkal is rendelkezhetnek.
Előfordul, hogy az IXP további szolgáltatásokat is nyújt résztvevői számára:
- elhelyezve az IXP TLD DNS-kiszolgálón,
- hardveres NTP-szerverek telepítése, lehetővé téve a résztvevőknek az idő pontos szinkronizálását,
- védelmet nyújtanak a DDoS támadások ellen stb.
Működési elv
Nézzük meg egy forgalmi cserepont működési elvét egy egyszerű IXP példáján, EVE-NG segítségével modellezve, majd nézzük meg a BIRD szoftveres útválasztó alapbeállításait. A diagram egyszerűsítése érdekében elhagyjuk az olyan fontos dolgokat, mint a redundancia és a hibatűrés.
A hálózati topológia az alábbi ábrán látható.
Tegyük fel, hogy egy kis cserepontot adminisztrálunk, és biztosítjuk a következő társviszony-létesítési lehetőségeket:
- nyilvános szemlélődés,
- privát bejárás,
- társkeresés útvonalszerveren keresztül.
AS számunk 555, birtokunkban van egy IPv4-címblokk – 50.50.50.0/24, amelyből IP-címeket adunk ki azoknak, akik csatlakozni szeretnének hálózatunkhoz.
50.50.50.254 – IP-cím az útvonalszerver interfészén konfigurálva, ezzel az IP-vel a kliensek BGP-munkamenetet hoznak létre RS-en keresztüli peering esetén.
Ezenkívül az RS-en keresztüli társításhoz egy egyszerű, a BGP közösségen alapuló útválasztási szabályzatot dolgoztunk ki, amely lehetővé teszi az IXP résztvevői számára, hogy szabályozzák, kinek és milyen útvonalakat küldjenek:
BGP közösség
Leírás
LOCAL_AS:PEER_AS
Előtagok küldése csak a PEER_AS számára
LOCAL_AS:IXP_AS
Az előtagok átvitele az összes IXP résztvevőhöz
3 kliens szeretne csatlakozni az IXP-ünkhöz, és forgalmat cserélni; Tegyük fel, hogy ezek internetszolgáltatók. Mindannyian egy útvonalszerveren keresztül akarják megszervezni a társkeresést. Az alábbi diagram az ügyfélkapcsolat paramétereit tartalmazza:
vásárló
Ügyfél AS szám
Az ügyfél által meghirdetett előtagok
A kliensnek kiadott IP-cím az IXP-hez való csatlakozáshoz
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
Alapvető BGP-beállítások a kliens útválasztón:
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
Itt érdemes megjegyezni a no bgp enforce-first-as beállítást. Alapértelmezés szerint a BGP megköveteli, hogy a fogadott BGP-frissítés as-útvonala tartalmazza annak a partnernek a as bgp számát, amelytől a frissítés érkezett. De mivel az útvonalszerver nem módosítja az as-path-ot, annak száma nem lesz az as-path-ban, és a frissítés elveti. Ez a beállítás arra szolgál, hogy az útválasztó figyelmen kívül hagyja ezt a szabályt.
Azt is látjuk, hogy az ügyfél ehhez az előtaghoz a bgp Community 555:555-öt állította be, ami szabályzatunk szerint azt jelenti, hogy az ügyfél ezt az előtagot szeretné hirdetni az összes többi résztvevő számára.
Más kliensek routereinél a beállítások hasonlóak lesznek, kivéve egyedi paramétereiket.
Példa BIRD konfigurációra:
define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];
template bgp RS_CLIENT {
local as ixp_as;
rs client;
}
Az alábbiakban egy olyan szűrőt írunk le, amely nem fogadja el a marsiak előtagjait, valamint magának az IXP-nek az előtagjait:
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;
}
Ez a funkció a korábban leírt útválasztási szabályzatot valósítja meg.
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;
}
Konfiguráljuk a társviszony-létesítést, alkalmazzuk a megfelelő szűrőket és szabályzatokat.
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;
}
}
Érdemes megjegyezni, hogy egy útvonalszerveren jó gyakorlat, ha a különböző társaktól származó útvonalakat különböző RIB-ekbe helyezi. A BIRD lehetővé teszi ezt. Példánkban az egyszerűség kedvéért az összes ügyféltől kapott összes frissítés egyetlen közös RIB-be kerül.
Szóval, nézzük, mit kaptunk.
Az útvonalszerveren azt látjuk, hogy mindhárom klienssel létrejött egy BGP-munkamenet:
Látjuk, hogy minden ügyféltől kapunk előtagot:
Az as 100-as útválasztón azt látjuk, hogy ha csak egy BGP-munkamenet van az útvonalkiszolgálóval, akkor 200-ból és 300-ból is kapunk előtagokat, miközben a BGP-attribútumok nem változtak, mintha a kliensek közötti peering közvetlenül történt volna:
Így azt látjuk, hogy az útvonalszerver jelenléte nagyban leegyszerűsíti a társviszony-létesítés megszervezését az IXP-n.
Remélem, hogy ez a bemutató segített jobban megérteni az IXP-k működését és az útvonalszerver működését egy IXP-n.
Linxdatacenter IX
A Linxdatacenternél saját IXP-t építettünk, amely 2 kapcsolóból és 2 útvonalszerverből álló hibatűrő infrastruktúrára épül. Az IXP-nk most teszt módban fut, és mindenkit meghívunk, hogy csatlakozzon a Linxdatacenter IX-hez és vegyen részt a tesztelésben. Csatlakozáskor egy 1 Gbit/s sávszélességű portot, az útvonalszervereinken való peerelés lehetőségét, valamint hozzáférést kap az IX portálon elérhető személyes fiókjához, amely a következő címen érhető el. .
Írja meg kommentben vagy privát üzenetben, hogy hozzáférjen a teszteléshez.
Teljesítmény
A forgalmi cserepontok az internet hajnalán jelentek meg a távközlési szolgáltatók közötti szuboptimális forgalom problémájának megoldására. Most, az új globális szolgáltatások megjelenésével és a CDN forgalom növekedésével, a cserepontok továbbra is optimalizálják a globális hálózat működését. Az IXP-k számának növekedése a világon mind a szolgáltatás végfelhasználójának, mind a távközlési szolgáltatóknak, tartalomszolgáltatóknak stb. Az IXP résztvevői számára a haszon a külső peering megszervezésének költségeinek csökkentésében, a magasabb szintű szolgáltatóknak fizetendő forgalom csökkentésében, az útválasztás optimalizálásában, valamint a tartalomszolgáltatókkal való közvetlen kapcsolattartás lehetőségében fejeződik ki.
Hasznos Linkek
- Tekintse meg a forgalmi cserepontok elhelyezkedésének térképét:
- Részletes statisztikák megtekintése a BGP társviszony-létesítésről, beleértve az IXP-n való jelenlétet:
Forrás: will.com