Date: Sun, 19 Sep 2004 14:11:46 +1000 From: Edwin Groothuis <edwin@mavetju.org> To: freebsd-net@freebsd.org Subject: ospf / gif / packets not pushed into gif tunnel Message-ID: <20040919041146.GA32274@k7.mavetju>
next in thread | raw e-mail | index | archive | help
Hello, I'm trying to get dynamic routing working between two private networks. A gif tunnel is created between the two networks. The central server (FreeBSD 4.8) has 10.10.12.1/32 on its side of the tunnel, the remote (FreeBSD 5.2.1.) has 10.10.12.2/32 on its side of the tunnel. Static routes are added on both sides to point to the other networks. This works fine. If I remove the static routes and start running an OSPF daemon on both sides (using quagga), things start working out strange. This part is working: - OSPF information is exchanged. - The routing table is updated. But the moment this is done, the other side of the tunnel isn't reachable anymore (as in: no answers to my icmp echos). Running tcpdump on different places show me: gif-interface on server: 13:28:30.220792 10.10.12.1 > 10.10.12.2: icmp: echo request fxp-interface on server: 13:28:30.291934 IP 218.185.88.254 > 192.168.1.1: IP 10.10.12.1 > 10.10.12.2: icmp 64: echo request seq 512 (ipip-proto-4) fxp-interface on remote: 13:28:30.220823 218.185.88.254 > 203.111.122.2: 10.10.12.1 > 10.10.12.2: icmp: echo request (ipip-proto-4) gif-interface on remote: nothing The absence of output on the gif tunnel got me a little bit worried. Then I saw something else: my routing table is sometimes full (114 entries, directly connected and OSPF) and sometimes it's empty (only directly connected interfaces). This is all in 40 seconds intervals which make me believe its related to OSPF hello timeouts. I compared the routing tables and only saw this as the difference: Destination Gateway Flags Refs Use Netif empty: 10.10.12.1 10.10.12.2 UH 0 2957 gif1 full : 10.10.12.1 10.10.12.2 UH 99 2957 gif1 10.10.12.1 is the other side of the tunnel. The 99 isn't a stuck value, if I add more routes in the central network it will go up to 100, 101, 102 etc. With the nearly empty routing table, all traffic towards "the other side of the tunnel" goes happily via the fxp0 on to the internet... With the full routing table, all traffic towards "the other side of the tunnel" goes happily over the gif1 tunnel to the other side, but the answers are although received on this side never appear in this end of the gif1 tunnel: fxp0: 13:59:23.291934 IP 218.185.88.254 > 192.168.1.1: IP 10.10.10.3 > 10.10.12.2: icmp 64: echo reply seq 743 (ipip-proto-4) 13:59:24.256239 IP 192.168.1.1 > 218.185.88.254: IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 744 (ipip-proto-4) 13:59:24.350126 IP 218.185.88.254 > 192.168.1.1: IP 10.10.10.3 > 10.10.12.2: icmp 64: echo reply seq 744 (ipip-proto-4) 13:59:25.265971 IP 192.168.1.1 > 218.185.88.254: IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 745 (ipip-proto-4) 13:59:25.335384 IP 218.185.88.254 > 192.168.1.1: IP 10.10.10.3 > 10.10.12.2: icmp 64: echo reply seq 745 (ipip-proto-4) 13:59:26.276325 IP 192.168.1.1 > 218.185.88.254: IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 746 (ipip-proto-4) gif1: 13:59:23.246677 IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 743 13:59:24.256193 IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 744 13:59:25.265928 IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 745 13:59:26.276274 IP 10.10.12.2 > 10.10.10.3: icmp 64: echo request seq 746 Does anybody know a good reason why a packet arrived for a gif-tunnel doesn't get delivered properly into the gif-tunnel, depending on the size of the routing table? More information can be supplied if required. Edwin -- Edwin Groothuis | Personal website: http://www.mavetju.org edwin@mavetju.org | Weblog: http://weblog.barnet.com.au/edwin/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040919041146.GA32274>