Hi Leute!
Ich möchte zwei eingerichtete Tunneldevices tun0 und tun1 via ifenslave ... verknüpfen:
ifconfig (Auszug): eth0 Link encap:Ethernet HWaddr 00:13:20:E9:1B:6F inet addr:192.93.15.11 Bcast:192.93.15.255 Mask:255.255.255.0 inet6 addr: fe80::213:20ff:fee9:1b6f/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:492 (492.0 b) Base address:0x2000 Memory:28180000-281a0000
eth1 Link encap:Ethernet HWaddr 00:13:20:E9:1B:70 inet addr:192.93.15.21 Bcast:192.93.15.255 Mask:255.255.255.0 inet6 addr: fe80::213:20ff:fee9:1b70/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:6 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:492 (492.0 b) Base address:0x1100 Memory:28020000-28040000
tun0 Link encap:IPIP Tunnel HWaddr inet addr:10.0.1.1 P-t-P:10.0.1.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
tun1 Link encap:IPIP Tunnel HWaddr inet addr:10.0.3.1 P-t-P:10.0.3.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
ip tunnel: sit0: ipv6/ip remote any local any ttl 64 nopmtudisc tunl0: ip/ip remote any local any ttl inherit nopmtudisc tun0: ip/ip remote 192.93.15.14 local 192.93.15.11 ttl 255 tun1: ip/ip remote 192.93.15.24 local 192.93.15.21 ttl 255
Wenn ich jetzt das Bonding ausführe: modprobe bonding miimon=100 mode=5 ifconfig bond0 192.93.15.100 ifenslave bond0 tun0 tun1
dann meckert er: Could not set MAC address of bond0: Invalid argument SIOCBONDENSLAVE: Operation not supported. SIOCBONDENSLAVE: Operation not supported.
...und unter /var/log/messages: Sep 26 18:34:42 wlan-thea2-1 kernel: Ethernet Channel Bonding Driver: v3.0.1 (January 9, 2006) Sep 26 18:34:42 wlan-thea2-1 kernel: bonding: MII link monitoring set to 100 ms Sep 26 18:34:42 wlan-thea2-1 kernel: bonding: bond0: Error: The slave device you specified does not support setting the MAC address. Your kernel likely does not support slave devices.
Hmmm...!?! hat dazu Jemand eine Idee? System ist SuSE 10.1 mit Kernel: Linux version 2.6.16.13-4-default.
Vielen Dank schon mal!!!
Gruß! Peter.
Hallo Peter,
On Tue, Sep 26, 2006 at 18:55:13 +0200, pzabelt@sz-online.de wrote:
Ich moechte zwei eingerichtete Tunneldevices tun0 und tun1 via ifenslave ... verknuepfen:
ifconfig (Auszug):
[...]
tun0 Link encap:IPIP Tunnel HWaddr inet addr:10.0.1.1 P-t-P:10.0.1.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
[...]
ifenslave bond0 tun0 tun1
dann meckert er: Could not set MAC address of bond0: Invalid argument SIOCBONDENSLAVE: Operation not supported.
tun-Interfaces haben keine eigene MAC-Adresse, sie transportieren nur IP-Pakete ohne Ethernet-Header. Fuer Bonding braucht man anscheinend Interfaces, die komplette Ethernet-Frames transportieren. Dafuer gibt es tap-Interfaces. Hast Du Einfluss darauf, wie die tun/tap-Interfaces erzeugt/konfiguriert werden?
Gruss, Chris
Hallo Chris!
Hallo Peter,
On Tue, Sep 26, 2006 at 18:55:13 +0200, pzabelt@sz-online.de wrote:
Ich moechte zwei eingerichtete Tunneldevices tun0 und tun1 via ifenslave ... verknuepfen:
ifconfig (Auszug):
[...]
tun0 Link encap:IPIP Tunnel HWaddr inet addr:10.0.1.1 P-t-P:10.0.1.1 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MTU:1480 Metric:1
[...]
ifenslave bond0 tun0 tun1
dann meckert er: Could not set MAC address of bond0: Invalid argument SIOCBONDENSLAVE: Operation not supported.
tun-Interfaces haben keine eigene MAC-Adresse, sie transportieren nur IP-Pakete ohne Ethernet-Header. Fuer Bonding braucht man anscheinend Interfaces, die komplette Ethernet-Frames transportieren. Dafuer gibt es tap-Interfaces. Hast Du Einfluss darauf, wie die tun/tap-Interfaces erzeugt/konfiguriert werden?
Gruss, Chris
Danke für deine Antwort! Ja, ich kann tun (<- schon wieder beim Thema :-) ) und lassen, was ich will, ist sowieso erst mal 'ne Teststrecke, die "heiße" WLAN-Leitung läuft soweit schon lange, ist nur nicht ausfallsicher konzipiert worden (von mir :-( ) und nun kann ich mit nagelneuen Geräten bissel spielen... Aber: tun-devs sind mir ein Begriff, tap = ??? Ich wer' mal dazu bissel googlen, vielleicht kannst du mir aber auch noch etwas mehr Info rüberbringen?
Danke & Gruß! Peter.
Am Dienstag, 26. September 2006 18:55 schrieb pzabelt@sz-online.de:
Hi Leute!
Hi.
Ich möchte zwei eingerichtete Tunneldevices tun0 und tun1 via ifenslave ... verknüpfen:
Wieso versuchst Du eigentlich einen bond über logische Netzwerkschnittstellen zu legen? Ziel des Bonding ist doch eigentlich der Ausfall von physischer Hardware. Warum legst Du das bond nicht über eth0 und eth1 und die tun-devices auf das bonding-Interface?
Was sind denn die tun-Devices? VPN-Verbindungen?
MfG, Silvio
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 27.09.2006 um 08:05 schrieb Silvio Schmidt:
Am Dienstag, 26. September 2006 18:55 schrieb pzabelt@sz-online.de:
Hi Leute!
Hi.
Ich möchte zwei eingerichtete Tunneldevices tun0 und tun1 via ifenslave ... verknüpfen:
Wieso versuchst Du eigentlich einen bond über logische Netzwerkschnittstellen zu legen? Ziel des Bonding ist doch eigentlich der Ausfall von physischer Hardware.
_Das_ wäre mir neu. *SCNR*.
- -- mfg, Steffen Liebergeld
A charlatan makes obscure what is clear; a thinker makes clear what is obscure. -- Hugh Kingsmill
Moin!
Am 27.09.2006 um 08:05 schrieb Silvio Schmidt:
Am Dienstag, 26. September 2006 18:55 schrieb pzabelt@sz-online.de:
Hi Leute!
Hi.
Ich möchte zwei eingerichtete Tunneldevices tun0 und tun1 via ifenslave ... verknüpfen:
Wieso versuchst Du eigentlich einen bond über logische Netzwerkschnittstellen zu legen? Ziel des Bonding ist doch eigentlich der Ausfall von physischer Hardware.
_Das_ wäre mir neu. *SCNR*.
mfg, Steffen Liebergeld
Wie soll ich bitte DAS verstehen???
Gruß! Peter.
Hi Silvio & all!
Hi.
Ich möchte zwei eingerichtete Tunneldevices tun0 und tun1 via ifenslave ... verknüpfen:
Wieso versuchst Du eigentlich einen bond über logische Netzwerkschnittstellen zu legen? Ziel des Bonding ist doch eigentlich der Ausfall von physischer Hardware. Warum legst Du das bond nicht über eth0 und eth1 und die tun-devices auf das bonding-Interface?
Was sind denn die tun-Devices? VPN-Verbindungen?
MfG, Silvio
Vielleicht habe ich ja da einen Gedankenfehler und muss nochmal bissel Text nachreichen: Also: Ziel ist es, zwei Netzwerke über zwei WLAN-Strecken mit (quasi) doppelter Bandbreite ausfallsicher zu verknüpfen. Wären zwischen den beiden Linux-Routern, um die es hier geht, Netzwerkkabel o.ä., wäre das kein Problem. Beim Channelbonding merkt m.W. der Kernel-Treiber: Upps, da ist ein Link ausgefallen, da nehm ich nur noch das andere, noch funktionierende! Nun habe ich aber WLAN-Router (Dazu noch dumme von D-Link, die weder Traffic messen lassen noch Logs zeigen!) dazwischen, so dass zwar eine Seite den ausgefallenen Link merkt und "umschaltet", die andere aber nicht, da deren eth-device immer noch den Link zum WLAN-Router hat!!! Deswegen habe ich versucht, einen simplen Tunnel (Absicherung kommt später noch nach!) zu bauen, so dass das Device tun0 "merkt", das sein Link zum gegenüberliegenden Ende des Tunnels (also über die WLAN-Wolke hinweg) weg ist und deswegen beide umschalten! Hier nochmal 'ne Skizze:
LINUX-Router---WLAN-Device-----W-L A N - "W O L K E"------WLAN-Device---LINUX-Router
IST eth0---<Device-IP>------------------------------------------<Device-IP>---eth0 eth1----<Device-IP>------------------------------------------<Device-IP>---eth1 SOLL tun0---------------------------------------------------------------------------------tun0 tun1----------------------------------------------------------------------------------tun1
Bin ich da völlig auf dem falschen Dampfer, wenn ich versuche, die beiden tun-Devices zu bonden??? Es scheint daran zu liegen, dass ich den tun's keine HWAddr verpassen kann!?!
Gruß! Peter.
Am Mittwoch, 27. September 2006 08:48 schrieb pzabelt@sz-online.de:
Hi Silvio & all!
Hi.
Also: Ziel ist es, zwei Netzwerke über zwei WLAN-Strecken mit (quasi) doppelter Bandbreite ausfallsicher zu verknüpfen.
Du hast also zwei Funkstrecken die zwei Netzwerke miteinander verbinden? In dem WLAN selbst sind keine Clients oder den WLAN-Routern?
Ich glaube dann kann es auch ohne die tun-devices gehen. Ich habe gerade mal die bonding.txt der Kernel-Sourcen gelesen ( http://www.nwlab.net/art/teaming/bonding.txt ) . Folgendes könnte interessant sein:
<schnipp> It is critical that either the miimon or arp_interval and arp_ip_target parameters be specified, otherwise serious network degradation will occur during link failures.
arp_interval
Specifies the ARP monitoring frequency in milli-seconds. If ARP monitoring is used in a load-balancing mode (mode 0 or 2), the switch should be configured in a mode that evenly distributes packets across all links - such as round-robin. If the switch is configured to distribute the packets in an XOR fashion, all replies from the ARP targets will be received on the same link which could cause the other team members to fail. ARP monitoring should not be used in conjunction with miimon. A value of 0 disables ARP monitoring. The default value is 0.
arp_ip_target
Specifies the ip addresses to use when arp_interval is > 0. These are the targets of the ARP request sent to determine the health of the link to the targets. Specify these values in ddd.ddd.ddd.ddd format. Multiple ip adresses must be seperated by a comma. At least one ip address needs to be given for ARP monitoring to work. The maximum number of targets that can be specified is set at 16.
...
Limitations =========== The main limitations are : - only the link status is monitored. If the switch on the other side is partially down (e.g. doesn't forward anymore, but the link is OK), the link won't be disabled. Another way to check for a dead link could be to count incoming frames on a heavily loaded host. This is not applicable to small servers, but may be useful when the front switches send multicast information on their links (e.g. VRRP), or even health-check the servers. Use the arp_interval/arp_ip_target parameters to count incoming/outgoing frames. <schnapp>
Zumindest wenn Du "konstanten" Traffic hast kann es so funktionieren.
MfG, Silvio
Hi Silvio!
Also: Ziel ist es, zwei Netzwerke über zwei WLAN-Strecken mit (quasi) doppelter Bandbreite ausfallsicher zu verknüpfen.
Du hast also zwei Funkstrecken die zwei Netzwerke miteinander verbinden? In dem WLAN selbst sind keine Clients oder den WLAN-Routern?
Nein!
Ich glaube dann kann es auch ohne die tun-devices gehen. Ich habe gerade mal die bonding.txt der Kernel-Sourcen gelesen ( http://www.nwlab.net/art/teaming/bonding.txt ) . Folgendes könnte interessant sein:
....
Habe ich alles durch, geht aber nicht (siehe voriges Posting!): Wenn einer der Linux-Router auf einer Leitung erkennt: Hoppla, das WLAN-Gerät ist tot! dann macht dort der Kernel-Bonding-Treiber schwupps und nimmt nur noch das zweite Device am Linux-Router! Der andere Linux-Router merkt aber an keinem seiner devices einen Link-Down! Weil dort alle Links zu seinen beiden W_LAN-Routern noch ok sind! Und genau hier legt sich das ganze Konstrukt (welches ich schon am Laufen hatte) die Karten!
Trotzdem Danke! Peter.
Am Mittwoch, 27. September 2006 12:06 schrieb pzabelt@sz-online.de:
Hi Silvio!
Hi Peter.
Habe ich alles durch, geht aber nicht (siehe voriges Posting!): Wenn einer der Linux-Router auf einer Leitung erkennt: Hoppla, das WLAN-Gerät ist tot! dann macht dort der Kernel-Bonding-Treiber schwupps und nimmt nur noch das zweite Device am Linux-Router! Der andere Linux-Router merkt aber an keinem seiner devices einen Link-Down! Weil dort alle Links zu seinen beiden W_LAN-Routern noch ok sind!
Das habe ich schon verstanden.
Ich nehme mal an Dein Setup sieht ungefähr so aus:
|------(WL1a) ))) ((( (WL1b)------| LR LR |------(WL2a) ))) ((( (WL2b)------|
LR .. Linux Router WL .. WLAN Router
Wenn also eine der Funkstrecken unterbrochen ist ist der Link zwischen LR und WL noch aktiv. mii prüft den physischen Link und wird natürlich scheitern. Mit arp wird allerdings gerprüft ob Pakete von einer bestimmten Adresse ankommen. Also kann der eine LR prüfen ob Pakete des anderen LR über die Interface WL1 oder WL2 ankommen. Deswegen ist es hier ja wichtig das regelmäßig Pakete ankommen. Vielleicht kann man mit einem im Hintergrund laufen arping nachhelfen die beide Router regelmäßig über beide Interfaces austauschen.
Allerdings habe ich mit so einem Szenario keine Erfahrung. Vielleicht kann jemand mit mehr Netzwerk-Know-How mal sagen was er davon hält.
Trotzdem Danke! Peter.
MfG, Silvio
Hallo Silvio & all!
Ich nehme mal an Dein Setup sieht ungefähr so aus:
|------(WL1a) ))) ((( (WL1b)------|LR LR |------(WL2a) ))) ((( (WL2b)------|
LR .. Linux Router WL .. WLAN Router
....
Ja, genau so sieht mein Problem aus....aber...ich bin gerade in meinen "Grundfesten" Durchgeschüttelt worden und beende da erst mal den Thread:
Da ich mich offensichtlich total verhaspelt(?) habe, habe ich das ganze Tunneling und das ganze Bonding abgeschaltet. Ich habe also nur noch die reinen Verbindungen, wie oben von Silvio gezeichnet! Ich habe mal mit ksysguard gemessen und bin dem Mist auf die Spur gekommen... Ich habe mich vom rechten zum linken LR per ssh connected und dort richtig Traffic gemacht (Im mc was suchen lassen). Und was soll ich sagen?! Die Pakete laufen wie folgt: ausgehender Traffic von rechts nach links über die "obere" Leitung, aber einkommender ("Rück-")Traffic kommt auf "unterer" Leitung rein! Da muss ich mir wohl erst mal was zum Routing überlegen und melde mich später wieder!
Danke! Peter.
Zusatz zu meinem vorherigen Post.
Offenbar habe ich die bonding.txt selbst falsch verstanden. Mit arp_interval sendet offenbar das "bonding" selbst die passenden Pakete an das arp_ip_target. Also gibts Du einfach die IP-Adressen des gegenüberliegenden Routers an.
Wenn ich das richtig verstehe wird dann auf beiden physischen Interfaces versucht den gegenüberliegenden Router anzupingen. Wenn die Funkstrecke auf einer Seite zusammenbricht sollte der arping scheiter obwohl der Link zwischen LR und WL noch besteht.
MfG, Silvio
lug-dd@mailman.schlittermann.de
-
Christian Perle -
pzabelt＠sz-online.de -
Silvio Schmidt -
Steffen Liebergeld