Punto di scambio traffic: dalle origini alla creazione del proprio IX

Punto di scambio traffic: dalle origini alla creazione del proprio IX

«Abbiamo stabilito una connessione telefonica tra noi e i ragazzi della SRI…», ha detto Kleinrock in un'intervista:
«Abbiamo digitato la L e abbiamo chiesto al telefono, „Vedi la L?“»
«Sì, vediamo la L,» è stata la risposta.
«Abbiamo digitato la O e abbiamo chiesto, „Vedi la O?“»
«Sì, vediamo la O.»
«Poi abbiamo digitato la G e il sistema si è bloccato»…

Eppure una rivoluzione era iniziata…

L'inizio di Internet.


Ciao a tutti!

Mi chiamo Alessandro, sono un ingegnere di rete presso Linxdatacenter. Nell'articolo di oggi, parlerò dei punti di scambio traffic (Internet Exchange Point, IXP): di ciò che ha preceduto la loro apparizione, quali problemi risolvono e come sono costruiti. In questo articolo, mostrerò anche il principio di funzionamento di un IXP utilizzando la piattaforma EVE-NG e il router software BIRD, per far capire come funziona «sotto il cofano».

Un po' di storia

Se guardiamo qui, si può notare che la rapida crescita del numero di punti di scambio del traffico è iniziata nel 1993. Questo è legato al fatto che la maggior parte del traffico degli operatori di telecomunicazione esistenti a quel tempo passava attraverso la rete backbone degli Stati Uniti. Ad esempio, quando il traffico viaggiava da un operatore in Francia a un operatore in Germania, questo passava prima per gli Stati Uniti e solo successivamente arrivava in Germania. La rete backbone fungeva da transito tra Francia e Germania. Anche il traffico all'interno di un singolo paese spesso non viaggiava direttamente, ma passava attraverso le reti di supporto degli operatori americani.

Questa situazione si rifletteva non solo sul costo della consegna del traffico di transito, ma anche sulla qualità delle connessioni e sui ritardi. Il numero di utenti della rete Internet cresceva, nuovi operatori emergevano, il volume del traffico aumentava, e Internet si sviluppava. Gli operatori di tutto il mondo cominciarono a comprendere che era necessaria un'approccio più razionale all'organizzazione dell'interazione tra operatori. "Perché io, operatore A, dovrei pagare per il transito attraverso un altro paese per consegnare il traffico all'operatore B, che si trova nella strada vicina?". Più o meno, questa era la domanda che si ponevano gli operatori di telecomunicazioni in quel periodo. Così, in diverse parti del mondo, nei punti di concentrazione degli operatori iniziarono a comparire i punti di scambio di traffico:

  • 1994 – LINX a Londra,
  • 1995 – DE-CIX a Francoforte,
  • 1995 – MSK-IX, a Mosca, ecc.

Internet ai giorni nostri

Concettualmente, l'architettura dell'Internet moderno è composta da molteplici sistemi autonomi (autonomous system, AS) e da un gran numero di collegamenti tra di essi, sia fisici che logici, che determinano il percorso del traffico da un AS a un altro.

Gli AS sono solitamente rappresentati da operatori di telecomunicazioni, provider Internet, CDN, centri dati e aziende del segmento enterprise. Gli AS organizzano collegamenti logici (peering) tra loro, normalmente tramite il protocollo BGP.

Il modo in cui i sistemi autonomi organizzano questi collegamenti è determinato da una serie di fattori:

  • geografici,
  • economici,
  • politici,
  • accordi e interessi comuni tra i proprietari degli AS,
  • ecc.

Naturalmente, in questo schema c'è una certa struttura e gerarchia. Gli operatori si dividono in tier-1, tier-2 e tier-3 e, mentre i clienti di un provider Internet locale (tier-3) sono generalmente utenti normali, ad esempio, i clienti degli operatori di livello tier-1 sono altri operatori. Gli operatori tier-3 aggregano il traffico dei loro abbonati, gli operatori di telecomunicazioni tier-2 aggregano a loro volta il traffico degli operatori tier-3, mentre i tier-1 gestiscono tutto il traffico Internet.

Schematicamente può essere rappresentato così:

Punto di scambio traffic: dalle origini alla creazione del proprio IX
Nell'immagine si vede che il traffico viene aggregato dal basso verso l'alto, cioè dagli utenti finali agli operatori tier-1. Inoltre, è presente uno scambio orizzontale di traffico tra AS sostanzialmente equivalenti.

Un aspetto intrinseco e al contempo un difetto di questo schema è una certa disorganicità dei legami tra le autonomous systems che si trovano più vicine all'utente finale, all'interno di una zona geografica. Consideriamo l'immagine qui sotto:

Punto di scambio traffic: dalle origini alla creazione del proprio IX

Supponiamo che in una grande città ci siano 5 operatori di telecomunicazioni, il peering tra i quali, per vari motivi, è organizzato come mostrato sopra.

Se l'utente Petya, connesso al provider internet Go, desidera accedere a un server collegato al provider ASM, il traffico dovrà passare attraverso 5 sistemi autonomi. Questo aumenta la latenza, poiché cresce il numero di dispositivi di rete attraverso i quali passerà il traffico, così come il volume del traffico in transito tra i sistemi autonomi tra Go e ASM.

Come ridurre il numero di AS di transito che il traffico deve attraversare? La risposta è semplice: punto di interscambio del traffico.

Oggi, la nascita di nuovi IXP è determinata dalle stesse esigenze che si erano presentate all'inizio degli anni '90 e 2000, ma su una scala più ridotta, in risposta al crescente numero di operatori di telecomunicazioni, utenti e traffico, e all'aumento del contenuto generato dalle reti CDN e dai data center.

Che cos'è un punto di scambio del traffico?

Un punto di scambio del traffico è un luogo dotato di un'infrastruttura di rete speciale in cui i partecipanti interessati allo scambio reciproco di traffico organizzano il peer-to-peer reciproco. I principali partecipanti ai punti di scambio del traffico includono operatori di telecomunicazioni, fornitori di servizi Internet, fornitori di contenuti e data center. Nei punti di scambio del traffico, i partecipanti possono connettersi direttamente tra loro. Questo consente di risolvere le seguenti problematiche:

  • ridurre la latenza,
  • abbattere il traffico di transito,
  • ottimizzare la routing tra AS.

Dato che gli IXP sono presenti in molte delle principali città del mondo, ciò ha un effetto positivo anche sulla rete Internet nel suo insieme.

Se si cerca di risolvere la situazione sopra descritta con Petya tramite IXP, potrebbe apparire circa così:

Punto di scambio traffic: dalle origini alla creazione del proprio IX

Come è strutturato un punto di scambio del traffico?

In genere, un IXP è un AS separato con il proprio blocco di indirizzi IPv4/IPv6 pubblici.

La rete IXP è spesso un dominio L2 continuo. A volte è semplicemente un VLAN in cui si trovano tutti i clienti dell'IXP. Quando si parla di IXP più grandi e geograficamente distribuiti, si possono utilizzare tecnologie come MPLS, VXLAN, ecc. per organizzare il dominio L2.

