Oracle 21 su Docker

Mi serve una installazione Oracle sul mio Linux Ubuntu 22.04. Dai vari link vedo che c’è qualche difficoltà a trovare pacchetti di installazionde diversi da distribuzioni Suse e RedHat. Per cui decido di utlizzare un container Docker al fine di sorpassare questi problemi di compatibilità, per lo sviluppo può andare più che bene.

Ho trovato un aiuto nel link citato nei Riferimenti

Download dell’immagine

Scarico l’express edition:

$ docker pull container-registry.oracle.com/database/express:21.3.0-xe

21.3.0-xe: Pulling from database/express
2318ff572021: Pull complete 
c6250726c822: Pull complete 
33ac5ea7f7dd: Pull complete 
753e0fae7e64: Pull complete 
Digest: sha256:dcf137aab02d5644aaf9299aae736e4429f9bfdf860676ff398a1458ab8d23f2
Status: Downloaded newer image for container-registry.oracle.com/database/express:21.3.0-xe

Sono all’incirca 3 GB.

Creo il container e lo avvio (attenzione che con l’istruzione di creazione definisco la password di system!):

$ docker container create -it --name oracle-devel -p 1521:1521 -e ORACLE_PWD=welcome123 container-registry.oracle.com/database/express:21.3.0-xe 
5640b42ae4387deffad2594fb0f9a391e13a53ed8e9bc8cc87cf17e41e445be2

$ docker ps -a
CONTAINER ID   IMAGE                                                      COMMAND                  CREATED              STATUS    PORTS     NAMES
5640b42ae438   container-registry.oracle.com/database/express:21.3.0-xe   "/bin/bash -c $ORACL…"   About a minute ago   Created             oracle-devel

$ docker start oracle-devel
oracle-devel

$ docker ps -a
CONTAINER ID   IMAGE                                                      COMMAND                  CREATED         STATUS                            PORTS                                       NAMES
5640b42ae438   container-registry.oracle.com/database/express:21.3.0-xe   "/bin/bash -c $ORACL…"   2 minutes ago   Up 2 seconds (health: starting)   0.0.0.0:1521->1521/tcp, :::1521->1521/tcp   oracle-devel

Alla fine mi connetto con Sqldeveloper in localhost specificando

  • nome utente: system
  • password
  • nome host: localhost
  • porta host: 1521
  • SID: xe

La connessione funziona (Stato: operazione riuscita):

Oracle XE Docker connection success
Oracle XE Docker connection success

Riferimenti

Algoritmi di crittografia con SSH

ssh
ssh

Da tempo non accedevo via ssh ad un server di un mio cliente, è successo questo:

$ ssh user@myhost.com
Unable to negotiate with <some IP adddress> port 22: no matching key exchange method found. Their offer: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1

Il problema si chiama key exchange method, metodo di scambio delle chiavi. Ho controllato quali erano i metodi disponibili in locale con:

$ ssh -Q kex
diffie-hellman-group1-sha1
diffie-hellman-group14-sha1
diffie-hellman-group14-sha256
diffie-hellman-group16-sha512
diffie-hellman-group18-sha512
diffie-hellman-group-exchange-sha1
diffie-hellman-group-exchange-sha256
ecdh-sha2-nistp256
ecdh-sha2-nistp384
ecdh-sha2-nistp521
curve25519-sha256
curve25519-sha256@libssh.org

Mi pare ce ne siano parecchi. Ne scelgo uno:

$ ssh -oKexAlgorithms=diffie-hellman-group1-sha1 user@myhost.com
Unable to negotiate with <some IP adddress> port 22: no matching host key type found. Their offer: ssh-rsa,ssh-dss

Il problema si sposta, adesso si chiama host key type (tipo di chiave host), allora aggiungo anche l’altro parametro:

$ ssh -oKexAlgorithms=diffie-hellman-group1-sha1 -oHostKeyAlgorithms=ssh-rsa user@myhost.com
The authenticity of host 'myhost.com (<some IP adddress>)' can't be established.
RSA key fingerprint is SHA256:QrIQ15WsEr48UvcEE9cLJhoj7ilRCTL3ghaRMYI2Ewg.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'myhost.com' (RSA) to the list of known hosts.
user@myhost.com's password: 
Last login: Tue Jan  9 11:54:48 2024 from <some other IP address>
-bash-3.2$

L’ultimo problema (server authenticity) era la firma RSA dell’host che non era tra i miei host conosciuti (con questo PC in effetti era la prima volta che mi connettevo).

Cos’è successo al mio client SSH?

Al client SSH ovviamente non è successo nulla: i tre problemi sono di natura diversa. L’ultimo (il problema della firma o fingerprint) l’ho già spiegato.

Vediamo cosa sono gli altri due.

I parametri HostKeyAlgorithms e KexAlgorithms sono entrambi utilizzati per specificare gli algoritmi crittografici utilizzati durante la fase di negoziazione di una connessione SSH. Tuttavia, hanno scopi leggermente diversi:

  1. HostKeyAlgorithms:
    Questo parametro specifica gli algoritmi utilizzati per generare e verificare le chiavi pubbliche degli host. Quando un client si connette a un server SSH per la prima volta, il server invia la sua chiave pubblica al client. Il client verifica quindi questa chiave pubblica confrontandola con una copia locale. Se le chiavi pubbliche non corrispondono, potrebbe esserci un attacco man-in-the-middle in corso. Gli algoritmi elencati in HostKeyAlgorithms specificano quali algoritmi il client accetterà per la chiave pubblica del server.
  2. KexAlgorithms:
    Questo parametro specifica gli algoritmi utilizzati per lo scambio delle chiavi segrete durante la fase di negoziazione della chiave di sessione. Questa fase è cruciale per garantire che le comunicazioni tra client e server siano protette da crittografia. Gli algoritmi elencati in KexAlgorithms specificano quali algoritmi il client è disposto ad utilizzare per lo scambio delle chiavi durante la connessione SSH.

Entrambi i parametri sono importanti per garantire la sicurezza e la compatibilità delle connessioni SSH. È possibile configurarli in modo da includere solo gli algoritmi più sicuri e recenti supportati da entrambe le parti, evitando quelli considerati obsoleti o vulnerabili. Tuttavia, è importante anche assicurarsi che l’algoritmo specificato sia supportato sia dal client che dal server per evitare errori di compatibilità, come quelli che ho riscontrato.

È infatti importante che il client e il server abbiano almeno un algoritmo in comune per poter stabilire una connessione sicura.

Da quanto detto è chiaro che esistono due fasi nella transazione:

  • l’invio della chiave pubblica dell’host
  • lo scambio di una chiave segreta per cifrare la sessione

Vediamo con un po’ più di dettaglio la fase di negoziazione.

Come si stabilisce una connessione sicura tra client e server con SSH

Una connessione SSH (Secure Shell) coinvolge diverse fasi per stabilire una comunicazione sicura e autenticata tra un client e un server remoto. Ecco le fasi principali di una connessione SSH:

  1. Inizializzazione della connessione: Il client SSH inizia la connessione al server SSH specificando l’host a cui desidera connettersi e autenticandosi, se necessario.
  2. Negoziazione delle chiavi crittografiche: Il client e il server SSH si scambiano informazioni sulle chiavi crittografiche supportate e selezionano una chiave per la sessione corrente.
  3. Scambio delle chiavi pubbliche: Il server invia la sua chiave pubblica al client per consentire al client di autenticare l’identità del server.
  4. Verifica dell’identità del server: Il client verifica che la chiave pubblica ricevuta dal server corrisponda a quella memorizzata localmente per il server a cui si sta connettendo.
  5. Generazione della chiave di sessione: Una volta che l’identità del server è stata verificata, client e server generano una chiave di sessione condivisa per crittografare i dati scambiati durante la connessione.
  6. Autenticazione: Se richiesta, il client si autentica con il server utilizzando password, chiavi SSH o altri metodi di autenticazione supportati.
  7. Stabilimento della connessione sicura: Una volta completate le fasi precedenti con successo, la connessione SSH è stabilita in modo sicuro e i dati trasmessi tra client e server sono crittografati per garantire la riservatezza e l’integrità.
  8. Interazione con il server: Una volta stabilita la connessione, il client può interagire con il server SSH per eseguire comandi remoti, trasferire file in modo sicuro o utilizzare altre funzionalità offerte dal protocollo SSH.

Il punto cruciale è il punto 5. Qui si decide la chiave da utilizzare da qui in avanti per cifrare il contenuto dei messaggi per questa sessione. Fino al punto 5 infatti la trasmissione avviene in chiaro. Del resto lo scambio della chiave pubblica dal server al client non è un segreto: è pubblica! Per il calcolo della chiave di sessione, che è una chiave simmetrica, di solito vengono utilizzati algoritmi di scambio di chiavi come il Diffie-Hellman o il suo derivato Elliptic Curve Diffie-Hellman (ECDH). Questi algoritmi consentono a client e server di concordare in modo sicuro una chiave di sessione condivisa senza dover trasmettere in chiaro la chiave attraverso la rete, garantendo così la riservatezza della chiave simmetrica. Una volta che la chiave di sessione è generata utilizzando l’algoritmo di scambio di chiavi concordato, viene utilizzata per crittografare i dati scambiati durante la connessione SSH. L’algortimo da usare per calcolare la chiave è esattamente quello indicato con i due parametri visti sopra.

il parametro KexAlgorithms viene utilizzato per specificare gli algoritmi di scambio di chiavi (key exchange algorithms) che possono essere utilizzati per stabilire una connessione sicura tra il client e il server. Questi algoritmi sono utilizzati per generare la chiave di sessione condivisa, che è una chiave simmetrica utilizzata per crittografare i dati scambiati durante la connessione SSH.

D’altra parte, l’opzione HostKeyAlgorithms specifica gli algoritmi di chiave pubblica che il server accetta per autenticarsi durante la procedura di handshake iniziale. Questi algoritmi sono utilizzati per verificare l’identità del server e stabilire una connessione sicura con esso.

