AISA

2026-01-05 18:48:20

ANDU, FLC-CGIL, Roars, nonché la Rete delle Società Scientifiche, hanno espresso allarme o almeno preoccupazione per i doni che lo stato si appresta a regalare alla ricerca italiana. Questi doni, che rafforzeranno i poteri, già non poco oppressivi, del ministero dell’università e della ricerca, dell’Anvur che gli è sottomesso e delle gerarchie accademiche locali, consistono:

1. in una riforma del reclutamento, già approvata in senato, che rende i concorsi interamente locali, ma sotto il controllo dell’Anvur sia in ingresso sia in uscita;
2. in una riforma dell’Anvur, per via regolamentare e non legislativa, volta ad accentuarne ulteriormente la subordinazione al ministero;
3. in una riforma dell’amministrazione delle università, per via legislativa, che accentuerebbe il dispotismo locale dei rettori e la loro sudditanza al governo nazionale.

La scienza italiana, che nell’età moderna si fondò e perseguì la libertà dell’uso pubblico della ragione e l’emancipazione dal segreto, si trova ora a misurarsi con tre poteri che hanno solo accidentalmente a che vedere con la ricerca della verità: quello, locale, di colleghi e rettori, quello, centralizzato, dell’agenzia sedicente indipendente per la valutazione di stato, la quale attribuisce la quota cosiddetta “premiale” del finanziamento ordinario, e quello del governo a cui essa stessa è sottoposta fin dalla sua istituzione.

Promuovendo la scienza aperta come scienza libera e non come costoso adempimento burocratico, abbiamo sostenuto che la valutazione amministrativa della ricerca, in Italia centralizzata in forma di valutazione di stato, è intrinsecamente dispotica e retrograda: dispotica perché sostituisce alla libera discussione entro le comunità scientifiche una statuizione di un’autorità esterna e non scientifica, in quanto derivante da una gerarchia amministrativa; retrograda perché impone indicatori costruiti sul passato che disconoscono non solo la riflessività dell’azione sociale,¹ ma anche la natura aperta della ricerca.

A questo dispositivo, che Mario Ricciardi descrisse precocemente come un “apparato burocratico di tipo sovietico”, i professori italiani si sono – sostanzialmente – piegati. Fra gli effetti della sottomissione c’è stato il blocco di un’evoluzione verso una scienza aperta nel senso di libera da oligopoli editoriali privati e liste di riviste “scientifiche” ed “eccellenti” di composizione amministrativa. Accettarla, ai più, è parsa una scelta prudente: si tratta però di capire se è stata anche una scelta sapiente.

1. La metamorfosi del “cretino locale”

Pietro Rossi, in un fortunato articolo, criticò i concorsi introdotti nel 1998, in cogestione fra “facoltà e corporazione disciplinare”. Secondo Rossi, in un sistema in cui la sede che fa il favore di bandire una valutazione comparativa può barattare la vittoria del proprio candidato interno con le idoneità di candidati esterni supplementari che trovano cattedra a casa loro, l’ascesa del “cretino locale”, entro comunità di disciplina sempre più frammentate e chiuse, non può che essere irresistibile.

Il disegno di legge approvato in senato abolisce l’Abilitazione Scientifica Nazionale a favore di concorsi esclusivamente locali con vincitori unici, accessibili tramite un’autocertificazione della soddisfazione di criteri stabiliti con decreto ministeriale su proposta dell’Anvur, sentito il CUN, i quali comprenderanno “indicatori minimi di quantità, continuità e distribuzione temporale dei prodotti della ricerca”. I commissari dovranno godere dei medesimi requisiti. Dopo tre anni i vincitori verranno valutati dall’Anvur, con eventuali conseguenze sanzionatorie in termini di finanziamento istituzionale.

Si tornerà dunque al “cretino locale”, o, come scrive più gentilmente Roberta Calvano, a un sistema in cui “il nepotismo e gli abusi sono stati per anni alla radice di un diffuso malcostume accademico”? No: in virtù dell’Anvur e del ministero, questa volta il “cretino”, selezionato tramite valutazione amministrativa in ingresso e in uscita e giudicato da commissari simili a lui, sarà probabilmente bibliometrico, sicuramente governativo, e giocoforza sottomesso ai colleghi disposti a usare il loro potere di ricatto – qualità, queste, che con la scienza libera hanno ben poco a che vedere.

