Bernd Lentes schrieb:
Hi,
ich habe ein Problem mit einem bonding device: ich habe zwei Ethernetintfaces zu einem bond zusammengefaßt. Die eth's hängen am selben switch. Meine /etc/sysconfig/network/ifcfg-bond0 sieht wie folgt aus:
======================= BONDING_MASTER='yes' BONDING_MODULE_OPTS='mode=active-backup arp_interval=5000 arp_ip_target=146.107.1.88,146.107.8.88,146.107.1.40,146.107.3 .101, arp_validate=1' BONDING_SLAVE0='eth0' BONDING_SLAVE1='eth1' BOOTPROTO='static' BROADCAST='' ETHTOOL_OPTIONS='' IPADDR='146.107.235.132/24' MTU='' NAME='' NETWORK='' REMOTE_IPADDR='' STARTMODE='auto' USERCONTROL='no' =======================
Mit dieser Konfiguration schmeißt mir /var/log/messages permant Fehler:
================================== ... Dec 5 17:05:39 SUNHB58820 kernel: [353590.799505] bonding: bond0: link status definitely down for interface eth1, disabling it Dec 5 17:05:39 SUNHB58820 kernel: [353590.799509] bonding: bond0: making interface eth0 the new active one. Dec 5 17:05:44 SUNHB58820 kernel: [353595.797963] bonding: bond0: link status definitely up for interface eth1. Dec 5 17:05:49 SUNHB58820 kernel: [353600.796362] bonding: bond0: link status definitely down for interface eth0, disabling it Dec 5 17:05:49 SUNHB58820 kernel: [353600.796366] bonding: bond0: making interface eth1 the new active one. Dec 5 17:05:54 SUNHB58820 kernel: [353605.794882] bonding: bond0: link status definitely up for interface eth0. Dec 5 17:05:59 SUNHB58820 kernel: [353610.793334] bonding: bond0: link status definitely down for interface eth1, disabling it Dec 5 17:05:59 SUNHB58820 kernel: [353610.793338] bonding: bond0: making interface eth0 the new active one. Dec 5 17:06:04 SUNHB58820 kernel: [353615.791842] bonding: bond0: link status definitely up for interface eth1. Dec 5 17:06:09 SUNHB58820 kernel: [353620.794618] bonding: bond0: link status definitely down for interface eth0, disabling it Dec 5 17:06:09 SUNHB58820 kernel: [353620.794623] bonding: bond0: making interface eth1 the new active one. ... ==================================
Ich verstehe aber nicht wieso. Mit geht es vor allem um HA. Daher bonding, und mittelfristig sollen die beiden eth's auch an verschiedenen Switches hängen.
Außerdem sagt /proc/net/bonding/bond0:
========================= Ethernet Channel Bonding Driver: v3.5.0 (November 4, 2008) Bonding Mode: fault-tolerance (active-backup) Primary Slave: None Currently Active Slave: eth1 MII Status: up MII Polling Interval (ms): 0 Up Delay (ms): 0 Down Delay (ms): 0 ARP Polling Interval (ms): 5000 ARP IP target/s (n.n.n.n form): 146.107.1.88, 146.107.8.88, 146.107.1.40, 146.107.3.101
Slave Interface: eth0 MII Status: up Link Failure Count: 89 Permanent HW addr: 68:b5:99:c2:4a:36
Slave Interface: eth1 MII Status: up Link Failure Count: 89 Permanent HW addr: 68:b5:99:c2:4a:37 ==========================
Woher kommt der MII Status ? Ich habe gemäß /usr/src/linux/Documentation/networking/bonding.txt /sys/class/net/bond0/bonding/miimon auf 0 gesetzt, womit MII link monitoring ausgeschaltet sein sollte. Der MII Status ändert sich übrigens auch, wenn ich mir /proc/net/bonding/bond0 öfters anschaue.
Setze ich arp_validate auf 0, hat der Spuk im log sofort ein Ende. Wofür ist denn arp_validate genau gut ? So wie ich das verstehe, wird der arp-reply genau untersucht, ob er auch zum anfragenden slave gehört. Aber das sollte doch bei arp_validate=1 der Fall sein. Wieso wird da das bonding device so durcheinander gebracht ?
Hi, den ersten Fehler habe ich gefunden: ich kann als arp_ip_target natürlich nur hosts angeben, die im gleichen Subnetz liegen. Von Rechnern außerhalb des Subnetzes kriege ich wohl kaum einen arp-reply. Jetzt aber nächstes Problem: Momentan hängen beide eth's noch am gleichen switch. Verbinde ich nur einen zweiten switch (baugleich, Cisco 300-28) mit dem ersten, kriege ich nach einigen Sekunden wieder Fehler im log: Dec 6 14:08:32 SUNHB58820 kernel: [429341.423530] bonding: bond0: making interface eth0 the new active one. Dec 6 14:08:33 SUNHB58820 kernel: [429342.423281] bonding: bond0: link status definitely up for interface eth1. hier schließe ich den zweiten switch an. Dec 6 14:09:16 SUNHB58820 kernel: [429385.410377] bonding: bond0: link status definitely down for interface eth0, disabling it Dec 6 14:09:16 SUNHB58820 kernel: [429385.410382] bonding: bond0: making interface eth1 the new active one. Dec 6 14:09:17 SUNHB58820 kernel: [429386.410132] bonding: bond0: link status definitely up for interface eth0. Dec 6 14:09:18 SUNHB58820 kernel: [429387.409835] bonding: bond0: link status definitely down for interface eth1, disabling it Dec 6 14:09:18 SUNHB58820 kernel: [429387.409839] bonding: bond0: making interface eth0 the new active one. ... Dec 6 14:09:41 SUNHB58820 kernel: [429410.404491] bonding: bond0: link status definitely up for interface eth0. Dec 6 14:09:42 SUNHB58820 kernel: [429411.402644] bonding: bond0: link status definitely down for interface eth1, disabling it Dec 6 14:09:42 SUNHB58820 kernel: [429411.402649] bonding: bond0: making interface eth0 the new active one. Dec 6 14:09:43 SUNHB58820 kernel: [429412.402375] bonding: bond0: link status definitely up for interface eth1. Dec 6 14:09:44 SUNHB58820 kernel: [429413.403596] bonding: bond0: link status definitely down for interface eth0, disabling it Dec 6 14:09:44 SUNHB58820 kernel: [429413.403600] bonding: bond0: making interface eth1 the new active one. Dec 6 14:09:45 SUNHB58820 kernel: [429414.401729] bonding: bond0: link status definitely up for interface eth0. Nach rund 30 Sekunden ist der Spuk vorbei. In dieser Zeit ist dann natürlich auch die Netzwerkverbindung weg: 64 bytes from www.helmholtz-muenchen.de (146.107.1.40): icmp_seq=22 ttl=62 time=0.302 ms 64 bytes from www.helmholtz-muenchen.de (146.107.1.40): icmp_seq=23 ttl=62 time=0.279 ms 64 bytes from www.helmholtz-muenchen.de (146.107.1.40): icmp_seq=24 ttl=62 time=0.253 ms 64 bytes from www.helmholtz-muenchen.de (146.107.1.40): icmp_seq=25 ttl=62 time=0.221 ms Switch anschließen 64 bytes from www.helmholtz-muenchen.de (146.107.1.40): icmp_seq=56 ttl=62 time=0.271 ms 64 bytes from www.helmholtz-muenchen.de (146.107.1.40): icmp_seq=57 ttl=62 time=0.309 ms 64 bytes from www.helmholtz-muenchen.de (146.107.1.40): icmp_seq=58 ttl=62 time=0.299 ms Woher kommt das ? Bernd Helmholtz Zentrum München Deutsches Forschungszentrum für Gesundheit und Umwelt (GmbH) Ingolstädter Landstr. 1 85764 Neuherberg www.helmholtz-muenchen.de Aufsichtsratsvorsitzende: MinDir´in Bärbel Brumme-Bothe Geschäftsführer: Prof. Dr. Günther Wess und Dr. Nikolaus Blum Registergericht: Amtsgericht München HRB 6466 USt-IdNr: DE 129521671 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org