Trasferimento del traffico IP su reti SDH o esiste un'alternativa ad ATM? Nascondere il traffico: una tecnica per nascondere il traffico IP utilizzando canali passivi segreti.

04.07.2019 In contatto con

Trasferimento del traffico IP su reti SDH o esiste un'alternativa ad ATM?

Oleg ALLENOV
Gruppo AMT

Si discute molto su quali tecnologie di trasporto verranno alla ribalta nelle reti multimediali ad alta velocità come Internet. Anche se la maggioranza dei contendenti vota a favore dell'ATM, non tutti sono d'accordo con questo punto di vista. È possibile un'altra opzione alternativa per costruire reti di trasporto multimediale: utilizzare il protocollo IP (protocollo Internet) con incapsulamento diretto in una rete gerarchica digitale sincrona (SDH).

L’IP è in uso da oltre 15 anni, mentre ATM è un protocollo relativamente nuovo. Nel corso della sua esistenza, Internet IP si è trasformata da una rete scientifica unita di campus universitari isolati in un'enorme rete informatica che copriva l'intero pianeta. Il numero sempre crescente di utenti Internet (oggi ammontano a milioni) e la crescente domanda di larghezza di banda minacciano di portare al fatto che la rete non è più in grado di far fronte al carico. Le nuove applicazioni multimediali impongono requisiti molto più esigenti in termini di larghezza di banda disponibile, spesso in tempo reale. Ciò ci costringe a riconsiderare gli approcci esistenti per costruire l’infrastruttura Internet.

Per aumentare la capacità di Internet è necessario innanzitutto un “trasporto” ad alta velocità. Un'opzione è utilizzare la popolare tecnologia ATM. Va notato che l'ATM come protocollo di trasporto sta suscitando sempre più critiche sia da parte dei produttori di apparecchiature che degli utenti finali. Cercheremo di analizzare le carenze di ATM in modo più dettagliato e di considerare gli argomenti a favore di un altro metodo di trasmissione del traffico Internet: l'incapsulamento diretto dei protocolli TCP/IP nei protocolli SONET/SDH.

Tecnologia ATM

La modalità di trasferimento asincrono, ATM, è stata presentata ai produttori e ai fornitori di servizi di rete come una tecnologia in grado di fornire larghezza di banda su richiesta e qualità del servizio garantita a un'ampia gamma di applicazioni multimediali, con Internet in testa. Pertanto, nemmeno la parte più recente dei componenti ATM è stata orientata e sviluppata specificamente per la trasmissione del traffico Internet. Si prevedeva che nel prossimo futuro la Rete sarebbe stata costituita in gran parte da utenti ATM e client LANE (Emulazione LAN), consentendo una migrazione facile e naturale delle applicazioni Internet al nuovo protocollo di trasporto, che prometteva possibilità illimitate.

Tuttavia (forse a causa dell’alto costo delle nuove soluzioni o della loro natura inorganica) per qualche motivo ciò non è avvenuto. Inoltre è diventata sempre più evidente la tendenza ad aumentare l'influenza dei protocolli TCP/IP proprio come protocolli di trasporto.

In effetti, lo stack del protocollo TCP/IP è stato sviluppato e testato da tempo; sono stati investiti molti soldi e molti sforzi nella sua creazione e nel debugging. Sebbene il protocollo IPv4 presenti alcune carenze, la prossima versione IPv6 ne eliminerà la maggior parte. Ma anche la versione attuale di IPv4 è adatta a molte persone e, secondo gli esperti, può durare ancora per molti anni. Un buon numero di produttori considera IP un protocollo di trasporto promettente per le moderne infrastrutture di telecomunicazione. Allora cosa c'entra l'ATM?

ATM è stata proposta dall'ITU-T come tecnologia di base per l'ISDN a banda larga (o B-ISDN). Poiché B-ISDN è progettato principalmente per trasportare traffico multimediale, ATM era ben posizionata per supportare questo tipo di traffico nelle reti reali.

Passò del tempo e i produttori di apparecchiature per le telecomunicazioni rivolsero la loro attenzione all'ATM. È stato creato l'ATM Forum, che ha iniziato a dare vita alla nuova tecnologia. Allo stesso tempo, i compiti assegnati al Forum ATM erano quello di standardizzare e sviluppare un protocollo efficace e scalabile che supporti il traffico con caratteristiche diametralmente opposte (multimedia), garantisca una certa qualità di servizio (QoS) e supporti la trasmissione multicast. Inoltre, questo protocollo deve essere compatibile con le tecnologie LAN e WAN esistenti.

Dovrebbe essere chiaro che la tecnologia ATM ha guadagnato una popolarità così diffusa proprio a causa della convinzione generale che le tecnologie esistenti a quel tempo non fossero in grado di soddisfare i requisiti di cui sopra.

Tecnologia IP