2. L’autoaffermazione dell’università italiana

“Noi vogliamo noi stessi” proclamava un rettore a Friburgo, perorando l’autoaffermazione dell’università. Correva l’anno 1933: Martin Heidegger diceva “noi”, ma era entrato in carica su pressione del governo nazista, dopo che il suo predecessore, riluttante a licenziare gli ebrei, era stato indotto alle dimissioni. Tra poco, forse, anche i rettori italiani, pur più sottilmente e con qualche sbavatura normativa, potranno dire “noi” al modo di Heidegger:

1. la composizione, legalmente determinata, del consiglio di amministrazione consentirà loro di contare su una maggioranza certa purché ubbidiscano al governo. Eliminato il rappresentante del personale tecnico-amministrativo, degli 11 membri del consiglio uno sarà il rettore stesso, quattro saranno nominati direttamente da lui (due docenti e due componenti esterni); a questi si aggiungerà uno studente eletto, come residuo vestigiale di democrazia, due docenti indicati dal senato, il candidato rettore soccombente e un membro nominato dal governo. Al rettore basterà restare agli ordini di quest’ultimo – esercizio che, probabilmente, non gli sarà difficile – per avere una maggioranza garantita;²
2. il mandato del rettore sarà prolungato da sei a otto anni, con un eventuale plebiscito di conferma dopo quattro anni, qualora proposto dai 3/5 del senato accademico. A proposito del mandato, dall’ipotetico testo di riforma cadono le parole “non rinnovabile”;
3. nella programmazione triennale il rettore dovrà tener conto anche di “linee generali di indirizzo stabilite dal Ministro”.

I rettori preferiranno continuare a regnare all’inferno o proveranno a servire in paradiso? Non si sa: ma certamente con “rettori che agiscono sotto l’occhiuta vigilanza del ministro e da cui dipenderanno a catena tutte le cariche interne agli atenei (i cui mandati vengono allineati alla durata di quello dei rettori)” l’esercizio della libertà della ricerca, sia in senso negativo sia in senso positivo, sarà ancor più difficile, e rischioso.

3. L’epifania dell’Anvur

Come ha osservato Roberto Caso, l’Anvur, istituita nel 2006 sotto il governo Prodi II, è nata così dipendente da aver ricevuto critiche perfino da una sostenitrice della valutazione amministrativa come Fiorella Kostoris. Il regolamento di riforma – che viola, secondo il Consiglio di Stato, la gerarchia delle fonti³ – renderebbe più intenso un controllo del governo sulla ricerca già in atto, al quale i più, a dispetto del primo comma dell’articolo 33 della costituzione italiana, hanno ritenuto opportuno sottomettersi.

1. L’Anvur sarà ancor più ministeriale e dipendente: rispetto al regime attuale, il presidente dell’Anvur diverrebbe di nomina ministeriale diretta, così come i comitati di selezione delle rose dei candidati fra i quali il ministro sceglierà i quattro membri del consiglio direttivo, non più costituiti su indicazione di enti esterni.
2. L’Anvur diverrà la valutatrice generale di stato: l’agenzia, che attualmente valuta solo università ed enti di ricerca vigilati dal MUR (quali CNR, INAF, INDIRE, INFN, INGV, INVALSI), allungherà il suo occhio agli altri enti di ricerca pubblici (ASI, CREA, ENEA, ISPRA, ISS, ISTAT) in base ad accordi con i ministeri vigilanti, alle Accademie e all’Alta Formazione Artistica e Musicale (AFAM) a enti privati ma finanziati pubblicamente (IIT di Genova, HT di Milano e Fondazione Biotecnopolo di Siena) e simili, nonché, per chi mai volesse richiederlo, in ambito internazionale. E non si occuperà solo di arte, musica e ricerca bensì anche delle cosiddette “competenze trasversali e disciplinari” acquisite dagli studenti e degli “sbocchi occupazionali dei laureati”. Tutto ciò, chiarisce la relazione di accompagnamento, nel “rispetto dell’indirizzo politico dato dal Ministero dell’università e della ricerca, quale Ministero vigilante”.

