Liikluse vahetuspunkt: allikatest oma IX loomiseni

„Me seadsime telefonikontakti meie ja SRI poiste vahel…“ ütles Kleinrock ühes intervjuus:
„Me sisestasime L-i ja küsisime telefoni teel: „Kas näete L-i?““
„Jah, me näeme L-i,“ tuli vastus.
„Sisestasime O ja küsisime: „Kas näete O-d?““
„Jah, me näeme O-d.“
„Siis sisestasime G ja süsteem krahh...“

Kuid revolutsioon oli alanud…

Interneti algus.

Tere kõigile!

Minu nimi on Aleksander, olen võrginsener ettevõttes Linxdatacenter. Täna räägime liikluse vahetuspunktidest (Internet Exchange Point, IXP): sellest, mis eelnes nende tekkimisele, milliseid ülesandeid nad täidavad ja kuidas need on üles ehitatud. Samuti demonstreerin selles artiklis IXP tööpõhimõtet EVE-NG platvormi ja BIRD tarkvararuuteri kaudu, et oleks arusaam, kuidas see „kapoti all“ töötab.

Enne kui liigume edasi

Kui vaadata siia, siis võib märgata, et liikluse vahetuspunktide kiire kasv algas 1993. aastal. See oli tingitud sellest, et enamus sel ajal olemas olnud sideteenuste liiklusest läbis USA selgroo. Näiteks, kui liiklus suundus Prantsusmaalt Saksamaale, jõudis see esmalt USA-sse ja alles sealt Saksamaale. Selgroo võrk toimis sellisel juhul transiidina Prantsusmaa ja Saksamaa vahel. Isegi riigi sees liikuv liiklus ei läinud sageli otse, vaid Ameerika operaatorite toetavate võrkude kaudu.

Selline olukord mõjutas mitte ainult transiitliikluse kulu, vaid ka kanalite kvaliteeti ja viivitust. Interneti kasutajate arv suurenes, ilmus uusi operaatorite, liiklusmaht kasvas, internet arenes. Operaatorid üle kogu maailma hakkasid mõistma, et on vajalik ratsionaalsem lähenemine operatsioonidevahelise koostöö korraldamisele. „Küsimus, miks peaks operaator A maksma transiidi eest teise riigi kaudu, et saata liiklust operaatorile B, kes asub naabruses?“ Sellise küsimuse esitasid endale sideteenuste operaatorid sel ajal. Nii hakkasid erinevates maailma nurkades operaatorite kontsentratsioonikohtadesse ilmuma liikluse vahetuspunktid:

• 1994 – LINX Londonis,
• 1995 – DE-CIX Frankfurtis,
• 1995 – MSK-IX, Moskvas jne.

Internet ja meie päevad

Kontseptuaalselt esindab tänapäeva interneti arhitektuur paljusid iseseisvaid süsteeme (autonomous system, AS) ja mitmeid sidemeid nende vahel, nii füüsilisi kui ka loogilisi, mis määravad liikluse teed ühelt AS-ilt teisele.

AS-i rolli täidavad tavaliselt sideoperaatorid, interneti pakkujad, CDN-id, andmekeskused ja ettevõtted ettevõtete segmentis. AS-id korraldavad omavahelisi loogilisi sidemeid (peering) peamiselt BGP protokolli abil.

Autonoomsete süsteemide sidemete korralduse määrab mitu tegurit:

• geograafilised,
• majanduslikud,
• poliitilised,
• lepingud ja ühised huvid AS-i omanike vahel,
• jne.

Muidugi on selles skeemis teatud struktuur ja hierarhia. Nii jaotatakse operaatorid tier-1, tier-2 ja tier-3, ning kui kohaliku interneti pakkuja (tier-3) kliendid on tavaliselt tavalised kasutajad, siis näiteks tier-1 operaatorite kliendid on teised operaatorid. Tier-3 operaatorid koguvad oma klientide liiklust, tier-2 sideoperaatorid koguvad omakorda tier-3 operaatorite liiklust, ning tier-1 kogub kogu interneti liikluse.

Schemaatiliselt võib seda kujutada järgmiselt:

Sellel pildil on näha, et liiklus kogutakse alt üles, st lõppkasutajatelt tier-1 operaatoriteni. Samuti toimub horisontaalne liikluse vahetamine omavahel peaaegu võrdsete AS-ide vahel.