L'IP, d'altro canto, non sembra un protocollo legacy da dimenticare. Esiste un numero enorme di soluzioni IP su Ethernet installate in tutto il mondo e non è affatto facile convincere i clienti a buttare via schede Ethernet economiche e installare adattatori ATM senza promettere funzionalità fondamentalmente nuove o almeno velocità più elevate (l'aumento della velocità è dovuto non è affatto ovvio).

Penso che molti clienti che hanno esperienza nell'uso degli adattatori ATM per personal computer saranno d'accordo con me sul fatto che una scheda di rete Fast Ethernet da 100 Mbps (per non parlare del Full Duplex) non è almeno non più lenta di un adattatore ATM da 155 Mbps. Ciò è dovuto alla maggiore ridondanza del protocollo ATM e ai ritardi nel montaggio/smontaggio delle celle. Per quanto riguarda la qualità del servizio garantita da ATM, praticamente non è implementata in LANE e AAL5 UBR (massimo UBR+ o ABR) viene ora utilizzato per trasmettere il traffico IP su ATM. Quindi non è necessario parlare di QoS.

Naturalmente, la nuova tecnologia deve supportare un’ampia gamma di livelli di qualità del servizio. Tuttavia, l'IP è stato scelto come protocollo per l'internetworking universale e ha funzionato bene sull'Internet allora composta da 20.000 computer a metà degli anni '80 e continua a connettere con successo diversi milioni di host oggi. L’IP è davvero diventato obsoleto? I sostenitori dell’ATM probabilmente risponderebbero di sì.

Enormi quantità di denaro sono state investite nello sviluppo di una famiglia di protocolli Internet e nel portarli allo stato attuale. Non è attivo solo l'ATM Forum, ma anche l'IETF (Internet Engineering Task Force): continua la ricerca su come utilizzare l'IP nelle reti multimediali emergenti ad alta velocità. Sono stati creati protocolli per supportare la trasmissione multicast (IGMP, DVMRP, PIM) e protocolli che forniscono la prenotazione delle risorse per la trasmissione del traffico (RSVP). È possibile effettuare un routing (anche se non ancora così flessibile come con PNNI) in base alla qualità del servizio richiesta (Tag Switching) e allo standard MPLS (Multiprotocol Label Switching), che è in preparazione per il rilascio in IETF, garantirà l'interoperabilità di tutti i dispositivi che supportano la commutazione dei tag e probabilmente sostituirà in modo significativo la posizione dell'MPOA (Multiprotocol Over ATM).

Ha quindi senso sostituire la consolidata tecnologia IP con l’emergente ATM?

IP su ATM

Inizialmente, l'idea di trasmettere IP tramite ATM era considerata come un possibile modo per introdurre ATM nell'architettura Internet esistente e quindi sostituire completamente IP. Ora, comprendendo che ATM non è in grado di sostituire completamente l'IP, possiamo porci la domanda: perché non sono stati ancora creati metodi efficaci per trasportare il traffico IP su ATM? A quanto pare, si ritiene che ATM offra una tecnologia di commutazione rapida unica in grado di risolvere gli attuali problemi di larghezza di banda Internet. Tuttavia, in realtà ci sono alcuni problemi qui.

Innanzitutto prestiamo attenzione al fatto che quasi tutte (con rare eccezioni, ad esempio ATM25, TAXI, ecc.) le interfacce fisiche degli switch ATM funzionano nel formato frame SDH/SONET/PDH. Ciò viene fatto per facilitare l'integrazione con le diffuse reti di trasporto SDH. Ma anche quando SDH è completamente assente e non previsto dalla progettazione, nella trasmissione del traffico utente viene comunque introdotto un sovraccarico SDH che, per usare un eufemismo, non aumenta la velocità e le prestazioni della rete.

È opportuno inoltre precisare che SDH è una modalità di trasmissione sincrona, mentre ATM è asincrona. Quando si invia traffico ATM su reti di trasporto SDH, perdiamo tutti i vantaggi del metodo di trasferimento cellulare asincrono, per non parlare della duplicazione di alcune funzioni (ad esempio OA&M).

L’incapsulamento dell’IP in ATM, che a sua volta opera tramite SDH, non migliora la situazione. Il protocollo ATM è orientato alla connessione, mentre IP no. Questa discrepanza porta anche a un'ulteriore complessità e alla duplicazione di una serie di funzioni.

Pertanto, ciascuno dei protocolli, IP e ATM, richiede il proprio protocollo di routing. Sono necessarie ulteriori funzioni di controllo per controllare il funzionamento congiunto di IP e ATM. L'efficienza della trasmissione del traffico multicast diminuisce, poiché senza la conoscenza dell'esatta topologia della rete ai livelli inferiori, la trasmissione dei pacchetti multicast si trasforma nella loro semplice copia sui router edge. Tali pacchetti sono distribuiti lungo percorsi tutt'altro che ottimali per una rete reale.

Non è necessario soffermarsi sugli svantaggi dei metodi di emulazione della rete locale, poiché qualsiasi specialista di rete qualificato concorderà sul fatto che la tecnologia LANE non può essere definita organica e promettente. Da molti punti di vista, questa tecnologia è un tentativo fallito di “estrarre” i protocolli progettati per ambienti di trasmissione in modo che funzionino in un ambiente in cui tale modalità di trasferimento dati è impossibile (NBMA, Nonbroadcast Multiple Access).

Quindi, se Internet è ancora se stessa e continua a basarsi su IP, è necessario un ulteriore “strato” sotto forma di ATM tra IP e il protocollo di trasporto SDH veramente efficiente e ad alta velocità, che funziona altrettanto bene? trasportare quasi ogni tipo di traffico?

IP su SDH

La tecnologia SDH è ampiamente utilizzata per organizzare trasporti affidabili. SDH è stato sviluppato per fornire un protocollo standard per l'interoperabilità dei provider; unificare i sistemi digitali americani, europei e giapponesi; fornire multiplexing di segnali digitali a velocità gigabit; fornire supporto per le funzioni OA&M (operazione, amministrazione e manutenzione).

Sebbene SDH operi su frame e abbia una propria struttura di canali, dal punto di vista del livello di rete, SDH è solo un flusso di ottetti. Per racchiudere correttamente un pacchetto IP in un contenitore SDH è necessario definire chiaramente i confini del pacchetto (o del gruppo di pacchetti) all'interno del modulo di trasporto sincrono STM (modulo di trasporto sincrono). In altre parole, è necessario uno “strato” di protocollo tra IP e SDH per formare frame a livello di collegamento.

Poiché SDH fornisce connessioni punto-punto, l'utilizzo di PPP (protocollo punto-punto) come protocollo intermedio sembra abbastanza logico. PPP è ampiamente utilizzato su Internet come protocollo a livello di collegamento per organizzare le connessioni su reti geografiche. Inoltre, PPP consente di utilizzare funzioni aggiuntive del protocollo PPP:

possibilità di incapsulamento multiprotocollo;
protezione dagli errori;
utilizzo del protocollo LCP per stabilire, configurare e testare connessioni a livello di collegamento;
la possibilità di utilizzare la famiglia di protocolli NCP per supportare e configurare vari protocolli di rete.

Tuttavia, va notato che come protocollo di rete, ora ci interessa solo l'IP e, inoltre, una serie di funzioni del protocollo NCP (ad esempio l'assegnazione dinamica degli indirizzi IP) non sono rilevanti nel nostro caso. Ciò che ci interessa veramente è incapsulare IP in PPP e quindi posizionare i frame PPP in SDH.