Il modello dell’università-azienda – si è detto – è neoliberale; quello nei disegni del governo è autoritario. Qui però il “liberale” che segue al “neo-” non ha nulla a che vedere con Benedetto Croce: l’azienda è una struttura non democratica, bensì autoritaria e chi la impone come modello sostiene un’ideologia altrettanto autoritaria, se non totalitaria. In questo senso, il disegno di “riforma” dell’Anvur non è una metamorfosi, bensì un’epifania.

Non esiste una valutazione amministrativa buona o cattiva, così come non esiste un dispotismo cattivo o buono a seconda che sul trono sieda Commodo oppure Marco Aurelio. Se si accetta che la valutazione della ricerca non sia scientifica – e parte della ricerca stessa – bensì amministrativa e a essa esterna, si accetta anche che chi amministra ne fissi e ne muti i criteri e abbia titolo a controllare i suoi eventuali agenti in modo più o meno stretto. Il vizio della valutazione di stato non sta nel modo in cui valuta, come suggerito elusivamente dell’Unione Europea, ma nel fatto che Caesar sia supra grammaticos, non importa se come Marco Aurelio o come Commodo. Non è, questa, un’idea radicale, né sul piano della storia, né su quello della cronaca: lo scorso aprile, in Francia, l’assemblea nazionale ha votato a favore dell’abolizione dell’agenzia di valutazione di stato HCERES.

In questa prospettiva non ha senso limitarsi a chiedere un guinzaglio appena un po’ più lungo, o a sollevare il problema dei finanziamenti alla ricerca senza toccare quello della sua libertà, vale a dire della possibilità stessa di fare scienza – libertà, questa, che non si promuove difendendo l’Anvur attuale⁴ come se fosse indipendente, bensì considerandone l’abolizione.

Contro il disegno di intensificare il controllo politico di “un’università più piccola, gerarchica e precaria”, FLC-CGIL⁵ si è appellata alle “forze libere e pensanti dell’accademia e della comunità universitaria”. In effetti, se, dopo lustri di valutazione di stato, esistessero ancora “forze libere e pensanti”, non sarebbe loro difficile promuovere una campagna di ubbidienza civile alla costituzione, a partire dagli articoli 21 e 33. In un momento in cui dovremmo invece parlare, davanti agli stati armati per la guerra, delle condizioni della pace pubblica, continuare a compilare moduli e a supplicare favori ministeriali ci salverà, forse, come impiegati, ma certamente non come studiosi.

---

1. Questa riflessività è nota a chi si occupa di valutazione come legge di Goodhart: i soggetti valutati non si limitano a farsi valutare, ma adeguano riflessivamente le loro prestazioni al criterio di valutazione. Così chi viene premiato per il numero di pubblicazioni inflazionerà i testi, mentre chi viene premiato per le citazioni scriverà solo per farsi citare. Le conseguenze sono tristemente note. ↩︎
2. Per un aggiornamento sugli orientamenti ministeriali si veda però quanto riferito dall’ANDU qui. [nota aggiunta il 7/01/2026]↩︎
3. Il Consiglio di Stato, nel parere formulato nell’adunanza del 23 settembre 2025, ha ricordato che, proprio in virtù della gerarchia delle fonti del diritto, un regolamento, perfino se riguarda la valutazione di stato, non può cambiare la legge che l’ha istituita. ↩︎
4. L’agenzia, peraltro, si è mostrata incapace di onorare gli impegni di riforma della valutazione che aveva sottoscritto aderendo alla coalizione europea COARA. ↩︎
5. ANVUR: un’Agenzia che diventa governativa, con l’intenzione di valutare e quindi disciplinare anche saperi e conoscenze (2025) merita di essere letto per la sua analisi dettagliata della bozza di DPR qui solo sommariamente esposta. ↩︎

This text is licensed under CC BY-SA 4.0 license
- The post’s content. aisa.sp.unipi.it/anvur-recluta…