Selle skeemi lahutamatuks osaks ja samas puuduseks on teatud kaootilisus sidemete vahel iseseisvate süsteemide, mis asuvad lõppkasutajale lähemal, geograafilises piirkonnas. Vaatame allolevat pilti:

Võtame aluseks, et suures linnas on 5 sideoperaatorit, kelle vahel on fikseeritud peering, erinevatel põhjustel, nagu allpool näidatud.

Kui kasutaja Petja, kes on ühendatud interneti pakkujaga Go, soovib pääseda juurde serverile, mis on ühendatud pakkujaga ASM, peab nende vahelise liiklus läbima 5 iseseisvat süsteemi. Seeläbi suureneb viivitus, kuna suureneb võrgu seadmete arv, mille kaudu liiklus läbib, samuti suureneb tranzitliikluse maht iseseisvate süsteemide vahel Go ja ASM vahel.

Kuidas vähendada tranzitsete AS-ide arvu, mille läbi liiklus peab läbi minema? Õige vastus on liikluse vahetuspunkt.

Tänapäeval on uute IXP-de tekkimise põhjuseks samad vajadused nagu 90ndate alguses ja 2000ndatel, kuid nüüd väiksemas mahus, vastuseks kasvavale sideoperaatorite, kasutajate ja liikluse arvule, samuti järjest suurenevale sisu hulgale, mida genereerivad CDN-võrgud ja andmekeskused.

Mis on liikluse vahetuspunkte?

Liikluse vahetuspunkt on koht, kus on spetsiaalne võrguinfrastruktuur, kus huvi liikluse vastastikuse vahetuse vastu olevad osalised organiseerivad vastastikku peeringu. Peamised osalised liikluse vahetuspunktides on sideoperaatorid, internetiteenuse pakkujad, sisu pakkujad ja andmekeskused. Liikluse vahetuspunktides ühendavad osalised end omavahel otse. See võimaldab lahendada järgmised ülesanded:

• vähendada viivitust,
• kujundada ümber transitliiklust,
• optimeerida marsruute AS-ide vahel.

Kuna IXP-d on paljude suurte linnade maailmas, on see kõik positiivselt mõjutanud ka interneti võrku tervikuna.

Kui ülaltoodud olukorda Pete osas lahendada IXP kaudu, siis see võib välja näha umbes nii:

Kuidas liikluse vahetuspunkt töötab?

Tavaliselt on IXP eraldi AS koos oma avalike IPv4/IPv6 aadresside plokiga.

IXP võrk koosneb enamasti ühtsest L2 domeenist. Mõnikord on see lihtsalt VLAN, kuhu on koondatud kõik IXP kliendid. Suuremate, geograafia poolest jaotatud IXP-de puhul võib L2 domeeni organiseerimiseks kasutada tehnoloogiaid nagu MPLS, VXLAN jne.

IXP elemendid

• SKS. Siin pole midagi ebatavalist: riiulid, optilised ristlõiked, patch-paneelid.
• Lülitid – IXP alus. Lülitite port on sisenemispunkt IXP võrku. Samuti täidavad lülitid osaliselt turvafunktsioone – filtreerivad prügi liiklust, mida ei tohiks IXP võrgus olla. Tavaliselt valitakse lülitid vastavalt funktsionaalsetele nõudmistele – töökindlus, toetatud portide kiirus, turvafunktsioonid, sFlow toetamine jne.
• Marsruudi server (RS) – lahutamatu ja vajalik osa igast kaasaegsest liikluse vahetuspunktist. Töö põhimõttelt sarnaneb see väga iBGP route reflectorile või OSPF designated routerile ning lahendab samad probleemid. Liikmete arvu suurenedes liikluse vahetuspunktis suureneb ka BGP sessioonide arv, mida tuleb igaühel hoida, st see meenutab klassikalist full-mesh topoloogiat iBGP-s. RS lahendab probleemi järgmiselt: see loob BGP sessiooni iga huvitatud IXP osalejaga, kes muutub RS kliendiks. Saades BGP uuenduse ühelt oma kliendilt, edastab RS selle uuenduse kõigile oma teistele klientidele, välja arvatud sellele, kellelt uuendus saadi. Nii vabastab RS vajadusest luua full-mesh kõigi IXP osalejate vahel ja lahendab elegantselt skaleerimise probleemi. Tuleb märkida, et marsruutide server edastab marsruudid ühelt AS-ilt teisele läbinägematult, muudatusi tegemata edastatavatest BGP attribuutidest, näiteks ei lisa oma AS numbrit AS-pathi. Samuti toimub RS-s põhifiltratsioon, näiteks RS ei aktsepteeri martians võrgustikke ja IXP enda prefikseid.

  Route serverina kasutatakse sageli avatud lähtekoodiga tarkvara marsruutimistarkvara – BIRD (bird internet routing daemon). Selle eelised on, et see on tasuta, kiiruselt lihtne seadistada enamikul Linuxi distributsioonidel, tal on paindlik marsruudi/poliitikate seadistamise mehhanism ja see ei nõua palju arvutusressursse. RS-ks võib valida ka Cisco, Juniperi jms riistvaralise/virtuaalse marsruuteri.