L’incapsulamento dell’IP nel PPP non è un problema perché è ben consolidato e ampiamente utilizzato. La procedura di incapsulamento da PPP a SDH (definita come Path Signal Label = 207hex), mostrata in figura, deve essere eseguita da un apposito adattatore di servizio a livello di percorso SDH. L'adattatore di servizio può essere una "scatola nera" che riceve un flusso di frame PPP e "produce" un flusso di moduli di trasporto STM. PPP è molto adatto per lavorare con SDH, poiché entrambi i protocolli sono progettati per funzionare in modalità a byte singolo.

Pertanto, incapsulando direttamente il traffico Internet nel servizio di trasporto SDH esistente, semplifichiamo in modo significativo la complessa infrastruttura di rete, riducendone così i costi e aumentando il throughput effettivo. Con l'avvento di nuove opportunità per la trasmissione del traffico IP a velocità gigabit (Gigabit Ethernet) e delle tecnologie di commutazione rapida dei pacchetti IP (Multiprotocol Label Switching - MPLS), l'uso del protocollo IP come base di un servizio di trasporto unificato per la trasmissione di video, la telefonia e altre applicazioni multimediali diventano reali - fortunatamente, la maggior parte del lavoro sull'introduzione del protocollo IP nel World Wide Web è già stata completata. A questo proposito, l’emergere di standard (RFC 1619) e le prime implementazioni pratiche di interfacce come “PPP over SDH” (o Packets Over Sonet - POS) sui moderni router destinati a Internet, in particolare il GSR 12000 di Cisco Systems , sembra molto attuale.

In conclusione, vorrei sottolineare che l'autore non intende in alcun modo minimizzare l'importanza della tecnologia ATM e negare il suo impatto positivo sullo sviluppo dei servizi di telecomunicazione globali. Ha trovato interessante considerare, in modo discorsivo, la possibilità di modi alternativi per sviluppare servizi multimediali diversi dalla tecnologia di trasferimento cellulare asincrono.

CIRCA L'AUTORE

Oleg Allenov è un istruttore presso il centro di formazione del Gruppo AMT, CCSI/CCIE. Può essere contattato telefonicamente. 725 - 7660

Il traffico Internet globale crescerà fino a 1,6 zettabyte entro il 2018. I principali fattori di crescita saranno la diffusione dei video Ultra-HD/4K e delle tecnologie di comunicazione da macchina a macchina, comprese le auto intelligenti.

Secondo uno studio Cisco intitolato “Visual Networking Index: Global Forecast and Service Distribution, 2013-2018”. (Cisco VNI), il traffico IP globale quasi triplicherà entro 4 anni. Ciò accadrà a causa della crescita del numero di utenti Internet e di vari dispositivi, dell'aumento della velocità della banda larga e del numero di visualizzazioni di video. Si prevede che entro il 2018 il volume annuo del traffico IP globale che passa attraverso connessioni fisse e mobili raggiungerà 1,6 zettabyte*, ovvero più di un trilione e mezzo di gigabyte. Si tratta di più traffico IP (1,3 zettabyte) generato in tutto il mondo tra il 1984 e il 2013.

Decine di milioni di tifosi guarderanno la trasmissione delle partite dei Mondiali su Internet. Lo streaming di video e giochi IP può generare 4,3 exabyte di traffico Internet, ovvero tre volte il volume di traffico mensile in Brasile. Inoltre, si prevede che il traffico Internet generato dagli spettatori in ogni stadio e nel percorso verso la partita supererà la quantità media di traffico generato durante le ore di punta** da tutti gli smartphone attualmente posseduti dai brasiliani.

Si prevede che il traffico IP globale raggiungerà i 132 exabyte al mese entro il 2018. La stessa quantità di traffico può essere generata da:

streaming video ad altissima definizione (Ultra-HD/4K) su 8,8 miliardi di schermi contemporaneamente durante la finale della Coppa del Mondo;
5,5 miliardi di telespettatori che, utilizzando il servizio di video on demand, guardano senza interruzioni la quarta stagione di “Il Trono di Spade” in alta definizione (HD), ovvero 1,5 miliardi in ultra-alta definizione;
House of Cards Stagione 3 in streaming simultaneamente su 24 miliardi di schermi in altissima definizione;
940 quadrilioni di messaggi di testo;
4,5 trilioni di clip YouTube.

Nei prossimi anni la composizione del traffico IP cambierà radicalmente. Entro il 2018, per la prima volta, la maggior parte di essi non sarà associata ai personal computer, ma ad altri dispositivi. Inoltre, per la prima volta, il volume del traffico Wi-Fi supererà il volume del traffico via cavo e il volume del traffico video ad alta definizione supererà quello del video normale.

