"Ni starigis telefonan konekton inter ni kaj la uloj ĉe SRI...", Kleinrock... diris en intervjuo:
"Ni tajpis la L kaj ni demandis telefone, "Ĉu vi vidas la L?"
"Jes, ni vidas la L," venis la respondo.
"Ni tajpis la O, kaj ni demandis: "Ĉu vi vidas la O."
"Jes, ni vidas la O."
"Tiam ni tajpis la G, kaj la sistemo kraŝis"...Tamen revolucio komenciĝis...
La komenco de la interreto.
Saluton ĉiuj!
Mi nomiĝas Aleksandro, mi estas reta inĝeniero ĉe Linxdatacenter. En la hodiaŭa artikolo ni parolos pri trafikaj interŝanĝo-punktoj (Interretaj Interŝanĝaj Punktoj, IXP): kio antaŭis ilian aperon, kiajn taskojn ili solvas kaj kiel ili estas konstruitaj. Ankaŭ en ĉi tiu artikolo mi montros la principon de funkciado de IXP uzante la platformon EVE-NG kaj la programenkursigilon BIRD, por ke vi komprenu kiel ĝi funkcias "sub la kapuĉo".
Iom da historio
Se vi rigardas , tiam vi povas vidi, ke la rapida kresko de la nombro da trafikinterŝanĝaj punktoj komenciĝis en 1993. Ĉi tio ŝuldiĝas al la fakto, ke la plej granda parto de la trafiko de la telekomunikaj telefonistoj, kiuj ekzistis en tiu tempo, pasis tra la usona spina reto. Do, ekzemple, kiam trafiko iris de funkciigisto en Francio al funkciigisto en Germanio, ĝi unue iris de Francio al Usono, kaj nur poste de Usono al Germanio. La spina reto en ĉi tiu kazo funkciis kiel transito inter Francio kaj Germanio. Eĉ trafiko ene de unu lando ofte pasis ne rekte, sed tra la spinaj retoj de usonaj funkciigistoj.
Ĉi tiu stato de aferoj influis ne nur la koston de liverado de transittrafiko, sed ankaŭ la kvaliton de kanaloj kaj prokrastoj. La nombro de interretaj uzantoj pliiĝis, novaj funkciigistoj aperis, la volumo de trafiko pliiĝis, kaj la interreto maturiĝis. Funkciigistoj ĉirkaŭ la mondo komencis ekkompreni ke pli racia aliro al organizado de interfunkciigista interagado estis necesa. "Kial mi, funkciigisto A, pagu por trafiko tra alia lando por liveri trafikon al operatoro B, kiu situas sur la apuda strato?" Ĉi tio estas proksimume la demando kiun teleentreprenistoj faris al si tiutempe. Tiel, trafikinterŝanĝpunktoj komencis aperi en malsamaj mondopartoj ĉe funkciigistkoncentrejoj:
- 1994 - LINX en Londono,
- 1995 - DE-CIX en Frankfurto,
- 1995 - MSK-IX, en Moskvo, ktp.
Interreto kaj niaj tagoj
Koncipe, la arkitekturo de la moderna Interreto konsistas el multaj aŭtonomaj sistemoj (AS) kaj multaj ligoj inter ili, ambaŭ fizikaj kaj logikaj, kiuj determinas la vojon de trafiko de unu AS al alia.
ASs estas kutime teleentreprenistoj, interretaj provizantoj, CDNoj, datencentroj kaj entreprenaj segmentfirmaoj. AS-oj organizas logikajn ligojn (peering) inter si, kutime uzante la BGP-protokolon.
Kiel aŭtonomiaj sistemoj organizas ĉi tiujn ligojn estas determinita de kelkaj faktoroj:
- geografia,
- ekonomia,
- politika,
- interkonsentoj kaj komunaj interesoj inter AS-posedantoj,
- kaj tiel plu.
Kompreneble, ĉi tiu skemo havas certan strukturon kaj hierarkion. Tiel, funkciigistoj estas dividitaj en tier-1, tier-2 kaj tier-3, kaj se la klientoj por loka interreta provizanto (tier-3) estas, kiel regulo, ordinaraj uzantoj, tiam, ekzemple, por tier-1 nivelaj operatoroj la klientoj estas aliaj funkciigistoj. Tier-3-funkciigistoj agregas la trafikon de siaj abonantoj, tier-2 teleentreprenistoj, siavice, agregas la trafikon de tier-3-funkciigistoj, kaj tier-1 - la tuta interreta trafiko.
Skeme ĝi povas esti reprezentita jene:
Ĉi tiu bildo montras, ke trafiko estas kunigita de malsupre supren, t.e. de finaj uzantoj ĝis tier-1-funkciigistoj. Ekzistas ankaŭ horizontala interŝanĝo de trafiko inter AS kiuj estas proksimume ekvivalentaj unu al la alia.
Integra parto kaj samtempe malavantaĝo de ĉi tiu skemo estas certa konfuzo de ligoj inter aŭtonomaj sistemoj situantaj pli proksime al la fina uzanto, ene de geografia areo. Konsideru la suban bildon:
Ni supozu, ke en granda urbo estas 5 telekomunikaj telefonistoj, peering inter kiuj, ial aŭ alia, estas organizita kiel montrite supre.
Se la uzanto Petya, konektita al la Go ISP, volas aliri servilon konektitan al la ASM-provizanto, tiam la trafiko inter ili estos devigita trapasi 5 aŭtonomajn sistemojn. Ĉi tio pliigas la prokraston ĉar la nombro da retaj aparatoj tra kiuj trafiko iros pliiĝas, same kiel la volumeno de transittrafiko sur aŭtonomaj sistemoj inter Go kaj ASM.
Kiel redukti la nombron da transitaj AS-oj, kiujn trafiko estas devigita trapasi? Ĝuste - trafika interŝanĝo punkto.
Hodiaŭ, la apero de novaj IXP-oj estas pelata de la samaj bezonoj kiel en la fruaj 90-2000-aj jaroj, nur sur pli malgranda skalo, en respondo al la kreskanta nombro da telekomunikaj telefonistoj, uzantoj kaj trafiko, la kreskanta kvanto de enhavo generita de CDN-retoj. kaj datumcentroj.
Kio estas interŝanĝpunkto?
Trafika interŝanĝo-punkto estas loko kun speciala reto-infrastrukturo kie partoprenantoj interesitaj pri reciproka trafika interŝanĝo organizas reciprokan peering. La ĉefaj partoprenantoj de trafikaj interŝanĝo-punktoj: telekomunikaj telefonistoj, interretaj provizantoj, enhavaj provizantoj kaj datumcentroj. Ĉe trafikaj interŝanĝopunktoj, partoprenantoj konektas rekte unu kun la alia. Ĉi tio permesas vin solvi la sekvajn problemojn:
- redukti latencia,
- redukti la kvanton de trafika trafiko,
- optimumigi vojigon inter AS.
Konsiderante ke IXP-oj ĉeestas en multaj grandaj urboj ĉirkaŭ la mondo, ĉi tio ĉio havas utilan efikon sur la Interreto entute.
Se la supra situacio kun Petya estas solvita per IXP, ĝi rezultos io kiel ĉi tio:
Kiel funkcias trafika interŝanĝo-punkto?
Kiel regulo, IXP estas aparta AS kun sia propra bloko de publikaj IPv4/IPv6-adresoj.
La IXP-reto plej ofte konsistas el kontinua L2-domajno. Kelkfoje ĉi tio estas simple VLAN, kiu gastigas ĉiujn IXP-klientojn. Kiam temas pri pli grandaj, geografie distribuitaj IXP-oj, teknologioj kiel MPLS, VXLAN, ktp. povas esti uzataj por organizi L2-domajnon.
IXP-elementoj
- SKS. Estas nenio nekutima ĉi tie: rakoj, optikaj kruc-konektiloj, flikaj paneloj.
- Ŝaltiloj – la bazo de IXP. La ŝaltila haveno estas la enirpunkto en la IXP-reton. La ŝaltiloj ankaŭ plenumas parton de la sekurecaj funkcioj - ili filtras ruban trafikon, kiu ne devus ĉeesti en la IXP-reto. Kiel regulo, ŝaltiloj estas elektitaj surbaze de funkciaj postuloj - fidindeco, subtenataj havenaj rapidoj, sekurecaj funkcioj, sFlow-subteno ktp.
- Itinerservilo (RS) – integra kaj necesa parto de iu ajn moderna trafika interŝanĝo-punkto. La principo de funkciado estas tre simila al la itinero-reflektanto en iBGP aŭ la elektita enkursigilo en OSPF kaj solvas la samajn problemojn. Ĉar la nombro da partoprenantoj en trafikinterŝanĝpunkto kreskas, la nombro da BGP-sesioj kiujn ĉiu partoprenanto bezonas subteni pliiĝas, t.e. ĉi tio rememorigas la klasikan plen-maŝan topologion en iBGP. RS solvas la problemon jene: ĝi establas BGP-sesion kun ĉiu interesata IXP-partoprenanto, kaj tiu partoprenanto fariĝas RS-kliento. Ricevante BGP-ĝisdatigon de unu el siaj klientoj, RS sendas ĉi tiun ĝisdatigon al ĉiuj siaj aliaj klientoj, kompreneble, kun la escepto de tiu de kiu ĉi tiu ĝisdatigo estis ricevita. Tiel, RS forigas la bezonon establi plenan maŝon inter ĉiuj IXP-membroj kaj elegante solvas la skaleblan problemon. Indas noti, ke la itinero-servilo travideble transdonas itinerojn de unu AS al alia sen fari ŝanĝojn al la atributoj transdonitaj de BGP, ekzemple, ĝi ne aldonas la nombron en sia AS al la AS-vojo. Ankaŭ ĉe RS ekzistas baza filtrado de itineroj: ekzemple, RS ne akceptas marsajn retojn kaj la prefiksojn de la IXP mem.
Malfermfonta programara enkursigilo, BIRD (bird internet routing daemon), ofte estas uzata kiel itinerservila solvo. La bona afero pri ĝi estas ke ĝi estas senpaga, deplojiĝas rapide ĉe la plej multaj Linuksaj distribuoj, havas flekseblan mekanismon por starigi vojajn/filtritajn politikojn, kaj ne postulas pri komputikaj rimedoj. Ankaŭ, aparataro/virtuala enkursigilo de Cisco, Juniper, ktp. povas esti elektita kiel RS.
- Sekureco. Ĉar IXP-reto estas koncentriĝo de granda nombro da AS-oj, la sekureca politiko, kiun ĉiuj partoprenantoj devas sekvi, devas esti bone skribita. Ĝenerale, ĉiuj la samaj mekanismoj kiuj validas kiam establado de BGP-najbareco inter du apartaj BGP-kunuloj ekstere de IXP validas ĉi tie, kaj plie kelkaj kromaj sekureciniciatoj.
Ekzemple, estas bona praktiko permesi trafikon nur de specifa mac-adreso de la partoprenanto de IXP, kiu estas intertraktata anticipe. Nei trafikon kun etertipaj kampoj krom 0x0800(IPv4), 0x08dd(IPv6), 0x0806(ARP); ĉi tio estas farita por filtri trafikon, kiu ne apartenas al BGP peering. Ankaŭ povas esti uzataj mekanismoj kiel GTSM, RPKI ktp.
Eble ĉi-supraj estas la ĉefaj komponantoj de iu ajn IXP, sendepende de skalo. Kompreneble, pli grandaj IXP-oj povas havi kromajn teknologiojn kaj solvojn.
Okazas, ke IXP ankaŭ provizas siajn partoprenantojn per pliaj servoj:
- metita sur la IXP TLD DNS-servilon,
- instali aparatajn NTP-servilojn, permesante al partoprenantoj precize sinkronigi tempon,
- provizi protekton kontraŭ DDoS-atakoj, ktp.
Kiel ĝi funkcias
Ni rigardu la principon de funkciado de trafika interŝanĝo-punkto uzante la ekzemplon de simpla IXP, modeligita per EVE-NG, kaj tiam konsideru la bazan aranĝon de BIRD-programara enkursigilo. Por simpligi la diagramon, ni preterlasos tiajn gravajn aferojn kiel redundon kaj faŭltoleremo.
La retotopologio estas montrita en la figuro malsupre.
Ni supozu, ke ni administras malgrandan interŝanĝan punkton kaj provizas la sekvajn interkonajn eblojn:
- publika peering,
- privata rigardado,
- peering per itinerservilo.
Nia AS-numero estas 555, ni posedas blokon de IPv4-adresoj - 50.50.50.0/24, de kiu ni eldonas IP-adresojn por tiuj, kiuj volas konektiĝi al nia reto.
50.50.50.254 - IP-adreso agordita sur la itinera servila interfaco, kun ĉi tiu IP klientoj establos BGP-sesion en kazo de peering per RS.
Ankaŭ, por peering per RS, ni evoluigis simplan enrutigan politikon bazitan sur la BGP-komunumo, kiu permesas al IXP-partoprenantoj reguligi al kiu kaj kiujn itinerojn sendi:
BGP-komunumo
Priskribo
LOCAL_AS:PEER_AS
Sendu prefiksojn nur al PEER_AS
LOCAL_AS:IXP_AS
Transdonu prefiksojn al ĉiuj partoprenantoj de IXP
3 klientoj volas konektiĝi al nia IXP kaj interŝanĝi trafikon; Ni diru, ke ĉi tiuj estas interretaj provizantoj. Ili ĉiuj volas organizi peering per itinera servilo. Malsupre estas diagramo kun klientkonektparametroj:
Kliento
Kliento AS-numero
Kliento reklamis prefiksojn
IP-adreso eldonita al la kliento por konekti al la IXP
ISP numero 1
KIEL 100
1.1.0.0/16
50.50.50.10/24
ISP numero 2
KIEL 200
2.2.0.0/16
50.50.50.20/24
ISP numero 3
KIEL 300
3.3.0.0/16
50.50.50.30/24
Baza BGP-aranĝo sur la klienta enkursigilo:
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
Indas noti la agordon no bgp enforce-first-as ĉi tie. Defaŭlte, BGP postulas ke la as-pado de ricevita BGP-ĝisdatigo enhavu la as bgp-numeron de la kunulo de kiu la ĝisdatigo estis ricevita. Sed ĉar la itinerservilo ne faras ŝanĝojn al la as-path, ĝia numero ne estos en la as-path kaj la ĝisdatigo estos forĵetita. Ĉi tiu agordo estas uzata por ke la enkursigilo ignoru ĉi tiun regulon.
Ni ankaŭ vidas, ke la kliento starigis bgp-komunumon 555:555 al ĉi tiu prefikso, kio laŭ nia politiko signifas, ke la kliento volas reklami ĉi tiun prefikson al ĉiuj aliaj partoprenantoj.
Por enkursigiloj de aliaj klientoj, la agordoj estos similaj, escepte de iliaj unikaj parametroj.
Ekzempla BIRD-agordo:
define ixp_as = 555;
define ixp_prefixes = [ 50.50.50.0/24+ ];
template bgp RS_CLIENT {
local as ixp_as;
rs client;
}
La sekvanta priskribas filtrilon kiu ne akceptas marsajn prefiksojn, same kiel la prefiksojn de la IXP mem:
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;
}
Ĉi tiu funkcio efektivigas la enrutigan politikon, kiun ni priskribis antaŭe.
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;
}
Ni agordas peering, aplikas taŭgajn filtrilojn kaj politikojn.
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;
}
}
Indas noti, ke sur itinerservilo estas bona praktiko meti itinerojn de malsamaj samuloj en malsamajn RIBojn. BIRD permesas vin fari ĉi tion. En nia ekzemplo, por simpleco, ĉiuj ĝisdatigoj ricevitaj de ĉiuj klientoj estas aldonitaj al unu komuna RIB.
Do, ni kontrolu, kion ni ricevis.
Sur la itinerservilo ni vidas, ke BGP-sesio estis establita kun ĉiuj tri klientoj:
Ni vidas, ke ni ricevas prefiksojn de ĉiuj klientoj:
Sur la as 100-enkursigilo, ni vidas, ke se ekzistas nur unu BGP-sesio kun la itinerservilo, ni ricevas prefiksojn de kaj kiel 200 kaj kiel 300, dum la BGP-atributoj ne ŝanĝiĝis, kvazaŭ peering inter klientoj estus farita rekte:
Tiel, ni vidas, ke la ĉeesto de itinera servilo multe simpligas la organizon de peering sur la IXP.
Mi esperas, ke ĉi tiu pruvo helpis vin pli bone kompreni kiel funkcias IXP-oj kaj kiel funkcias la itinera servilo sur IXP.
Linxdatacenter IX
Ĉe Linxdatacenter, ni konstruis nian propran IXP bazitan sur misfunkcia infrastrukturo de 2 ŝaltiloj kaj 2 itinerserviloj. Nia IXP nun funkcias en prova reĝimo, kaj ni invitas ĉiujn konekti al Linxdatacenter IX kaj partopreni en testado. Kiam vi estas konektita, vi ricevos havenon kun bendolarĝo de 1 Gbit/s, la kapablo rigardi tra niaj itinerserviloj, kaj ankaŭ aliron al via persona konto de la IX-portalo, disponebla ĉe .
Skribu en komentoj aŭ privataj mesaĝoj por akiri aliron al testado.
konkludo
Trafikinterŝanĝpunktoj ekestis ĉe la krepusko de la Interreto kiel ilo por solvi la problemon de suboptimuma trafikfluo inter teleentreprenistoj. Nun, kun la apero de novaj tutmondaj servoj kaj pliiĝo de la kvanto de CDN-trafiko, interŝanĝpunktoj daŭre optimumigas la funkciadon de la tutmonda reto. La pliiĝo en la nombro da IXP-oj en la mondo profitigas kaj la finuzanton de la servo kaj telekomunikajn funkciigistojn, enhavfunkciigistojn, ktp. Por IXP-partoprenantoj, la avantaĝo estas esprimita en reduktado de la kostoj de organizado de ekstera kunulado, reduktado de la kvanto de trafiko por kiu altnivelaj funkciigistoj devas pagi, optimumigante vojigon kaj la kapablo havi rektan interfacon kun enhavfunkciigistoj.
utilaj ligoj
- Rigardu mapon de la loko de trafikaj interŝanĝopunktoj:
- Rigardu detalajn statistikojn pri BGP-kunulado, inkluzive de ĉeesto sur IXP:
fonto: www.habr.com