Liiklusvahetuspunkt: algusest kuni oma IX loomisega

„Me lõime telefoniga ühenduse meie ja SRI meestega…“, ütles Kleinrock intervjuus.
„Me sisestasime L ja küsisime telefonis: „Kas näete L-i?“
„Jah, me näeme L-i,“ tuli vastus.
„Me sisestasime O ja küsisime: „Kas näete O-d?“
„Jah, me näeme O-d.“
„Siis sisestasime G ja süsteem langes välja“…

Kuid revolutsioon oli alanud…

Interneti algus.

Tere kõigile!

Minu nimi on Aleksander, olen võrguinsener ettevõttes Linxdatacenter. Täna räägime liiklusvahetuspunktidest (Internet Exchange Point, IXP): sellest, mis eelnes nende tekkele, milliseid ülesandeid nad lahendavad ja kuidas nad on üles ehitatud. Samuti demonstreerin selles artiklis IXP tööpõhimõtet EVE-NG platvormi ja tarkvararuuter BIRD abil, et mõista, kuidas see töötab „kapoti all“.

Veidi ajalugu

Kui vaadata siia, on märgata, et liiklusvahetuspunktide arvu kiire kasv algas 1993. aastal. See on seotud sellega, et enamik tol ajal tegutsevatest sideoperaatoritest edastas oma liiklust Ameerika Ühendriikide backbone-võrgu kaudu. Näiteks, kui liiklus liikus operaatorilt Prantsusmaal operaatorile Saksamaal, siis jõudis see esmakordselt Prantsusmaalt Ameerikasse ja alles seejärel Ameerikast Saksamaale. Backbone-võrk toimis sel juhul transiidina Prantsusmaa ja Saksamaa vahel. Isegi liiklus ühe riigi sees ei kulgenud sageli otse, vaid Ameerika operaatorite tugivõrkude kaudu.

See olukord mõjutas mitte ainult transiittrafiku kohaletoimetamise maksumust, vaid ka kanalite kvaliteeti ja viivitust. Interneti kasutajate arv kasvas, ilmusid uued operaatorid, liiklusmaht suurenes, internet kasvas. Operaatorid kogu maailmas hakkasid mõistma, et on vaja ratsionaalsemat lähenemist operaatoritevahelise suhtluse korraldamiseks. "Miks peaks operaator A maksma transiidi eest läbi teise riigi, et edastada liiklust operaatorile B, kes asub naaber tänaval?". Umbes sellise küsimuse esitasid endale telekommunikatsiooni operaatorid tol ajal. Nii hakkasid eri maailma paikades operaatorite kogunemiskohtadesse tekkima liiklusvahetuspunktid:

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

Internet ja meie päevad

Kontseptuaalselt esindab kaasaegse Interneti arhitektuur mitmeid autonoomseid süsteeme (autonomous system, AS) ja mitmeid nende vahelisi füüsilisi ja loogilisi sidemeid, mis määravad liikluse tee ühe AS-ist teise.

AS-idena esindavad tavaliselt sideoperaatorid, internetiteenuse pakkujad, CDN-id, andmekeskused ja ettevõtte segment. AS-id loovad omavahel loogilisi seoseid (peering) peamiselt BGP protokolli abil.

Eraisikute süsteemide viis, kuidas need seosed korraldatakse, määratakse mitmete tegurite poolt:

• geograafilised,
• majanduslikud,
• poliitilised,
• kokkulepped ja ühised huvid AS-ide omanike vahel,
• Kui kaua aega kulub väljastamiseks?

Muidugi on sellel skeemil teatud struktuur ja hierarhia. Näiteks jagunevad operaatorid tier-1, tier-2 ja tier-3 vahel, kusjuures tier-3 internetiteenuse pakkujate (kohalikud operaatorid) klientideks on tavaliselt tavalised kasutajad, samas kui tier-1 operaatorite klientideks on teised operaatorid. Tier-3 operaatorid koondavad enda alla oma abonentide liiklust, tier-2 sideoperaatorid koondavad omakorda tier-3 operaatorite liiklust, ja tier-1 koondab kogu internetiliiklust.