Anche l’Internet of Everything sta guadagnando slancio ed entro il 2018 il numero di moduli di comunicazione machine-to-machine sarà pari al numero di persone. Quindi, per ogni vettura “intelligente” ci saranno quasi 4 collegamenti.

"Nel primo rapporto di questo tipo, pubblicato 9 anni fa, abbiamo fissato gli zettabyte come pietra miliare di crescita per il traffico IP globale", ha affermato Doug Webster, vicepresidente Cisco del marketing di prodotti e soluzioni. - Oggi viviamo già nell'era degli zettabyte, avendo assistito a incredibili cambiamenti del settore. Tra le principali tendenze evidenziate nelle attuali previsioni, che offrono significative opportunità per i fornitori di servizi sia oggi che nel prossimo futuro, notiamo l'implementazione dell'Internet of Everything, la crescente domanda di mobilità di rete e l'emergere di video ad altissima definizione .”

Previsioni di crescita del traffico globale e fattori chiave dell'adozione del servizio

traffico IP

Entro il 2018, la maggior parte del traffico sarà guidato da dispositivi mobili e indossabili, senza personal computer. Se nel 2013 i dispositivi diversi dai PC rappresentavano il 33% del traffico IP, entro il 2018 la loro quota raggiungerà il 57%. Il tasso di crescita del traffico PC sarà del 10% annuo, mentre per gli altri dispositivi e connessioni questa cifra sarà più alta: 18% per la TV, 74% per i tablet, 64% per gli smartphone e 84% per la comunicazione machine-to-machine (M2M). moduli.

Il traffico durante le ore di punta cresce più velocemente del normale traffico Internet. Nel 2013, la crescita del traffico Internet nelle ore di punta è stata del 32%, mentre il traffico negli altri orari della giornata è cresciuto del 25%.

Nel 2013, le reti urbane trasportavano più traffico delle connessioni urbane. Nel periodo 2013-2018. il traffico nelle reti urbane crescerà quasi due volte più velocemente che nei collegamenti interurbani. Ciò è in parte dovuto al previsto raddoppio del traffico Internet sulle reti di distribuzione dei contenuti entro il 2018.

video IP

Entro il 2018, la quota di video IP sul traffico IP totale raggiungerà il 79% (nel 2013 era del 66%).

La quota di video ad altissima definizione sul traffico IP totale entro il 2018 aumenterà dello 0,1% rispetto al 2013 e ammonterà all'11%. La quota di video ad alta definizione aumenterà dal 36% nel 2013 al 52% entro il 2018, mentre i video a definizione standard diminuiranno dal 64% al 37% del traffico IP totale.

Traffico IP per tipo di accesso

Entro il 2018, Wi-Fi e dispositivi mobili genereranno il 61% del traffico IP. La quota del Wi-Fi rappresenterà il 49%, la quota delle reti cellulari - 12%. Il traffico fisso nel 2018 rappresenterà solo il 39% del traffico IP totale. Per fare un confronto: nel 2013 la quota Wi-Fi era del 41%, il traffico cellulare - 3%, il traffico fisso - 56%.

Entro il 2018, Wi-Fi e dispositivi mobili genereranno il 76% del traffico Internet. La quota del Wi-Fi rappresenterà il 61%, la quota delle reti cellulari - 15%. Il traffico fisso rappresenterà solo il 24% del traffico Internet totale entro il 2018. Per fare un confronto: nel 2013 la quota Wi-Fi era del 55%, il traffico cellulare - 4%, il traffico fisso - 41%.

Dispositivi e connessioni

Entro il 2018 ci saranno in media 2,7 dispositivi o connessioni di rete per ogni persona sul nostro pianeta. Nel 2013, questa cifra era di 1,7 pro capite.

Il numero globale di connessioni machine-to-machine sarà di 7,3 miliardi, ovvero quasi una connessione per persona (ipotizzando una popolazione globale di 7,6 miliardi entro il 2018).

Il numero di dispositivi fissi e mobili abilitati IPv6 crescerà da 2 miliardi nel 2013 a 10 miliardi nel 2018.

Aumento della velocità della banda larga

La velocità della banda larga nel mondo aumenterà da 16 Mbit/s alla fine del 2013 a 42 Mbit/s entro il 2018.

La maggior parte (circa il 55%) delle connessioni a banda larga supererà i 10 Mbps entro il 2018. In Giappone e Corea del Sud la velocità media della banda larga si avvicinerà ai 100 Mbit/s entro il 2018.

Erogazione di servizi avanzati

Il servizio in più rapida crescita nel settore residenziale sarà quello dei video online: con una crescita media annua del 10% nel periodo 2013-2018. il numero degli utenti aumenterà da 1,2 a 1,9 miliardi di persone.

Nel segmento consumer, i servizi mobili basati sulla posizione cresceranno più rapidamente, con un CAGR del 36% tra il 2013 e il 2018. il numero degli utenti di tali servizi crescerà da 236 milioni a oltre un miliardo di persone.

Nel segmento business, il servizio Internet in più rapida crescita sarà quello delle videoconferenze tramite dispositivi personali e computer desktop: con una crescita media annua del 45% nel periodo 2013-2018. il numero degli utenti crescerà da 37 milioni a 238 milioni di persone.

Previsioni per paese e regione

Entro il 2018, il maggior volume di traffico IP – 47,7 exabyte al mese – sarà generato nella regione Asia-Pacifico. La regione più popolosa del mondo, che ospita la maggior parte dei dispositivi e delle connessioni, rimarrà la prima in termini di volume di traffico per tutto il 2018.

In Medio Oriente e Africa nel periodo 2013-2018. rimarranno i tassi di crescita più elevati del traffico IP (un aumento di cinque volte con un incremento medio annuo del 38%).