Quindi, per generare la chiave simmetrica durante una connessione SSH, sono importanti sia gli algoritmi di scambio di chiavi specificati con KexAlgorithms che gli algoritmi di chiave pubblica specificati con HostKeyAlgorithms. Entrambi giocano un ruolo cruciale nella sicurezza e nell’efficienza della connessione SSH.

Diciamo, in ultima analisi, che

  • HostKeyAlgorithms serve per stabilire quale algoritmo di chiave pubblica asimmetrica verrà usato per scambiarsi la chiave simmetrica di sessione.
  • KexAlgorithms serve per stabilire quale algoritmo di chiave simmetrica verrà usato per generare la chiave (simmetrica) di sessione.

Dunque

  1. prima si calcola la chiave simmetrica con l’algoritmo concordato con KexAlgorithms (nel mio caso: diffie-hellman-group1-sha) e
  2. poi il client invia al server la chiave di sessione, dopo averla cifrata con l’agoritmo di chiave asimmetrica concordato con HostKeyAlgorithms (nel mio caso ssh-rsa) che utilizza la chiave pubblica del server.
  3. Alla fine il server è in grado di confontare che la chiave simmetrica calcolata da lui è uguale a quella calcolata dal client e cifrata con la sua chiave pubblica. Questo consente al server di autenticare il client.

Fonti

È stato divertente cercare di capire l’argomento utilizzando tre sistemi di AI: ChatGpt, Aria (Opera) e Skype/Bing.

Ci sono arrivato per interpolazione e verificando su siti attendibili come ssh.com, nessuno spiegava veramente bene come funziona il tutto, ma si avvicinava comunque alla realtà.

Poi… sono cose studiate tanti anni fa e un ripassino è sempre utile.

gRPC e Protocol Buffers: una introduzione.

gRPC è una tecnologia nata in Google che astrae il concetto di classe immergendolo in quello di cloud: supponiamo che il nostro progetto locale sfrutti una classe Figura che realizza una figura piana della geometria.

Chi l’ha detto che la classe debba trovarsi sullo stesso PC in cui stiamo sviluppando il nostro progetto?

Protocol Buffers è una tecnologia open source di Google che implementa questa architettura: istanziare nel nostro ambiente local un oggetto (stub) definito altrove:

gRPC architecture
gRPC architecture

gRPC è stato inizialmente creato da Google, che da oltre un decennio utilizza un’unica infrastruttura RPC generica chiamata Stubby per connettere il gran numero di microservizi in esecuzione all’interno e attraverso i suoi data center. Nel marzo 2015, Google ha deciso di creare una nuova versione di Stubby rendendola open source.

In gRPC, un’applicazione client può chiamare direttamente un metodo su un’applicazione server su un computer diverso come se fosse un oggetto locale, semplificando la creazione di applicazioni e servizi distribuiti. Come in molti sistemi RPC, gRPC si basa sull’idea di definire un servizio, specificando i metodi che possono essere chiamati da remoto con i relativi parametri e tipi di ritorno. Sul lato server, il server implementa questa interfaccia ed esegue un server gRPC per gestire le chiamate client. Dal lato client, il client ha uno stub (indicato semplicemente come client in alcuni linguaggi) che fornisce gli stessi metodi del server.

I client e i server gRPC possono essere eseguiti e comunicare tra loro in una varietà di ambienti, dai server interni a Google al desktop, e possono essere scritti in qualsiasi linguaggio supportato da gRPC. Quindi, ad esempio, puoi creare facilmente un server gRPC in Java con client in Go, Python o Ruby. Inoltre, le ultime API di Google disporranno di versioni gRPC delle rispettive interfacce, consentendoti di integrare facilmente le funzionalità Google nelle tue applicazioni.

Lavorare con i protocol buffer (PB) di gRPC

Si parte dalla definizione del messaggio che può essere un file JSON o più convenientemente un file di tipo proto (per protocol), per esempio questo potrebbe essere il contenuto del file message.proto:

message Person {
  string name = 1;
  int32 id = 2;
  bool has_ponycopter = 3;
}

Nota che 1, 2 e 3 sono i segnaposto, non sono assegnazioni.

Quindi, una volta specificate le strutture dati, si utilizza il compilatore del protocol buffer protocper generare classi di accesso ai dati nel linguaggio di programmazione scelto nella definizione del prototipo. Queste classi forniscono semplici metodi di accesso (get/set) per ciascun campo, come name()set_name(), nonché metodi per serializzare/analizzare l’intera struttura da/verso byte grezzi. Quindi, ad esempio, se il linguaggio scelto è C++, l’esecuzione del compilatore nell’esempio sopra genererà una classe chiamata Person. Puoi quindi utilizzare questa classe nella tua applicazione per popolare, serializzare e recuperare Personi messaggi del protocol buffer.

Oltre ai dati, nei file proto vengono definiti anche i servizi:

// The greeter service definition.
service Greeter {
  // Sends a greeting
  rpc SayHello (HelloRequest) returns (HelloReply) {}
}

// The request message containing the user's name.
message HelloRequest {
  string name = 1;
}

// The response message containing the greetings
message HelloReply {
  string message = 1;
}

Il comando protoc (compilatore) poi esegue la magia, convertendo i file .proto in classi nel linguaggio scelto per il progetto.

La versione 3 di PB (proto3) è disponibile nei seguenti linguaggi di programmazione:  Java, C++, Dart, Python, Objective-C, C#, un runtime lite (Android Java), Ruby e JavaScript. Anche PHP con l’adozione di un plugin.

Riferimenti

Port forwarding con Docker

La mappatura delle porte Docker, nota anche come port forwarding , è una tecnica utilizzata per esporre i servizi di rete – che sono in esecuzione all’interno di un contenitore Docker – verso l’host, verso altri contenitori Docker dello stesso host o verso altri host o dispositivi di rete.

Il port forwarding consente di mappare una porta specifica dal sistema host a una porta sul contenitore, rendendo il servizio accessibile dall’esterno del contenitore.

Quando si esegue un contenitore, in genere esiste un proprio spazio dei nomi di rete isolato con il proprio indirizzo IP (per questo, si veda il comando docker network). Per impostazione predefinita, i contenitori possono comunicare tra loro e con il sistema host, ma l’accesso alla rete esterna non è abilitato automaticamente. La mappatura delle porte viene utilizzata per creare la comunicazione tra la rete isolata del contenitore e la rete del sistema host.

La mappatura delle porte

Possiamo eseguire la mappatura delle porte in Docker in due modi: usando il Dockerfile e i comandi di docker, oppure con docker-compose.

Quando si esegue un contenitore con docker run.

Quando si utilizza il comando docker run, è possibile utilizzare il flag -p--publishper specificare la mappatura delle porte. La sintassi è la seguente: -p host_port:container_port. Ad esempio, per mappare:

  • la porta 3307 sull’host
  • alla porta 3306 all’interno del contenitore,

Quindi: -p 3307:3306. È possibile specificare più mappature di porte ripetendo il flag -p. Questo per esempio ci serve se nello stesso container vogliamo pubblicare un database, un web server Apache o un Tomcat.

# docker run - p 8080:80 myapp

Quando si utilizza docker compose:

Se si utilizza Docker Compose per gestire i contenitori, si può puoi definire la mappatura delle porte nel file di configuazione docker-compose.yml utilizzando la sezione portssezione. La sintassi è la stessa del comando docker run.

Nel mio caso ho un container che contiene un’applicazione PHP – Laravel e una che contiene il DBMS MySQL:

version: '3'

services:
  app:
    image: ap2mylaravel
    container_name: app
    networks:
      - my_network

  mysql_db_container:
    image: mysql_db
    container_name: app_db
    ports:
      - "3307:3306" # Mappa la porta 3306 del container sulla porta 3307 dell'host
    networks:
      - my_network

networks:
  my_network:
     driver: bridge

Il container che ospita MySQL si intende pubblicato sulla porta interna 3306 che, all’esterno dell’host, viene mappata sulla 3307 (per non confliggere con quella del MySQL che gira sull’host che è pubblicato sulla 3306).

Il comando

# docker-compose up

avvierà il contenitore con la mappatura della porta specificata.

Ho disegnato questo schema funzionale completo in cui si vede come vanno usati i comandi per collegarsi al container del db a partire dall’altro container, dall’host e anche da un computer remoto: si vedono i due container che giurano all’interno di Host, il container dedicato al dbms ascolta sulla porta 3306 e internamente a Host ed è questa la porta che va usata nei client (sia che si utilizzi il calinet in Host che nel container app.

Posso altresì accedere allo stesso db anche dall’esterno del host – un pc remoto – puntando alla porta 3307 e utilizzando l’indirizzo del netowk virtuale creato da docker che posso trovare digitanto docker network ls (posso verificare che l’interfaccia è proprio quella che si vede digitando il comando ifconfig).

È possibile configurare la rete (sia agendo a livello di configurazione docker che sulla configurazione di mysql) in modo tale da avere il livello di sicurezza che si vuole: per esempio ho fatto in modo che l’accesso al dbms come root sia possibile esclusivamente dall’interno del container app_db e che laravel possa accedere soltanto dal suo container (app) con un utente applicativo a cui sono stati concessi i soli privilegi di crud.

docker network layout
docker network layout

Riferimenti

Matematici della storia

Con GPT-3.5, Octave e un po’ di lavoro

matematici della storia
Matematici della storia (formato SVG)

Let’s go CERN 2024

CERN - Wandering the immeasurable
CERN – Wandering the immeasurable

Ho organizzato una visita al CERN di Ginevra venerdì 19 gennaio 2024, per l’Associazione Amici dello Zuccante di cui faccio parte, come ideale prosecuzione di una serie di appuntamenti dedicati alla Fisica.

L’anno scorso abbiamo visitato in due sessioni il Museo di Storia della Fisica Giovanni Poleni, dell’Università di Padova.

Quest’anno, nel periodo di stop per la manutenzione annuale, tutti i maggiori esperimenti erano aperti alle visite del pubblico e l’esperimento CMS (Compact Muon Solenoid) era quello che ci dava una maggiore disponibilità di posti. Ho sentito anche ALICE e ATLAS ma consentivano l’accesso solo a gruppi più esigui.

La visita si è articolata in più incontri: una visita tecnica all’esperimento CMS e una conversazione con la dott.ssa Barbara Rusconi, Financial Controller al CERN, che mi ha spiegato alcuni aspetti del finanziamento delle ricerche e dell’accesso all’istituzione. La visita del CERN si è conclusa al Science Gateway, un nuovo spazio dedicato alle esposizioni, alla didattica e alle conferenze.

La nostra guida all’esperimento CMS, un fisico e informatico che ha lavorato qui diversi anni durante il suo post-dottorato, il dott. Simone Bologna, ci ha illustrato l’esperimento assieme agli aspetti di computer science (che interessano parecchi noi che lavorano nell’informatica e/o l’hanno insegnata) e ha condotto la visita a CMS, spiegandoci più in dettaglio la struttura dell’esperimento.

LHC

Il Large Hadron Collider è un cosiddetto anello di accumulazione, o acceleratore, una infrastruttura che serve a spingere fasci di particelle quasi alla velocità della luce per essere poi impiegati in esperimenti di collisione, collisioni che avvengono fuori dall’anello, all’interno di macchine molto complesse dette detectors o rivelatori. Un rivelatore all’incirca coincide con un esperimento. CMS è uno di questi.

Point 5

Il sito al di sotto del quale si trova in profondità il detector CMS (denominato Point 5, vicino al paese di Cessy, Francia) ha una storia sbalorditiva. Gli scavi iniziarono, dopo l’approvazione del progetto da parte del CERN, nel 1999 e subirono immediatamente un colpo d’arresto: fu infatti rinvenuta dagli escavatori una casa di epoca romana, completa di vasellame, piastrelle e monete, che richiese un po’ di tempo agli archeologi per lo studio, la repertazione e la traslazione in altra area.

Dopodiché lo scavo subì un secondo arresto: ad un certo punto i carotaggi davano la presenza di una falda acquifera, un vero e proprio fiume sotterraneo che si rivelò profondo da 10 a 20 metri.

Il pozzo del Point 5 durate lo scavo
Il pozzo del Point 5 durate lo scavo (Fonte: CERN)

Per poter proseguire con lo scavo, la squadra ha dovuto prima congelare il terreno attorno ai due pozzi (si vedono nella foto: dovevano ospitare il pozzo per calare le apparecchiature e l’ascensore) per fungere da barriera per l’acqua. Praticando poi dei fori attorno alla circonferenza di ciascun albero e pompando la salamoia, raffreddata a -25°C, l’acqua si congelò andando a costituire una parete di ghiaccio di 3 metri. Ma l’acqua proveniente da Cessy si muoveva più velocemente del previsto e, in combinazione con l’effetto di incanalamento dell’acqua tra i due pozzi, la pressione aumentò fino a penetrare nelle pareti.

Si cominciò quindi a iniettare nei fori una sostanza ancora più fredda: l’azoto liquido, a una temperatura inferiore a -195°C, tecnica che finalmente risolse il problema. Con l’impiego dell’azoto liquido gli ingegneri formarono un muro di ghiaccio attorno ai pozzi che era sufficientemente solido da consentire alle squadre di continuare a perforare il terreno per continuare l’escavo del pozzo.

I problemi non erano finiti: la destinazione finale del sarcofago dell’esperimento si trovava in un volume di terriccio friabile (molassa) nel quale non era possibile costruire una caverna.

Poiché anche l’ambiente a 100 metri sotto la superficie è pieno d’acqua, le fasi finali hanno riguardato l’impermeabilizzazione, l’installazione di sistemi di drenaggio e la verniciatura della caverna, poiché altrimenti l’acqua potrebbe trasformare la roccia tenera in fango. “Una volta che tutto era a posto, abbiamo potuto sigillare la caverna con l’impermeabilizzazione e inserire un muro permanente di cemento spesso fino a 4 metri, rinforzato con barre d’acciaio” spiega John Osborne, project manager di ingegneria civile CMS. [11]

Questo racconto illustra quanto fondamentale sia l’ingegneria civile in questo tipo di realizzazioni. Indubbiamente… standing ovation per le imprese e le maestranze che hanno realizzato tutto questo!

Compact Muon Solenoid

L’esperimento CMS si trova 100 metri sotto il paese di Cessy (Francia): lo abbiamo raggiunto con un pullman privato per riuscire a minimizzare (e di parecchio) i tempi di percorrenza dalla reception Building 33 di Meyrin (Svizzera), dove c’è anche il Science Gateway di cui vi parlerò più avanti.

Logo CMS
Logo CMS

Molto brevemente, i detector o rivelatori sono macchine molto complesse all’interno delle quali vengono fatti scontrare frontalmente gruppi (bunch) di protoni e vengono seguite le traiettorie della miriade di particelle che si generano. I bunch provengono da due tubi sotto vuoto che circolano lungo la circonferenza di LHC, nei quali sono stati accelerati in direzioni opposte fino a portarli ad una velocità molto prossima alla velocità della luce (precisamente, il 99,999997 % di c).

Quindi immaginate un infrastruttura, l’acceleratore vero e proprio o anello di accumulazione che è LHC dal quale, on demand l’esperimento preleva due o più bunch in direzioni opposte per essere scontrati dentro al detector. LHC non fa circolare solo protoni. A volte (e l’utilizzatore principale ne è l’esperimento ATLAS) fa circolare ioni di piombo, ideali per produrre li cosiddetto plasma quark-gluone.

Sono le moderne evoluzioni dei primi detector: le camere a nebbia o a bolle; rispetto a queste, essi consentono una maggiore precisione nella misura e l’archiviazione digitale dei parametri che descrivono questi fenomeni (traiettorie, rapporto carica/massa, energia).

Il rivelatore CMS non è il più grande dei quattro esperimenti maggiori di LHC (con ALICE, ATLAS e LHCb) ma sicuramente il più massiccio (da qui l’aggettivo: Compact), con le sue 14000 T (quasi il doppio della Tour Eiffel), un concentrato di tecnologia con i suoi componenti: tracker, calorimetri EM, calorimetri adronici, magnete solenoidale superconduttore e il calorimetro muonico.

Vista in sezione di CMS
Vista in sezione di CMS

In sostanza il tubicino centrale che porta la corrente di protoni è la sede della collisione (qui dovete immaginare che questo tubo esca dallo schermo – è una sezione trasversale dell’esperimento); spostandoci via via radialmente verso l’esterno abbiamo

  • il tracker che è una pila di lamine al silicio, disposte attorno alla camera di collisione, analoghe ai CCD delle fotocamere: questo device consente di ricostruire esattamente (con una precisione di qualche micron) le traiettorie delle particelle EM che possono essere cariche (nel qual caso viene misurato il rapporto q/m) oppure neutre (fotoni);
  • i due calorimetri che si incontrando proseguendo verso l’esterno: il calorimetro EM che misura l’energia di elettroni e fotoni e il calorimetro adronico (barioni e mesoni). Va da sé che misurare l’energia di una particella equivale a misurarne la massa.
  • Il solenoide superconduttore che genera il campo magnetico di 4 Tesla necessario a incurvare le particelle cariche;
  • Nella parte esterna del rivelatore, il cosiddetto “giogo di ritorno” (return yoke) del magnete, che confina il campo magnetico e ferma tutte le particelle rimanenti tranne muoni e neutrini, sono collocate le cosiddette camere muoniche all’interno delle quali si misurano le masse dei muoni (i “cugini” massicci degli elettroni). Questa disposizione, oltre a trovarsi in senso radiale, viene ripetuta in senso longitudinale, secondo l’asse del cilindro, perché durante la collisione le particelle vanno dappertutto, anche parallelamente all’asse del detector.

C’è da dire che così da vicino si ha la misura della complessità di questa macchina, che è terrificante.

Nella prossima foto si vede uno spaccato del rivelatore (che era aperto per manutenzione) in cui si possono notare a destra (in quel grande tubo centrale con rastremazione conica verso sinistra) i calorimetri interni e sulla sinistra (attorno al foro circolare) il solenoide e le camere muoniche radiali:

Spaccato del rivelatore CMS conevidenza dei calorimetri interni, il solenoide superconduttore e le camere muoniche radiali
Spaccato del rivelatore CMS con evidenza dei calorimetri interni, il solenoide superconduttore e le camere muoniche radiali
[Foto: Gemma Zuin]

Una visione spaccata in prospettiva è la seguente (che potete trovare anche nel sito di CMS), nella quale sono indicati precisamente i componenti che ho appena elencato:

Sezione di CMS con tutti i componenti
Sezione di CMS con tutti i componenti (CERN)

CMS Data Collection

I dati da cui si ricavano le traiettorie delle particelle prodotte dall’urto vengono elaborati con un primo livello di filtro (detto trigger) che è lo strato software che si occupa della selezione degli eventi che interessa studiare.

Tuttavia non tutte le particelle prodotte da queste collisioni sono interessanti per cui viene fatta una selezione iniziale per potersi concentrare sulle collisioni “buone”. I protoni che non partecipano alla collisione vengono tuttavia rivelati ma solo per tenere sotto controllo il valore della sezione d’urto [2].

In una pagina della sezione di Fisica mostrerò qual è l’ordine di grandezza del numero di collisioni che realmente hanno luogo quando i bunch di protoni si scontrano.

Trigger CMS
Trigger (L1T) CMS

Quando l’LHC fa collidere i protoni, CMS rileva circa 40 di milioni di collisioni ogni secondo, solo una manciata delle quali sono utili per gli studi di fisica. Gli scontri tra protoni non sono tutti centrali, molti avvengono di striscio, producono poche particelle, magari le meno interessanti per ciò che si sta cercando: per esempio, eventi come quelli che hanno segnalato la presenza del bosone di Higgs, per esempio, sono estremamente rari. Se si dovessero salvare tutti i dati prodotti, si dovrebbe disporre di 40 Petabyte di capacità disco ogni secondo. Un po’ troppo!

Il compito del Trigger CMS è selezionare solo le poche centinaia di migliaia di eventi utili scartando il resto.

Trigger di I livello (L1T)

Il primo livello del trigger a due fasi, noto come trigger di livello 1 (o L1T), seleziona un massimo di centomila eventi al secondo dei quali puoi viene eseguita una seconda selezione più dettagliata da parte del secondo livello, noto come trigger di alto livello. [8]

Pertanto questa selezione, che richiede tempi di elaborazione velocissimi, può essere eseguita solo da dispositivi FPGA che consentono velocità di elaborazione non raggiungibili con i processori tradizionali

Il sistema L1T è progettato per raccogliere le informazioni dai calorimetri CMS e dagli spettrometri per muoni, è un sistema completamente sincronizzato montato a bordo del rivelatore stesso – per non sprecare tempo in trasmissione – che fornisce la sua decisione se mantenere il dataset acquisto o scartarlo in soli 3,8 μs dopo che si è verificata la collisione delle particelle al centro del CMS.

High-Level Trigger (LHT)

Una seconda fase di selezione accurata viene eseguita da un trigger software chiamato High-Level Trigger (HLT), che è implementato in una farm di 30.000 core che si trova in superficie. [7]

HLT, alla fine, dei 40 milioni di eventi ne salva all’incirca un migliaio.

La nostra guida Simone Bologna ha lavorato proprio alla realizzazione di questi due livelli di trigger durante il suo post-doc.

La nostra guida al CMS
La nostra guida al CMS [Foto: Raffaele Comelato}

Ultime note: CMS è uno di due esprimenti del CERN (l’altro è ATLAS) che hanno annunciato a luglio 2014 la scoperta del bosone di Higgs.

Inoltre, la tecnologia creata al CERN per rivelare i muoni ha trovato applicazioni altrove: una radiografia muonica della piramide di Cheope ha consentito di individuare una stanza sconosciuta al suo interno.

L’INFN di Napoli ha avviato uno studio del sistema di bocche di cratere all’interno del Vesuvio utilizzanod sempre la tecnlogia di imaging muonica.

Come il CERN mette a disposizione la sua tecnologia per chiunque abbia una buona idea da sviluppare.

La piacevole chiacchierata con la dott.ssa Barbara Rusconi, Financial Controller and Analyst presso il Financial and Administration Processes Department del CERN mi ha fatto conoscere una persona piacevolissima, entusiasta del suo lavoro e della missione del CERN.

La sua attività prevede molti tipi di task tra i quali: aiutare i progetti a trovare finanziamenti, stendere i business plan, reperire le risorse umane e tecnologiche per poter raggiungere gli obiettivi del progetto.

E’ un lavoro molto impegnativo che richiede grande conoscenza dei meccanismi di finanziamento pubblico e privato, del tipo di attività che si svolge lì dentro e capacità di regia e di relazione.

Mi ha spiegato come il CERN si sia dato diversi compiti: quello di portare avanti una ricerca di alta qualità a livello mondiale, mettere a disposizione un set completo di macchine acceleratrici a servizio della ricerca nelle alte energie in un modo sostenibile, unire persone provenienti da tutto il mondo per ampliare le frontiere della scienza e della tecnologia, a beneficio di tutti; formare nuove generazioni di fisici, ingegneri e tecnici e coinvolgere tutti i cittadini nella ricerca e nei valori della scienza. In particolare, c’è la missione di mettere a disposizione le competenze sviluppate al suo interno in aiuto a chiunque abbia una buona idea da sviluppare: un apparato, un software, un metodo di misura.

Il CERN ha un apposito organismo che si preoccupa di trasferire le competenze CERN al mondo esterno: il Gruppo KT (Knowledge Transfer Group) il quale mira a collaborare con esperti in scienza, tecnologia e industria al fine di creare opportunità per il trasferimento della tecnologia e del know-how del CERN. L’obiettivo finale è accelerare l’innovazione e massimizzare l’impatto positivo globale del CERN sulla società. Ciò avviene promuovendo e trasferendo il capitale tecnologico e umano sviluppato al CERN.

Le possibilità di applicazione riguardano la medicina, le applicazioni aerospaziali, Industria 4.0, sicurezza, tecnologie emergenti e molto altro ancora.

Per fare partire una collaborazione si può sottoporre l’idea al KT group con una semplice mail. [9]

Barbara Rusconi e io davanti al Sceince Gateway
Barbara Rusconi e io davanti al Science Gateway

Arrivederci Barbara, è stato veramente un piacere incontrarti!

Il Science Gateway

Nel 2022 è stato inaugurato un nuovo spazio destinato alle esposizioni, alla divulgazione delle Fisica e agli eventi aperti al pubblico come le conferenze, che è stato chiamato Science Gateway.

Science Gateway con gli spazi espositivi (clindri) paralleli all'Esplanade des Particules e l'attraversamento in altezza
Science Gateway con gli spazi espositivi (cilindri) paralleli all’Esplanade des Particules e l’attraversamento in altezza (foto mia)

Esso si dispone parallelamente all’Explanade des Particules, con i due spazi espositivi paralleli al corso e una galleria trasparente che li collega transitando sopra la strada e collega così anche i due lati del CERN.

Progettato da Renzo Piano, il nuovo complesso comprende cinque strutture cilindriche che ospitano mostre e laboratori e un auditorium da 900 posti. Ci trovate anche il ristorante Big Bang e un negozio in cui potete acquistare i souvenir.

Con piacevole sorpresa – come detto, il Science Gateway offre anche uno spazio destinato a mostre ed esposizioni d’arte – ho incontrato nuovamente questa installazione Chroma III dell’artista sudcoreano Yunchul Kim, che avevo visto nel 2022 alla Biennale di Venezia:

Yunchul Kim - Chroma III, 2021
Yunchul Kim – Chroma III, 2021 – [Foto: Gemma Zuin]

Le sezioni del Science Gateway comprendono anche l’Atelier Didattico, Our Universe, Quantum World.

Nella sezione Quantum world una serie di installazioni immersive (in cui ci si può aggirare) spiegano le pazzesche proprietà delle particelle elementari come la funzione d’onda, l’entanglement, la dualità onda particella, l’esperimento della doppia fenditura.

In Our Universe svengono raccontati i 13 miliardi di anni del nostro Universo e quello che di strano si porta dentro, come la Materia e l’Energia Oscura o l’asimmetria tra materia e antimateria, misteri che sono tuttora irrisolti.

Nell’Atelier didattico si può giocare ad accelerare una biglia di acciaio per mezzo di campi magnetici prodotti da bobine che possiamo comandare agendo su un pulsante, oppure si può giocare a calcio con i protoni per riuscire a scontarli e produrre particelle elementari, ciò che avviene nei detector come CMS che abbiamo visitato fino al suo interno.

Una partita a... protoni!
Una partita a… protoni! [Foto: Nicoletta Lugato]

Qui per esempio Gemma e io siamo riusciti a produrre una collisione, ma non è stato semplice 🙂

Sezione d'urto massimizzata :-))))
Sezione d’urto massimizzata :-)))) [Foto: Nicoletta Lugato]

Tutti i partecipanti sono rimasti soddisfatti ed entusiasti della visita! Voglio anche ringraziare tutti coloro che mi hanno aiutato nell’organizzazione, con il supporto logistico.

Foto di Gruppo: cheese!
Foto di Gruppo: CHEESE! [Foto: Raffaele Comelato]

Arrivederci alla prossima esperienza!

Greetings from Geneva
Greetings from Geneva

Riferimenti

Convertire un file CSV in una tabella MD in Python

Markdown
Markdown

Utilizzo spesso Markdown perché è un modo veloce di produrre documenti formattati che ospitano molto codice e contenuti tabulari. Con Python, qui di seguito descrivo un modo per convertire una tabella csv in una tabella markdown:

Step 1. Intallazione di Pandas

$ pip install pandas
Defaulting to user installation because normal site-packages is not writeable
Collecting pandas
  Downloading pandas-2.0.0-cp310-cp310-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (12.3 MB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 12.3/12.3 MB 5.2 MB/s eta 0:00:00
Requirement already satisfied: pytz>=2020.1 in /usr/lib/python3/dist-packages (from pandas) (2022.1)
Requirement already satisfied: numpy>=1.21.0 in /usr/lib/python3/dist-packages (from pandas) (1.21.5)
Collecting tzdata>=2022.1
  Downloading tzdata-2023.3-py2.py3-none-any.whl (341 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 341.8/341.8 kB 4.0 MB/s eta 0:00:00
Collecting python-dateutil>=2.8.2
  Downloading python_dateutil-2.8.2-py2.py3-none-any.whl (247 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 247.7/247.7 kB 4.8 MB/s eta 0:00:00
Requirement already satisfied: six>=1.5 in /usr/lib/python3/dist-packages (from python-dateutil>=2.8.2->pandas) (1.16.0)
Installing collected packages: tzdata, python-dateutil, pandas
Successfully installed pandas-2.0.0 python-dateutil-2.8.2 tzdata-2023.3

Step 2. Installazione di Tabulate

$ pip install tabulate
Defaulting to user installation because normal site-packages is not writeable
Collecting tabulate
  Downloading tabulate-0.9.0-py3-none-any.whl (35 kB)
Installing collected packages: tabulate
Successfully installed tabulate-0.9.0

Step 3. Programma Python

import pandas as pd

df = pd.read_csv("source.csv")
with open("destination.md", 'w') as md:
  df.to_markdown(buf=md, tablefmt="grid")

Questo è l’output prodotto su un file CSV di prova:

|    |      ID |   CODE |   CODE2 |   QUANTITY |   ASPECT |   CATEGORY |   BULK_ID |   ITEM_ID |   SHARE_ID | STATUS   | LOCK   |
|----|---------|-----------------------------|------------------|------------------|------------|----------------|---------------|-----------|-------------|-----------------|-------------|
|  0 | 1033896 |                      350821 |              446 |                7 |          3 |              5 |      40090302 |         4 |       21278 | S               | N           |
|  1 | 1033617 |                      350797 |              446 |               10 |          4 |              5 |      40090302 |         4 |       21278 | S               | N           |
|  2 | 1033903 |                      350822 |              446 |              107 |          3 |              5 |      40090302 |         4 |       21278 | S               | N           |
|  3 | 1033935 |                      350823 |              446 |              108 |          3 |              5 |      40090302 |         4 |       21278 | S               | N           |

che renderizzato in ReText (editor MD) si vede così:

Riferimenti web

Aggiornamento di TeXLive

TeXLive è un package per gestire in modo centralizzato LaTeX e tutte le ue componenti (librerie, fonts, ecc.)

Tempo fa ho installato un plugin che renderizza la sintassi di campi di tipo codice sorgente con la sintassi che si vuole. Si chiama Pygmentize. Ora però aggiornando il plugin non mi funziona più LaTeX, e dopo aver perso tempo a googlare sono arrivato alla considerazione (scritta nero su bianco sul sito di TeXLive) di reinstallare tutto:

Ho seguito questa lista di comandi trovata su un forum di Linux Mint:

  1. sudo apt-get purge texlive*
  2. sudo rm -rf /usr/local/texlive/*
  3. rm -rf ~/.texlive*
  4. sudo rm -rf /usr/local/share/texmf
  5. sudo rm -rf /var/lib/texmf
  6. sudo rm -rf /etc/texmf
  7. sudo apt-get remove tex-common --purge
  8. sudo apt autoremove
  9. rm -rf ~/.texlive
  10. find -L /usr/local/bin/ -lname /usr/local/texlive/*/bin/* | xargs -r rm

E comincio una nuova installazione da zero

  1. cd /tmp # working directory of your choice
  2. wget https://mirror.ctan.org/systems/texlive/tlnet/install-tl-unx.tar.gz # or curl instead of wget
  3. zcat < install-tl-unx.tar.gz | tar xf -
  4. cd install-tl-20230821
  5. sudo perl ./install-tl --no-interaction # as root or with writable destination
  6. Finally, prepend /usr/local/texlive/YYYY/bin/PLATFORM to your PATH, e.g., /usr/local/texlive/2023/bin/x86_64-linux

.

.

Riferimenti

  1. https://forums.linuxmint.com/viewtopic.php?t=390218
  2. https://tug.org/texlive/quickinstall.html

Perché i fisici menzionano “cinque sigma” nei loro risultati?

Questo articolo è la traduzione dall’inglese dell’articolo del CERN https://home.cern/resources/faqs/five-sigma

Quando viene fatta una nuova scoperta sulla fisica delle particelle, potresti aver sentito usare il termine “sigma”. Cosa significa? Perché è così importante parlare di sigma quando si avanza una richiesta per la scoperta di una nuova particella? E perché “Five Sigma” in particolare è così importante?

Perché la fisica delle particelle si basa sulla statistica?

Le particelle prodotte nelle collisioni nel Large Hadron Collider (LHC) sono minuscole e hanno una vita estremamente breve. Poiché decadono quasi immediatamente in altre particelle, è impossibile per i fisici “vederle” direttamente. Invece, esaminano le proprietà delle particelle finali, come la loro carica, massa, spin e momento. SI comportano come investigatori: i prodotti finali forniscono indizi sulle possibili trasformazioni che le particelle hanno subito durante il loro decadimento. Le probabilità di questi cosiddetti “canali di decadimento” sono previste dalla teoria.

Nell’LHC, milioni di collisioni di particelle al secondo vengono tracciate dai rilevatori e filtrate attraverso sistemi di trigger per identificare i decadimenti di particelle rare. Gli scienziati quindi analizzano i dati filtrati per cercare anomalie, che possono indicare nuova fisica.

Come in ogni esperimento, c’è sempre la possibilità di errore. Il rumore di fondo può causare fluttuazioni naturali nei dati con conseguenti errori statistici. Esiste anche il rischio di errori se non ci sono dati sufficienti o di errori sistematici causati da apparecchiature difettose o piccoli errori nei calcoli. Gli scienziati cercano modi per ridurre l’impatto di questi errori per garantire che le affermazioni che fanno siano il più accurate possibile.

Qual è la significatività statistica?

Immagina di lanciare un dado standard. C’è una probabilità su sei di ottenere un numero. Ora immagina di lanciare due dadi: la probabilità di ottenere un certo numero totale varia: c’è solo un modo per ottenere un due e sei modi diversi per ottenere un sette. Se lanciassi due dadi molte, molte volte e registrassi i risultati, la forma del grafico seguirebbe una curva a campana nota come distribuzione normale.

La distribuzione normale ha alcune proprietà interessanti. È simmetrica, il suo picco è chiamato media e la dispersione dei dati viene misurata utilizzando la deviazione standard. Per i dati che seguono una distribuzione normale, la probabilità che un punto dati si trovi all’interno di una distanza dal valore medio pari a una deviazione standard è del 68%, entro due deviaizioni standard è del 95%, entro tre è ancora più alta.

La deviazione standard è rappresentata dalla lettera greca σ, o sigma. Misurata in base al numero di deviazioni standard dalla media, la significatività statistica è la distanza di un determinato punto dati dal suo valore atteso.

Un grafico che mostra la curva a campana di una distribuzione normale con zone che mostrano le deviazioni standard
Per i dati che seguono una distribuzione normale, la probabilità che un punto dati si trovi all’interno di una deviazione standard o di un sigma (σ) del valore medio è del 68%, entro due σ è del 95%, entro tre σ è ancora più alta (Immagine: MW Toews )

Cosa c’entra questo con la fisica?

LHC 5 sigma significance
LHC 5 sigma significance

Quando gli scienziati registrano i dati dell’LHC, è naturale che si verifichino piccole irregolarità e fluttuazioni statistiche, ma queste sono generalmente vicine al valore atteso. C’è un’indicazione di un nuovo risultato quando c’è un’anomalia più grande. A che punto questa anomalia può essere classificata come un fenomeno nuovo? Gli scienziati usano la statistica per scoprirlo.

Immagina di nuovo la metafora dei dadi. Solo che questa volta stai lanciando un dado, ma non sai se è truccato. Lo lanci una volta e ottieni un tre. Non c’è nulla di particolarmente significativo in questo – c’era una possibilità su sei del tuo risultato – hai bisogno di più dati per determinare se è ponderato. Lo lanci due, tre o anche di più e ogni volta esce un tre. A che punto puoi confermare che è truccato?

Non esiste una regola particolare per questo, ma dopo circa otto volte in cui hai ottenuto lo stesso numero, sarai abbastanza certo che lo sia. La probabilità che ciò accada per caso è solo (1/6) 8 = 0,00006%.

Allo stesso modo, è così che i fisici determinano se un’anomalia è effettivamente un risultato. Con un numero sempre maggiore di dati, la probabilità di una fluttuazione statistica in un punto specifico diventa sempre più piccola. Nel caso del bosone di Higgs , i fisici avevano bisogno di dati sufficienti affinché la significatività statistica superasse la soglia di cinque sigma. Solo allora avrebbero potuto annunciare la scoperta di “una particella simile a Higgs”.

Cosa significa quando i fisici affermano che i dati hanno un significato statistico di cinque sigma?

Un risultato che ha una significatività statistica di cinque sigma indica la probabilità quasi certa che un aumento nei dati sia causato da un nuovo fenomeno, piuttosto che da una fluttuazione statistica. Gli scienziati lo calcolano misurando il segnale rispetto alle fluttuazioni previste nel rumore di fondo su tutta la gamma. Per alcuni risultati, le cui anomalie potrebbero trovarsi in entrambe le direzioni al di sopra o al di sotto del valore atteso, una significatività di cinque sigma è la probabilità dello 0,00006% che i dati siano fluttuanti. Per altri risultati, come la scoperta del bosone di Higgs, una significatività di cinque sigma è la probabilità dello 0,00003% di una fluttuazione statistica, poiché gli scienziati cercano dati che superano il valore di cinque sigma su metà del grafico della distribuzione normale.

Perché il cinque sigma è particolarmente importante per la fisica delle particelle?

Nella maggior parte delle aree scientifiche che utilizzano l’analisi statistica, la soglia di cinque sigma sembra eccessiva. In uno studio sulla popolazione, come i sondaggi su come voteranno le persone, di solito sarebbe sufficiente un risultato con una significatività statistica di tre sigma. Tuttavia, quando si parla della struttura stessa dell’Universo, gli scienziati mirano ad essere il più precisi possibile. I risultati della natura fondamentale della materia sono di grande impatto e hanno ripercussioni significative se sono sbagliati.

In passato, i fisici hanno notato risultati che potevano indicare nuove scoperte, con i dati che avevano solo una significatività statistica da tre a quattro sigma. Questi sono stati spesso smentiti man mano che venivano raccolti più dati.

Se si verifica un errore sistematico, ad esempio un errore di calcolo, l’elevato significato iniziale di cinque sigma può significare che i risultati non sono completamente nulli. Tuttavia, ciò significa che il risultato non sia definitivo e non possa essere utilizzato per rivendicare una nuova scoperta.

Five Sigma è considerato il “gold standard” nella fisica delle particelle perché garantisce una probabilità estremamente bassa che un’affermazione sia falsa.

Ma non tutti e cinque i sigma sono uguali…

Cinque sigma è generalmente il valore accettato per la significatività statistica per la ricerca di nuove particelle all’interno del Modello Standard – quelle particelle che sono previste dalla teoria e si trovano nella nostra attuale comprensione della natura. La significatività cinque sigma è accettata anche quando si ricercano proprietà specifiche del comportamento delle particelle, poiché ci sono meno possibilità di trovare fluttuazioni altrove nell’intervallo.

Se cinque sigma siano una significatività statistica sufficiente può essere determinato confrontando la probabilità della nuova ipotesi con la possibilità che si tratti di una fluttuazione statistica, tenendo conto della teoria.

Per la fisica oltre il Modello Standard, o per i dati che contraddicono la fisica generalmente accettata, è richiesto un valore di significatività statistica molto più elevato – abbastanza efficace da “confutare” la fisica precedente. Nel suo articolo “ Il significato di cinque sigma ”, il fisico Louis Lyons suggerisce che i risultati per fenomeni più improbabili dovrebbero avere un significato statistico più elevato, come il sette sigma per il rilevamento delle onde gravitazionali o la scoperta dei pentaquark.

In questo articolo, Lyons ritiene anche che la significatività statistica di cinque sigma sia sufficiente per la scoperta del bosone di Higgs. Questo perché la teoria del bosone di Higgs era stata prevista, testata matematicamente e generalmente accettata dalla comunità dei fisici delle particelle ben prima che LHC potesse generare le condizioni per poterlo osservare. Ma una volta raggiunto questo obiettivo, era ancora necessaria un’elevata significatività statistica per determinare se il segnale rilevato fosse effettivamente una scoperta.

_____________________________________________________________________________

Una significatività statistica di cinque sigma è rigorosa, ma in realtà è minima. Un valore più elevato per la significatività statistica conferma che i dati sono più affidabili. Tuttavia, ottenere risultati con significatività statistica di sei, sette o addirittura otto sigma richiede molti più dati, molto più tempo e molta più energia. In altre parole, una probabilità pari al massimo allo 0,00006% che un nuovo fenomeno non sia un colpo di fortuna statistico è abbastanza buona.

Scopri di più:

Routing IP

Mi sono trovato a dover studiare meglio l’argomento del routing IP in seguito a problemi di configurazione nel nuovo pc della VPN di un cliente.

routing intro
routing IP

Una delle cose che mi sono ritrovato a fare è stampare la tabella di routing dalla quale posso vedere gli indirizzi raggiungibili dal mio host (ho un computer nuovo e l’ho chiamato poleni in onore di Giovanni Poleni, fisico veneziano, 1683-1761):

Routing IP: stampa della tabella di routing
Routing IP: stampa della tabella di routing

Questo articolo estende e chiarisce alcune informazioni che ho già trattato nell’area del blog dedicata al Networking.

Questo argomento mi ricorda Ricerca Operativa, in cui ho studiato la teoria dei grafi che qui entra prepotentemente in gioco.

Cos’è il routing IP: panoramica

Routing IP è un termine generico per l’insieme di protocolli che determinano il percorso seguito dai dati per viaggiare su più reti dalla sorgente alla destinazione. I dati vengono instradati dall’origine alla destinazione attraverso una serie di router e su più reti.

Il compito del router è collegare due reti.

I protocolli di routing IP consentono ai router di creare una tabella di inoltro che correla le destinazioni finali con gli indirizzi dell’hop successivo.

Questi protocolli includono:

  • BGP ( Border Gateway Protocol)
  • IS-IS (Intermediate System – Intermediate System)
  • OSPF (Open Shortest path First)
  • RIP (Routing Information Protocol)

che verranno descritti più avanti.

Quando un pacchetto IP deve essere inoltrato ad un’altra rete, un router utilizza la propria tabella di inoltro per determinare l’hop successivo per la destinazione del pacchetto (in base all’indirizzo IP di destinazione che si trova nell’intestazione del pacchetto IP) e inoltra il pacchetto in modo appropriato. Il router successivo ripete quindi questo processo utilizzando la propria tabella di inoltro e così via finché il pacchetto non raggiunge la sua destinazione. In ogni fase, l’indirizzo IP nell’intestazione del pacchetto è un’informazione sufficiente per determinare l’hop successivo; non sono necessarie intestazioni di protocollo aggiuntive.

Dunque, in qualche modo, ogni router cerca di “indovinare” la prossima rete che più probabilmente porterà a destinazione il pacchetto IP.

Quindi è chiaro che il nodo della questione è: come funziona un router? dal suo funzionamento infatti dipende il successo della consegna di un pacchetto TCP/IP alla destinazione.

Panoramica sul funzionamento di un algoritmo di routing

Un algoritmo di routing è progettato per determinare il percorso ottimale o più appropriato attraverso una rete di comunicazione da una sorgente a una destinazione. Questo processo è fondamentale nelle reti di computer e nei sistemi di comunicazione per garantire che i dati vengano instradati in modo efficiente e affidabile da un punto all’altro. Ecco una panoramica generale di come funziona un algoritmo di routing:

  1. Rilevamento della topologia di rete: l’algoritmo deve avere informazioni sulla topologia della rete, cioè la configurazione dei dispositivi di rete e i collegamenti tra di essi.
  2. Scelta del percorso: l’algoritmo valuta i vari percorsi possibili dalla sorgente alla destinazione sulla base di criteri specifici, come la larghezza di banda disponibile, la congestione della rete, la qualità del collegamento e altre metriche.
  3. Costruzione della tabella di routing: l’algoritmo utilizza le informazioni raccolte per costruire una tabella di routing, che associa destinazioni specifiche ai percorsi ottimali o alle interfacce dei dispositivi di rete successivi.
  4. Aggiornamento della tabella di routing: la tabella di routing viene continuamente aggiornata per riflettere eventuali cambiamenti nella topologia di rete o nelle condizioni operative. Ciò può avvenire automaticamente o essere gestito manualmente.
  5. Instradamento dei pacchetti: quando un pacchetto dati viene inviato dalla sorgente, l’algoritmo di routing utilizza la tabella di routing per determinare il percorso ottimale. Il pacchetto viene quindi inoltrato da un dispositivo di rete all’altro lungo il percorso stabilito fino a raggiungere la destinazione.

Ci sono diversi algoritmi di routing, ognuno con i propri vantaggi e svantaggi. Alcuni esempi includono l’algoritmo di routing a vettore delle distanze (distance vector), l’algoritmo di stato del collegamento (link state), e BGP (Border Gateway Protocol) nell’ambito di Internet (vedi più avanti).

L’efficienza di un algoritmo di routing dipende dalla sua capacità di adattarsi a cambiamenti nella rete, di gestire la congestione e di ottimizzare le prestazioni complessive del sistema di comunicazione.

Una trattazione sistematica di questo argomento utilizza l’astrazione dei Sistemi Autonomi.

Sistemi autonomi

Internet è una rete di reti e i sistemi autonomi sono le grandi reti che compongono Internet. Più specificamente, un sistema autonomo (AS) è una rete di grandi dimensioni o un gruppo di reti che dispone di una politica di routing unificata. Ogni computer o dispositivo che si connette a Internet è connesso in prima istanza a un AS.

Proviamo a immaginare un AS come l’ufficio postale di una città o come gli hub di un’azienda di trasporti. La posta va da un ufficio postale all’altro finché non raggiunge la città giusta, e l’ufficio postale di quella città consegnerà poi la posta all’interno di quella città. Allo stesso modo, i pacchetti di dati attraversano Internet saltando da un AS all’altro fino a raggiungere l’AS che contiene l’indirizzo IP di destinazione: a questo punto i router all’interno di quest’ultimo AS invieranno il pacchetto all’indirizzo IP di destinazione finale.

Routing IP: Internet come rete di Sistemi Autonomi
Routing IP: Internet come rete di Sistemi Autonomi

Ogni AS controlla un insieme specifico di indirizzi IP, proprio come l’ufficio postale di ogni città è responsabile della consegna della posta a tutti gli indirizzi all’interno di quella città. L’intervallo di indirizzi IP su cui un determinato AS ha il controllo è chiamato spazio degli indirizzi IP.

I sistemi autonomi sono dunque stati introdotti per regolamentare le organizzazioni di rete come i fornitori di servizi Internet (ISP), gli istituti scolastici e le agenzie governative.

Da un punto di vista pratico, un AS è un insieme di prefissi IP assegnato a un organizzazione (entità) che sono instradabili su Internet appartenenti alla rete o all’insieme di reti che sono tutte gestite, controllate e supervisionate dall’entità o organizzazione.

Un AS utilizza un’unica politica di routing controllata dall’organizzazione. All’AS viene assegnato un numero identificativo di 16 cifre univoco a livello globale, noto come numero di sistema autonomo o ASN, dall’Internet Assigned Numbers Authority (IANA).

I sistemi autonomi numerati da 1 a 64511 sono disponibili da IANA per l’uso globale. La serie da 64512 a 65535 è riservata ad usi privati ​​e riservati.

Topologia dei sistemi autonomi
Topologia dei sistemi autonomi [Cloudflare]

Per esempio l’AS a cui è connessa la rete da cui sto scrivendo questo articolo è AS3269 che è Telecom Italia S.p.A. Per trovare qual è il vostro è sufficiente individuare con quale indirizzo IP la vostra rete è connessa a Internet (lo sa il vostro router, se avete accesso alla consolle, oppure potete usare un servizio web come whatismyip.com), poi interrogare il database whois con l’argomento l’IP che avete trovato:

whois for IP routing
whois for IP routing

L’AS3269 a cui questa rete è connessa è quella di Telecom Italia. Il protocollo whois restituisce informazioni diverse a seconda che lo si interroghi con un indirizzo IP o con un nome di dominio. L’informazione sull’ASN viene esposta solo interrogando con l’indirizzo IP.

Se poi l’AS è di transito (vedi poco oltre, Telecom Italia è un caso di questi), il comando whois espone una pletora di dettagli (che sono pubblici) come tutte le direttive per l’importazione e l’esportazione delle tabelle di routing da e verso gli altri AS.

Internet, ai fini del routing, è dunque una collezione di Sistemi Autonomi (AS).

Fisicamente, un AS è un gruppo di router che sono sotto il controllo di un’unica amministrazione e scambiano informazioni di routing utilizzando un protocollo di routing comune. Ad esempio, una intranet aziendale o una rete ISP possono solitamente essere considerate come un singolo AS.

Un AS può essere classificato come uno dei tre tipi seguenti.

  1. Un Sistema Autonomo Stub ha una singola connessione con un altro AS. Tutti i dati inviati o ricevuti da una destinazione esterna all’AS devono viaggiare su tale connessione. Una piccola rete universitaria è un esempio di AS stub.
  2. Un Sistema Autonomo di transito ha più connessioni a uno o più AS, il che consente ai dati che non sono destinati a un nodo all’interno di quell’AS di attraversarlo. Una rete ISP è un esempio di AS di transito.
  3. Un Sistema Autonomo Multihomed ha anche più collegamenti con uno o più AS, ma non consente che i dati ricevuti su uno di questi collegamenti vengano nuovamente inoltrati dall’AS. In altre parole, non fornisce un servizio di transito ad altri AS. Un AS Multihomed è simile a un AS Stub, tranne per il fatto che i punti di ingresso e di uscita per i dati che viaggiano da o verso l’AS possono essere scelti da una serie di connessioni, a seconda di quale connessione offre il percorso più breve verso la destinazione finale. Una rete aziendale di grandi dimensioni sarebbe normalmente un AS multihomed.

Il calcolo delle rotte: Interior ed Exterior Protocols

Il termine “Interior Gateway Protocol” (IGP) si riferisce a un protocollo di routing utilizzato all’interno di una rete autonoma per determinare il percorso ottimale per la trasmissione dei dati tra i suoi nodi. Gli IGPs sono progettati per gestire il routing all’interno di una singola rete e sono complementari con gli “Exterior Gateway Protocol” (EGP), che gestiscono il routing tra reti autonome separate.

Teoria dei grafi

I protocolli di routing si basano fortemente sulla teoria dei grafi per determinare i percorsi ottimali attraverso una rete. La teoria dei grafi fornisce un framework matematico per rappresentare e analizzare le relazioni tra gli elementi di una rete, come i nodi e i collegamenti.

La teoria dei grafi sistematizza questo tipo di oggetti e studia le possibili soluzioni (e ne determina la complessità computazionale) per problemi classici come quello dei ponti di Koenigsberg o del Postino Cinese. I problemi in sostanza sono questi: come posso visitare (se possibile) tutti i nodi di un grafo? oppure tutti gli archi? qual è il percorso più conveniente da un nodo all’altro? In quest’ultimo caso la “convenienza” si traduce in un costo numerico ogni volta che mi sposto da un nodo all’altro e l’algoritmo cerca di minimizzare (o massimizzare, a seconda del problema) la somma di questi costi elementari. Le applicazioni, come è noto, sono molteplici: dagli algoritmi di routing per le reti alla costruzione di percorsi più rapidi o meno inquinanti per Google Maps.

Ecco come i protocolli di routing utilizzano la teoria dei grafi:

  1. Rappresentazione della Rete: La topologia di una rete può essere rappresentata come un grafo, dove i nodi rappresentano i dispositivi di rete (come router o switch) e gli archi rappresentano i collegamenti tra di essi. Questa rappresentazione è cruciale per comprendere la struttura della rete.
  2. Nodi e Collegamenti: I nodi del grafo corrispondono ai dispositivi di rete, mentre gli archi del grafo corrispondono ai collegamenti fisici o logici tra questi dispositivi.
  3. Algoritmi di Routing: Gli algoritmi di routing, come quelli utilizzati nei protocolli di routing, operano sul grafo per determinare il percorso ottimale da un punto all’altro nella rete. Due tipi principali di algoritmi di routing basati su grafi sono:
    • Distance-Vector: Questo tipo di algoritmo assegna un “vettore di distanza” a ciascun nodo, indicando la distanza stimata tra il nodo e ogni altro nodo nella rete. L’algoritmo converge gradualmente verso la soluzione ottimale (la distanza minima o shortest path). Un esempio di questo algoritmo è il Routing Information Protocol (RIP) che assegna un “costo” a ciascun percorso e sceglie il percorso con il costo complessivo più basso. RIP è spesso utilizzato in reti di dimensioni medio-piccole.
      Il calcolo del percorso in questo caso viene effettuato con l’algoritmo di Ford e Bellman.
    • Link-State: è un algoritmo più raffinato in quanto i suoi archi sono pesati. Questo tipo di algoritmo assegna uno “stato” a ciascun collegamento nella rete, indicando informazioni come la larghezza di banda e lo stato del collegamento. Gli algoritmi link-state determinano il percorso ottimale sulla base di queste informazioni dettagliate. Un esempio di questo tipo è Open Shortest Path First (OSPF) che assegna pesi ai collegamenti tra i router e calcola il percorso più breve in base a questi pesi. OSPF è più adatto per reti di grandi dimensioni e offre una maggiore flessibilità nella progettazione della rete. l calcolo del percorso in questo caso viene effettuato con l’algoritmo di Dijkstra.

Riassumendo, la teoria dei grafi fornisce un modo potente per modellare e risolvere problemi di routing nelle reti. I protocolli di routing utilizzano gli algoritmi basati su grafi per determinare in modo efficiente i percorsi ottimali attraverso le complesse topologie di rete.

Un Interior Gateway Protocol (IGP) calcola dunque i percorsi all’interno di un singolo AS. L’IGP consente ai nodi di reti diverse all’interno di un AS di scambiarsi dati. L’IGP consente inoltre l’inoltro dei dati attraverso un AS dall’ingresso all’uscita, quando l’AS fornisce servizi di transito.

Un Exterior Gateway Protocol (EGP) consente ai router all’interno di un AS di scegliere il miglior punto di uscita dall’AS per i dati che stanno tentando di instradare.

L’EGP e gli IGP in esecuzione all’interno di ciascun AS collaborano per instradare i dati su Internet. L’EGP determina gli AS che i dati devono attraversare per raggiungere la propria destinazione, e l’IGP determina il percorso all’interno di ciascun AS che i dati devono seguire per andare dal punto di ingresso (o punto di origine) al punto di uscita (o la destinazione finale).

Protocolli esterni (EGP)

Lo scambio dei pacchetti da un AS ad un altro avviene utilizzando il protocollo BGP.

Border Gateway Protocol

Gli AS annunciano la loro politica di routing ad altri AS e router tramite il Border Gateway Protocol (BGP).

Finora abbiamo visto come i pacchetti vengano girati all’interno della rete di un singolo AS, ma come passano da un AS all’altro? BGP è il protocollo per l’instradamento dei pacchetti di dati tra AS. Senza queste informazioni di instradamento, il funzionamento di Internet su larga scala diventerebbe presto poco pratico: i pacchetti di dati andrebbero persi o impiegherebbero troppo tempo per raggiungere la loro destinazione.

Ciascun AS utilizza BGP per annunciare di quali indirizzi IP è responsabile e a quali altri AS si connette. I router BGP prendono tutte queste informazioni dagli AS di tutto il mondo e le inseriscono in database chiamati tabelle di routing per determinare i percorsi più veloci da AS ad AS. Quando arrivano i pacchetti, i router BGP fanno riferimento alle loro tabelle di instradamento per determinare a quale AS dovrà andare successivamente il pacchetto.

Il protocollo whois ci fornisce alcune informazioni sui collegamenti tra AS.

Ogni AS può consorziarsi con altri AS per gestire più efficientemente il traffico dati. Queste informazioni vengono visualizzate in due sezioni dell’ouput del comando che sono import ed export. Nel contesto dell’output del comando “whois” per un ASN (Autonomous System Number) – vedi la trascrizione del comando più avanti -, le sezioni “import” ed “export” si riferiscono alle relazioni di peering (di “parità”) tra sistemi autonomi. Un sistema autonomo può avere accordi di peering con altri sistemi autonomi per facilitare lo scambio diretto di traffico senza dover passare attraverso terzi.

Ecco cosa significano solitamente le sezioni “import” ed “export”:

  • Import (Importazione): elenca i prefissi IP (range di indirizzi IP) che il sistema autonomo corrente riceve dai sistemi autonomi con cui ha un accordo di peering. Questi prefissi sono quelli che il sistema autonomo corrente “importa” dalla rete dei suoi peer. In altre parole, indica quali reti l’ASN corrente è disposto a accettare direttamente dai suoi partner di peering:
    “Io, AS3209, sono a disposizione per far transitare i pacchetti provenienti da AS6762 e AS1913″.
  • Export (Esportazione): elenca i prefissi IP che il sistema autonomo corrente annuncia e rende disponibili per essere raggiunti da altri sistemi autonomi con cui ha un accordo di peering:
    “i pacchetti destinati a AS1913 li faccio transitare – o li consegno – io, AS3209!”.
    Questi prefissi sono quelli che il sistema autonomo corrente “esporta” verso la rete dei suoi peer. In altre parole, indica quali reti il sistema autonomo corrente è disposto a rendere disponibili ai suoi partner di peering.
    Queste informazioni sono cruciali per la configurazione e la gestione del routing nei sistemi autonomi. Gli operatori di rete utilizzano queste informazioni per definire come il traffico dovrebbe fluire attraverso la rete, in base agli accordi di peering stabiliti. In genere, questi accordi sono basati su principi di reciprocità, dove due sistemi autonomi concordano di scambiare traffico direttamente per migliorare l’efficienza del routing e ridurre i costi di transito.
marco@poleni:~$ whois AS3269
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See https://apps.db.ripe.net/docs/HTML-Terms-And-Conditions

% Note: this output has been filtered.
%       To receive output for a database update, use the "-B" flag.

% Information related to 'AS3209 - AS3353'

as-block:       AS3209 - AS3353
descr:          RIPE NCC ASN block
remarks:        These AS Numbers are assigned to network operators in the RIPE NCC service region.
mnt-by:         RIPE-NCC-HM-MNT
created:        2018-11-22T15:27:19Z
last-modified:  2018-11-22T15:27:19Z
source:         RIPE

% Information related to 'AS3269'

% Abuse contact for 'AS3269' is 'abuse@business.telecomitalia.it'

aut-num:        AS3269
as-name:        ASN-IBSNAZ
org:            ORG-IA34-RIPE
import:         from AS6762 action pref=100; accept ANY
import:         from AS1913 action pref=100; accept AS1913
import:         from AS2162 action pref=100; accept AS2162
import:         from AS2164 action pref=100; accept AS2164
import:         from AS4589 action pref=100; accept AS4589
import:         from AS5395 action pref=100; accept AS5395
...
export:         to AS1913 announce ANY
export:         to AS2162 announce ANY
export:         to AS2164 announce ANY
export:         to AS5395 announce ANY
export:         to AS5502 announce ANY
export:         to AS5609 announce ANY
export:         to AS6665 announce ANY
export:         to AS6840 announce ANY
export:         to AS6875 announce ANY
export:         to AS8265 announce ANY
export:         to AS8463 announce ANY
export:         to AS8660 announce ANY
export:         to AS8754 announce ANY
export:         to AS8822 announce ANY
export:         to AS8884 announce ANY
export:         to AS8911 announce ANY
export:         to AS8978 announce ANY
export:         to AS8980 announce ANY

...

Il ruolo di BGP è cruciale allo stesso modo del protocollo DNS e il suo funzionamento è molto simile, quello di una database distribuito. Con così tanti AS nel mondo, infatti, i router BGP aggiornano costantemente le loro tabelle di routing. Quando le reti vanno offline, nuove reti vengono online e gli AS espandono o contraggono il loro spazio di indirizzi IP, tutte queste informazioni devono essere annunciate tramite BGP in modo che i router BGP possano modificare le loro tabelle di instradamento.

Protocolli interni (IGP)

IS-IS Protocol

Il protocollo IS-IS (Intermediate System – Intermediate System) fa parte di una famiglia di protocolli di routing IP ed è un protocollo IGP (Interior Gateway Protocol) per Internet, utilizzato per distribuire le informazioni di routing IP attraverso un singolo sistema autonomo (AS) in una rete IP.

IS-IS è un protocollo di routing dello stato del collegamento (link-state), il che significa che i router scambiano informazioni sulla topologia con i vicini più prossimi. Le informazioni sulla topologia vengono diffuse in tutto l’AS, in modo che ogni router all’interno dell’AS abbia un quadro completo della topologia dell’AS. Questa immagine viene quindi utilizzata per calcolare i percorsi end-to-end attraverso l’AS, normalmente utilizzando una variante dell’algoritmo Dijkstra. Pertanto, in un protocollo di routing dello stato del collegamento, l’indirizzo dell’hop successivo a cui vengono inoltrati i dati viene determinato scegliendo il miglior percorso end-to-end verso la destinazione finale.

OSPF

Anche OSPF è un protocollo di tipo IGP.

Ogni router OSPF distribuisce informazioni sul proprio stato locale (interfacce utilizzabili, vicini raggiungibili e costo di utilizzo di ciascuna interfaccia) ad altri router pubblicando un messaggio LSA (Link State Advertisement). D’altra parte, ogni router utilizza i messaggi ricevuti per costruire un database identico che descrive la topologia dell’AS.

Da questo database, ogni router calcola la propria tabella di instradamento utilizzando un algoritmo Shortest Path First (SPF) o Dijkstra. Questa tabella di routing contiene tutte le destinazioni conosciute dal protocollo di routing, associate all’indirizzo IP dell’hop successivo e all’interfaccia in uscita.

RIP

RIP è un semplice protocollo di routing vettoriale. In un protocollo di routing vettoriale, i router scambiano informazioni sulla raggiungibilità della rete con i vicini più prossimi. In altre parole, i router comunicano tra loro gli insiemi di destinazioni (“prefissi di indirizzo”) che possono raggiungere e l’indirizzo del salto successivo a cui inviare i dati per raggiungere tali destinazioni. Ciò contrasta con gli IGP link-state; i protocolli di vettorizzazione si scambiano percorsi tra loro, mentre i router dello stato dei collegamenti scambiano informazioni sulla topologia e calcolano i propri percorsi localmente.

Chiariamo alcuni termini relativi al routing IP

Elenco nel seguito alcuni termini usati in precedenza per spiegarli più approfonditamente.

Cos’è una policy (o politica) di routing per un AS?

Una policy di routing è l’unione di due elenchi:

  • un elenco dello spazio degli indirizzi IP controllato dall’AS (quindi gli indirizzi all’interno della rete dell’AS),
  • un elenco degli altri AS a cui si connette.

Queste informazioni sono necessarie per instradare i pacchetti alle reti corrette. Gli AS annunciano queste informazioni su Internet utilizzando il Border Gateway Protocol (BGP).

Cos’è uno spazio di indirizzi?

Un gruppo o un intervallo specificato di indirizzi IP è denominato “spazio degli indirizzi IP”. Ciascun AS controlla una certa quantità di spazio di indirizzi IP. (Un gruppo di indirizzi IP può anche essere chiamato “blocco” di indirizzi IP.)

Immaginiamo per un instante che tutti i numeri di telefono del mondo siano elencati in ordine numerico in un mega elenco, che due aziende di telecomunicazioni (la Phone Company A e la Phone Company B) gestiscano l’intero traffico telefonico globale. Supponiamo inolter che a ciascuna compagnia telefonica sia assegnato un intervallo di numeri di telefono:

  • i numeri controllati dalla Phone Co. A da 000-0000 a 599-9999 e
  • i numeri controllati dalla Phone Co. B da 600-0000 a 999- 9999.

Se Alice è connessa alla rete telefonica tramite Phone Co. A e chiama Michelle (connessa anch’essa a Phone Co. A) al 555-2424, la sua chiamata verrà instradata a Michelle tramite Phone Co. A.

Se chiama Jenny (connessa invece a Phone Co. B) al 867-5309, la sua chiamata verrà instradata a Jenny tramite Phone Co. B.

Questo è più o meno il modo in cui funziona lo spazio degli indirizzi IP.

Supponiamo che ACME (A Company Making Everything) gestisca un AS e controlli un intervallo di indirizzi IP che include l’indirizzo 192.0.2.253, che è assegnato per esempio ad server web. Se un computer dall’altra parte del mondo invia un pacchetto a 192.0.2.253, questo pacchetto raggiungerà prima o poi l’AS controllato da ACME. Se invece, sempre dal computer dall’altra parte del mondo, vengono inviati pacchetti a 198.51.100.255, questi andranno a un AS diverso (sebbene possano transitare, lungo il loro percorso, per l’AS di ACME).

Cosa sono i prefissi IP?

Quando gli ingegneri di rete comunicano quali indirizzi IP sono controllati da determinati AS, lo fanno parlando dei “prefissi” degli indirizzi IP posseduti da ciascun AS.

Un prefisso di indirizzo IP è un intervallo di indirizzi IP. A causa del modo in cui vengono scritti gli indirizzi IP, i prefissi degli indirizzi IP sono espressi in questo modo: 192.0.2.0/24.

Attenzione però! Questo prefisso rappresenta gli indirizzi IP da 192.0.2.0 a 192.0.2.255, non da 192.0.2.0 a 192.0.2.24. La “/24” indica la lunghezza del prefisso in termini di bit. In questo caso, “/24” significa che i primi 24 bit dei 32 rappresentano la parte di rete dell’indirizzo IP, mentre i rimanenti 8 bit rappresentano la parte di host. Potete rivedere alcuni di questi concetti qui.

L’output del comando ip route

Il comando “ip route” è utilizzato nei sistemi operativi basati su Linux per visualizzare e manipolare la tabella di routing del kernel (lo smistamento di pacchetti tcp/ip è infatti un compito svolto a basso livello direttamente dal kernel del Sistema Operativo). L’output di questo comando fornisce informazioni dettagliate sulla configurazione della tabella di routing del sistema. Ecco un esempio di come potrebbe apparire l’output:

default via 192.168.1.1 dev eth0 proto static
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
10.0.0.0/8 via 10.0.0.1 dev tun0

Di seguito è spiegato il significato di ciascuna riga dell’output:

  1. Riga predefinita (default route):
  • default via 192.168.1.1 dev eth0 proto static
    • Indica che tutti i pacchetti destinati a indirizzi non inclusi nelle altre voci della tabella di routing (default) verranno instradati attraverso l’interfaccia di rete eth0 verso il gateway con l’indirizzo IP 192.168.1.1. Il protocollo è static, il che significa che questa voce è stata configurata staticamente.
  1. Riga di rete locale (local network):
  • 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
    • Specifica che la rete con l’indirizzo 192.168.1.0 e maschera di sottorete 255.255.255.0 è raggiungibile tramite l’interfaccia di rete eth0. L’indirizzo IP locale dell’interfaccia eth0 è 192.168.1.100. “scope link” significa che significa che il pacchetto viene semplicemente rilasciato sul collegamento (link) e inviato direttamente all’interfaccia poiché la destinazione è nella sottorete e “ascolterà” il pacchetto – quindi non è necessario alcun gateway. In altre parole, significa che la rete è valida e raggiungibile tramite questo dispositivo (eth0).
  1. Riga specifica (specific route):
  • 10.0.0.0/8 via 10.0.0.1 dev tun0
    • Indica che la rete con l’indirizzo 10.0.0.0 e maschera di sottorete 255.0.0.0 è raggiungibile attraverso l’interfaccia di rete tun0 e deve passare attraverso il gateway con l’indirizzo IP 10.0.0.1.

Un abuona risorsa per una descrizione completa del comando ip è in [2]

Ho trovato questa bella immagine realizzata da Nassim sul forum ServerFault.com:

ip route example
ip route example

Bibliografia

[1] Metaswitch.com

[2] linux-ip.net

[3] Cloudflare.com