Sull’incontro dell’ANDU con Mancini, segretario generale del MUR – ANDU

Sull’incontro dell’ANDU con Mancini, segretario generale del MUR

^ANDU

Spcnet.it

2026-07-10 13:26:33

Network Bonding su Linux: guida completa a ridondanza e throughput aggregato

Perché il bonding delle interfacce di rete è ancora rilevante

Una singola scheda di rete è un punto singolo di fallimento. Su un server di produzione, un cavo che si stacca, una porta dello switch che si guasta o un driver che va in crash possono bastare per portare giù un servizio. Il network bonding su Linux (noto anche come NIC teaming o link aggregation) risolve il problema aggregando due o più interfacce fisiche in un’unica interfaccia logica gestita dal kernel: bond0. A seconda della modalità scelta, si ottiene ridondanza, throughput aggregato maggiore, oppure entrambi.

Non è una tecnologia nuova, il driver bonding è nel kernel Linux da anni, ma resta uno degli strumenti più sottoutilizzati nella cassetta degli attrezzi di chi amministra server fisici, hypervisor o anche semplici home lab. Vediamo come funziona davvero, quali modalità scegliere e come configurarlo con gli strumenti che si trovano oggi sulle distribuzioni più diffuse.

Bonding non è bridging

Prima di entrare nella configurazione, vale la pena chiarire un equivoco comune: il bonding non è la stessa cosa del bridging. Un bridge collega segmenti di rete distinti, permettendo al traffico di attraversare due reti separate. Il bonding, invece, aggrega più interfacce fisiche facendole apparire al sistema operativo e alle applicazioni come un unico dispositivo di rete. Sono strumenti diversi, per scopi diversi, e vanno configurati in modo diverso.

Un altro equivoco frequente riguarda la banda: il bonding non raddoppia automaticamente il throughput di una singola connessione TCP. La maggior parte delle modalità distribuisce connessioni multiple su interfacce diverse, non spezzetta un singolo trasferimento su tutti i link contemporaneamente. Il guadagno di banda aggregata si ottiene quando più flussi sono attivi in parallelo, non con un singolo trasferimento di file.

Va inoltre notato che le interfacce WiFi generalmente non sono compatibili con il bonding: la maggior parte dei driver wireless non supporta la modalità promiscua e la manipolazione dell’indirizzo MAC richieste dal driver bonding. Il bonding va quindi limitato a interfacce Ethernet cablate.

Le modalità di bonding: quale scegliere

Il driver bonding del kernel Linux supporta sette modalità. Per la maggior parte degli scenari operativi ne bastano tre o quattro:

• Mode 0 (balance-rr): round-robin, trasmette i pacchetti in sequenza su tutte le interfacce. Offre load balancing e fault tolerance, ma richiede un gruppo di aggregazione statico configurato correttamente sullo switch. Senza questo, si ottengono pacchetti fuori ordine e prestazioni scadenti.
• Mode 1 (active-backup): una sola interfaccia attiva alla volta; se quella attiva si guasta, subentra la backup. Non richiede alcuna configurazione sullo switch. È la modalità più sicura e compatibile, ideale quando l’obiettivo è puramente la ridondanza.
• Mode 2 (balance-xor): selezione dell’interfaccia basata su un hash degli indirizzi MAC sorgente e destinazione. Load balancing per connessione e fault tolerance, richiede supporto dello switch.
• Mode 3 (broadcast): trasmette ogni pacchetto su tutte le interfacce contemporaneamente. Usata raramente, solo in scenari di fault tolerance molto specifici.
• Mode 4 (802.3ad / LACP): link aggregation dinamica secondo lo standard IEEE 802.3ad. Richiede uno switch gestito con LACP abilitato. È la modalità più usata in ambito enterprise: se lo switch la supporta, è la scelta corretta per la produzione.
• Mode 5 (balance-tlb): load balancing adattivo del traffico in uscita in base al carico corrente su ciascuna interfaccia; il traffico in ingresso arriva sull’interfaccia attiva corrente. Non richiede configurazione dello switch.
• Mode 6 (balance-alb): come mode 5, ma bilancia anche il traffico in ingresso tramite negoziazione ARP. Non richiede switch gestito e offre buoni guadagni di throughput, anche se alcuni switch e ambienti virtualizzati gestiscono il bilanciamento basato su ARP in modo incoerente: va testato prima di affidarcisi in produzione.