Entro il 2018, i paesi che genereranno i maggiori volumi di traffico saranno gli Stati Uniti e la Cina (rispettivamente 37 e 18 exabyte al mese).

La crescita più rapida del traffico IP nel periodo 2013-2018. sarà osservato in India e Indonesia (rispettivamente 39% e 37% di crescita media annua).

Cosa significa tutto questo per i fornitori di servizi?

Le reti dei fornitori di servizi avranno bisogno di maggiore sicurezza e intelligenza. Dovranno adattarsi per far fronte al crescente numero di tablet, smartphone e dispositivi di comunicazione machine-to-machine che richiederanno l’autenticazione per accedere alle reti fisse e mobili.

Lo sviluppo di servizi video come video ad alta e ultra-alta definizione potrebbe richiedere ai fornitori di servizi di aumentare la larghezza di banda e aggiungere ulteriore scalabilità. Continuerà ad esserci una forte domanda nei settori residenziale, mobile e aziendale per l'accesso a servizi video avanzati attraverso reti e dispositivi di tutti i tipi. I fattori chiave di successo qui saranno la qualità del servizio, la facilità d'uso e il prezzo.

La continua proliferazione di servizi quali videoconferenze ad alta definizione, videoconferenze Web e video aziendali on demand nel segmento aziendale potrebbe favorire una maggiore crescita della virtualizzazione della rete e dell'uso di Internet per la trasmissione video, il che porrà alcune sfide sia per fornitori di servizi e per fornitori di servizi indipendenti (fornitori over-the-top, OTT).

La crescita delle reti 4G e la diffusione dei servizi correlati potrebbero accelerare, dato che gli utenti mobili continuano a richiedere servizi e qualità di servizio simili sulle loro reti fisse e mobili.

Le reti IP devono essere sufficientemente intelligenti e flessibili da supportare il numero sempre crescente di applicazioni nuove ed in evoluzione per le reti fisse e mobili. Nel tentativo di differenziare i propri servizi, molti fornitori di servizi collaborano attivamente con gli sviluppatori di applicazioni.

Qualunque amministratore prima o poi riceve istruzioni dal management: “conta chi va online e quanto scarica”. Per i fornitori, questo è completato dal compito di “far entrare chiunque ne abbia bisogno, accettare il pagamento, limitare l’accesso”. Cosa contare? Come? Dove? Ci sono molte informazioni frammentarie, non sono strutturate. Salveremo l'amministratore alle prime armi da noiose ricerche fornendogli conoscenze generali e collegamenti utili all'hardware.
In questo articolo cercherò di descrivere i principi di organizzazione della raccolta, contabilità e controllo del traffico sulla rete. Esamineremo il problema ed elencheremo i possibili modi per recuperare informazioni dai dispositivi di rete.

Questo è il primo articolo teorico di una serie di articoli dedicati alla raccolta, contabilità, gestione e fatturazione del traffico e delle risorse informatiche.

Struttura dell'accesso a Internet

In generale, la struttura di accesso alla rete è simile alla seguente:

Risorse esterne: Internet, con tutti i siti, server, indirizzi e altre cose che non appartengono alla rete che controlli.
Dispositivo di accesso: router (hardware o basato su PC), switch, server VPN o concentratore.
Le risorse interne sono un insieme di computer, sottoreti, abbonati il cui funzionamento sulla rete deve essere preso in considerazione o controllato.
Un server di gestione o contabilità è un dispositivo su cui viene eseguito un software specializzato. Può essere funzionalmente combinato con un router software.

In questa struttura, il traffico di rete passa dalle risorse esterne a quelle interne, e viceversa, attraverso il dispositivo di accesso. Trasmette le informazioni sul traffico al server di gestione. Il server di controllo elabora queste informazioni, le memorizza nel database, le visualizza ed emette comandi di blocco. Tuttavia, non tutte le combinazioni di dispositivi (metodi) di accesso e metodi di raccolta e controllo sono compatibili. Le varie opzioni verranno discusse di seguito.

Traffico di rete

Innanzitutto è necessario definire cosa si intende per “traffico di rete” e quali informazioni statistiche utili possono essere estratte dal flusso di dati degli utenti.
Il protocollo di internetworking dominante è ancora la versione IP 4. Il protocollo IP corrisponde al livello 3 del modello OSI (L3). Le informazioni (dati) tra il mittente e il destinatario sono raggruppate in pacchetti, aventi un'intestazione e un "carico utile". L'intestazione determina da e verso il pacchetto (indirizzi IP del mittente e del destinatario), la dimensione del pacchetto e il tipo di carico utile. La maggior parte del traffico di rete è costituita da pacchetti con payload UDP e TCP: si tratta dei protocolli Layer 4 (L4). Oltre agli indirizzi, l'intestazione di questi due protocolli contiene i numeri di porta, che determinano il tipo di servizio (applicazione) che trasmette i dati.

Per trasmettere un pacchetto IP via cavo (o radio), i dispositivi di rete sono costretti a “avvolgerlo” (incapsularlo) in un pacchetto di protocollo Layer 2 (L2). Il protocollo più comune di questo tipo è Ethernet. La trasmissione vera e propria “al filo” avviene al 1° livello. Tipicamente, il dispositivo di accesso (router) non analizza le intestazioni dei pacchetti a livelli superiori al livello 4 (ad eccezione dei firewall intelligenti).
Le informazioni provenienti dai campi indirizzi, porte, protocolli e contatori di lunghezza delle intestazioni L3 e L4 dei pacchetti di dati costituiscono la "materia prima" utilizzata nella contabilità e nella gestione del traffico. La quantità effettiva di informazioni trasmesse si trova nel campo Lunghezza dell'intestazione IP (inclusa la lunghezza dell'intestazione stessa). A proposito, a causa della frammentazione dei pacchetti dovuta al meccanismo MTU, la quantità totale di dati trasmessi è sempre maggiore della dimensione del carico utile.