Skeemiliselt võib seda esitada nii:

Antud pildil on näha, et liiklus koondatakse alt üles, st lõppkasutajatelt tier-1 operaatoriteni. Samuti toimub horisontaalne liikluse vahetus ligikaudu võrdsete AS-ide vahel.

Selle skeemi lahutamatuks osaks ja samas puuduseks on mingisugune segadus ühendustes autonoomsete süsteemide vahel, mis asuvad lähemal lõppkasutajale teatud geograafilises piirkonnas. Vaadake allolevat pilti:

Oletame, et suures linnas on 5 teenusepakkujat, kelle vaheline peer'ing on mingil põhjusel korraldatud nagu ülal näidatud.

Kui kasutaja Petja, kes on ühendatud internetiteenuse pakkujaga Go, soovib pääseda ligi serverile, mis on ühendatud pakkujaga ASM, siis peab nende vahel liikuv liiklus läbima 5 autonoomset süsteemi. Seetõttu suureneb viivitus, kuna suureneb võrgu seadmete arv, mille kaudu liiklus läheb, samuti liikluse maht autonoomsete süsteemide vahel Go ja ASM.

Kuidas vähendada tranzit AS-ide arvu, mis peab liiklust läbima? Õige vastus on - liikluse vahetuspunkt.

Tänapäeval on uute IXP-de ilmumine tingitud samadest vajadustest, mis olid 90ndate ja 2000. aastate alguses, kuid väiksemas mastaabis, vastates üha suurenevale sideteenuste pakkujate, kasutajate ja liikluse hulgale, samuti kasvavale sisu hulgale, mida genereerivad CDN-võrgud ja andmekeskused.

Mis on liikluse vahetuspunkt?

Liikluse vahetuspunkt on koht, kus on spetsiaalne võrginfrastruktuur, kus huvitatud osalised korraldavad omavahelise peerimise. Peamised liikluse vahetuspunktide osalised on sideteenuste pakkujad, interneti-teenuse pakkujad, sisuteenuste pakkujad ja andmekeskused. Liikluse vahetuspunktides ühenduvad osalised omavahel otse. See võimaldab lahendada järgmisi ülesandeid:

• minimeerida viivitusi,
• vähendada transiidiliiklust,
• optimeerida marsruutimist AS-ide vahel.

Arvestades, et IXP-d on paljudes suuremates linnades üle maailma, avaldab see positiivset mõju ka kogu internetivõrgule.

Kui ülaltoodud olukorda Peeteriga lahendada IXP abil, toimub see umbes nii:

Kuidas on liikluse vahetuspunkt üles ehitatud?

Üldiselt on IXP eraldi AS oma avalike IPv4/IPv6 aadresside plokiga.

IXP võrk on enamasti pidev L2 domeen. Mõnikord on see lihtsalt VLAN, kuhu on paigutatud kõik IXP kliendid. Suuremate, geograafiliselt hajutatud IXP-de puhul võivad L2 domeeni korraldamiseks kasutada selliseid tehnoloogiaid nagu MPLS, VXLAN jne.

IXP elemendid

