"Loimme puhelinyhteyden meidän ja SRI:n kavereiden välille...", Kleinrock... sanoi haastattelussa:
"Kirjoitimme L:n ja kysyimme puhelimessa: "Näetkö L?"
"Kyllä, näemme L", kuului vastaus.
"Kirjoitimme O:n ja kysyimme: "Näetkö O."
"Kyllä, me näemme O."
"Sitten kirjoitimme G, ja järjestelmä kaatui"...Vallankumous oli kuitenkin alkanut…
Internetin alku.
Hei kaikille!
Nimeni on Alexander, olen verkkoinsinööri Linxdatacenterissä. Tämän päivän artikkelissa puhumme liikenteen vaihtopisteistä (Internet Exchange Points, IXP): mikä edelsi niiden ilmestymistä, mitä tehtäviä ne ratkaisevat ja miten ne rakennetaan. Myös tässä artikkelissa esitän IXP:n toimintaperiaatteen käyttämällä EVE-NG-alustaa ja BIRD-ohjelmistoreititintä, jotta sinulla on käsitys siitä, kuinka se toimii "konepellin alla".
Vähän historiaa
Jos katsot , niin näet, että liikenteen vaihtopisteiden määrän nopea kasvu alkoi vuonna 1993. Tämä johtuu siitä, että suurin osa tuolloin olemassa olevien teleyritysten liikenteestä kulki Yhdysvaltain runkoverkon kautta. Joten esimerkiksi kun liikenne meni ranskalaiselta operaattorilta saksalaiselle operaattorille, se meni ensin Ranskasta Yhdysvaltoihin ja vasta sitten USA:sta Saksaan. Runkoverkko toimi tässä tapauksessa kauttakulkuna Ranskan ja Saksan välillä. Jopa yhden maan sisäinen liikenne ei usein kulkenut suoraan, vaan amerikkalaisten operaattoreiden runkoverkkojen kautta.
Tämä tilanne ei vaikuttanut vain siirtoliikenteen toimituskustannuksiin, vaan myös kanavien laatuun ja viivästyksiin. Internetin käyttäjien määrä kasvoi, uusia operaattoreita ilmestyi, liikenteen määrä kasvoi ja Internet kypsyi. Operaattorit ympäri maailmaa alkoivat ymmärtää, että operaattorien välisen vuorovaikutuksen järjestämiseen tarvitaan järkevämpi lähestymistapa. "Miksi minun, operaattorin A, pitäisi maksaa kauttakulusta toisen maan kautta, jotta liikenne toimitetaan operaattorille B, joka sijaitsee seuraavalla kadulla?" Karkeasti tämän kysymyksen teleoperaattorit kysyivät itseltään tuolloin. Siten liikenteen vaihtopisteitä alkoi ilmestyä eri puolille maailmaa operaattorien keskittymispisteisiin:
- 1994 – LINX Lontoossa,
- 1995 – DE-CIX Frankfurtissa,
- 1995 – MSK-IX, Moskovassa jne.
Internet ja päivämme
Käsitteellisesti nykyaikaisen Internetin arkkitehtuuri koostuu monista autonomisista järjestelmistä (AS) ja monista niiden välisistä yhteyksistä, sekä fyysisistä että loogisista, jotka määrittävät liikenteen polun AS:sta toiseen.
AS:t ovat yleensä teleoperaattoreita, Internet-palveluntarjoajia, CDN-verkkoja, datakeskuksia ja yrityssegmentin yrityksiä. AS:t järjestävät loogisia yhteyksiä (peering) keskenään, yleensä käyttämällä BGP-protokollaa.
Se, kuinka autonomiset järjestelmät järjestävät nämä yhteydet, määräytyvät useiden tekijöiden perusteella:
- maantieteellinen,
- taloudellinen,
- poliittinen,
- AS:n omistajien väliset sopimukset ja yhteiset edut,
- jne.
Tietenkin tällä järjestelmällä on tietty rakenne ja hierarkia. Siten operaattorit jaetaan tasoon 1, tasoon 2 ja tasoon 3, ja jos paikallisen Internet-palveluntarjoajan (taso 3) asiakkaat ovat pääsääntöisesti tavallisia käyttäjiä, niin esimerkiksi tasolle 1 tason operaattorit asiakkaat ovat muita operaattoreita. Tier-3-operaattorit yhdistävät tilaajiensa liikenteen, tier-2-teleoperaattorit puolestaan yhdistävät tason 3-operaattoreiden liikenteen ja tier-1 – kaiken Internet-liikenteen.
Kaavamaisesti se voidaan esittää näin:
Tästä kuvasta näkyy, että liikenne on koottu alhaalta ylöspäin, ts. loppukäyttäjistä tason 1 operaattoreihin. Liikenteen horisontaalista vaihtoa tapahtuu myös suunnilleen toisiaan vastaavien AS:ien välillä.
Tämän järjestelmän olennainen osa ja samalla haittapuoli on tietty sekavuus autonomisten järjestelmien välillä, jotka sijaitsevat lähempänä loppukäyttäjää, maantieteellisellä alueella. Harkitse alla olevaa kuvaa:
Oletetaan, että suuressa kaupungissa on 5 teleoperaattoria, joiden välillä peering syystä tai toisesta on järjestetty yllä esitetyllä tavalla.
Jos Go ISP:hen yhdistetty käyttäjä Petya haluaa päästä ASM-palveluntarjoajaan yhdistettyyn palvelimeen, heidän välinen liikenne pakotetaan kulkemaan 5 autonomisen järjestelmän kautta. Tämä lisää viivettä, koska verkkolaitteiden määrä, joiden kautta liikenne kulkee, kasvaa, samoin kuin kauttakulkuliikenteen määrä autonomisissa järjestelmissä Go:n ja ASM:n välillä.
Kuinka vähentää transit AS:iden määrää, joiden kautta liikenne on pakotettu kulkemaan? Aivan oikein - liikenteen vaihtopiste.
Nykyään uusien IXP:iden syntymistä ohjaavat samat tarpeet kuin 90-2000-luvun alussa, vain pienemmässä mittakaavassa vastauksena teleoperaattoreiden, käyttäjien ja liikenteen lisääntymiseen sekä CDN-verkkojen tuottaman sisällön kasvavaan määrään. ja datakeskukset.
Mikä on vaihtopiste?
Liikenteenvaihtopiste on erityisen verkkoinfrastruktuurin omaava paikka, jossa keskinäisestä liikenteenvaihdosta kiinnostuneet järjestävät keskinäistä peeringiä. Liikenteen vaihtopisteiden päätoimijat: teleoperaattorit, Internet-toimittajat, sisällöntuottajat ja datakeskukset. Liikenteen vaihtopisteissä osallistujat ovat suoraan yhteydessä toisiinsa. Tämän avulla voit ratkaista seuraavat ongelmat:
- vähentää latenssia,
- vähentää kauttakulkuliikenteen määrää,
- optimoida reititys AS:n välillä.
Ottaen huomioon, että IXP:itä on monissa suurissa kaupungeissa ympäri maailmaa, tällä kaikella on myönteinen vaikutus Internetiin kokonaisuutena.
Jos yllä oleva tilanne Petyan kanssa ratkaistaan IXP: n avulla, siitä tulee jotain tällaista:
Miten liikenteen vaihtopiste toimii?
Yleensä IXP on erillinen AS, jolla on oma julkisten IPv4/IPv6-osoitteiden lohko.
IXP-verkko koostuu useimmiten jatkuvasta L2-alueesta. Joskus tämä on yksinkertaisesti VLAN, joka isännöi kaikkia IXP-asiakkaita. Mitä tulee suurempiin, maantieteellisesti hajautettuihin IXP:ihin, tekniikoita, kuten MPLS, VXLAN jne., voidaan käyttää L2-alueen järjestämiseen.
IXP elementtejä
- SKS. Tässä ei ole mitään epätavallista: telineet, optiset ristikytkennät, patch-paneelit.
- Kytkimet – IXP:n perusta. Kytkinportti on sisääntulopiste IXP-verkkoon. Kytkimet suorittavat myös osan suojaustoiminnoista - ne suodattavat roskaliikennettä, jota ei pitäisi olla IXP-verkossa. Pääsääntöisesti kytkimet valitaan toiminnallisten vaatimusten perusteella - luotettavuus, tuetut porttinopeudet, turvaominaisuudet, sFlow-tuki jne.
- Reittipalvelin (RS) – olennainen ja välttämätön osa mitä tahansa nykyaikaista liikenteen vaihtopistettä. Toimintaperiaate on hyvin samanlainen kuin iBGP:n reittiheijastin tai OSPF:n määrätty reititin ja ratkaisee samat ongelmat. Liikenteenvaihtopisteen osallistujien määrän kasvaessa kunkin osallistujan tarvitsemien BGP-istuntojen määrä kasvaa, ts. tämä muistuttaa iBGP:n klassista full-mesh-topologiaa. RS ratkaisee ongelman seuraavalla tavalla: se muodostaa BGP-istunnon jokaisen kiinnostuneen IXP-osallistujan kanssa, ja kyseisestä osallistujasta tulee RS-asiakas. Saatuaan BGP-päivityksen yhdeltä asiakkaaltaan RS lähettää tämän päivityksen kaikille muille asiakkailleen, lukuun ottamatta sitä, jolta tämä päivitys vastaanotettiin. Siten RS eliminoi tarpeen luoda täysverkko kaikkien IXP-jäsenten välille ja ratkaisee tyylikkäästi skaalautuvuusongelman. On syytä huomata, että reittipalvelin välittää reitit läpinäkyvästi yhdestä AS:sta toiseen tekemättä muutoksia esimerkiksi BGP:n lähettämiin attribuutteihin, esimerkiksi se ei lisää AS-polulle AS-nsa numeroa. Myös RS:llä on perusreittien suodatus: esimerkiksi RS ei hyväksy marsilaisten verkkoja ja itse IXP:n etuliitteitä.
Reittipalvelinratkaisuna käytetään usein avoimen lähdekoodin ohjelmistoreititintä BIRD (bird internet routing daemon). Hyvä puoli siinä on, että se on ilmainen, otetaan nopeasti käyttöön useimmissa Linux-jakeluissa, siinä on joustava mekanismi reititys-/suodatuskäytäntöjen määrittämiseen, eikä se vaadi laskentaresursseja. Myös Ciscon, Juniperin jne. laitteisto/virtuaalinen reititin voidaan valita RS:ksi.
- Turvallisuus. Koska IXP-verkko koostuu suuresta määrästä AS:ita, turvallisuuspolitiikan, jota kaikkien osallistujien on noudatettava, on oltava hyvin kirjoitettu. Yleensä kaikki samat mekanismit, joita käytetään luomaan BGP-viereisyys kahden erillisen BGP-vertaisen välille IXP:n ulkopuolella, ovat voimassa tässä, sekä joitain lisäturvatoimenpiteitä.
On esimerkiksi hyvä käytäntö sallia liikenne vain tietystä IXP-osallistujan mac-osoitteesta, joka on neuvoteltu etukäteen. Liikenteen estäminen muilla ethertype-kentillä kuin 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP); Tämä tehdään liikenteen suodattamiseksi, joka ei kuulu BGP-liikenteen vaihtoon. Voidaan myös käyttää mekanismeja, kuten GTSM, RPKI jne..
Ehkä yllä olevat ovat minkä tahansa IXP:n pääkomponentteja mittakaavasta riippumatta. Suuremmissa IXP:issä voi tietysti olla lisätekniikoita ja ratkaisuja.
Sattuu, että IXP tarjoaa myös osallistujilleen lisäpalveluita:
- sijoitettu IXP TLD DNS -palvelimelle,
- asentaa laitteiston NTP-palvelimia, joiden avulla osallistujat voivat synkronoida ajan tarkasti,
- tarjoavat suojan DDoS-hyökkäyksiä vastaan jne.
Toimintaperiaate
Tarkastellaan liikenteen vaihtopisteen toimintaperiaatetta yksinkertaisen IXP:n esimerkillä, joka on mallinnettu EVE-NG:llä, ja tarkastellaan sitten BIRD-ohjelmistoreitittimen perusasetuksia. Kaavion yksinkertaistamiseksi jätämme pois sellaiset tärkeät asiat kuin redundanssi ja vikasietoisuus.
Verkkotopologia näkyy alla olevassa kuvassa.
Oletetaan, että hallinnoimme pientä vaihtopistettä ja tarjoamme seuraavat peering-vaihtoehdot:
- julkinen katselu,
- yksityinen katselu,
- peering reittipalvelimen kautta.
AS-numeromme on 555, omistamme IPv4-osoitteiden lohkon – 50.50.50.0/24, josta annamme IP-osoitteet niille, jotka haluavat muodostaa yhteyden verkkoomme.
50.50.50.254 – IP-osoite määritetty reittipalvelimen liitännässä. Tämän IP-osoitteen avulla asiakkaat muodostavat BGP-istunnon RS:n kautta tapahtuvan liikenteen yhteydessä.
Olemme myös kehittäneet RS:n kautta tapahtuvaa peeringiä varten yksinkertaisen BGP-yhteisöön perustuvan reitityskäytännön, jonka avulla IXP:n osallistujat voivat säätää, kenelle ja mitä reittejä lähettää:
BGP-yhteisö
Kuvaus
LOCAL_AS:PEER_AS
Lähetä etuliitteet vain osoitteeseen PEER_AS
LOCAL_AS:IXP_AS
Siirrä etuliitteet kaikille IXP-osallistujille
3 asiakasta haluaa muodostaa yhteyden IXP:hen ja vaihtaa liikennettä; Oletetaan, että nämä ovat Internet-palveluntarjoajia. He kaikki haluavat järjestää peeringin reittipalvelimen kautta. Alla on kaavio asiakasyhteysparametreista:
asiakas
Asiakkaan AS-numero
Asiakkaan ilmoittamat etuliitteet
Asiakkaalle annettu IP-osoite IXP:hen yhdistämistä varten
ISP nro 1
AS 100
1.1.0.0/16
50.50.50.10/24
ISP nro 2
AS 200
2.2.0.0/16
50.50.50.20/24
ISP nro 3
AS 300
3.3.0.0/16
50.50.50.30/24
BGP-perusasetukset asiakasreitittimessä:
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
Tässä on syytä huomata no bgp enforce-first-as -asetus. Oletusarvoisesti BGP edellyttää, että vastaanotetun BGP-päivityksen as-polku sisältää sen vertaisohjelman as-bgp-numeron, jolta päivitys vastaanotettiin. Mutta koska reittipalvelin ei tee muutoksia as-polkuun, sen numero ei ole as-polussa ja päivitys hylätään. Tätä asetusta käytetään saamaan reititin huomioimatta tätä sääntöä.
Näemme myös, että asiakas on asettanut tälle etuliitteelle bgp Community 555:555, mikä käytäntömme mukaan tarkoittaa, että asiakas haluaa mainostaa tätä etuliitettä kaikille muille osallistujille.
Muiden asiakkaiden reitittimien asetukset ovat samanlaiset, lukuun ottamatta niiden ainutlaatuisia parametreja.
Esimerkki BIRD-kokoonpanosta:
define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];
template bgp RS_CLIENT {
local as ixp_as;
rs client;
}
Seuraavassa kuvataan suodatin, joka ei hyväksy marssialaisten etuliitteitä eikä itse IXP:n etuliitteitä:
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;
}
Tämä toiminto toteuttaa aiemmin kuvailemamme reitityskäytännön.
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;
}
Määritämme peeringin, käytämme asianmukaisia suodattimia ja käytäntöjä.
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;
}
}
On syytä huomata, että reittipalvelimella on hyvä käytäntö laittaa reitit eri vertaisilta eri RIB:ihin. BIRD antaa sinun tehdä tämän. Esimerkissämme yksinkertaisuuden vuoksi kaikki kaikilta asiakkailta saadut päivitykset lisätään yhdeksi yhteiseksi RIB:ksi.
Joten, katsotaan mitä meillä on.
Reittipalvelimella näemme, että BGP-istunto on muodostettu kaikkien kolmen asiakkaan kanssa:
Näemme saavamme etuliitteitä kaikilta asiakkailta:
As 100 -reitittimessä näemme, että jos reittipalvelimen kanssa on vain yksi BGP-istunto, saamme etuliitteitä sekä 200:sta että 300:sta, kun taas BGP-attribuutit eivät ole muuttuneet, ikään kuin asiakkaiden välinen peering olisi suoritettu suoraan:
Näin ollen näemme, että reittipalvelimen läsnäolo yksinkertaistaa huomattavasti peeringin järjestämistä IXP:ssä.
Toivon, että tämä esittely auttoi sinua ymmärtämään paremmin, kuinka IXP:t toimivat ja kuinka reittipalvelin toimii IXP:ssä.
Linxdatacenter IX
Linxdatacenterissä rakensimme oman IXP:n, joka perustuu 2 kytkimen ja 2 reittipalvelimen vikasietoiseen infrastruktuuriin. IXP:mme toimii nyt testitilassa, ja kutsumme kaikkia ottamaan yhteyttä Linxdatacenter IX:ään ja osallistumaan testaukseen. Kun yhteys on muodostettu, sinulle tarjotaan portti, jonka kaistanleveys on 1 Gbit/s, mahdollisuus vertailla reittipalvelimiemme kautta sekä pääsy henkilökohtaiseen IX-portaalin tiliisi, joka on saatavilla osoitteessa .
Kirjoita kommentteihin tai yksityisviesteihin päästäksesi testaukseen.
johtopäätös
Liikenteen vaihtopisteet syntyivät Internetin kynnyksellä työkaluksi ratkaista teleoperaattoreiden välisen epäoptimaalisen liikenteen sujuvuus. Nyt uusien globaalien palvelujen ilmaantumisen ja CDN-liikenteen lisääntymisen myötä vaihtopisteet jatkavat globaalin verkon toiminnan optimointia. IXP:n määrän kasvu maailmassa hyödyttää sekä palvelun loppukäyttäjää että teleoperaattoreita, sisältöoperaattoreita jne. IXP-osallistujille hyöty ilmenee ulkoisen peeringin järjestämisen kustannusten pienentymisenä, ylemmän tason operaattoreiden maksaman liikenteen määrän vähentämisessä, reitityksen optimoinnissa ja mahdollisuutena olla suorassa yhteydessä sisältöoperaattoreihin.
Hyödyllisiä linkkejä
- Katso karttaa liikenteen vaihtopisteiden sijainnista:
- Tarkastele yksityiskohtaisia tilastoja BGP-verkosta, mukaan lukien läsnäolo IXP:ssä:
Lähde: will.com