Routing/ARP/ICMP: Ein bißchen kaputt
Jan-Benedict Glaw
jbglaw at lug-owl.de
Sun Sep 24 11:32:33 CEST 2006
Hi!
Ich hab' das ein lustig' Phänomen, das ich nicht verstehe...
Router: eth0: 192.168.1.1/24
eth0:xx: 192.168.2.1/24
eth1: ADSL (-> ppp0)
tun1: 192.168.2.2:192.168.100.19
# cat /proc/sys/net/ipv4/ip_forward /proc/sys/net/ipv4/conf/all/send_redirects
1
1
eth0 hat also zwei Netze konfiguriert, die aber auf einem Kabel
laufen.
Eine weitere Kiste ("backup") bekommt via OpenVPN Backups und ist via
Switch mit eth0 vom Router verbunden:
Backup: eth0: 192.168.2.3/24
ADSL
|
+---------eth1-----------+
| Router | +-----------------------+
| | | Backup |
| eth0: 192.168.1.1/24| Switch | |
| eth0:x:192.168.2.1/24|-----+-----------|eth0: 192.168.2.3/24 |
| | | |GW: 192.168.2.1 |
| tun: 192.168.2.2 | | +-----------------------+
| <-> 192.168.100.19| |
+------------------------+ +----{Rest vom LAN, 192.168.1.0/24}
Beim Pingen von Backup an den Router:
backup:~# tcpdump -i eth0 -n not port \( ssh or 445 or 137 or 138 or ipp \)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:14:31.481817 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 18, length 64
11:14:32.481853 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 19, length 64
11:14:33.481918 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 20, length 64
11:14:34.481976 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 21, length 64
11:14:35.482037 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 22, length 64
11:14:36.482102 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 23, length 64
11:14:37.482162 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 24, length 64
11:14:38.482255 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 58126, seq 25, length 64
router:~# tcpdump -i eth0 -n not port \( ssh or 445 or 137 or 138 or ipp \)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:14:32.165733 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 19, length 64
11:14:33.164712 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 20, length 64
11:14:34.164852 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 21, length 64
11:14:35.164993 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 22, length 64
11:14:36.165123 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 23, length 64
11:14:37.165260 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 24, length 64
11:14:38.165399 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 58126, seq 25, length 64
backup:~# ping 192.168.2.1
PING 192.168.2.1 (192.168.2.1) 56(84) bytes of data.
--- 192.168.2.1 ping statistics ---
25 packets transmitted, 0 received, 100% packet loss, time 24011ms
Auf der Backup-Maschine sieht man nur die requests, auf dem Router nur
die replys?! Wtf!
Lustig wird das, wenn der Router dann einer _anderen_ Maschine aus dem
restlichen 192.168.1.0/24'er lan einen ICMP redirect schickt (ping von
192.168.1.7/24 an 192.168.2.3/24):
backup:~# tcpdump -i eth0 -n not port \( ssh or 445 or 137 or 138 or ipp \)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:17:58.250713 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 21, length 64
11:17:59.250775 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 22, length 64
11:18:00.250835 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 23, length 64
11:18:00.614082 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 1, length 64
11:18:00.614182 IP 192.168.2.3 > 192.168.1.7: ICMP echo reply, id 4906, seq 1, length 64
11:18:01.250905 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 24, length 64
11:18:01.625557 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 2, length 64
11:18:01.625604 IP 192.168.2.3 > 192.168.1.7: ICMP echo reply, id 4906, seq 2, length 64
11:18:01.628229 arp who-has 192.168.2.3 tell 192.168.1.7
11:18:01.628278 arp reply 192.168.2.3 is-at 00:00:f4:c9:3c:3d
11:18:02.250970 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 25, length 64
11:18:02.624663 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 3, length 64
11:18:02.624703 IP 192.168.2.3 > 192.168.1.7: ICMP echo reply, id 4906, seq 3, length 64
11:18:03.251025 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 26, length 64
11:18:04.251087 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 27, length 64
11:18:05.251154 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 28, length 64
11:18:05.613554 arp who-has 192.168.2.3 tell 192.168.2.1
11:18:05.613602 arp reply 192.168.2.3 is-at 00:00:f4:c9:3c:3d
11:18:05.615854 IP 192.168.2.1 > 192.168.2.3: ICMP redirect 192.168.1.3 to host 192.168.1.3, length 220
11:18:05.619146 arp who-has 192.168.1.3 tell 192.168.2.3
11:18:05.619364 arp reply 192.168.1.3 is-at 00:e0:81:03:74:51
11:18:06.251213 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 29, length 64
11:18:06.252697 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 29, length 64
11:18:06.252896 IP 192.168.2.1 > 192.168.2.3: ICMP redirect 192.168.1.3 to host 192.168.1.3, length 188
11:18:07.251279 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 30, length 64
11:18:07.252763 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 30, length 64
11:18:08.251339 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 31, length 64
11:18:08.252810 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 31, length 64
11:18:09.251400 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 32, length 64
11:18:09.252866 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 32, length 64
11:18:10.251465 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 33, length 64
router:~# tcpdump -i eth0 -n not port \( ssh or 445 or 137 or 138 or ipp \)
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
11:17:58.950222 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 22, length 64
11:17:59.949291 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 23, length 64
11:18:00.311993 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 1, length 64
11:18:00.312202 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 1, length 64
11:18:00.950540 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 24, length 64
11:18:01.323636 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 2, length 64
11:18:01.323734 IP 192.168.1.1 > 192.168.1.7: ICMP redirect 192.168.2.3 to host 192.168.2.3, length 92
11:18:01.323760 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 2, length 64
11:18:01.326576 arp who-has 192.168.2.3 tell 192.168.1.7
11:18:01.950683 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 25, length 64
11:18:02.322781 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 3, length 64
11:18:02.322908 IP 192.168.1.1 > 192.168.1.7: ICMP redirect 192.168.2.3 to host 192.168.2.3, length 92
11:18:02.322936 IP 192.168.1.7 > 192.168.2.3: ICMP echo request, id 4906, seq 3, length 64
11:18:02.950815 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 26, length 64
11:18:03.949890 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 27, length 64
11:18:04.951093 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 28, length 64
11:18:05.312076 arp who-has 192.168.2.3 tell 192.168.2.1
11:18:05.312646 arp reply 192.168.2.3 is-at 00:00:f4:c9:3c:3d
11:18:05.314206 IP 192.168.2.1 > 192.168.2.3: ICMP redirect 192.168.1.3 to host 192.168.1.3, length 220
11:18:05.318877 arp who-has 192.168.1.3 tell 192.168.2.3
11:18:05.951123 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 29, length 64
11:18:05.951246 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 29, length 64
11:18:05.951327 IP 192.168.2.1 > 192.168.2.3: ICMP redirect 192.168.1.3 to host 192.168.1.3, length 188
11:18:06.951260 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 30, length 64
11:18:06.951384 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 30, length 64
11:18:07.951391 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 31, length 64
11:18:07.951509 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 31, length 64
11:18:08.951531 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 32, length 64
11:18:08.951642 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 32, length 64
11:18:09.951669 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 33, length 64
11:18:09.951793 IP 192.168.2.1 > 192.168.2.3: ICMP echo reply, id 62222, seq 33, length 64
11:18:10.951817 IP 192.168.2.3 > 192.168.2.1: ICMP echo request, id 62222, seq 34, length 64
Interessanterweise kommt der Redirect für meinen
Arbeitsplatz-Rechner?! Das muß mir jetzt mal wer erklären... Ab da
pingt es dann natürlich auch, auffälligerweise mit zwei recht
unterschiedlichen RTTs:
(backup->router)
64 bytes from 192.168.2.1: icmp_seq=673 ttl=64 time=1.44 ms
64 bytes from 192.168.2.1: icmp_seq=674 ttl=64 time=0.395 ms
64 bytes from 192.168.2.1: icmp_seq=675 ttl=64 time=1.46 ms
64 bytes from 192.168.2.1: icmp_seq=676 ttl=64 time=0.387 ms
64 bytes from 192.168.2.1: icmp_seq=677 ttl=64 time=1.44 ms
64 bytes from 192.168.2.1: icmp_seq=678 ttl=64 time=0.377 ms
64 bytes from 192.168.2.1: icmp_seq=679 ttl=64 time=1.44 ms
64 bytes from 192.168.2.1: icmp_seq=680 ttl=64 time=0.405 ms
64 bytes from 192.168.2.1: icmp_seq=681 ttl=64 time=1.44 ms
64 bytes from 192.168.2.1: icmp_seq=682 ttl=64 time=1.44 ms
64 bytes from 192.168.2.1: icmp_seq=683 ttl=64 time=0.379 ms
Pinge ich vom Arbeitsplatz-Rechner, habe ich die Zeiten um 1.4ms,
solange noch kein redirect gekommen ist. Ab dem Redirect die Zeiten um
0.3 bis 0.5 msec. Wenn die Backup-Maschine den Router anpingt, kann
man mal den einen, mal den anderen Wert beobachten.
MfG, JBG
--
Jan-Benedict Glaw jbglaw at lug-owl.de +49-172-7608481
Signature of: The real problem with C++ for kernel modules is: the language just sucks.
the second : -- Linus Torvalds
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lug-owl.de/pipermail/linux/attachments/20060924/f7b9270f/attachment.sig>
More information about the Linux
mailing list