Hi,
folgendes Szenario: Ich hab ein Cluster aus 3 VMware ESX 4.0, die getrennt durch eine Wireless Bridge (openwrt) in meinem Netzwerk hängen. Die Rechner benutze ich zum Testen von einigen Dingen, u.a. Linux HA.
Linux-HA kennt eine Resource "IPaddr", die beim starten eine bestimmte konfigurierte IP Adresse zu einem Interface hinzufügt. Mit "ip addr show" kann man das auch schön sehen. Nur pingen kann ich die Adresse kaum:
Die DNS Namen "linux-ha-01" und "linux-ha-02" resolven auf die "ursprüngliche" IP der zwei Linux HA Nodes. Wie ihr seht gehen die ersten 9 Pings erstmal verloren. Der 10te kommt dann mal zurück. Die "ursprünglichen" IPs pingen wunderbar.
Das passiert aber _nur_ wenn ich von einem Rechner aus pinge, der nicht auf der Seite der Bridge ist, wie z.B. der "mini" im obigen Beispiel. Jetzt pinge ich mal von einem Rechner aus, der sich "hinter" der Bridge befindet, also auf der gleichen "Seite" wie die HA nodes:
Hier ist alles wunderbar. Jetzt bin ich grad irgendwie überfordert ... Was ist da los? Wie kann ich das "debuggen"?
cu
serow
folgendes Szenario: Ich hab ein Cluster aus 3 VMware ESX 4.0, die getrennt durch eine Wireless Bridge (openwrt) in meinem Netzwerk hängen. Die Rechner benutze ich zum Testen von einigen Dingen, u.a. Linux HA.
Linux-HA kennt eine Resource "IPaddr", die beim starten eine bestimmte konfigurierte IP Adresse zu einem Interface hinzufügt. Mit "ip addr show" kann man das auch schön sehen. Nur pingen kann ich die Adresse kaum:
Code:
mathias@mini:~$ ssh root@linux-ha-01 ip addr show eth0
root@linux-ha-01's password:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:50:56:b1:7a:f2 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.210/24 brd 10.0.0.255 scope global eth0
inet 10.0.0.254/24 brd 10.0.0.255 scope global secondary eth0
inet6 fe80::250:56ff:feb1:7af2/64 scope link
valid_lft forever preferred_lft forever
mathias@mini:~$ ssh root@linux-ha-02 ip addr show eth0
root@linux-ha-02's password:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
link/ether 00:50:56:b1:0d:86 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.211/24 brd 10.0.0.255 scope global eth0
inet6 fe80::250:56ff:feb1:d86/64 scope link
valid_lft forever preferred_lft forever
mathias@mini:~$ ping 10.0.0.254
PING 10.0.0.254 (10.0.0.254) 56(84) bytes of data.
64 bytes from 10.0.0.254: icmp_seq=9 ttl=64 time=175 ms
^C
--- 10.0.0.254 ping statistics ---
44 packets transmitted, 1 received, 97% packet loss, time 43308ms
rtt min/avg/max/mdev = 175.981/175.981/175.981/0.000 ms
mathias@mini:~$ ping 10.0.0.211
PING 10.0.0.211 (10.0.0.211) 56(84) bytes of data.
64 bytes from 10.0.0.211: icmp_seq=1 ttl=64 time=2.87 ms
^C
--- 10.0.0.211 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.874/2.874/2.874/0.000 ms
mathias@mini:~$ ping 10.0.0.210
PING 10.0.0.210 (10.0.0.210) 56(84) bytes of data.
64 bytes from 10.0.0.210: icmp_seq=1 ttl=64 time=1.45 ms
64 bytes from 10.0.0.210: icmp_seq=2 ttl=64 time=3.30 ms
^C
--- 10.0.0.210 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.459/2.379/3.300/0.921 ms
mathias@mini:~$
Die DNS Namen "linux-ha-01" und "linux-ha-02" resolven auf die "ursprüngliche" IP der zwei Linux HA Nodes. Wie ihr seht gehen die ersten 9 Pings erstmal verloren. Der 10te kommt dann mal zurück. Die "ursprünglichen" IPs pingen wunderbar.
Das passiert aber _nur_ wenn ich von einem Rechner aus pinge, der nicht auf der Seite der Bridge ist, wie z.B. der "mini" im obigen Beispiel. Jetzt pinge ich mal von einem Rechner aus, der sich "hinter" der Bridge befindet, also auf der gleichen "Seite" wie die HA nodes:
Code:
mathias@storage:~$ ping -c 2 10.0.0.210
PING 10.0.0.210 (10.0.0.210) 56(84) bytes of data.
64 bytes from 10.0.0.210: icmp_seq=1 ttl=64 time=3.95 ms
64 bytes from 10.0.0.210: icmp_seq=2 ttl=64 time=0.383 ms
--- 10.0.0.210 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 0.383/2.169/3.955/1.786 ms
mathias@storage:~$ ping -c 2 10.0.0.211
PING 10.0.0.211 (10.0.0.211) 56(84) bytes of data.
64 bytes from 10.0.0.211: icmp_seq=1 ttl=64 time=2.51 ms
64 bytes from 10.0.0.211: icmp_seq=2 ttl=64 time=0.386 ms
--- 10.0.0.211 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1005ms
rtt min/avg/max/mdev = 0.386/1.452/2.518/1.066 ms
mathias@storage:~$ ping -c 2 10.0.0.254
PING 10.0.0.254 (10.0.0.254) 56(84) bytes of data.
64 bytes from 10.0.0.254: icmp_seq=1 ttl=64 time=1.06 ms
64 bytes from 10.0.0.254: icmp_seq=2 ttl=64 time=1.40 ms
--- 10.0.0.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1004ms
rtt min/avg/max/mdev = 1.064/1.233/1.403/0.173 ms
mathias@storage:~$
Hier ist alles wunderbar. Jetzt bin ich grad irgendwie überfordert ... Was ist da los? Wie kann ich das "debuggen"?
cu
serow
Zuletzt bearbeitet: