ping verses kernel - jak skonfigurowa

[zacharyjos]

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:

Kod: Zaznacz cały

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

Kod: Zaznacz cały

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

Kod: Zaznacz cały

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

Kod: Zaznacz cały

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:

Kod: Zaznacz cały

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

Kod: Zaznacz cały

# 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:

Kod: Zaznacz cały

# 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]

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.