Comment diagnostiquer-t-on les problèmes Linux LACP au niveau du noyau?
Existe-t-il une interface administrative ou diagnostique sous-jacente au pilote de liaison Linux afin de déterminer ce qui se passe en interne?
J'ai utilisé une agrégation de liaison entre les boîtes Linux et les commutateurs Cisco pendant de nombreuses années. Périodiquement, je rencontre une impasse lors de la configuration de nouvelles boîtes où le côté Linux ne répond tout simplement pas aux paquets Cisco Lacp. Je suivez méticuleusement un ensemble strict d'instructions pour chaque serveur, mais les résultats semblent varier.
Si la liaison contient une esclave ou huit, TCPDump montre des paquets LACP provenant de l'interrupteur sur toutes les interfaces liées et aucun paquets n'est jamais transmis. En fait, aucun paquet n'est une période transmise. rx_packets pour l'interface montre un trafic considérable, mais tx_packets est zéro. Il n'y a rien d'intéressant dans les journaux concernant MII ou la liaison. Il n'y a même aucune erreur.
Actuellement, je traite une boîte qui n'a que deux Nics. Pour le moment, je n'ai que d'ETH1 dans le lien. De toute évidence, il s'agit d'une configuration dégénérée. La situation ne change pas avec Eth0 et Eth1 dans le lien; Cela rend simplement plus difficile de travailler avec la machine lorsque la pile de réseau est complètement inférieure. Je peux la reconfigurer pour les deux Nics si nécessaire et passer par une interface administrative (DRAC), mais je ne peux pas copier-coller de la boîte de cette façon.
Quelques préliminaires:
- J'ai testé les nics, les ports et les câbles. Tout fonctionne comme prévu lorsque les interfaces ne sont pas liées.
- J'ai redémarré et confirmé que les modules se chargent correctement.
- J'ai essayé cela avec et sans la goulotte de VLAN; Peu importe que l'agrégation de liaison ait lieu en dessous de ce point dans la pile.
- Le commutateur fonctionne, des groupes de canaux joints allant à d'autres boîtes Linux. Les configurations sont plus ou moins identiques, même si les distributions, les noyaux et le matériel des boîtes Linux ne sont pas.
C'est Debian 8.6 téléchargé aujourd'hui.
Linux box 3.16.0-4-AMD64 #1 SMP Debian 3.16.36-1+deb8u2
(2016-10-19) x86_64 GNU/Linux
Une configuration abrégée:
iface eth1 inet manual
auto bond0
iface bond0 inet manual
slaves eth1
address 10.10.10.10
netmask 255.255.255.0
bond_mode 4
bond_miimon 100
bond_downdelay 200
bond_updelay 200
bond_xmit_hash_policy layer2+3
bond_lacp_rate slow
Certains État:
# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)
Bonding Mode: IEEE 802.3ad Dynamic link aggregation
Transmit Hash Policy: layer2+3 (2)
MII Status: down
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200
802.3ad info
LACP rate: slow
Min links: 0
Aggregator selection policy (ad_select): stable
bond bond0 has no active aggregator
Slave Interface: eth1
MII Status: down
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 78:2b:cb:5a:2b:3e
Aggregator ID: N/A
Slave queue ID: 0
Un enregistrement TCPdump entrant sur Eth1 de l'interrupteur:
22:18:47.333928 M 44:ad:d9:6c:8d:8f ethertype Slow Protocols (0x8809),
length 126: LACPv1, length 110
Actor Information TLV (0x01), length 20
System 44:ad:d9:6c:8d:80, System Priority 32768, Key 12,
Port 272, Port Priority 32768
State Flags [Activity, Aggregation, Synchronization,
Collecting, Distributing, Default]
Partner Information TLV (0x02), length 20
System 00:00:00:00:00:00, System Priority 0, Key 0, Port 0,
Port Priority 0
State Flags [none]
Collector Information TLV (0x03), length 16
Max Delay 32768
Terminator TLV (0x00), length 0
Le côté Cisco:
interface GigabitEthernet1/0/15
switchport trunk allowed vlan 100,101,102
switchport mode trunk
channel-group 12 mode active
end
interface Port-channel12
switchport trunk allowed vlan 100,101,102
switchport mode trunk
end
Finalement, l'interrupteur abandonne et l'interface entre en mode "autonome". S'il y a deux interfaces dans le groupe de canaux, ils les deux entrer en mode autonome.
#show etherchannel 12 sum
Flags: I - stand-alone
Group Port-channel Protocol Ports
------+-------------+-----------+-----------
12 Po12(SD) LACP Gi1/0/15(I)
J'ai accumulé mon cerveau en toute la journée. J'ai choisi et reconstruit la configuration Cisco plusieurs fois. Si ce n'était pas pour le TCPDump montrant des paquets LacPv1 arrivant sur l'interface Linux, je regarderais le côté Cisco. Hélas, le noyau Linux semble ignorer complètement les paquets. Mon prochain arrêt est le code source du noyau et le pire des cas, noyau sur mesure pour les diagnostics. Espérons que quelqu'un a un aperçu du pilote de liaison et de ce qui la fait courir correctement.
Le pilote de liaison n'expose aucun débogage de la machine d'état lacpo à l'espace utilisateur, vous devez connaître le code et utiliser l'instrumentation du noyau comme SystemTap ou écrire votre propre débogage dans votre propre module de liaison et la compiler pour votre noyau.
Cependant, le problème est que le conducteur de liaison pense que l'esclave est en panne:
MII Status: down
Vous dites que vous êtes confiant que l'esclave a un lien, nous allons donc ignorer un problème physique.
Soit le lien/esclave n'est pas configuré correctement et l'esclave est bas de l'administrateur, ou le pilote utilisé ne prend pas en charge netif_carrier() à l'intérieur du noyau et vous devez définir use_carrier=0 les options de votre module de liaison.
Essayez de définir les propriétés de Lacp suivantes sur le côté Linux à:
bond_downdelay 0
bond_updelay 0
bond_xmit_hash_policy layer3+4
bond_lacp_rate fast
Sur Cisco Côté, recréez le canal portuaire et permettez la vitesse rapide de la LACP:
port-channel load-balance src-dst-ip
interface GigabitEthernet1/0/15
lacp rate fast
exit
Si le commutateur Cisco ne peut pas définir lacp rate fast, alors vous devez mettre à jour son iOS.
Cisco travaille avec la lacp pire que Linux. Régler port-channel load-balance src-dst-port Si votre commutateur Cisco peut.