• SKS. Siin ei ole midagi ebatavalist: riiulid, optilised ristpunktid, patch-paneelid.
• Lülitid – IXP aluseks. Lüliti port on sisenemispunkt IXP võrku. Samuti täidavad lülitid osa turvafunktsioonidest – filtreerivad prügiliiklust, mis ei peaks IXP võrgus olema. Üldiselt valitakse lülitid vastavalt funktsionaalsuse nõuetele – usaldusväärsus, toetatud portide kiirus, turvafunktsioonid, sFlow tugi jne.
• Route server (RS) – on oluline ja hädavajalik osa igast kaasaegsest andmevahetuspunktist. Tööprincipid sarnanevad väga iBGP-s route reflector'i või OSPF-is designated router'iga ning lahendavad samu probleeme. Andmevahetuspunkti osalejate arvu kasvades suureneb ka iga osaleja jaoks vajalik BGP sessioonide arv, mis meenutab klassikalist full-mesh topoloogiat iBGP-s. RS lahendab probleemi järgmiselt: loob BGP-sessiooni iga huvilise osalejaga IXP-s, mistõttu muutub see RS-i kliendiks. Saades BGP värskenduse ühelt oma kliendilt, saadab RS selle värskenduse kõigile oma teistele klientidele, loomulikult välja arvatud sellele, kellelt antud värskendus saadud oli. Seega vabastab RS vajadusest luua full-mesh kõigi IXP osalejate vahel ning lahendab elegantset probleemid skaleerimisest. Oluline on märkida, et marsruutimise server edastab marsruute ühiselt ühelt AS-ilt teisele, mitte muutes edastatavaid BGP atribuute, näiteks ei lisa ta oma AS-numbrite AS-path'i. Samuti toimub RS-is põhifiltreerimine: näiteks RS ei võta vastu martian'ite võrgustikke ja IXP enda prefikseid.

  Route serveri lahendusena kasutatakse sageli avatud lähtekoodiga tarkvara, nagu BIRD (bird internet routing daemon). See on hea, kuna see on tasuta, kiirelt seadistatav enamikus Linuxi distributsioonides, omab paindlikku marsruudipoliitikate/filtreerimise seadistamise mehhanismi ja ei nõua palju arvutusressursse. Samuti võib RS-ks valida riistvara/virtuaalse ruuteri, näiteks Cisco, Juniper jne.

• Turvalisus. Kuna IXP võrk on suures osas AS-i koondamine, peab ka kõigi osaliste järgitud turvapoliitika olema hästi sõnastatud. Reeglina rakendatakse samu mehhanisme, mis kehtivad BGP-naabruse loomisel kahe eraldi BGP-pira vahel väljaspool IXP-d, ning kasutatakse ka mõningaid täiendavaid kaitsevahendeid.

  Näiteks on hea praktikana soovită ning edastada liiklust ainult teatud IXP osalejate mac-aadressidelt, mis on eelnevalt kokku lepitud. Liiklus, mille ethertype väljad erinevad 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP), tuleb keelata; see tehakse selleks, et filtreerida välja liiklus, mis ei mahtu BGP-pirniga. Samuti võivad rakenduda sellised mehhanismid nagu GTSM, RPKI jne.

Võib öelda, et eeltoodud on igasuguste IXP-de põhikomponendid olenemata nende suurusest. Loomulikult võivad suurte IXP-de korral rakenduda mõningad lisatehnoloogiad ja lahendused.
Juhtub, et IXP pakub oma osalejatele ka täiendavaid teenuseid:

• paigutavad IXP-le TLD DNS-servereid,
• paigaldavad riistvaralised NTP-serverid, andes osalejatele võimaluse aega täpselt sünkroniseerida,
• pakuvad DDoS-rünnakute kaitset jne.

Tööprintsiip

Käime läbi liiklusvahetuspunkti tööprintsiibi lihtsaima IXP näite kaudu, simuleerituna EVE-NG abil, ning seejärel vaatame üle BIRD tarkvararuuteri aluskonfiguratsiooni. Skeemi lihtsustamiseks jätame välja sellised olulised asjad nagu reservimine ja talitlushäired.

Võrgu topoloogia on esitatud alloleval joonisel.

Oletame, et haldame väikest liikluse vahetuspunkti ja pakume järgmisi piirimisvõimalusi:

• avalik piirimine,
• privaatne piirimine,
• piirimine route server'i kaudu.

Meie AS-i number on 555, omame IPv4 aadressiblokki – 50.50.50.0/24, millest jagame IP-aadresse neile, kes soovivad meie võrguga ühineda.

50.50.50.254 on IP-aadress, mis on seadistatud route server'i liidesele; selle IP-ga loovad kliendid BGP sessiooni, kui piirimine toimub RS kaudu.

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

BGP community
Kirjeldus

LOCAL_AS:PEER_AS
Eda edastamine ainult PEER_AS-ile

LOCAL_AS:IXP_AS
Eda edastamine kõikidele IXP osalejatele