Per un homelab o un setup semplice senza switch gestito, Mode 1 (failover puro) o Mode 6 (bilanciamento senza configurazione switch) sono le scelte pratiche. Per server di produzione con switch gestito, Mode 4 (LACP) è la strada corretta.

Prerequisiti

Servono almeno due interfacce di rete fisiche (o virtuali, in una VM), accesso root o sudo, il modulo kernel bonding e uno strumento di gestione della rete (NetworkManager, systemd-networkd o Netplan, a seconda della distribuzione).

Verificare che il modulo bonding sia disponibile:

modinfo bonding

Se restituisce le informazioni del modulo, si può procedere caricandolo:

sudo modprobe bonding

Prima di modificare qualsiasi configurazione, è indispensabile identificare le interfacce disponibili:

ip link show

Sui sistemi moderni i nomi saranno del tipo enp3s0, enp4s0, oppure i più tradizionali eth0, eth1. Annotarli, perché verranno referenziati per tutta la configurazione.

Metodo 1: NetworkManager (desktop e la maggior parte dei server moderni)

Su Ubuntu, Fedora, Debian con NetworkManager, o qualunque distribuzione desktop, questo è l’approccio più semplice, grazie al supporto per il bonding consolidato da anni tramite nmcli.

Creare l’interfaccia bond:

sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=active-backup,miimon=100"

Aggiungere le interfacce fisiche come slave del bond:

sudo nmcli con add type ethernet slave-type bond con-name bond0-slave1 ifname enp3s0 master bond0
sudo nmcli con add type ethernet slave-type bond con-name bond0-slave2 ifname enp4s0 master bond0

Assegnare un indirizzo IP statico al bond:

sudo nmcli con modify bond0 ipv4.addresses 192.168.1.100/24 ipv4.gateway 192.168.1.1 ipv4.dns 1.1.1.1 ipv4.method manual

Oppure, per usare il DHCP:

sudo nmcli con modify bond0 ipv4.method auto

Attivare il bond:

sudo nmcli con up bond0

Le interfacce slave dovrebbero attivarsi automaticamente. In caso contrario, portarle su manualmente:

sudo nmcli con up bond0-slave1
sudo nmcli con up bond0-slave2

Verificare lo stato del bond:

cat /proc/net/bonding/bond0

Il file /proc/net/bonding/bond0 è lo strumento diagnostico principale: va consultato ogni volta che qualcosa non sembra funzionare come previsto.

Metodo 2: systemd-networkd (server e installazioni minimali)

Su server senza NetworkManager, systemd-networkd gestisce il bonding in modo pulito. Creare il file netdev del bond:

sudo nano /etc/systemd/network/10-bond0.netdev

[NetDev]
Name=bond0
Kind=bond

[Bond]
Mode=active-backup
MIIMonitorSec=100ms
UpDelaySec=200ms
DownDelaySec=200ms

Creare la configurazione di rete per l’interfaccia bond (esempio DHCP):

sudo nano /etc/systemd/network/20-bond0.network

[Match]
Name=bond0

[Network]
DHCP=yes

Vincolare le interfacce fisiche al bond, un file per ciascuno slave:

sudo nano /etc/systemd/network/30-bond0-slave1.network

[Match]
Name=enp3s0

[Network]
Bond=bond0

Riavviare systemd-networkd e verificare:

sudo systemctl restart systemd-networkd
cat /proc/net/bonding/bond0

Metodo 3: Netplan (Ubuntu Server)

Ubuntu Server 18.04 e successivi usano Netplan come layer di configurazione di rete predefinito. Editare il file (di solito /etc/netplan/01-netcfg.yaml):

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: no
    enp4s0:
      dhcp4: no
  bonds:
    bond0:
      interfaces:
        - enp3s0
        - enp4s0
      addresses:
        - 192.168.1.100/24
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses:
          - 1.1.1.1
      parameters:
        mode: active-backup
        mii-monitor-interval: 100
        primary: enp3s0

