„Telefonkapcsolatot hoztunk létre köztünk és az SRI-nél dolgozó srácok között...“ - mondta Kleinrock egy interjúban.
„Beírtuk az L betűt, és telefonon kérdeztük: ‚Látjátok az L-t?‘“
„Igen, látjuk az L-t“ - érkezett a válasz.
„Beírtuk az O betűt, és kérdeztük: ‚Látjátok az O-t?‘“
„Igen, látjuk az O-t.“
„Aztán beírtuk a G-t, és a rendszer összeomlott“...Mégis forradalom indult...
Az internet kezdete.
Mindenkinek szia!
A nevem Alexander, hálózati mérnök vagyok a Linxdatacenter cégnél. A mai cikkben a forgalomcsere pontjairól (Internet Exchange Point, IXP) fogok beszélni: arról, ami a létrejöttük előtt történt, milyen feladatokat látnak el, és hogyan épülnek fel. Ezen kívül bemutatom az IXP működési elvét az EVE-NG platform és a BIRD szoftver útválasztó segítségével, hogy lássuk, hogyan működik ez „a motorháztető alatt“.
Egy kis történelem
Ha megnézzük, , akkor észrevehetjük, hogy a forgalomcsere pontok számának robbanásszerű növekedése 1993-ban kezdődött. Ez összefügg azzal, hogy a korábban létező távközlési szolgáltatók többségének forgalma az Egyesült Államok backbone hálózatán haladt keresztül. Például amikor a forgalom Franciaországból egy német szolgáltatóhoz tartott, először az Egyesült Államokba érkezett, majd onnan Németországba. A backbone hálózat ebben az esetben tranzit szerepet játszott Franciaország és Németország között. Még egy országon belül is gyakran nem közvetlenül történt a forgalomterelés, hanem az amerikai szolgáltatók gerinchálózatai mentén.
Ez a helyzet nemcsak a tranzit forgalom szállításának költségeit befolyásolta, hanem a csatornák minőségét és késését is. Az internet felhasználóinak száma növekedett, új szolgáltatók jelentek meg, és a forgalom mennyisége nőtt, az internet növekedett. A világ minden táján a szolgáltatók kezdték megérteni, hogy racionálisabb megközelítésre van szükség a szolgáltatók közötti interakció megszervezésében. „Miért fizetnék A szolgáltatóként tranzitért egy másik országon keresztül, hogy eljuttassam a forgalmat B szolgáltatóhoz, aki a szomszédos utcában van?“ - ilyen kérdéseket tettek fel maguknak a szolgáltatók abban az időben. Így a világ különböző részein, a szolgáltatók koncentrációjának pontjain forgalomcsere pontok kezdtek kialakulni:
- 1994 - LINX Londonban,
- 1995 - DE-CIX Frankfurtban,
- 1995 - MSK-IX Moszkvában, stb.
Az internet és a mai nap
A modern internet architecture conceptually consists of numerous autonomous systems (autonomous system, AS) and numerous connections between them, both physical and logical, which define the route of traffic from one AS to another.
Typically, AS are represented by telecom operators, internet providers, CDNs, data centers, and enterprise segment companies. AS establish logical connections (peering) among themselves, usually through the BGP protocol.
The way autonomous systems organize these connections is determined by several factors:
- geographical,
- economic,
- political,
- agreements and common interests between AS owners,
- stb.
Of course, this scheme has a certain structure and hierarchy. Operators are divided into tier-1, tier-2, and tier-3, and while tier-3 local internet provider clients are usually regular users, tier-1 operators have other operators as clients. Tier-3 operators aggregate the traffic of their subscribers, tier-2 operators aggregate the traffic of tier-3 operators, and tier-1 aggregates all internet traffic.
This can be schematically represented as follows:
In this picture, it can be seen that traffic is aggregated from the bottom up, i.e., from end users to tier-1 operators. There is also horizontal traffic exchange between relatively equivalent AS.
An integral part and at the same time a drawback of this scheme is a certain disorder in the connections between the autonomous systems located closer to the end user within the geographical area. Let's consider the image below:
Let's assume that in a large city there are 5 telecom operators, between whom peering is organized for various reasons as shown above.
If a user named Petya, connected to the internet provider Go, wants to access a server connected to the provider ASM, then the traffic between them will need to go through 5 autonomous systems. This increases latency, as the number of network devices through which the traffic will pass increases, as well as the volume of transit traffic on the autonomous systems between Go and ASM.
Hogyan lehet csökkenteni a tranzit AS-ek számát, amelyeken a forgalomnak át kell haladnia? A helyes válasz: a forgalmi csomópont.
A mai világban az új IXP-k megjelenése ugyanazon igények miatt történik, mint az 1990-es évek elején és a 2000-es években, csak kisebb léptékben, a növekvő szolgáltató, felhasználó és forgalomszám, valamint a CDN-hálózatok és adatközpontok által generált tartalom növekvő mennyisége válaszreakciójaként.
Mi az a forgalmi csomópont?
A forgalmi csomópont egy olyan hely, ahol speciális hálózati infrastruktúra található, ahol az érdeklődő felek kölcsönös forgalomcserét szerveznek. A forgalmi csomópontok fő résztvevői: szolgáltatók, internetszolgáltatók, tartalom szolgáltatók és adatközpontok. A forgalmi csomópontokban a résztvevők közvetlenül kapcsolódnak egymáshoz. Ez lehetővé teszi a következő problémák megoldását:
- a késleltetés csökkentése,
- a tranzitforgalom csökkentése,
- az AS-ek közötti útvonal optimalizálása.
Tekintettel arra, hogy az IXP-k számos nagyvárosban jelen vannak világszerte, ez kedvezően hat az Internet hálózatára is.
Ha a fenti problémát Péterrel IXP révén kívánja megoldani, akkor így nézne ki:
Hogyan működik egy forgalmi csomópont?
Általában az IXP egy külön AS saját nyilvános IPv4/IPv6 címblokkjával.
Az IXP hálózata általában egy folyamatos L2 domain. Néha egyszerűen csak egy VLAN, amelyben az összes IXP ügyfél található. Amikor viszont nagyobb, földrajzilag elosztott IXP-k szakembereivel beszélünk, az L2 domain létrehozásához ilyen technológiákat használnak, mint az MPLS, VXLAN stb.
Az IXP elemei
- SCS. Itt semmi különös: állványok, optikai kapcsolók, patch panelek.
- A kapcsolók – az IXP alapja. A kapcsoló portja a belépési pont az IXP hálózatába. A kapcsolók egy része a biztonsági funkciókat is ellátja – szűrik a nem kívánt forgalmat, amelynek nem szabad jelen lennie az IXP hálózatában. Általában a kapcsolókat a funkcionalitásra vonatkozó 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.
- Route server (RS) – elengedhetetlen és szükséges része minden modern forgalomcsere-pontnak. Működési elve nagyon hasonlít az iBGP route reflector-ra vagy az OSPF designated router-re, és ugyanazokat a problémákat oldja meg. Ahogy a forgalomcsere-pont résztvevőinek száma növekszik, úgy növekszik a BGP session-ok száma is, amelyeket minden résztvevőnek támogatnia kell, azaz ez egy klasszikus full-mesh topológiához hasonlítható az iBGP-ben. Az RS a következőképpen oldja meg a problémát: BGP session-t állít fel minden érdeklődő IXP résztvevővel, ők lesznek az RS ügyfelei. Amikor az RS kap egy BGP update-et az egyik ügyfelétől, ezt az update-et eljuttatja minden egyéb ügyfelének, természetesen kivéve azt, akitől az update-et kapta. Így az RS megszünteti a full-mesh létrehozásának szükségességét az összes IXP résztvevő között, és elegánsan oldja meg a skálázás problémáját. Érdemes megjegyezni, hogy a route server átláthatóan továbbítja az útvonalakat egyik AS-ről a másikra, anélkül, hogy módosítaná a továbbított BGP attribútumokat, például nem adja hozzá a saját AS számát az AS-path-hez. Az RS-en alapvető útvonal szűrés is történik: például az RS nem fogad el martians networks-et és az IXP saját prefixeit.
Route server-ként gyakran használják az open-source szoftver routert – BIRD (bird internet routing daemon). Azért jó, mert ingyenes, gyorsan telepíthető a legtöbb linux disztribúcióra, rugalmas routing/filtering politika beállítási mechanizmussal rendelkezik, és nem igényel sok számítási erőforrást. Ezen kívül RS-ként hardveres/virtuális routerek, mint például Cisco, Juniper stb. is választhatók.
- Biztonság. Mivel az IXP hálózata nagy számú AS koncentrációja, ezért a biztonsági politika, amelyet minden résztvevőnek követnie kell, jól kidolgozottnak kell lennie. Általában azok a mechanizmusok, amelyeket a BGP szomszédság kialakításakor alkalmaznak két külön BGP peer között az IXP-n kívül, itt is érvényesek, és további védelmi eszközöket is alkalmaznak.
Például jó gyakorlat, hogy csak a résztvevő IXP előre egyeztetett mac-címéről érkező forgalmat engedünk át. Megtagadjuk a forgalmat az ethertype mezőkkel, amelyek eltérnek a 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP) értékektől; ezt azért tesszük, hogy kiszűrjük a BGP-peering során helyet nem foglaló forgalmat. Olyan mechanizmusok is alkalmazhatók, mint a GTSM, RPKI stb.
Valószínűleg a fenti tényezők a legfontosabbak bármely IXP esetében, függetlenül a mérettől. Természetesen a nagyobb IXPok esetében további technológiák és megoldások is alkalmazhatók.
Előfordulhat, hogy az IXP további szolgáltatásokat is kínál a résztvevőknek:
- TLD DNS-szervereket helyeznek el az IXP-n,
- hardveres NTP-szervereket telepítenek, lehetővé téve ezzel a résztvevők számára az idő pontos szinkronizálását,
- DDoS-támadások elleni védelmet biztosítanak stb.
A működés elve
Vizsgáljuk meg a forgalomcsere pontjának működését egy egyszerű IXP példáján, amelyet az EVE-NG eszközeivel modelleztünk, majd megvitatjuk a BIRD szoftveres útválasztó alapvető beállításait. A terv egyszerűsítése érdekében figyelmen kívül hagyjuk az olyan fontos tényezőket, mint a tartalék és a hibatűrés.
A hálózat topológiája az alábbi ábrán látható.
Tegyük fel, hogy egy kiscsoportos forgalomcserét adminisztrálunk, és az alábbi peering lehetőségeket kínáljuk:
- nyilvános peering,
- privát peering,
- peering route server-en 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 kívánnak a hálózatunkhoz.
50.50.50.254 – az IP-cím, amelyet a route server interfészére állítottunk be, ezzel az IP-vel a kliensek BGP-ülést állítanak fel, ha RS-en keresztül peeringelnek.
RS-on keresztüli peeringhez egyszerű BGP közösségek alapú irányítási politikát 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
Csak PEER_AS által hirdetett prefixek átadása
LOCAL_AS:IXP_AS
Prefixek átadása minden IXP résztvevőnek
Három ügyfél kíván csatlakozni az IXP-hez és forgalmat cserélni; tegyük fel, hogy ők internet szolgáltatók. Mindannyian a route server-en keresztüli peeringet szeretnének megszervezni. Az alábbiakban bemutatjuk az ügyfelek csatlakozási paramétereit:
Ügyfél
Az ügyfél AS száma
Az ügyfél által bejelentett prefixek
az IP cím, amelyet az ügyfél kapott 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 az ügyfél útválasztójá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 fontos megjegyezni a no bgp enforce-first-as beállítást. Alapértelmezetten a BGP megköveteli, hogy a fogadott BGP frissítés as-path-jében szerepeljen az a BGP peer AS száma, ahonnan a frissítés érkezett. Mivel azonban a route server nem módosítja az as-path-t, annak száma hiányozni fog az as-path-ból, és a frissítést el fogják utasítani. Ez a beállítás lehetővé teszi, hogy az útválasztó figyelmen kívül hagyja ezt a szabályt.
Azt is látjuk, hogy az ügyfél beállította a bgp community 555:555 értéket erre a prefikszre, ami a politikánk szerint azt jelenti, hogy az ügyfél szeretné bejelenteni ezt a prefikszet minden más résztvevő számára.
A többi ügyfél útválasztójának beállítása hasonló lesz, kivéve a saját egyedi paramétereiket.
BIRD konfigurációs példa:
define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];
template bgp RS_CLIENT {
local as ixp_as;
rs client;
}
Ezután egy szűrőt írunk le, amely nem fogadja el a martians prefikszeket, valamint az IXP prefikszeit is:
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ó valósítja meg a korábban leírt útválasztási politikát.
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;
}
Beállítjuk a peeringet, alkalmazzuk a megfelelő szűrőket és politikákat.
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;
}
}
Fontos megjegyezni, hogy a route server-en jó szokás, hogy a különböző peer-ektől érkező útvonalakat külön RIB-be gyűjtsük. A BIRD ezt lehetővé teszi. Példánkban a könnyebb érthetőség érdekében minden frissítést, amit az ügyfelektől kaptunk, egy közös RIB-be helyezünk.
Tehát nézzük meg, mit értünk el.
A route szerveren látjuk, hogy mindhárom klienssel BGP-session van létrehozva:
Látjuk, hogy minden kliensről prefixeket kapunk:
A 100-as as routeren látjuk, hogy egyetlen BGP-session jelenlétében a route szerverrel prefixeket kapunk mind a 200-as, mind a 300-as as-től, miközben a BGP-attribútumok változatlanok maradtak, mintha a kliensek között közvetlen peering valósulna meg:
Így láthatjuk, hogy a route szerver megléte jelentősen megkönnyíti a peering megszervezését az IXP-n.
Remélem, hogy ez a bemutató segített jobban megérteni, hogyan működnek a forgalomcsere pontok és hogyan valósul meg a route szerver működése az IXP-n.
Linxdatacenter IX
A Linxdatacenterben saját IXP-nket hoztuk létre egy megbízható infrastruktúrára építve, ami két switchből és két route szerverből áll. Jelenleg az IXP-t tesztelési üzemmódban futtatjuk, és várjuk mindazokat, akik szeretnének csatlakozni a Linxdatacenter IX-hez és részt venni a tesztelésben. Csatlakozás esetén egy 1 Gbit/s sávszélességű portot kap, lehetőséget a peeringre a route szervereinken keresztül, valamint hozzáférést az IX-portál felhasználói fiókjához, amely elérhető a címen: .
Írj a megjegyzésekbe vagy privát üzenetekbe a tesztelési hozzáférésért.
Következtetés
A forgalomcsere pontok az internet hajnalán alakultak ki, mint eszköz az optimális forgalomirányítással kapcsolatos problémák megoldására a szolgáltatók között. Jelenleg az új globális szolgáltatások megjelenésével és a CDN forgalom növekedésével a forgalomcsere pontok 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 világszerte előnyös mind a szolgáltatások végfelhasználói, mind a szolgáltatók, tartalom szolgáltatók stb. számára. Az IXP tagjainak előnye abban rejlik, hogy csökkennek a külső peering megszervezésével kapcsolatos költségek, csökken a fizetendő forgalom mennyisége a felsőbb szolgáltatóknak, optimalizálható az útvonalirányítás, és lehetőség nyílik közvetlen kapcsolat kialakítására a tartalom szolgáltatókkal.
Hasznos linkek
- Tekintsd meg a forgalomcserék helyének térképét:
- Tekintsd meg a BGP peering részletes statisztikáját, beleértve az IXP-n való jelenlétet is:
Forrás: habr.com
