GRE tunnels and OSPF adjacencies

I made the mistake of starting to play with one of Ivan Pepelnjak's OSPF challenges on his great IOS blog, and got carried away playing with GRE tunnels instead.

On R1:

interface Loopback0
ip address 10.1.2.1 255.255.255.0

interface Serial1/0
ip unnumbered Loopback0
encapsulation ppp

interface Tunnel0
ip unnumbered Loopback0
ip ospf 1 area 1
tunnel source Serial1/0
tunnel destination 10.1.2.3



On R2:

interface Loopback0
ip address 2.2.2.2 255.255.255.0

interface Serial1/0
ip address 10.1.2.3 255.255.255.248
encapsulation ppp


interface Tunnel0
ip address 22.22.22.22 255.255.255.0
ip ospf 1 area 1
tunnel source Serial1/0
tunnel destination 10.1.2.1


This configuration forms no adjacency because the GRE tunnel interfaces are on different networks. A debug confirms this:


R2#deb ip os adj
OSPF adjacency events debugging is on
R2#
*Oct 29 09:43:03.123: OSPF: Rcv pkt from 10.1.2.1, Tunnel0, area 0.0.0.1 : src not on the same network

from a debug ip packet at the same time:

*Oct 29 10:08:11.015: IP: s=22.22.22.22 (Tunnel0), d=224.0.0.5, len 76, rcvd 0

[incidentally, I'm not sure why this behavior doesn't violate section 8.2 of RFC 2328, which states:

  ...the packet's IP source address is required to
be on the same network as the receiving interface.  This
can be verified by comparing the packet's IP source
address to the interface's IP address, after masking
both addresses with the interface mask.  This comparison
should not be performed on point-to-point networks. On
point-to-point networks, the interface addresses of each
end of the link are assigned independently, if they are
assigned at all.

GRE tunnels are considered point-to-point networks by OSPF.]

However, if I remove the explicitly configured IP address on R2's tunnel interface and replace it with an unnumbered configuration, using a loopback that's still not in the same network, it works:

R2(config)#int tu 0
R2(config-if)#ip unn lo 0
R2(config-if)#^Z
R2#
*Oct 29 09:44:44.907: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on Tunnel0 from LOADING to FULL, Loading Done

R2#sh ip os n

Neighbor ID Pri State Dead Time Address Interface
10.0.0.1 0 FULL/ - 00:00:33 10.1.2.1 Tunnel0


R1#sh ip os n

Neighbor ID Pri State Dead Time Address Interface
10.1.2.3 0 FULL/ - 00:00:32 2.2.2.2 Tunnel0


At first I thought that maybe the router was changing the source address for OSPF packets to the address of the tunnel source, but that's not the case:

R1#deb ip packet
IP packet debugging is on
R1#
*Oct 29 10:05:44.955: IP: s=10.1.2.1 (local), d=224.0.0.5 (Tunnel0), len 80, sending broad/multicast
*Oct 29 10:05:44.955: IP: s=10.1.2.1 (Tunnel0), d=10.1.2.3 (Serial1/0), len 104, sending
*Oct 29 10:05:45.703: IP: s=2.2.2.2 (Tunnel0), d=224.0.0.5, len 80, rcvd 0

As you can see, the OSPF hellos are coming from the loopback IP of R2, which is on a completely different network.