La lunghezza totale dei campi IP e TCP/UDP del pacchetto che ci interessano in questo contesto è pari al 2...10% della lunghezza totale del pacchetto. Se elabori e memorizzi tutte queste informazioni batch per batch, non ci saranno risorse sufficienti. Fortunatamente, la stragrande maggioranza del traffico è strutturata in modo da consistere in una serie di “conversazioni” tra dispositivi di rete esterni ed interni, chiamati “flussi”. Ad esempio, nell'ambito di un'operazione di invio di un'e-mail (protocollo SMTP), viene aperta una sessione TCP tra il client e il server. È caratterizzato da un insieme costante di parametri (indirizzo IP di origine, porta TCP di origine, indirizzo IP di destinazione, porta TCP di destinazione). Invece di elaborare e memorizzare informazioni pacchetto per pacchetto, è molto più conveniente memorizzare i parametri di flusso (indirizzi e porte), nonché informazioni aggiuntive: il numero e la somma delle lunghezze dei pacchetti trasmessi in ciascuna direzione, facoltativamente durata della sessione, interfaccia del router indici, valore del campo ToS, ecc. Questo approccio è vantaggioso per i protocolli orientati alla connessione (TCP), dove è possibile intercettare esplicitamente la terminazione di una sessione. Tuttavia, anche per i protocolli non orientati alla sessione, è possibile eseguire l'aggregazione e il completamento logico di un record di flusso in base, ad esempio, a un timeout. Di seguito è riportato un estratto dal database SQL del nostro sistema di fatturazione, che registra le informazioni sui flussi di traffico:

È necessario notare il caso in cui il dispositivo di accesso esegue la traduzione degli indirizzi (NAT, mascheramento) per organizzare l'accesso a Internet per i computer della rete locale utilizzando un indirizzo IP pubblico esterno. In questo caso, uno speciale meccanismo sostituisce gli indirizzi IP e le porte TCP/UDP dei pacchetti di traffico, sostituendo gli indirizzi interni (non instradabili su Internet) secondo la sua tabella di traduzione dinamica. In questa configurazione è necessario ricordare che per registrare correttamente i dati sugli host della rete interna, le statistiche devono essere raccolte in un modo e in un luogo in cui il risultato della traduzione non “anonimizzi” ancora gli indirizzi interni.

Metodi per la raccolta di informazioni sul traffico/statistiche

È possibile acquisire ed elaborare le informazioni sul traffico in transito direttamente sul dispositivo di accesso stesso (router PC, server VPN), trasferendole da questo dispositivo a un server separato (NetFlow, SNMP) o "dal cavo" (tap, SPAN). Diamo un'occhiata a tutte le opzioni in ordine.

Router del computer

Consideriamo il caso più semplice: un dispositivo di accesso (router) basato su un PC con Linux.

Come impostare un server di questo tipo, traduzione degli indirizzi e routing, molto è stato scritto. Siamo interessati al passaggio logico successivo: informazioni su come ottenere informazioni sul traffico che passa attraverso tale server. Esistono tre metodi comuni:

intercettare (copiare) i pacchetti che passano attraverso la scheda di rete del server utilizzando la libreria libpcap
intercettare i pacchetti che passano attraverso il firewall integrato
utilizzando strumenti di terze parti per convertire le statistiche pacchetto per pacchetto (ottenute con uno dei due metodi precedenti) in un flusso di informazioni aggregate netflow

Cap. lib

Nel primo caso, una copia del pacchetto che passa attraverso l'interfaccia, dopo aver superato il filtro (man pcap-filter), può essere richiesta da un programma client sul server scritto utilizzando questa libreria. Il pacchetto arriva con un'intestazione di livello 2 (Ethernet). È possibile limitare la lunghezza delle informazioni catturate (se siamo interessati solo alle informazioni dalla sua intestazione). Esempi di tali programmi sono tcpdump e Wireshark. Esiste un'implementazione di libpcap per Windows. Se la traduzione degli indirizzi viene utilizzata su un router PC, tale intercettazione può essere effettuata solo sulla sua interfaccia interna collegata agli utenti locali. Sull'interfaccia esterna, dopo la traduzione, i pacchetti IP non contengono informazioni sugli host interni della rete. Tuttavia, con questo metodo non è possibile tenere conto del traffico generato dal server stesso su Internet (cosa importante se gestisce un servizio web o di posta elettronica).

libpcap richiede il supporto del sistema operativo, che attualmente equivale all'installazione di un'unica libreria. In questo caso, il programma applicativo (utente) che raccoglie i pacchetti deve:

aprire l'interfaccia richiesta
specificare il filtro attraverso il quale far passare i pacchetti ricevuti, la dimensione della parte catturata (snaplen), la dimensione del buffer,
impostare il parametro promisc, che mette l'interfaccia di rete in modalità di acquisizione per tutti i pacchetti che passano e non solo quelli indirizzati all'indirizzo MAC di questa interfaccia
impostare una funzione (callback) chiamata su ciascun pacchetto ricevuto.

Quando un pacchetto viene trasmesso attraverso l'interfaccia selezionata, dopo aver superato il filtro, questa funzione riceve un buffer contenente Ethernet, (VLAN), IP, ecc. intestazioni, dimensione totale fino a snaplen. Poiché la libreria libcap copia i pacchetti, non può essere utilizzata per bloccarne il passaggio. In questo caso, il programma di raccolta ed elaborazione del traffico dovrà utilizzare metodi alternativi, come richiamare uno script per inserire un determinato indirizzo IP in una regola di blocco del traffico.

