Date: Thu, 17 Jan 2002 15:31:41 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: freebsd-stable@freebsd.org Subject: NTP packet routing problem Message-ID: <20020117153141.P72285@gsmx07.alcatel.com.au>
next in thread | raw e-mail | index | archive | help
I'm having a problem with NTP packets being routed via the wrong interface. Specifically, given the following network, with NTP peering between host1 and host2, host2 will send NTP packets to host1 via the ethernet rather than via PPP following a temporary link outage. Other TCP traffic seems to be routed normally. +------+ +------+ +------+ | | ppp | | fxp0 | | |host1 |-------|host2 |-------| net2 | | | | | | | +------+ +------+ +------+ "ppp" is a dial-on-demand link that is initiated by host1 using ppp(8) (the PPP link addresses are static). "enet" are the ethernet links to the LANs (net1 and net2). "host2.ppp" refers to the IP address of the PPP interface on host2 etc. Both hosts are running 4.4-STABLE from mid-December (just before the 4.5 freeze). host2 is running ipfw rules to block "invalid" packets. The hosts were happily exchanging PPP packets until the PPP link dropped out. ntpd on host2 then started reporting "permission denied" on every attempt to send a packet to host1 - even after the PPP link was restored. Looking at the ipfw logs, I find: Jan 17 12:07:47 host2 /kernel: ipfw: 12000 Deny UDP host2-ppp:123 host1-ppp:123 out via fxp0 Those addresses are correct, but the packet should be going via tun0 not fxp0. The routing table on host2 looks like: tcsbrpc# netstat -r Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 192.168.123.1 UGSc 1 2756 fxp0 localhost localhost UH 1 520 lo0 host2-ppp host1-ppp UH 7 10208 tun0 net2 link#1 UC 6 0 fxp0 router x:x:xx:x:xx:xx UHLW 1 0 fxp0 75 host3 x:x:x:x:x:xx UHLW 2 3397 fxp0 4 host4 x:x:x:x:x:xx UHLW 0 8525 fxp0 1094 host5 x:x:x:x:x:xx UHLW 2 747 fxp0 1084 host6 x:x:x:x:x:xx UHLW 4 11467 fxp0 1161 host2-fxp0 x:x:xx:xx:xx:xx UHLW 1 2 lo0 I've tried playing with the routing tables with no effect. Restarting ntpd has restored the expected behaviour - but presumably only until the next link outage. Has anyone else seen this behaviour? Can anyone offer any suggestions? Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020117153141.P72285>