E' passato anche il 2017 ...

Carissimi lettori, come consuetudine ReissBlog durante il periodo Natalizio e l'inizio del nuovo anno va in vacanza.

ReissBlog è migrato sulla nuova piattaforma blogger di Google dal 15 Febbraio 2016. Nell’anno che sta terminando vi sono stati quasi 60.000 contatti, una media di più di 160 contatti giornalieri, sicuramente poca roba rispetto a molti altri blog, ma considerando che questo è un blog tecnico di un settore specifico, diretto a un pubblico prevalentemente Italiano, non posso che ritenermi soddisfatto.  

Come liberarsi dalla "sindrome del cavo giallo" - Parte II

Nella prima parte di questo post, disponibile a questo link, ho esposto alcune idee elementari su come sia possibile, con un po' di astuzia, eliminare il forwarding di Livello 2, senza toccare il "sacro graal" dell'implementazione corrente dello stack TCP/IP nei Sistemi Operativi, che sembra essere un tabù inattaccabile.

Come liberarsi dalla "sindrome del cavo giallo" - Parte I

Nell'ultimo post prima della vacanze, diviso in due parti che potete trovare qui e qui, ho lanciato un messaggio un po' provocatorio circa l'utilizzo di Ethernet come strumento di forwarding del traffico, secondo me una prassi che ha creato e crea tanti problemi e di cui si poteva fare a meno. Il forwarding, secondo i canoni classici del modello di riferimento ISO/OSI, come ho ampiamente argomentato nel post precedente, dovrebbe essere svolto dal Livello 3 (oggi sostanzialmente il protocollo IP) e non dal Livello 2.

Il Livello 2: ne abbiamo realmente bisogno ? - Parte II

Nella prima parte di questo post, a dire il vero un po' "provocatorio", ho cercato di illustrare alcune mie idee  (non solo mie per la verità, ma anche di altri networker, molto più illustri del sottoscritto) sull'opportunità di utilizzare il Livello 2 nelle reti IP, in particolare di utilizzare le reti Switched Ethernet. Prima di leggere questa seconda parte, vi invito quindi a leggere la prima parte, che trovate a questo link.

Il Livello 2: ne abbiamo realmente bisogno ? - Parte I

Dopo una lunga pausa dovuta a pressanti impegni di lavoro, ritorno a scrivere un post, il primo di una serie, e l'ultimo prima delle vacanze estive.

L'argomento riguarda il Livello 2, in particolare il Livello 2 Ethernet. Degli altri protocolli di Livello 2 non parlerò perché o obsoleti (vedi ATM e Frame Relay) o perché, anche se attualmente utilizzati, vi è poco da dire (es. PPP).

Sincronizzazione IGP-LDP nelle reti IP/MPLS

In un post precedente pubblicato su questo blog, ho mostrato come la continuità  dei LSP MPLS PE-PE sia un aspetto chiave nel funzionamento dei più importanti servizi MPLS (es. L3VPN, L2VPN, 6PE, 6VPE, ecc.), illustrando come una intelligente estensione di due strumenti arcinoti come ping e traceroute, consenta di individuare se un LSP MPLS è continuo ed eventualmente determinare il punto di interruzione.

Troubleshooting del piano dati MPLS: ping e traceroute MPLS

La continuità dei LSP MPLS PE-PE è un aspetto chiave nel funzionamento dei più importanti servizi MPLS. Come noto infatti, tutti questi servizi (es. L3VPN, L2VPN, 6PE, 6VPE, ecc.) hanno un denominatore comune, utilizzano sul piano dati più etichette MPLS.

Back to the Future: Data Center TCP (DCTCP)

E' stupefacente che un protocollo come il TCP, nato nel lontano 1973, sia ancora oggi oggetto di studi e ricerche e proposte di miglioramento. Il TCP è il protocollo di trasporto più utilizzato nell'Internet. Si stima che più del 95% del traffico IP mondiale utilizzi a livello di trasporto il TCP, e la percentuale sale addirittura al 99% nei moderni Data Center. 