• Turvalisus. Kuna IXP võrk keskendub suure hulga AS-ide koondamisele, peab kõigil osalejatel olema hästi väljendatud turvapoliitika. Reeglina kehtivad kõik samad mehhanismid, mida kasutatakse BGP naabruse loomisel kahe eraldi BGP-pira vahel väljaspool IXP, ka siin, ning on rakendatud ka mitmeid täiendavaid kaitsevahendeid.

  Näiteks on hea praktika suunata liiklust ainult teatud osaleja IXP MAC-aadressilt, mis on eelnevalt kokku lepitud. Liiklus, mille ethertype väljad erinevad 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP), on keelatud; see tehakse selleks, et filtreerida liiklust, millel BGP peerimiseks kohta ei ole. Samuti võivad olla kasutusel sellised mehhanismid nagu GTSM, RPKI jne.

Ilmselt on eespool loetletud peamised koostisosad igas IXP-s, olenemata suurusest. Loomulikult võivad suurtel IXP-del olla täiendavad tehnoloogiad ja lahendused.
On juhtunud, et IXP pakub oma osalejatele ka täiendavaid teenuseid:

• paigutatakse IXP-sse TLD DNS-serverid,
• paigaldatakse riistvara NTP-serverid, mis võimaldavad osalejatel täpselt aega sünkroonida,
• pakuvad DDoS-rünnakute kaitset jne.

Töö принцип

Vaatame, kuidas liikluse vahetamise punkt töötab, kasutades lihtsustatud IXP näidet, simuleeritud EVE-NG abil, seejärel vaatame põhiseadet BIRD tarkvara marsruuteril. Skeemi lihtsustamiseks jätame välja sellised olulised asjad nagu varundamine ja rikete taluvus.

Võrgu topoloogia on kujutatud alloleval joonisel.

Oletame, et haldame väikest liikluse vahetamise punkti ja pakume järgmisi pirimise variante:

• avalik pirimine,
• privaatne pirimine,
• pirimine läbi marsruudiserveri.

Meie AS number on 555, meil on IPv4 aadresside plokk – 50.50.50.0/24, millest jagame IP-aadresse neile, kes soovivad meie võrguga liituda.

50.50.50.254 on IP-aadress, mis on seadistatud marsruudiserveri liidesesse; selle IP-ga loovad kliendid BGP seansi, kui nad pirivad läbi RS.

Samuti oleme RS kaudu pirimise jaoks välja töötanud lihtsa marsruutimise poliitika, mis põhineb BGP community-l, mis võimaldab IXP liikmetel reguleerida, kellele ja milliseid marsruute edastada:

BGP community
Kirjeldus

LOCAL_AS:PEER_AS
Edastada eelistused ainult PEER_AS-ile

LOCAL_AS:IXP_AS
Edastada eelistused kõigile IXP liikmetele

Meie IXP-sse soovivad ühenduda ja liiklust vahetada 3 klienti; oletame, et need on internetiteenuse pakkujad. Kõik nad soovivad korraldada pirimist läbi marsruudiserveri. Allpool on kliendi ühendamise parameetrite skeem:

Kliendi
Kliendi AS number
Kliendi poolt kuulutatud eelistused
IP aadress, mis on kliendile antud ühenduse loomiseks IXP-ga

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

