Administrace komentářů

Mám SUN Blade centrum a v něm dva interní ethernetové switche, které zprostředkují komunikaci do jedné IPv4 sítě. Každá žiletka má tudíž dvě síťová rozhraní připojená do sítě. Chci oživit failover bonding, aby to komunikovalo, i když se rozbije interní switch nebo něco jiného na cestě do sítě. Síť je na linkové úrovni složitě strukturovaná a je rozváděná do různých lokalit.

Žiletky slouží pro KVM virtualizaci, proto mají aktivní virtuální bridge, ten spojuje vnější fyzickou síť s vnitřní virtuální sítí. Všecko běhá přes br0 a stávající konfigurace na testovací žiletce je

~ 0> brctl show br0
bridge name	bridge id		STP enabled	interfaces
br0		8000.001b21da8e28	no		eth1
~ 0> ip addr

  . . .

3: eth1: -BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP qlen 1000
    link/ether 00:1b:21:da:8e:28 brd ff:ff:ff:ff:ff:ff

   . . .

12: br0: -BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
    link/ether 00:1b:21:da:8e:28 brd ff:ff:ff:ff:ff:ff
    inet 10.5.75.142/24 brd 10.5.75.255 scope global br0
    inet6 fe80::21b:21ff:feda:8e28/64 scope link 
       valid_lft forever preferred_lft forever
~ 0> 

Z konzoly shodím eth1 a vyndám ho z br0. Potom si udělám bonding:

~ 0> modprobe bonding mode=1  arp_interval=1000 arp_ip_target=10.5.75.140 arp_validate=1
~ 0> ip link set bond0 up
~ 0> ip link set eth1  up
~ 0> ip link set eth4  up
~ 0> ifenslave bond0 eth1 eth4
~ 0> brctl addif br0 bond0

Načež mi to nějak komunikuje, ale odezva je mizerná, ve statistice bondingu přibývají výpadky linky střídavě eth1 a eth4. messages ukazují:

Feb 12 15:12:38 blade5 kernel: [ 1565.997923] device eth4 entered promiscuous mode
Feb 12 15:12:38 blade5 kernel: [ 1565.998178] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0
Feb 12 15:12:39 blade5 kernel: [ 1566.997126] bonding: bond0: link status definitely up for interface eth1.
Feb 12 15:12:39 blade5 kernel: [ 1566.997137] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0
Feb 12 15:12:40 blade5 kernel: [ 1567.996676] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0
Feb 12 15:12:41 blade5 kernel: [ 1568.996217] bonding: bond0: link status definitely down for interface eth4, disabling it
Feb 12 15:12:41 blade5 kernel: [ 1568.996224] bonding: bond0: making interface eth1 the new active one.
Feb 12 15:12:41 blade5 kernel: [ 1568.996228] device eth4 left promiscuous mode
Feb 12 15:12:41 blade5 kernel: [ 1568.996559] device eth1 entered promiscuous mode
Feb 12 15:12:41 blade5 kernel: [ 1568.996818] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0
Feb 12 15:12:42 blade5 kernel: [ 1569.995776] bonding: bond0: link status definitely up for interface eth4.
Feb 12 15:12:42 blade5 kernel: [ 1569.995786] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0
Feb 12 15:12:43 blade5 kernel: [ 1570.995307] bonding: bond0: no path to arp_ip_target 10.5.75.140 via rt.dev br0
Feb 12 15:12:44 blade5 kernel: [ 1571.994850] bonding: bond0: link status definitely down for interface eth1, disabling it
Feb 12 15:12:44 blade5 kernel: [ 1571.994857] bonding: bond0: making interface eth4 the new active one.
Feb 12 15:12:44 blade5 kernel: [ 1571.994861] device eth1 left promiscuous mode

Pořád dokola. Na testovacím stroji trvale existuje ARP záznam cílového stroje 10.5.75.140 . Naopak na cílovém stroji vůbec neexistuje ARP záznam testovacího stroje. Na cílovém stroji jsem chytal pakety a od testovacího stroje jsem neviděl nic. Možná jsem se špatně díval, hledal jsem IP komunikaci. Nemá to být něco jiného?

Při aktivním bondingu mi ip link ukazuje, že rozhraní eth1, eth4, bond0 mají všechny stejnou MAC adresu, a to tu, kterou měl původně eth1. Možná že bond0 posílá testovací pakety po aktivním rozhraní, ale pakety nedojdou, protože br0 pakety ukradne. V tom případě by se aktivní cesta považovala za nefunkční a to by byl důvod flapování. Ale nevím, byla by prosím, nějaká rada?