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 ?
Hab's rausgefunden: schließe ich einen zweiten switch an, ist dies eine Netzwerktopologieänderung, und die sorgt dafür, daß STP 30sec. lange alle Ports blockiert. http://de.wikipedia.org/wiki/Spanning_Tree_Protocol : "Diese Neuberechnung des Baumes dauert im schlimmsten Fall bis zu 30 Sekunden. Während dieser Zeit dürfen die Spanning-Tree-fähigen Bridges außer Spanning-Tree-Informationen keine Pakete im Netz weiterleiten." 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