|
|
ping verses kernel - jak skonfigurować jądro
zacharyjos - 26-02-2007 12:51
Witam.
Trzy łącza ADSL 8Mbps/640kbps od tepsy. ÂŁącza padają kilka razy w tygodniu. Losowo jedno lub dwa padną, za 30minut zmiana. Następnie jedno nie działa sobie przez 3 godzinki w godzinach szczytu ... . Niestety nie mamy alternatywnego operatora :| Masakra z takim netem, żyliśmy w ciągłym stresie :-||, a nóż znowu coś padnie.
Rozwiązanie okazało się proste. Co dwie minuty pingujemy skryptem bramę domyślną modemow DSL:
ping -c 2 -I eth1 213.25.2.204
i sprawdzamy czy ping wróci przez dany interfejs. Jeśli link padnie, skrypt automatycznie przełącza podsieci LAN z tego interfejsu na dobrego DSL'a. Wszystko ładnie chodziło do czasu aż musieliśmy przestać działać na standardowym kernelu, czyli przekonfigurować i skompilować swoje. Na jądrach "z instalki" (przygotowanych przez developerów dystrybucji) pakiety ping wychodzą i wracają tym intefejsem, który wskażemy opcją -I. Natomiast jak sam konfiguruję i kompiluję jądro, to jakbym tego nie skonfigurował, pakiety zawsze wychodzą bramą domyślną (eth2) i już nie wracają. Dla dwóc DSL'i wygląda to tak:
eth1,eth2 - łącza na świat
root@LEON:~# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
83.11.9.208 0.0.0.0 255.255.255.248 U 0 0 0 eth1
83.22.153.176 0.0.0.0 255.255.255.240 U 0 0 0 eth2
192.168.5.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.248.0 U 0 0 0 eth0
0.0.0.0 83.22.153.185 0.0.0.0 UG 0 0 0 eth2
0.0.0.0 83.11.19.209 0.0.0.0 UG 1 0 0 eth1
ping 213.25.2.204 -I eth2
PING 213.25.2.204 (213.25.2.204) from 83.22.153.186 eth2: 56(84) bytes of data.
64 bytes from 213.25.2.204: icmp_seq=1 ttl=126 time=47.5 ms
64 bytes from 213.25.2.204: icmp_seq=2 ttl=126 time=33.1 ms
64 bytes from 213.25.2.204: icmp_seq=3 ttl=126 time=30.5 ms
64 bytes from 213.25.2.204: icmp_seq=4 ttl=126 time=29.0 ms
--- 213.25.2.204 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 29.033/35.063/47.511/7.340 ms
LEON:~# tcpdump host 213.25.2.204 and icmp -n -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
11:53:47.377263 IP 83.22.153.186 > 213.25.2.204: icmp 64: echo request seq 1
11:53:47.424709 IP 213.25.2.204 > 83.22.153.186: icmp 64: echo reply seq 1
11:53:48.377536 IP 83.22.153.186 > 213.25.2.204: icmp 64: echo request seq 2
11:53:48.410664 IP 213.25.2.204 > 83.22.153.186: icmp 64: echo reply seq 2
11:53:49.378547 IP 83.22.153.186 > 213.25.2.204: icmp 64: echo request seq 3
11:53:49.408997 IP 213.25.2.204 > 83.22.153.186: icmp 64: echo reply seq 3
11:53:50.382769 IP 83.22.153.186 > 213.25.2.204: icmp 64: echo request seq 4
11:53:50.411735 IP 213.25.2.204 > 83.22.153.186: icmp 64: echo reply seq 4
8 packets captured
8 packets received by filter
0 packets dropped by kernel
Wszystko ładnie idzie przez jeden interfejs (bramę domyślną).
Natomiast dla drugiego łącza:
ping 213.25.2.204 -I eth1
PING 213.25.2.204 (213.25.2.204) from 83.11.9.210 eth1: 56(84) bytes of data.
--- 213.25.2.204 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 3000ms
# tcpdump host 213.25.2.204 and icmp -n -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel
a zobaczmy na drugi interfejs:
# tcpdump host 213.25.2.204 and icmp -n -i eth2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth2, link-type EN10MB (Ethernet), capture size 96 bytes
12:03:19.876169 IP 83.11.9.210 > 213.25.2.204: icmp 64: echo request seq 1
12:03:20.877728 IP 83.11.9.210 > 213.25.2.204: icmp 64: echo request seq 2
12:03:21.877279 IP 83.11.9.210 > 213.25.2.204: icmp 64: echo request seq 3
12:03:22.876316 IP 83.11.9.210 > 213.25.2.204: icmp 64: echo request seq 4
4 packets captured
4 packets received by filter
0 packets dropped by kernel
Pakiety zamiast wychodzić eth1 idą przez eth2! Popatrzmy na IP źródła. Mimo, że pakiety idą przez eth2, źródłowe IP mają z eth1!!!
No i żyjemy w permanentnym stresie, które łacze teraz padnie ??? ÂŻyczę dużo świętego spokoju wszystkim adminom ...
Co może być nie tak w jądrze. Pomóżcie bracia... :)
Grabos - 10-03-2007 15:52
Z manuala ping:
-I interface address
Set source address to specified interface address. Argument may be numeric IP address or name of device. When pinging IPv6 link-local address this option is required.
Czyli zachowanie waniliowego jądra(fajne tłumaczenie :P ) jest poprawne, pewnie Debianowe jądro ma łatę która sprawdza by wychodzący adres zgadzał się z adresem interfejsu.
Polecam użycie polecenia arping które działa podobnie jak ping ale nie w warstwie IP a arp a opcja -I tego polecenia zachowuje się tak jak tego oczekujesz w swoim przełączaniu.
Z manuala arping:
-I interface
Name of network device where to send ARP REQUEST packets. This option is required.
Pozdrawiam.
zanotowane.pldoc.pisz.plpdf.pisz.plminister.pev.pl
|