Applicare la configurazione:

sudo netplan apply

Se si sta lavorando da remoto, Netplan offre una modalità di test sicura che ripristina automaticamente la configurazione precedente dopo 120 secondi se non viene confermata:

sudo netplan try

Per usare LACP, basta modificare il blocco parameters:

parameters:
  mode: 802.3ad
  lacp-rate: fast
  mii-monitor-interval: 100
  transmit-hash-policy: layer2+3

Metodo 4: LACP (Mode 4) con switch gestito

Con uno switch gestito che supporta LACP, Mode 4 vale la configurazione aggiuntiva: si ottiene link aggregation reale con negoziazione dinamica. Sul lato switch, le porte interessate vanno configurate come LAG (Link Aggregation Group) con LACP abilitato: su Cisco il comando è channel-group X mode active; sulla maggior parte degli switch gestiti consumer c’è una sezione LAG o Trunk nell’interfaccia web.

Sul lato Linux, l’unica differenza rispetto al Metodo 1 sono le opzioni del bond:

sudo nmcli con add type bond con-name bond0 ifname bond0 bond.options "mode=802.3ad,miimon=100,lacp_rate=fast"

La policy transmit-hash-policy: layer2+3 distribuisce il traffico basandosi sia sull’indirizzo MAC sia sull’IP, offrendo una distribuzione del carico migliore rispetto alla policy predefinita solo layer2.

Attenzione: se si abilita LACP sul lato Linux ma lo switch non è configurato di conseguenza, il bond torna a usare un solo link attivo. Non va in errore, ma non si ottiene alcuna aggregazione: va sempre configurato prima lo switch.

Testare il failover

Con il bonding in active-backup configurato, si può simulare un guasto e osservare il recupero. In un terminale, avviare un ping continuo verso il gateway:

ping 192.168.1.1

In un altro terminale, disattivare l’interfaccia attiva:

sudo ip link set enp3s0 down

Si osserveranno al massimo uno o due pacchetti persi, poi il traffico continuerà a fluire attraverso l’interfaccia di backup. Verificare lo stato del bond:

cat /proc/net/bonding/bond0

La riga Currently Active Slave mostrerà il passaggio alla seconda interfaccia. Per impostare un’interfaccia primaria preferita:

sudo nmcli con modify bond0 bond.options "mode=active-backup,miimon=100,primary=enp3s0"

Comandi utili per il monitoraggio

# Stato del bond in tempo reale
watch -n 1 cat /proc/net/bonding/bond0

# Traffico sull'interfaccia bond
sudo iftop -i bond0

# Stato IP e link
ip addr show bond0
ip link show bond0

# Conteggio dei fallimenti di link (utile per individuare cavi difettosi)
grep "Link Failure Count" /proc/net/bonding/bond0

Se il contatore dei fallimenti su una sola interfaccia cresce mentre il sistema funziona normalmente, probabilmente c’è un cavo o una porta dello switch difettosa: conviene sostituirli prima che il guasto si presenti nel momento peggiore.

Problemi comuni e soluzioni

Il bond non ha IP dopo il riavvio

Probabilmente le interfacce slave vengono attivate prima che il bond sia inizializzato. Con systemd-networkd, i numeri più bassi vengono processati per primi: assicurarsi che il file netdev (10-bond0.netdev) abbia un numero inferiore rispetto ai file network degli slave. Verificare anche che il modulo si carichi al boot:

echo "bonding" | sudo tee /etc/modules-load.d/bonding.conf

Solo uno slave risulta attivo anche in round-robin o LACP

Lo switch non è configurato per il LAG. Configurarlo correttamente, oppure passare a Mode 1 o Mode 6, che non richiedono configurazione dello switch.

I drop di ping durante il failover durano più del previsto

Abbassare il valore di miimon (l’intervallo di polling predefinito è 100ms):

bond.options "mode=active-backup,miimon=50,updelay=100,downdelay=100"