Elementi IXP

  • SCS. Qui non c'è nulla di insolito: armadi, cross optical, patch panel.
  • Switch – la base dell'IXP. La porta dello switch è il punto di ingresso nella rete IXP. Inoltre, gli switch svolgono alcune funzioni di sicurezza, filtrando il traffico spazzatura che non dovrebbe essere presente nella rete IXP. In genere, gli switch vengono selezionati in base ai requisiti funzionali: affidabilità, velocità di porta supportata, funzioni di sicurezza, supporto sFlow, etc.
  • Route server (RS) – una parte essenziale e necessaria di qualsiasi moderno punto di scambio del traffico. Il suo funzionamento ricorda molto quello di un route reflector in iBGP o di un designated router in OSPF e risolve gli stessi problemi. Con l'aumento del numero di partecipanti al punto di scambio del traffico, aumenta anche il numero di sessioni BGP che ogni partecipante deve gestire, il che ricorda la classica topologia full-mesh in iBGP. RS affronta il problema nel seguente modo: stabilisce una sessione BGP con ogni partecipante interessato all'IXP, e quest'ultimo diventa cliente di RS. Ricevendo un aggiornamento BGP da uno dei propri clienti, RS lo distribuisce a tutti gli altri propri clienti, ovviamente ad eccezione di quello dal quale è stato ricevuto l'aggiornamento. In questo modo, RS elimina la necessità di stabilire un full-mesh tra tutti i partecipanti dell'IXP e risolve elegantemente il problema della scalabilità. È importante notare che il server di routing trasmette le rotte da un AS all'altro senza apportare modifiche agli attributi BGP trasmessi, come ad esempio non aggiungendo il proprio numero AS nel percorso AS. Inoltre, su RS avviene una filtrazione di base delle rotte: ad esempio, RS non accetta reti martiane e prefissi dell'IXP stesso.

    Come soluzione, il route server viene spesso implementato utilizzando un router software open source – BIRD (bird internet routing daemon). È apprezzato per il fatto che è gratuito, si installa rapidamente sulla maggior parte delle distribuzioni Linux, dispone di un meccanismo flessibile per la configurazione delle politiche di routing/filtraggio e non richiede molte risorse computazionali. Inoltre, come RS, è possibile scegliere anche un router hardware/virtuale di Cisco, Juniper, ecc.

  • Sicurezza. Poiché la rete IXP concentra un gran numero di AS, anche la politica di sicurezza a cui devono attenersi tutti i partecipanti deve essere ben definita. In generale, gli stessi meccanismi utilizzati per stabilire la connessione BGP tra due singoli peer BGP al di fuori dell'IXP si applicano qui, insieme ad alcune ulteriori misure di protezione.

    Ad esempio, è buona prassi consentire il traffico solo da un determinato indirizzo MAC di un partecipante all'IXP, concordato in anticipo. Si vieta il traffico con campi ethertype che differiscono da 0x0800 (IPv4), 0x08dd (IPv6), 0x0806 (ARP); questo viene fatto per filtrare il traffico che non ha spazio durante il peer BGP. Possono essere applicati meccanismi come GTSM, RPKI, ecc.

Probabilmente, quanto sopra rappresenta i principali elementi di qualsiasi IXP, indipendentemente dalla scala. Certamente, gli IXP più grandi possono utilizzare tecnologie e soluzioni aggiuntive.
In alcuni casi, l'IXP offre anche servizi aggiuntivi ai propri partecipanti:

  • posizionano server DNS TLD presso l'IXP,
  • installano server NTP hardware, consentendo ai partecipanti di sincronizzare esattamente il tempo,
  • forniscono protezione contro attacchi DDoS, ecc.

Principio di funzionamento

Analizziamo il principio di funzionamento di un punto di interscambio del traffico prendendo come esempio il più semplice IXP, modellato con EVE-NG, e poi esaminiamo la configurazione di base del router software BIRD. Per semplificare il diagramma, ometteremo aspetti importanti come la ridondanza e la resilienza.

La topologia della rete è illustrata nell'immagine qui sotto.

Punto di scambio traffic: dalle origini alla creazione del proprio IX

Supponiamo di gestire un piccolo punto di scambio dati e di offrire le seguenti opzioni di peering:

  • peering pubblico,
  • peering privato,
  • peering tramite route server.

Il nostro numero AS è 555, possediamo un blocco di indirizzi IPv4 – 50.50.50.0/24, da cui rilasciamo indirizzi IP per coloro che desiderano connettersi alla nostra rete.

50.50.50.254 è l'indirizzo IP configurato sull'interfaccia del route server; con questo IP, i clienti stabiliranno una sessione BGP in caso di peering tramite RS.

Per il peering tramite RS, abbiamo anche sviluppato una semplice politica di instradamento basata su BGP community, che consente ai partecipanti dell'IXP di regolare a chi e quali percorsi inviare:

BGP community
Descrizione

LOCAL_AS:PEER_AS
Trasmettere i prefissi solo a PEER_AS

LOCAL_AS:IXP_AS
Trasmettere i prefissi a tutti i partecipanti dell'IXP

Tre clienti desiderano connettersi al nostro IXP e scambiare traffico; supponiamo che siano fornitori di servizi Internet. Tutti desiderano organizzare il peering tramite route server. Di seguito è presentato uno schema con i parametri di connessione dei clienti:

Cliente
Numero AS del cliente
Prefissi annunciati dal cliente
Indirizzo IP assegnato al cliente per la connessione all'IXP

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

Configurazione di base del BGP sul router del cliente:

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

È importante notare la configurazione no bgp enforce-first-as. Di default, il BGP richiede che nel percorso AS dell'aggiornamento BGP ricevuto sia presente il numero AS del peer BGP da cui è stato ricevuto l'aggiornamento. Tuttavia, poiché il route server non modifica il percorso AS, il suo numero mancherà nel percorso AS e l'aggiornamento verrà scartato. Questa configurazione viene applicata affinché il router inizi a ignorare questa regola.

Inoltre, vediamo che il cliente ha impostato la comunity BGP 555:555 su questo prefisso, il che secondo la nostra politica significa che il cliente desidera annunciare questo prefisso a tutti gli altri partecipanti.

Per i router degli altri clienti, la configurazione sarà simile, ad eccezione dei loro parametri unici.

Esempio di configurazione BIRD:

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

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

Di seguito viene descritto un filtro che non accetta i prefissi martians, così come i prefissi dell'IXP stesso:

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

Questa funzione implementa la politica di instradamento che abbiamo descritto in precedenza.

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;


}

Impostiamo il peering, applicando i filtri e le politiche appropriate.

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

È importante notare che sul route server è buona prassi organizzare le rotte da diversi peer in RIB separate. BIRD consente di fare ciò. Nel nostro esempio, per semplicità, tutti gli aggiornamenti ricevuti da tutti i clienti sono accumulati in un'unica RIB.

Dunque, verifichiamo cosa abbiamo ottenuto.

Sul route server vediamo che con tutti e tre i clienti è stata stabilita una sessione BGP:

Punto di scambio traffic: dalle origini alla creazione del proprio IX

Osserviamo che riceviamo i prefissi da tutti i clienti:

Punto di scambio traffic: dalle origini alla creazione del proprio IX

Sul router as 100 vediamo che, avendo solo una sessione BGP con il server dei route, riceviamo i prefissi sia da as 200 che da as 300, senza che gli attributi BGP siano cambiati, proprio come se il peering tra i clienti fosse avvenuto direttamente:

Punto di scambio traffic: dalle origini alla creazione del proprio IX

Pertanto, vediamo che la presenza di un server di routing semplifica notevolmente l'organizzazione del peering su IXP.

Spero che questa dimostrazione ti abbia aiutato a comprendere meglio come funzionano i punti di scambio del traffico e come opera un server di routing su IXP.

Linxdatacenter IX

In Linxdatacenter abbiamo costruito il nostro IXN basato su un'infrastruttura ridondante composta da 2 switch e 2 server di routing. Attualmente il nostro IXN è attivo in modalità test e invitiamo tutti a connettersi a Linxdatacenter IX e partecipare ai test. Una volta connessi, riceverete una porta con una capacità di 1 Gbit/s, la possibilità di peering attraverso i nostri server di routing e accesso al pannello personale del portale IX, disponibile all'indirizzo ix.linxdatacenter.com.

Contattateci nei commenti o in messaggi privati per ottenere accesso al test.

Risultato

I punti di scambio del traffico sono emersi all'inizio di Internet come uno strumento per affrontare la questione di un transito inefficiente del traffico tra gli operatori di telecomunicazione. Oggi, con l'emergere di nuovi servizi globali e l'aumento del traffico CDN, i punti di scambio continuano a ottimizzare il funzionamento della rete globale. L'aumento del numero di IXP nel mondo porta vantaggi sia per l'utente finale del servizio, sia per gli operatori di telecomunicazioni, gli operatori di contenuti, ecc. Per i partecipanti agli IXP, il vantaggio si traduce in una riduzione dei costi per l'organizzazione di peer interni, una diminuzione del traffico per il quale si deve pagare agli operatori superiori, ottimizzazione del routing e la possibilità di avere un collegamento diretto con gli operatori di contenuti.

Link utili

Fonte: habr.com

Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server 🔥 Acquista hosting affidabile per siti web con protezione DDoS, VPS VDS server | ProHoster