La seconda edizione del libro "BGP: dalla teoria alla pratica"

Sono passati 11 anni esatti dall'uscita della prima edizione del mio libro "BGP: dalla teoria alla pratica", e dopo 11 anni c'era bisogno di un "tagliando". 

Il BGP benché un protocollo datato (è nato nel lontano 1989), come direbbe Guccini "sembra quasi cosa viva". Negli ultimi 11 anni sono state introdotte molte novità e quindi era giusto mettersi di nuovo al lavoro per aggiornare "la cosa viva". Essendo ormai sulla soglia di consegnare i miei neuroni al riposo, ho chiesto ai miei cari amici, Antonio Prado - CTO SBTAP e Flavio Luciani - CTO Namex, due illustri esperti della materia, di darmi una mano.

Nòio... volevàm... volevòn savuàr... l'indirìss… di Facebook (di Antonio PRADO)

Carissimi lettori di ReissBlog,

è da molto tempo che ho trascurato questo blog, ma ho intenzione prima o poi di ricominciare a tediarvi con le mie "pippe mentali".

Questa volta però non ho saputo resistere a condividervi questo breve fantastico "saggio" scritto dal mio carissimo amico Antonio Prado, sull'ormai "epic fail" di Facebook/Instagram/Whatsapp del giorno di San Francesco (mi piace pensare che sia stato lui a volerci inviare un chiaro messaggio...).

Il nuovo libro "Servizi MPLS"

Dopo 17 anni dall'uscita della prima edizione, finalmente, grazie al mio nuovo datore di lavoro (l'INPS) che mi lascia un po' di tempo a disposizione, ho completato la nuova edizione del libro su MPLS. Il titolo è cambiato in "Servizi MPLS" perché la focalizzazione, oltre che sulle basi dello standard ormai ampiamente collaudate, è soprattutto sui servizi che è possibile offrire complementando le reti IP con MPLS.

DNSSEC: una guida ragionata all’implementazione - Parte IV (ultima)

Con questo post si conclude la serie dedicata a DNSSEC a cura dal mio amico brillante e appassionato networker Antonio PRADO. Colgo l'occasione per ringraziare Antonio per il suo prezioso contribuito su un  argomento di grande interesse, testimoniato dal gran numero di visualizzazioni.  

La prime tre parti del post le trovate qui, qui e qui.

Il ruolo dei risolutori ricorsivi

Scegliamo un risolutore come si deve. Innanzitutto dobbiamo comprendere che non tutti i risolutori sono uguali: ci sono quelli che rispondono solo per ciò che sanno in prima persona; quelli che non sanno nulla e chiedono tutto ad altri; quelli che hanno alcune informazioni di prima mano ma per tutto il resto si affidano alla misericordia di name server terzi. In questi ultimi due casi, ça va sans dire, l’atto di fede è essenziale, cioè dobbiamo fidarci delle risposte altrui (per non scoperchiare poi il vaso di Pandora contenente i temi privacy e raccolta dei dati delle interrogazioni fatte dai name server). 

DNSSEC: una guida ragionata all’implementazione - Parte III

Reissblog riprende la saga su DNSSEC, scritta dal mio amico Antonio PRADO, brillante e appassionato networker, con grande esperienza teorica e pratica maturata su reti in produzione. Antonio è un personaggio ben conosciuto nell'ambiente, ha un suo blog, collabora con molti enti internazionali (es. MANRS), è l'autore della collana "Internet per le Nonne", insieme a Max Stucchi è l'animatore di ITNOG-on-the-Web, e molto altro.

La prime due parti del post le trovate qui e qui.

La collaborazione tra NSD e OpenDNSSEC

Abbiamo ora tutte le carte in regola per comunicare al mondo della grande Rete che il nostro nome a dominio è incatenato a un àncora che garantisce la veridicità delle informazioni.

DNSSEC: una guida ragionata all’implementazione - Parte II

Reissblog riprende dopo la pausa estiva. Sempre con "viva e vibrante soddisfazione" ospito la seconda parte di un lungo post su DNSSEC, scritto dal mio amico Antonio PRADO, brillante e appassionato networker, con grande esperienza teorica e pratica maturata su reti in produzione. Antonio è un personaggio ben conosciuto nell'ambiente, ha un suo blog, collabora con molti enti internazionali (es. MANRS), è l'autore della collana "Internet per le Nonne", insieme a Max Stucchi è l'animatore di ITNOG-on-the-Web, e molto altro.

La prima parte del post la trovate qui.

Dalla teoria alla pratica ...

Se è chiara la teoria, passiamo alla pratica. Non navigheremo tutti i rivoli nei quali si ramifica il processo decisionale che conduce alla progettazione prima, alla scelta poi degli strumenti, alla finale configurazione di una infrastruttura di risoluzione dei nomi, poiché al di là delle finalità di questo documento.

DNSSEC: una guida ragionata all’implementazione - Parte I

Ultimamente confesso, sono stato un po' "lazzarone". Preso dalla revisione del mio libro "Servizi MPLS", che dovrebbe andare in stampa il prossimo Ottobre, e dai tanti impegni didattici (online), ho trascurato un po' il blog. Ho così colto l'occasione per chiedere a qualche amico di tenerlo vivo con qualche post di interesse per la comunità.

Questa volta, sempre con "viva e vibrante soddisfazione" ospito la prima parte di un post su DNSSEC, scritto dal mio amico Antonio PRADO, brillante e appassionato networker, con grande esperienza teorica e pratica maturata su reti in produzione. Antonio è un personaggio ben conosciuto nell'ambiente, ha un suo blog, collabora con molti enti internazionali (es. MANRS), è l'autore della collana "Internet per le Nonne", insieme a Max Stucchi è l'animatore di ITNOG-on-the-Web, e molto altro.

********************
INTRODUZIONE
La fiducia prima di tutto: anni a conquistarla, attimi a perderla. Così pure su Internet, i rapporti fiduciari stretti volontariamente intrecciano il tessuto della grande Rete e consentono lo sviluppo di servizi sempre più affidabili.

Seamless MPLS e “piccole variazioni sul tema” – parte II

Questa è la seconda parte del post su Seamless MPLS scritto dal mio amico Marco SERRA, brillante e appassionato networker, con grande esperienza teorica e pratica su MPLS e dintorni, maturata su reti in produzione. La prima parte la trovate qui.

*************

Ben ritrovati su Reissblog.

Nel post precedente ho parlato di reti di grandi dimensioni e descritto una soluzione per progettare un’infrastruttura di rete a pacchetto molto scalabile, nota come Seamless MPLS. È l’ora di passare dalla teoria alla pratica.  Ogni tanto però mi dovete concedere qualche richiamo teorico, anche per giustificare le configurazioni di router che di seguito troverete.

BGP RPKI: instructions for use (English Version)

As announced recently, “On March 25th, 2020, NTT GIN will deploy BGP routing policies which reject RPKI Invalid BGP route announcements on all AS 2914 EBGP sessions. This change will positively impact the Internet routing system.”

NTT GIN will therefore join the “reject Invalids” club which has, among its members with dimensions comparable to NTT GIN, AT&T (AS 7018), Cloudflare (AS 13335), Cogent (AS 174), KPN (AS 286), PCCW (AS 3491), Tata (AS 6453), Telia (AS 1299). Many others are doing plans to join the club (see for instance this link).

Per un'Internet più sicura: l'architettura BGP RPKI - parte III (pratica)

PREMESSA: questo è l'ultimo di tre post scritti congiuntamente dal sottoscritto e da Flavio Luciani, Chief Innovation Officer di NaMeX, che ringrazio per la sua disponibilità a collaborare a questo blog. Prima di leggere questo post è consigliabile leggere i due precedenti, il primo lo trovate qui, mentre il secondo qui.

Dopo aver visto i principali elementi dell'architettura RPKI e il suo funzionamento di base, è ora di mettere in pratica quanto detto. Illustreremo in questo post l'implementazione RPKI sia in ambiente Cisco (IOS XE) che Juniper (JUNOS).

Seamless MPLS e “piccole variazioni sul tema” – parte I

È con "viva e vibrante soddisfazione" che ReissBlog ospita questo post, scritto dal mio amico Marco SERRA, brillante e appassionato networker, con grande esperienza teorica e pratica su MPLS e dintorni, maturata su reti in produzione. 

*************

PREMESSA

Lo standard MPLS a partire dal suo esordio ha avuto un successo indiscutibile che continua nel tempo. È stato inizialmente adottato da Carrier e Service Provider, ma il suo utilizzo ha interessato, e ad oggi interessa, anche le reti Enterprise. 

Per un'Internet più sicura: l'architettura BGP RPKI - parte II (teoria)

PREMESSA: questo è il secondo di tre post scritti congiuntamente dal sottoscritto e da Flavio Luciani, Chief Innovation Officer di NaMeX, che ringrazio per la sua disponibilità a collaborare a questo blog. Prima di leggere questo post è consigliabile leggere il primo, che trovate a qui. 

L'ARCHITETTURA BGP RPKI: SCHEMA A BLOCCHI

L’architettura BGP RPKI, il cui schema a blocchi è riportato nella figura seguente, è basata su dei database (RPKI repository), dove sono contenute le informazioni sui ROA, informazioni che possono essere immesse direttamente dai RIR o anche dai NIR/LIR/ISP (verificate comunque dai RIR) attraverso un particolare Publication Protocol. Di solito per questo i RIR mettono a disposizione delle interfacce web semplificate, che consentono di nascondere agli end user tutte le complessità legate ai Certificati Digitali, focalizzando l’attenzione sulla sola creazione e pubblicazione dei ROA.

Per un'Internet più sicura: l'architettura BGP RPKI - parte I

PREMESSA: questo è il primo di tre post scritti congiuntamente dal sottoscritto e da Flavio Luciani, Chief Innovation Officer di NaMeX, che ringrazio per la sua disponibilità a collaborare a questo blog.

Qualsiasi trattazione di aspetti di sicurezza, non può non iniziare con una illustrazione dei possibili tipi di attacco e una analisi delle vulnerabilità. È chiaro che l’intera Internet è vulnerabile ad attacchi ai suoi protocolli di routing. Il BGP, da questo punto di vista non fa eccezione, ed essendo sicuramente il protocollo più importante, è quello su cui focalizzare maggiormente l’attenzione in termini di protezione. 

VXLAN + EVPN: lab test in ambiente Cisco Nexus - Parte III - Interconnessione DC-L3VPN (segue dalla puntata precedente)

In questo post precedente ho illustrato gli aspetti architetturali dell'interconnessione di un Data Center con una rete IP/MPLS esterna dove è realizzato un servizio L3VPN con siti dispersi geograficamente e appartenenti a un determinato tenant. In questo post, che è il seguito del precedente, illustrerò un Case Study su una rete di laboratorio. 

VXLAN + EVPN: lab test in ambiente Cisco Nexus - Parte III - Interconnessione DC-L3VPN

Questo post è il seguito dei due precedenti "VXLAN + EVPN: lab test in ambiente Cisco Nexus - Parte I e Parte II" che potete trovare a questo link (Parte I) e a questo link (Parte II).

In questo post illustrerò come interconnettere un tenant di un Data Center con una L3VPN esterna, sempre dello stesso tenant. Poiché il post è molto lungo sarà diviso in due parti.

VXLAN + EVPN: lab test in ambiente Cisco Nexus - Parte II

Questo post è il seguito di un post precedente che potete trovare a questo link. E il terzo, non ultimo, di una serie di lab test che dimostrano la fattibilità dell'implementazione di Overlay Virtual Networks realizzate attraverso lo standard VXLAN.

VXLAN + EVPN: lab test in ambiente Cisco Nexus - Parte I

In questo post precedente ho mostrato come realizzare segmenti VXLAN su una rete costituita da switch Cisco Nexus, che non utilizza alcun piano di controllo, ma solo un protocollo di routing IP multicast nella IP Fabric. La costruzione delle mappe MAC-to-VTEP avviene in questo caso interamente sul piano dati (VXLAN Flood & Learn), senza ausilio alcuno di un piano di controllo.

In questo post vedremo invece come realizzare segmenti VXLAN utilizzando un piano di controllo, che come visto in vari post di questo blog, è il protocollo EVPN, ampiamente trattato in post precedenti. La rete test è costituita anche in questo caso da switch Cisco Nexus della serie 9000.

VXLAN Flood & Learn: lab test in ambiente Cisco Nexus

Circa un paio di anni fa, in questo post sull'evoluzione del piano di controllo delle VXLAN, avevo illustrato un breve test di laboratorio utilizzando router Cisco (virtuali) CSR1000v, con la promessa che appena avessi avuto la possibilità di replicarlo in ambiente Cisco Nexus, lo avrei condiviso. Il test di laboratorio riguardava l'utilizzo di VXLAN senza un piano di controllo, con il MAC learning che avviene interamente sul piano dati utilizzando all'interno della IP Fabric un protocollo di routing multicast (VXLAN Flood & Learn).

OSPF negli switch Nexus: attenti al loop ...

Quando si dice "il diavolo si nasconde nei dettagli ...". Mi è capitato di recente, in una consulenza presso una grande azienda Enterprise, un problema che mi ha fatto riflettere e capire che non si finisce mai di imparare. Lo riporto in questo post perché il problema riguarda un aspetto dell'implementazione di OSPF negli switch Cisco della serie Nexus, tra i più utilizzati nei Data Center e non solo. 

Libro su IS-IS e Auguri

Cari Lettori del Blog,

è da un po' di tempo che non scrivo più le mie "balle". Progetti complessi da concludere entro la fine dell'anno mi hanno impedito di continuare a "tediarvi". Spero di riprendere l'anno prossimo, dove ho in animo di approfondire vari aspetti legati, anche pratici, legati alle nuove tecnologie di Networking dei Data Center, in particolare delle implementazioni di VXLAN con EVPN come piano di controllo, e della sicurezza del protocollo BGP, che come sapete è un mio pallino.