ospf / gif / packets not pushed into gif tunnel

[Edwin Groothuis]

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 at mavetju.org    |          Weblog: http://weblog.barnet.com.au/edwin/