Piattaforme per migliorare la QoE: Transparent Caching - II

PREMESSA: questo post è il seguito del post con identico titolo che potete trovare a questo link. Come il primo, è stato scritto a due mani, dal sottoscritto e dal mio amico Gianfranco Ciccarella, ex-Top Manager Telecom Italia, per anni alla guida della rete di Telecom Italia Sparkle e quindi delle Strategie per l'implementazione della NGAN in Telecom Italia. Chiediamo perdono in anticipo per le (piccole e semplici) derivazioni analitiche, ma siamo stati colti entrambi da una sorta di "Sindrome di Peter Pan" ...

UN PARAMETRO FONDAMENTALE: IL CACHE HIT RATIO

Una piattaforma di Transparent Caching, come è facile immaginare, svolge il suo lavoro al meglio, quanto più è alta la probabilità che la richiesta di un end user sia per un contenuto già presente nella memoria (cache) della piattaforma. Questa probabilità è un parametro fondamentale nella valutazione delle prestazioni della piattaforma, è ed nota come Cache Hit Ratio, abbreviato da qui in poi semplicemente come Hit Ratio (HR).

OpenContrail Case Study: interconnessione Cloud privato e L3VPN BGP/MPLS

PREMESSA: Questo post riflette le idee dell'autore e non vuole essere in alcun modo un veicolo di propaganda di quanto esposto. Per la scrittura di questo post, del precedente e dei successivi sull'argomento, né io personalmente, né la società di cui faccio parte, abbiamo ricevuto alcunché da Juniper Networks.

In un post precedente ho introdotto l'architettura di OpenContrail e le sue componenti fondamentali. Una delle applicazioni più importanti di soluzioni SDN come OpenContrail, è l’accesso da remoto a un Cloud privato. I Cloud Service Provider offrono una varietà di servizi di questo tipo: Infrastructure as a Service (IaaS), Platform as Service (PaaS), o Software as a Service (SaaS). O, mettendo tutto insieme, XaaS. Gli ISP tradizionali possono offrire l'accesso da remoto a questi servizi, ai loro Clienti che hanno servizi L3VPN/L2VPN sulla loro rete.

Piattaforme per migliorare la QoE: Transparent Caching - I

PREMESSA: questo post, il primo di due, è stato scritto a due mani, dal sottoscritto e dal mio amico Gianfranco Ciccarella, ex-Top Manager Telecom Italia, per anni alla guida della rete di Telecom Italia Sparkle e quindi delle Strategie per l'implementazione della NGAN in Telecom Italia.

In un post precedente, scritto per far chiarezza sulla differenza tra Banda e Throughput, sono stati accennati possibili metodi per aumentare il Throughput, citando le piattaforme di Transparent caching (per inciso il post precedente è stato il più letto di questo blog, superando le 1.100 visualizzazioni). In questo post cercheremo, il plurale è d'obbligo poiché come citato nella premessa il post è stato scritto a due mani, di illustrare i vantaggi che si ottengono dall'introduzione di piattaforme di Transparent Caching, sia in termini di prestazioni che economici.

Overlay Virtual Networking con OpenContrail

PREMESSA: Questo post riflette le idee dell'autore e non vuole essere in alcun modo un veicolo di propaganda di quanto esposto. Per la scrittura di questo post e per i successivi sull'argomento, né io personalmente né la società di cui faccio parte abbiamo ricevuto alcunché da Juniper Networks.

Il concetto di Overlay Virtual Network (OVN), benché non nuovo (ricordatevi sempre della RFC 1925, sez. 11), è la nuova tendenza nella realizzazione di Data Center, soprattutto di grandi dimensioni. I nuovi standard come VXLAN ed EVPN, trattati ampiamente in questo blog, costituiscono rispettivamente il braccio (= piano dati) e la mente (= piano di controllo) delle OVN.