Firewall

L'acquisizione dei dati che passano attraverso il firewall consente di tenere conto sia del traffico del server stesso che del traffico degli utenti della rete, anche durante la conversione degli indirizzi. La cosa principale in questo caso è formulare correttamente la regola di cattura e metterla nel posto giusto. Questa regola attiva il trasferimento del pacchetto verso la libreria di sistema, da dove l'applicazione di contabilizzazione e gestione del traffico potrà riceverlo. Per il sistema operativo Linux, iptables viene utilizzato come firewall e gli strumenti di intercettazione sono ipq, netfliter_queue o ulog. Per OC FreeBSD – ipfw con regole come tee o deviazione. In ogni caso, il meccanismo del firewall è completato dalla possibilità di lavorare con un programma utente nel modo seguente:

Un programma utente, un gestore del traffico, si registra nel sistema utilizzando una chiamata di sistema o una libreria.
Un programma utente o uno script esterno installa una regola nel firewall, “avvolgendo” il traffico selezionato (secondo la regola) all'interno del gestore.
Per ogni pacchetto che passa, il gestore riceve il suo contenuto sotto forma di buffer di memoria (con intestazioni IP, ecc. Dopo l'elaborazione (contabilità), il programma deve anche dire al kernel del sistema operativo cosa fare dopo con tale pacchetto: scartarlo oppure trasmetterlo.In alternativa è possibile passare il pacchetto modificato al kernel.

Poiché il pacchetto IP non viene copiato, ma inviato al software per l'analisi, diventa possibile “espellerlo” e quindi limitare completamente o parzialmente il traffico di un certo tipo (ad esempio, a un abbonato della rete locale selezionato). Tuttavia, se il programma applicativo smette di rispondere alla sua decisione al kernel (ad esempio, si blocca), il traffico attraverso il server viene semplicemente bloccato.
Va notato che i meccanismi descritti, con volumi significativi di traffico trasmesso, creano un carico eccessivo sul server, associato alla costante copia dei dati dal kernel al programma utente. Il metodo di raccolta delle statistiche a livello del kernel del sistema operativo, con l'output di statistiche aggregate al programma applicativo tramite il protocollo NetFlow, non presenta questo inconveniente.

Flusso netto

Questo protocollo è stato sviluppato da Cisco Systems per esportare informazioni sul traffico dai router a scopo di contabilità e analisi del traffico. La versione 5 più popolare ora fornisce al destinatario un flusso di dati strutturati sotto forma di pacchetti UDP contenenti informazioni sul traffico passato sotto forma di cosiddetti record di flusso:

La quantità di informazioni sul traffico è di diversi ordini di grandezza inferiore rispetto al traffico stesso, il che è particolarmente importante nelle reti grandi e distribuite. Naturalmente non è possibile bloccare la trasmissione delle informazioni quando si raccolgono statistiche tramite netflow (a meno che non vengano utilizzati meccanismi aggiuntivi).
Attualmente sta diventando popolare un ulteriore sviluppo di questo protocollo: la versione 9, basata sulla struttura del record di flusso del modello, implementazione per dispositivi di altri produttori (sFlow). Recentemente è stato adottato lo standard IPFIX, che consente la trasmissione di statistiche tramite protocolli a livelli più profondi (ad esempio, per tipo di applicazione).
L'implementazione dei sorgenti netflow (agenti, sonde) è disponibile per i router PC, sia sotto forma di utilità che funzionano secondo i meccanismi sopra descritti (flowprobe, softflowd), sia direttamente integrate nel kernel del sistema operativo (FreeBSD:, Linux:). Per i router software, il flusso delle statistiche del flusso di rete può essere ricevuto ed elaborato localmente sul router stesso o inviato tramite la rete (protocollo di trasferimento - su UDP) al dispositivo ricevente (collettore).

Il programma collector può raccogliere informazioni da molte fonti contemporaneamente, essendo in grado di distinguerne il traffico anche con spazi di indirizzi sovrapposti. Utilizzando strumenti aggiuntivi come nprobe, è anche possibile eseguire ulteriori aggregazioni di dati, biforcazione dei flussi o conversioni di protocollo, il che è importante quando si gestisce una rete ampia e distribuita con dozzine di router.

Le funzioni di esportazione di Netflow supportano i router di Cisco Systems, Mikrotik e alcuni altri. Funzionalità simili (con altri protocolli di esportazione) sono supportate da tutti i principali produttori di apparecchiature di rete.

Libpcap “fuori”

Complichiamo un po' il compito. Cosa succede se il tuo dispositivo di accesso è un router hardware di un altro produttore? Ad esempio, D-Link, ASUS, Trendnet, ecc. Molto probabilmente è impossibile installare su di esso un software aggiuntivo di acquisizione dati. In alternativa, hai un dispositivo di accesso intelligente, ma non è possibile configurarlo (non hai i diritti o è controllato dal tuo provider). In questo caso è possibile raccogliere informazioni sul traffico direttamente nel punto in cui il dispositivo di accesso incontra la rete interna, utilizzando strumenti “hardware” di copia dei pacchetti. In questo caso avrai sicuramente bisogno di un server separato con una scheda di rete dedicata per ricevere copie dei pacchetti Ethernet.
Il server deve utilizzare il meccanismo di raccolta dei pacchetti tramite il metodo libpcap sopra descritto, e il nostro compito è sottoporre all'ingresso della scheda di rete dedicata a questo scopo un flusso di dati identico a quello proveniente dal server di accesso. Per questo puoi usare:

Ethernet - hub: un dispositivo che inoltra semplicemente i pacchetti tra tutte le sue porte indiscriminatamente. Nelle realtà moderne, può essere trovato da qualche parte in un magazzino polveroso e l'utilizzo di questo metodo non è consigliabile: inaffidabile, a bassa velocità (non esistono hub con una velocità di 1 Gbit/s)
Ethernet: uno switch con la capacità di eseguire il mirroring (mirroring, porte SPAN. I moderni switch intelligenti (e costosi) consentono di copiare tutto il traffico (in entrata, in uscita, entrambi) di un'altra interfaccia fisica, VLAN, incluso remoto (RSPAN) su una specifica porta
Splitter hardware, che potrebbe richiedere l'installazione di due schede di rete invece di una da collezionare, e questa è in aggiunta a quella principale del sistema.

Naturalmente, puoi configurare una porta SPAN sul dispositivo di accesso stesso (router), se lo consente: Cisco Catalyst 6500, Cisco ASA. Ecco un esempio di tale configurazione per uno switch Cisco:
monitorare la sessione 1 sorgente vlan 100! da dove prendiamo i pacchi?
monitora la sessione 1 interfaccia di destinazione Gi6/3! dove emettiamo i pacchi?

SNMP

Cosa succede se non abbiamo un router sotto il nostro controllo, non vogliamo contattare netflow, non siamo interessati ai dettagli del traffico dei nostri utenti. Sono semplicemente collegati alla rete tramite uno switch gestito e dobbiamo solo stimare approssimativamente la quantità di traffico diretta a ciascuna delle sue porte. Come sapete, i dispositivi di rete supportano il controllo remoto e possono visualizzare i contatori dei pacchetti (byte) che passano attraverso le interfacce di rete. Per interrogarli sarebbe corretto utilizzare il protocollo standardizzato di gestione remota SNMP. Usandolo, puoi facilmente ottenere non solo i valori dei contatori specificati, ma anche altri parametri, come il nome e la descrizione dell'interfaccia, gli indirizzi MAC visibili attraverso di essa e altre informazioni utili. Questo viene fatto sia tramite utilità della riga di comando (snmpwalk), browser grafici SNMP, sia programmi di monitoraggio della rete più complessi (rrdtools, cactus, zabbix, whats up gold, ecc.). Tuttavia, questo metodo presenta due inconvenienti significativi:

Il blocco del traffico può essere effettuato solo disabilitando completamente l'interfaccia, utilizzando lo stesso SNMP
i contatori di traffico rilevati tramite SNMP si riferiscono alla somma delle lunghezze dei pacchetti Ethernet (unicast, broadcast e multicast separatamente), mentre il resto degli strumenti precedentemente descritti forniscono valori relativi ai pacchetti IP. Ciò crea una notevole discrepanza (soprattutto con i pacchetti brevi) a causa del sovraccarico causato dalla lunghezza dell'intestazione Ethernet (questo problema può essere tuttavia contrastato approssimativamente: L3_byte = L2_byte - L2_packets * 38).

VPN

Separatamente, vale la pena considerare il caso dell'accesso dell'utente alla rete stabilendo esplicitamente una connessione al server di accesso. Un classico esempio è il buon vecchio dial-up, il cui analogo nel mondo moderno sono i servizi di accesso remoto VPN (PPTP, PPPoE, L2TP, OpenVPN, IPSEC)

Il dispositivo di accesso non solo instrada il traffico IP dell'utente, ma funge anche da server VPN specializzato e termina i tunnel logici (spesso crittografati) all'interno dei quali viene trasmesso il traffico dell'utente.
Per tenere conto di tale traffico, è possibile utilizzare tutti gli strumenti sopra descritti (e sono particolarmente adatti per un'analisi approfondita per porte/protocolli), nonché meccanismi aggiuntivi che forniscono strumenti di controllo dell'accesso VPN. Innanzitutto parleremo del protocollo RADIUS. Il suo lavoro è un argomento piuttosto complesso. Menzioneremo brevemente che il controllo (autorizzazione) dell'accesso al server VPN (client RADIUS) è controllato da un'applicazione speciale (server RADIUS), che dispone di un database (file di testo, SQL, Active Directory) degli utenti consentiti con i loro attributi (restrizioni sulla velocità di connessione, indirizzi IP assegnati). Oltre al processo di autorizzazione, il client trasmette periodicamente al server messaggi di contabilità, informazioni sullo stato di ciascuna sessione VPN attualmente in esecuzione, inclusi i contatori di byte e pacchetti trasmessi.

Conclusione

Riuniamo insieme tutti i metodi per raccogliere informazioni sul traffico sopra descritti:

Riassumiamo. In pratica, esistono numerosi metodi per connettere la rete che gestisci (con clienti o abbonati d'ufficio) a un'infrastruttura di rete esterna, utilizzando una serie di strumenti di accesso: router software e hardware, switch, server VPN. Tuttavia, quasi in ogni caso, è possibile elaborare uno schema in cui le informazioni sul traffico trasmesso sulla rete possono essere inviate a uno strumento software o hardware per la loro analisi e gestione. È anche possibile che questo strumento consenta un feedback al dispositivo di accesso, utilizzando algoritmi intelligenti di restrizione dell'accesso per singoli client, protocolli e altre cose.
Qui finirò l'analisi del materiale. Gli altri argomenti senza risposta sono:

come e dove vanno i dati sul traffico raccolti
software di contabilità del traffico
Qual è la differenza tra la fatturazione e un semplice “contatore”?
Come si possono imporre restrizioni al traffico?
contabilità e limitazione dei siti Web visitati

Questo è il primo articolo teorico di una serie di articoli dedicati alla raccolta, contabilità, gestione e fatturazione del traffico e delle risorse informatiche.