Vai al contenuto
⚠️ Warning: Extraordinary electrical maintenance – Scheduled shutdown of the Cloud garr-ct1 region (Catania) from 22 to 29 July 2025. For more details, please read the maintenance notice.

Test di channel bonding con iperf

Questa pagina riporta raccomandazioni su come eseguire test di performance di rete con iperf in uno scenario di channel bonding. In particolare, assumiamo un setup con 4 NIC Broadcom 10Gbps in bonding ma le raccomandazioni dovrebbero essere applicabili a setup simili.

Prima controlla la configurazione corrente e la policy di hash di trasmissione1:

# cat /proc/net/bonding/bond0 | grep "Interface"
Slave Interface: eno4
Slave Interface: eno3
Slave Interface: eno2
Slave Interface: eno1

# cat /proc/net/bonding/bond0 | head
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer3+4 (1)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0
Peer Notification Delay (ms): 0

Quando esegui i test:

  • monitora le statistiche generali delle interfacce usando iptraf-ng2

  • usa iperf3 su entrambi i lati

  • probabilmente non hai bisogno dell'opzione -P "parallel streams" di iperf. I server possono solitamente generare 10Gbps su un singolo stream (e nota che iperf3 userebbe una singola CPU4). Meglio avviare diversi server iperf su porte diverse.

  • lato server, per TCP puoi usare: iperf -s -i 3 -p 5002

  • lato client, per TCP puoi usare: iperf -c <dest ip address> -i 3 -p 5002 -t 3600

  • lato server, per UDP puoi usare: iperf -s -i 3 -u -p 5002

  • lato client, per UDP puoi usare: iperf -c <dest ip address> -i 3 -p 5002 -t 3600 -u -b 12G

  • quando testi UDP, le prestazioni potrebbero essere solo una frazione di quelle ottenute per TCP. Questo potrebbe essere dovuto all'accelerazione hardware mancante/non attivata sulla NIC

  • probabilmente noterai che a volte diversi stream impiegano la stessa interfaccia fisica nel bonding. Questo potrebbe essere dovuto alla policy di hash di trasmissione configurata che calcola lo stesso hash per entrambi gli stream. A seconda della policy di hash di trasmissione configurata, fermare e riavviare il client iperf cambierà la porta sorgente e può attivare un'interfaccia fisica diversa

  • l'algoritmo della policy di hash di trasmissione di Linux potrebbe differire dall'algoritmo usato dal tuo switch. Controlla la documentazione della policy di hash5 e usa il codice sorgente (Luke)6

  • tieni conto che in OpenStack il traffico VM è incapsulato in altri protocolli di tunneling (es. GRE, VXLAN), quindi l'algoritmo della policy di hash di trasmissione sarà applicato agli header esterni del tunnel

  • prova a usare VM su host diversi per vedere se vengono impiegate interfacce fisiche diverse

  • probabilmente non hai bisogno di ottimizzazioni basate su NUMA78910 se hai NIC da 10Gbps

  1. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-using_channel_bonding ↩

  2. https://github.com/iptraf-ng/iptraf-ng ↩

  3. https://iperf.fr/iperf-doc.php ↩

  4. https://fasterdata.es.net/performance-testing/network-troubleshooting-tools/iperf/multi-stream-iperf3/ ↩

  5. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/networking_guide/sec-using_channel_bonding ↩

  6. https://github.com/torvalds/linux/tree/master/drivers/net/bonding https://elixir.bootlin.com/linux/latest/source/drivers/net/bonding/bond_main.c#L3429 ↩

  7. https://dropbox.tech/infrastructure/optimizing-web-servers-for-high-throughput-and-low-latency ↩

  8. https://h50146.www5.hpe.com/products/software/oe/linux/mainstream/support/whitepaper/pdfs/4AA4-9294ENW-2013.pdf ↩

  9. https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/virtualization/ch33s08 ↩

  10. https://fasterdata.es.net/host-tuning/linux/100g-tuning/ ↩