Meie IXP soovib ühineda ja liiklust vahetada 3 klient; oletame, et need on internetiteenuse pakkujad. Kõik nad soovivad korraldada piirimist route server'i kaudu. Allpool on toodud skeem koos klientide ühendamise parameetritega:

Klient
Kliendi AS number
Klientide poolt kuulutatud eelistused
IP aadress, mis on antud kliendile IXP-ga ühendamiseks

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

Kliendi ruuteri põhiseade BGP jaoks:

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 tasub märkida seadet no bgp enforce-first-as. Vaikimisi nõuab BGP, et vastuvõetud BGP uuenduste as-path'is oleks BGP peer'i number, kellelt uuendus saadud. Kuna route server ei muudab as-path'i, jääb selle number as-path'ist puudu ja uuendus lükatakse tagasi. See seade rakendatakse, et ruuter hakkaks seda reeglit tõlgendama.

Samuti näeme, et klient on seadnud bgp community 555:555 antud prefiksile, mis meie poliitika kohaselt tähendab, et klient soovib teada anda seda prefiksi kõigile teistele osalejatele.

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

BIRD konfiguratsiooninäide:

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

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

Allpool kirjeldatakse filtrit, mis ei aktsepteeri martians eeliseid ning ka IXP eeliseid:

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 marsruutimise poliitikat, 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 püringu, rakendame vastavaid filtreid ja poliitikaid.

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

Tuleb märkida, et route server’is on hea tava grupeerida marsruudid erinevatest peer'idest erinevatesse RIB-idesse. BIRD võimaldab seda teha. Meie näites, lihtsuse huvides, kogutakse kõik uuendused, mis saadakse kõigilt klientidelt, ühte üldisesse RIB-i.

Nii et kontrollime, mida oleme saavutanud.

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

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

Marsruuteris as 100 näeme, et ainult ühe BGP-seansiga route serveriga saame eelseadeid nii as 200-lt kui ka as 300-lt, samas kui BGP-atribuutide struktuur ei ole muutunud, justkui peerimine klientide vahel toimuks otse:

Nii näeme, et route serveri olemasolu lihtsustab oluliselt peerimise korraldamist IXP-l.

Loodan, et see demonstraatsioon aitas teil paremini mõista, kuidas liikluse vahetamispunktid töötavad ja kuidas route server IXP-l toimib.

Linxdatacenter IX

Linxdatacenteris oleme loonud oma IXP, mis põhineb kahekordselt varustatud infrastruktuuril, kus on kaks lülitit ja kaks marsruuteriserverit. Meie IXP on hetkel testimisseisundis ja kutsume kõiki soovijaid liituma Linxdatacenter IX-iga ning osalema testimises. Ühendamise korral antakse teile 1 Gbit/s läbilaskevõimega port, võimalus teha ühendusi meie marsruuteriserverite kaudu, samuti juurdepääs IX-portaali isiklikule kabinetile, mis on saadaval aadressil ix.linxdatacenter.com.

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

Kokkuvõte

Liiklusvahetuspunktid tekkisid interneti algusaegadel, et lahendada telekommunikatsioonioperaatorite vahelise liikluse mitteoptimaalset edastamist. Praegu, uute globaalsete teenuste ja CDN-i liikluse kasvu tõttu, jätkavad liiklusvahetuspunktid globaalse võrgu töö optimeerimist. IXP-de arvu kasv maailmas toob kasu nii teenuse lõppkasutajale kui ka telekommunikatsioonioperaatoritele ja sisuteenuse pakkujatele jne. IXP osalejate jaoks väljendub kasu väliste peer'ingute korraldamise kulude vähenemises, makstava liikluse arvu vähenemises kõrgematele operaatoritele, marsruutimise optimeerimises ja võimaluses olla otseühenduses sisuteenuse pakkujatega.

Kasulikud lingid

• Vaata liiklusvahetuspunktide asukoha kaarti: www.internetexchangemap.com
• Vaata üksikasjalikku statistikat BGP peer'ingust, sealhulgas kohalolekust IXP-l: www.peeringdb.com

Allikas: habr.com