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@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