Link-Aggregation (LACP) è uno strumento operativo fondamentale per ottenere ridondanza e throughput aggregato. La parola chiave Link-Aggregation (LACP) è posta intenzionalmente all’inizio: LACP riunisce più link Ethernet fisici in una connessione logica (LAG, Link Aggregation Group) e negozia questo stato mediante frame LACPDU. In pratica i problemi derivano meno dal protocollo in sé e più da impostazioni accessorie incoerenti: VLAN-Tagging, MTU, hashing, timer LACP, configurazioni multi-chassis (MLAG/vPC) o Loop‑Protection. Questa guida mostra una sequenza di verifica compatta, tipici scenari di errore, test concreti e una strategia pragmatica di fallback per l’esercizio in produzione.
Was LACP aushandelt — und was Sie separat klären müssen
LACP (IEEE 802.3ad / 802.1AX) fa sì che le due parti riconoscano le porte membro come parte di un’aggregazione e concordino quali link fisici saranno attivi. LACP gestisce l’assegnazione dei membri, ma non il VLAN-Tagging, la MTU né le decisioni di forwarding (hashing). Questa separazione è centrale: un LAG può essere formalmente «up», mentre determinati VLAN, trasferimenti di grandi dimensioni o sessioni firewall falliscono.
Entscheidungen vor der Konfiguration
Topologie: Single-Chassis vs. Multi-Chassis
Il Single-Chassis-LAG termina su uno switch/stack. Il Multi-Chassis-LAG (MLAG/vPC) distribuisce i membri su due switch fisici, aumenta la disponibilità, ma crea anche una ulteriore dominio di guasto: Peer-Link, State-Sync e protezione contro lo Split‑Brain. Molti apparenti deadlock LACP sono in realtà problemi di sincronizzazione MLAG.
Modus und Timer
Scegliete consapevolmente la modalità LACP (active/passive). Active/Active è in ambienti eterogenei generalmente più affidabile, perché entrambe le parti inviano LACPDUs. Impostate il rate LACP (fast/slow) su entrambi i lati: valori di timer differenti possono portare a rieselezioni impreviste.
Fehlerstrategie: Min-Links, Fallback, Degradation
Definite Min-Links (numero minimo di membri attivi) per evitare che una singola linea, come «Bündel», sopporti tutto il traffico da sola. Evitate, quando possibile, il fallback automatico verso Port-Channel statici; ciò aumenta il rischio di loop se i peer non sono configurati in modo identico. Per MLAG pianificate regole di comportamento chiare in caso di disturbi sul Peer-Link.
Typische Stolperfallen — praktische Ursachen
VLAN-/Trunk-Inkonsistenz
Nella maggior parte dei casi LACP non fallisce nella negoziazione, ma a causa di VLAN mancanti o di impostazioni trunk/access differenti sulle porte membro. Sintomo: il LAG è verde, ma singoli VLAN o servizi non sono raggiungibili. Verificate sempre la configurazione del trunk sull’interfaccia LAG, non sulle singole porte.
MTU- und Jumbo-Frame-Mismatch
La MTU è dipendente dal percorso. Se un link o un punto intermedio ha una MTU più piccola, il percorso frammenta o scarta i pacchetti. Conseguenza tipica: i pacchetti piccoli funzionano, i trasferimenti di grandi dimensioni si interrompono. PMTUD fallisce se gli ICMP «Fragmentation needed» vengono filtrati.
Hashing passt nicht zur Last
LACP distribuisce i flussi tramite hashing (es. campi L2/L3/L4). Un «flusso elefante» può saturare un singolo membro mentre gli altri restano liberi. Questo è spesso rilevante in esercizio per firewall, stream di backup o replicazione di storage.
Physische Probleme und Link Flapping
Transceiver difettosi, rotture di fibra, problemi con DAC, mismatch di autoneg o meccanismi di risparmio energetico causano flap e continue rinegoziazioni. LACP può rimanere nello stato Up, ma STP, MAC‑Learning e forwarding entrano in continua fluttuazione.
STP e protezione dai loop
STP considera una LAG correttamente costituita come una porta logica. In caso di mismatch (es. statico vs. LACP) STP può vedere e bloccare singoli membri della porta — ciò provoca apparenti deadlock. Le funzionalità di protezione dai loop (BPDU Guard, UDLD) possono porre le porte in err-disable e quindi paralizzare parzialmente l’aggregato.
Schemi simili a deadlock e cause tecniche
Deadlock non è uno stato LACP, ma descrive situazioni operative in cui meccanismi di controllo e protezione si bloccano a vicenda. Quattro schemi ricorrenti:
- LAG attiva, traffico assente o non desiderato: VLAN/MTU/hashing o guasto del link unidirezionale.
- Interruzioni periodiche: Timer‑Mismatch (fast/slow) o ritmi di flapping.
- MAC‑Flapping / problemi ARP: loop, MLAG‑Split‑Brain o Host‑Teaming‑Mismatch.
- Membro selezionato, ma il forwarding è bloccato: STP/Loop‑Protect o UDLD err‑disable.
Percorso di verifica nell’incidente — passaggi rapidi e riproducibili
Procedere in modo strutturato: dai controlli di configurazione semplici ai test Layer‑1/2.
1) Restringere l’ambito: was genau ist betroffen?
Domande: Solo una VLAN? Solo trasferimenti di grandi dimensioni? Solo un percorso in una direzione? Solo un membro? Ci sono state modifiche recenti (Firmware, Kabel, Konfiguration)?
2) LACP-Status beidseitig prüfen
Confrontare Actor/Partner‑IDs, lista dei membri, Aggregator‑ID e verificare se le porte sono nello stato collecting/distributing.
# Beispiel: Linux Bonding-Status und Link-Stats
cat /proc/net/bonding/bond0
for i in eth0 eth1; do
echo "=== $i ===";
ethtool $i;
ethtool -S $i | egrep -i "err|drop|crc|discard|timeout" || true;
done
lldpcli show neighbors
3) VLAN/Trunk-Konsistenz prüfen
Controllare i tag mediante capture su una porta membro e testare la raggiungibilità per VLAN. Se i tag mancano o appaiono solo su singoli membri, la configurazione dello switch è incoerente.
# VLAN-Tag-Paket sichtbar machen
tcpdump -eni eth0 -c 50 vlan
# Beispiel: VLAN-Subinterface prüfen
ip -d link show bond0.100
4) MTU-Pfad testen
Eseguire DF‑Ping per verificare la path‑MTU. Attenzione: il filtraggio ICMP può interferire con PMTUD.
# IPv4: DF-Tests
ping -M do -s 1472 -c 3 198.51.100.10 # MTU 1500
ping -M do -s 8972 -c 3 198.51.100.10 # MTU 9000 (Jumbo)
5) Fehlerzähler und unidirektionale Fehler
Gli CRC‑Errors, le correzioni FEC o gli Input‑Errors indicano problemi a Layer‑1/2. UDLD può rilevare errori unidirezionali, ma attivatelo solo se il comportamento è stato documentato nel tempo.
6) STP/Loop-Schutz prüfen
Le viste STP coincidono? La LAG viene trattata come interfaccia o si vedono singoli membri nella bridge? Eventi BPDU Guard o cambi di topologia spesso si correlano con problemi LACP.
7) MLAG/vPC: Peer-Link als eigene Fehlerdomäne
Verificare la stabilità del Peer‑Link, la VLAN‑Allow‑List sul Peer‑Link, il Keepalive‑Path e i Consistency‑Checks. Molte protezioni disabilitano le porte se il Peer‑Link ha problemi.
Esperimenti mirati in esercizio (Hypothesen schnell falsifizieren)
Mitgliedslink nacheinander deaktivieren
Disabilitare temporaneamente singoli membri per vedere se il problema scompare o si sposta. Se sì, il percorso o il dispositivo relativo a quel link è la causa.
MTU- und PMTUD-Experimente
Testare grandi trasferimenti con DF‑Ping e trasferimenti di file controllati. Se i messaggi di frammentazione mancano (a causa di filtri ICMP), i problemi PMTUD verranno rilevati solo osservando i TCP‑Retransmits.
Provocare/analizzare miratamente il MAC-Flapping
Accertate se gli Host usano modalità di teaming errate. Su Linux mostra /proc/net/bonding la modalità; incongruenze tra Switch-LACP e teaming dell’host sono cause di errore classiche.
Esempi concreti di configurazione e comandi di verifica
Gli esempi seguenti aiutano a riconoscere le forme di configurazione tipiche e a verificarle in modo valido. Adattate la sintassi al vostro vendor e alla versione del sistema operativo.
Cisco IOS / IOS-XE: Port-Channel con LACP
interface Port-channel10
description LAG to Firewall-Cluster
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 10,20,30
ip mtu 9000
!
interface GigabitEthernet1/0/1
switchport mode trunk
switchport trunk allowed vlan 10,20,30
channel-group 10 mode active
!
interface GigabitEthernet1/0/2
switchport mode trunk
switchport trunk allowed vlan 10,20,30
channel-group 10 mode active
Importante: le impostazioni di trunk e MTU sono efficaci sul Port-Channel. I singoli member non dovrebbero avere impostazioni VLAN o MTU divergenti.
Linux Bonding (active-backup vs. 802.3ad)
# /etc/network/interfaces (Debian-Beispiel)
auto bond0
iface bond0 inet static
address 10.0.0.10/24
bond-mode 802.3ad
bond-miimon 100
bond-lacp-rate fast
bond-slaves eth0 eth1
mtu 9000
Nota: bond-lacp-rate fast corrisponde al timer LACP rapido. Usate la stessa impostazione sullo switch.
How-to e troubleshooting specifici per firewall
I firewall sono particolarmente critici perché mantengono sessioni stateful. Una singola perdita di pacchetti o un percorso asimmetrico può interrompere le sessioni.
1) Verificare lo stato delle sessioni e del cluster
Controllate i contatori delle sessioni, i drop e gli errori di cluster-sync sul firewall. Nei cluster verificate errori di replica o di heartbeat — questi spesso correlano con problemi LACP.
2) Controlli per routing asimmetrico
Assicuratevi che il percorso di ritorno e l’ingress hashing siano coerenti. In caso di mancanza di simmetria eseguite tracciamenti dei pacchetti (tcpdump) su entrambe le parti e confrontate gli header TCP e IP.
# Beispiel: Paket-Trace an Firewall-Interface
tcpdump -ni eth0 -w /tmp/fw_eth0.pcap 'tcp and host 10.0.0.5'
# parallel auf Gegenstelle
tcpdump -ni eth1 -w /tmp/switch_eth1.pcap 'tcp and host 10.0.0.5'
3) Verificare la policy PMTUD
I firewall non devono bloccare ICMP in modo indiscriminato. Controllate le regole di filtraggio ICMP e, se necessario, attivate temporaneamente i log per ICMP Fragmentation Needed.
4) Policy di hashing per servizi stateful
Per carichi VPN, IPSec o proxy stateful si raccomanda un hash L3/L4 che consideri porta sorgente e destinazione. Evitate hashing puramente L2 in presenza di molte sessioni dalla stessa range IP.
Runbook operativo: playbook per incidenti LACP
Un runbook snello aumenta la probabilità di un rapido ripristino. Importante: responsabilità chiare, passi comunicabili, preservare la telemetria.
Passaggi d’emergenza (versione breve)
- Confermare l’allarme e documentare le conseguenze (VLAN, servizi interessati).
- Esportare snapshot delle configurazioni e dei log rilevanti (Switch, Firewall, Host).
- Disabilitare in modo controllato un Member alla volta e osservare (max 30s tra le modifiche).
- In presenza di indicazione chiara di guasto del Member: mettere fuori servizio la porta, attivare LAN/trasceiver di riserva.
- Se è coinvolto MLAG: verificare il Peer-Link, se necessario isolare temporaneamente il Peer e ripristinare il funzionamento in Single-Chassis.
Esempi di esportazione di configurazione/log
# Switch: Konfiguration sichern (Beispiel SSH-Session)
show running-config | redirect flash:running-config-$(date +%F).txt
show logging | redirect flash:logs-$(date +%F).txt
# Firewall: Sessions und Cluster-Status
show session summary
show cluster status
Monitoraggio e controlli preventivi
Automatizzate i seguenti controlli per ricevere avvisi precoci:
- Conteggio membri per LAG e modifiche inattese
- Cambi di stato LACP (Partner-ID-Wechsel, suspended)
- Rate di errore PMTU e messaggi ICMP di frammentazione
- Rate di MAC‑flapping per VLAN
- Latenza del Peer-Link, drop e errori di keepalive (per MLAG/vPC)
Le metriche possono essere raccolte via SNMP, Telemetry (gNMI/streaming) o tramite syslog/collectd. Stabilite delle baseline e generate allarmi in caso di deviazioni, non solo al superamento di soglie.
Best Practices riassunte
- Simmetria di configurazione: Trunk/VLAN/MTU/Speed/Auto-Neg identici su entrambe le estremità.
- Timing: allineare LACP-Rate e timeout su entrambe le parti.
- Min-Links: definire il numero minimo di link e testare scenari di degradazione.
- MLAG: monitorare Peer-Link e keepalive come servizi separati.
- Firewall: monitorare attivamente PMTUD e lo stato delle sessioni; adattare l’hashing per i workload stateful.
- Documentazione: definire runbook, backup di configurazione, scenari di test e processo di RCA.
Considerazioni finali
Una Link-Aggregation stabile si ottiene con coerenza: stessi parametri di porta, design coerente di VLAN e MTU, policy di hashing adeguata e, in scenari multi‑chassis, un Peer‑Link sano con una strategia chiara per lo split‑brain. Sintomi simili a deadlock sono spesso il risultato della sovrapposizione di più meccanismi di protezione (LACP, STP, Loop‑Protection, MLAG/Keepalive). Con una sequenza di verifica chiara, esperimenti precisi (disabilitare un membro, testare MTU, correlare eventi di flap/MAC) e una strategia di rollback pragmatica ridurrete i tempi di indisponibilità e getterete le basi per un’operatività affidabile.
Link-Aggregation (LACP) in esercizio, automazione e integrazione di sistema
Oltre alla sola configurazione di rete, è il funzionamento operativo a determinare l’affidabilità: come vengono tracciate le modifiche LACP, come reagisce il monitoring e come si integra il livello di rete nelle vostre soluzioni aziendali digitali e nella CMDB? Qui risiedono spesso i rischi maggiori — non perché LACP fallisca, ma perché processi, telemetria e peculiarità dei vendor non vengono confrontati automaticamente.
Aspetti operativi essenziali e raccomandazioni:
- Rilevare automaticamente la Config‑Drift: Esportate continuamente le configurazioni LAG e delle porte in un repository di versionamento. In questo modo è possibile applicare rapidamente un rollback e le modifiche risultano verificabili in audit.
- Documentare le Vendor‑Quirks: Algoritmi di hashing basati su ASIC, CPU‑offload o timer LACP di default differenti (Cisco vs. Arista vs. Broadcom‑Silicon) causano comportamenti non omogenei. Registrate queste deviazioni nell’inventario e verificate la compatibilità firmware prima dei roll-out.
- Protezione della Control‑Plane: Molti LACP‑flap generano elevato carico CPU sui controller di switch. Limiti, rate‑limit per LACPDU e segnalazioni mirate prevengono la degenerazione della control‑plane.
- Integrationsschnittstellen: Inviate le modifiche di stato LACP al vostro logging/telemetria (gNMI, SNMP‑Traps, syslog). Collegate gli allarmi al ticketing e al vostro inventario, in modo che le modifiche di configurazione e i ricambi fisici (Transceiver) vengano assegnati automaticamente.
Controllo pratico per l’automazione: un semplice SSH‑loop raccoglie gli ID dei partner LACP da più dispositivi e mette in evidenza le discrepanze. Adattate i comandi del vendor alla vostra CLI.
#!/usr/bin/env bash
# hosts.txt enthält eine Zeile pro Switch
while read host; do
echo "== $host ==";
ssh admin@${host} "show lacp neighbor || show etherchannel summary" 2>/dev/null | sed -n '1,120p'
done < hosts.txt
Utilizzate questo risultato come base per un diff automatizzato rispetto all’ultimo snapshot di configurazione persistito. Se viene rilevata una discrepanza, avviate un Canary‑Test: disattivazione temporanea di un membro in una VLAN di laboratorio, health‑check automatico e, in caso di esito positivo, rollout controllato.
Infine: collegate gli eventi di monitoring ai vostri processi operativi. Un cambiamento LACP non dovrebbe generare solo un allarme, ma fornire automaticamente il contesto (ultimo commit di configurazione, versione firmware, cluster firewall assegnati). In questo modo ridurrete il MTTR ed eviterete che problemi di infrastruttura provochino interruzioni alla vostra Business‑Software e alle soluzioni software di processo.