Baasseade BGP kliendi marsruuteris:

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

Siin on oluline märkida, et on seadistus no bgp enforce-first-as. Vaikimisi nõuab BGP, et vastuvõetud BGP uuenduste as-path sisaldaks BGP sõbra AS-i numbrit, kellelt uuendus saadud. Kuid kuna marsruutimisserver ei muuda as-path’i, siis ei sisaldu selle numbrit as-path’is ja uuendus lükatakse tagasi. See seadistus rakendatakse, et marsruuter ignoreeriks seda reeglit.

Samuti näeme, et klient on määranud BGP community 555:555 antud eelistusele, mis meie poliitika kohaselt tähendab, et klient soovib seda eelistust kuulutada kõigile teistele osalistele.

Muude klientide marsruutijate seadistus on sarnane, välja arvatud nende unikaalsed parameetrid.

BIRD konfiguratsiooni näidis:

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

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

Edasi on kirjeldatud filtrit, mis ei võta vastu martians eelistusi, samuti IXP enda eelistusi:

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

See funktsioon rakendab marsruutimispoliitikat, millest oleme varem rääkinud.

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;


}

Seame pilti, rakendame vastavad filtrid ja poliitikad.

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

Oluline on märkida, et marsruudiserveri puhul on heaks tooniks hoida erinevatelt sõpradelt saadud marsruute erinevates RIB-ides. BIRD võimaldab seda teha. Meie näites, lihtsuse huvides, kogutakse kõik kõikidest klientidest saadud uuendused üheks ühiseks RIB-iks.

Nii et kontrollime, mida oleme saavutanud.

Route serveril näeme, et kõigi kolme kliendiga on loodud BGP-seanss:

Näeme, et saame prefikseid kõigilt klientidelt:

Maršrutiseris as 100 näeme, et ühe BGP-seansi olemasolul marsruudiserveriga saame prefikseid nii as 200 kui ka as 300, samas BGP-atribuut ei ole muutunud, nagu oleks peerimine klientide vahel toimunud otse:

Seega näeme, et marsruudiserveri olemasolu lihtsustab oluliselt peerimise organiseerimist IXP-l.

Loodan, et see demonstratsioon aitas teil paremini mõista, kuidas toimivad liiklusvahetuspunktid ja kuidas marsruudiserver IXP-l töötab.

Linxdatacenter IX

Linxdatacenteris oleme loonud oma IXP, mis põhineb kaksikvõrgu ja kahe marsruudiserveri tõrketaluvusel infrastruktuuril. Praegu on meie IXP katsetamisrežiimis ja kutume kõiki huvitatud osalema Linxdatacenter IX-s ja osalema testimisel. Ühenduse loomisel antakse teile port, mille läbilaskevõime on 1 Gbit/s, võimalus peerida meie marsruudiserveritega ning juurdepääs IX-portaali isiklikule kabinetile, mis on saadaval aadressil ix.linxdatacenter.com.

Kirjutage kommentaaridesse või isiklikele sõnumitele, et saada ligipääs testimisele.

Kokkuvõte

Liiklusvahetuspunktid tekkisid interneti algusaegadel, et lahendada probleeme, mis olid seotud ebaoptimaalse liikluse läbimisega sideoperaatorite vahel. Tänapäeval, uute globaalsete teenuste ja CDN-liikluse suurenenud hulga ilmumisega, jätkavad liiklusvahetuspunktid globaalse võrgu töö optimeerimist. IXP-de arvu suurenemine maailmas toob kasu nii teenuse lõppkasutajale kui ka sideoperaatoritele ja sisuoperaatoritele jne. IXP osalejate eeliseid väljendatakse kulude vähenemises väliste peerimiste korraldamisel, alandatud liikluse hulgas, mille eest tuleb maksta kõrgematele operaatoritele, marsruutimise optimeerimisel ja võimaluses otseühenduse loomisel sisuoperaatoritega.

Kasulikud lingid

• Vaata liiklusvahetuspunktide asukoha kaarti: www.internetexchangemap.com
• Vaata üksikasjalikku statistikat BGP peerimise kohta, sealhulgas IXP-l osalemise kohta: www.peeringdb.com

Allikas: habr.com