updelay e downdelay prevengono il flapping su link instabili: impostarli ad almeno il doppio del valore di miimon.

Conclusione

Il network bonding è una di quelle funzionalità che sembrano complicate finché non si mettono effettivamente in pratica. Il modulo kernel è già presente nella maggior parte delle distribuzioni, la configurazione è lineare, e il risultato è concreto: failover a downtime quasi zero, throughput aggregato maggiore, o entrambi, a seconda della modalità scelta.

Per chi non ha certezze su quale modalità scegliere, Mode 1 è il punto di partenza più sicuro: non richiede configurazione dello switch, funziona ovunque e il failover è quasi istantaneo. Si può poi passare a Mode 4 con LACP quando si dispone di uno switch gestito e si desidera una vera link aggregation. In entrambi i casi, /proc/net/bonding/bond0 resta lo strumento diagnostico di riferimento: va controllato dopo il setup, dopo ogni modifica, e ogni volta che qualcosa sembra non funzionare come dovrebbe.

Fonte: LinuxBlog.io

Linux Network Bonding: Combine Network Interfaces | LinuxBlog.io

Two network interfaces are better than one. With Linux network bonding (also known as NIC bonding or link aggregation), you can combine multiple NICs into

^{Hayden James (LinuxBlog.io)}

Spcnet.it

2026-07-10 13:26:37

NetScaler MCP Gateway: Citrix mette ordine nel traffico degli agenti AI aziendali

Il problema: agenti AI che parlano con troppi sistemi, senza controllo

Il Model Context Protocol (MCP) si sta affermando rapidamente come lo standard con cui gli agenti AI aziendali si collegano a strumenti, database e sistemi interni. È comodo: un agente può interrogare un CRM, aprire un ticket, leggere un repository Git o lanciare una pipeline, tutto attraverso lo stesso protocollo. Il problema è che questa comodità sta creando, nella maggior parte delle aziende, un far west di endpoint MCP sparsi, ciascuno con la propria autenticazione, i propri permessi e nessuna visibilità centralizzata.

Gartner stima che il 60% dei proof-of-concept di GenAI venga abbandonato dopo il completamento, principalmente per mancanza di governance, controlli di rischio inadeguati e dati non pronti per l’AI. Citrix ha deciso di attaccare esattamente questo problema estendendo NetScaler, la sua piattaforma di application delivery e sicurezza, con una nuova funzionalità chiamata MCP Gateway.

Cos’è NetScaler MCP Gateway

MCP Gateway trasforma NetScaler in un punto di ingresso unico e governato per tutto il traffico MCP dell’organizzazione. Invece di lasciare che ogni team gestisca in autonomia i propri server MCP, con metodi di autenticazione diversi e nessun log centralizzato, il gateway instrada dinamicamente le richieste verso i server MCP approvati, applicando policy coerenti in un unico punto della rete.

Le funzionalità principali includono:

• Autenticazione centralizzata e granulare: token per utente e token globali, flussi OAuth e ibridi, rate limiting a livello di singolo tool e liste di allow/block per i server, così da impedire agli agenti di raggiungere endpoint non approvati o di generare carichi di richieste incontrollati.
• Affidabilità per i workflow multi-step: la persistenza di sessione e un monitoraggio “protocol-aware” mantengono l’agente collegato al backend corretto e verificano che i server MCP restino sani durante flussi di lavoro lunghi e articolati.
• Model routing e visibilità sui consumi per il traffico LLM: instradamento basato su content switching e tracciamento dell’uso a livello di token, per team, utente o applicazione.

Il tutto sfrutta l’architettura “single-pass” proprietaria di NetScaler, che esegue in un solo passaggio traffic management, autenticazione, routing, ispezione di sicurezza, rate limiting e observability. È una scelta progettuale rilevante: il traffico AI è molto volumetrico sia in termini di dimensioni dei payload che di numero di pacchetti, e concatenare più proxy separati aggiunge hop e latenza esattamente nel punto in cui le performance contano di più.

Governance anche sul lato LLM

Parallelamente al gateway MCP, Citrix ha esteso anche NetScaler AI Gateway, il componente che gestisce il traffico verso i provider LLM. Le richieste in arrivo da agenti e applicazioni possono ora essere instradate verso modelli diversi in base a policy, con tracciamento di token in ingresso e in uscita per team, utente o applicazione. L’obiettivo dichiarato è evitare il vendor lock-in su un singolo provider e responsabilizzare i team sui costi generati dall’uso dell’AI.

Un caso d’uso interessante, in anteprima privata, riguarda l’integrazione con Claude Code: NetScaler AI Gateway agisce da gateway LLM davanti a Claude Code, fornendo un punto di controllo centralizzato per l’accesso ai modelli Anthropic da parte di migliaia di sviluppatori, senza dover applicare l’identità due volte (una lato IdP aziendale, una lato provider AI).

Perché questo interessa a chi gestisce infrastrutture, non solo ai team AI

Per un sistemista o un architetto che ha già affrontato la messa in sicurezza di API gateway e reverse proxy classici, il parallelo con MCP Gateway è immediato: cambia il protocollo, ma la logica di centralizzazione di autenticazione, rate limiting e observability resta la stessa buona pratica che si applica da anni a qualunque superficie di API esposta internamente.

Ci sono almeno tre ragioni pratiche per iniziare a pensarci ora, anche se in azienda gli agenti AI sono ancora in fase pilota:

• Proliferazione silenziosa degli endpoint. Ogni team che sperimenta con agenti AI tende a esporre un proprio server MCP, spesso senza coinvolgere il team di sicurezza. Senza un punto di controllo centrale, il numero di endpoint cresce più velocemente della capacità di monitorarli.
• Settori regolamentati. In ambiti come finanza, sanità e pubblica amministrazione, un agente che accede a sistemi con dati sensibili senza audit trail centralizzato è un problema di compliance, non solo di sicurezza tecnica.
• Il costo nascosto del traffico LLM. Senza tracciamento dei token per team o applicazione, è comune scoprire solo a fine mese quale progetto ha generato la spesa maggiore verso un provider AI.

Come osserva Steve Shah, general manager di NetScaler in Citrix: “non è una questione di se, ma di quando le polizze di cyber-insurance inizieranno a richiedere l’uso di gateway MCP per proteggersi da agenti pericolosi”. È una previsione plausibile: lo stesso percorso è già avvenuto con i Web Application Firewall e, più di recente, con gli API Gateway.

Cosa fare oggi, anche senza NetScaler

Che l’organizzazione adotti NetScaler o un’altra soluzione, i principi di governance restano validi in modo tecnologicamente agnostico:

• Censire tutti i server MCP attivi in azienda, anche quelli nati come esperimento di un singolo team.
• Imporre un solo punto di ingresso autenticato per il traffico MCP verso sistemi che trattano dati sensibili, invece di esporre i server direttamente.
• Applicare rate limiting per tool, non solo per endpoint: un agente compromesso o mal configurato può generare un numero di chiamate ripetute a un singolo strumento capace di saturare un backend anche legittimo.
• Loggare in modo centralizzato ogni richiesta MCP, per poter ricostruire “chi ha fatto cosa” in caso di incidente, esattamente come si farebbe con un audit log su un database di produzione.

Conclusione

MCP sta diventando, nelle parole di Shah, “la nuova API call” per gli agenti AI aziendali. Ma proprio come le API REST hanno richiesto un decennio per maturare pattern di sicurezza consolidati (OAuth, rate limiting, API gateway centralizzati), anche MCP dovrà attraversare lo stesso percorso, probabilmente in tempi molto più compressi vista la velocità con cui l’adozione dell’AI agentica sta avvenendo nelle aziende. Chi gestisce infrastrutture farebbe bene ad anticipare questa esigenza, piuttosto che rincorrerla dopo il primo incidente.

Fonte: Help Net Security e 4sysops

Citrix NetScaler adds MCP Gateway to secure and govern AI agent traffic – 4sysops

Citrix has updated its NetScaler platform to include Model Context Protocol (MCP) Gateway functionality for enterprise environments. The Model Context Protocol

^{IT News (4sysops)}