Scenario from Puzzle #1 - Configured in a better way

Previously, I had posted puzzle #1, which had a network topology of two routers in the organization, R1 and R2, that connected via a tunnel over two serial connections using a statically routed transport network.  In the scenario from puzzle #1, the network administrator followed several back practices for the use of tunnels; some were pointed out and were part of the solution to the problem, some where not.

The bad habits that were pointed out where to make static routes for the tunnel destination that included more IP address space than needed and to include the network statements for the tunnel endpoints into the routing protocol that is used over the tunnel.  These bad habits often result into a recursive routing error like the one in the problem. 

There were some other bad habits throughout the configuration.  The mask on the loopback should have been a /32.  The /30 was really just wasted IP address space and because the transport network seemed to only use static routing there was really no benefit to use the loopback as a tunnel source except to have only a single tunnel that could be used for either interface, when, this would limit your ability to load balance across the two serial links.

My goal is to show a better configuration, although there are many more than just this one, that will allow the routers to load balance and retain a fairly simple tunneling configuration.  My first choice was to not use any loopback interfaces.  This allowed me to simplify the configuration.  The second is that I chose to use of only 2 tunnels rather than a full mesh of 4 tunnels.  While this also makes it easy to load balance over the two circuits, it does carry risk.  I will be using tunnels that go over R1's serial 0/0 interface to R2's serial0/0 interface and R1's serial 0/1 interface to R2's serial 0/1 interface (See the diagram below).  Redundancy will be offered, however, should one circuit for each tunnel, both tunnels could be inoperable even if there is a path that could exist (if R1's s0/0 fails and R2's s0/1 fails for example).  More tunnels could be created, or more advanced techniques could be used, to offer better redundancy, but I wanted an easier configuration.

The configurations below are for the described implementation of R1 and R2:

!!R1
hostname R1
!
logging buffered 4096 informational
!
interface Tunnel0
 description ***TUNNEL TO R2 OVER S0/0***
 ip address 172.18.1.1 255.255.255.252
 tunnel source Serial0/0
 tunnel destination 12.43.78.134
!
interface Tunnel1
 description ***TUNNEL TO R2 OVER S0/1***
 ip address 172.18.1.5 255.255.255.252
 tunnel source Serial0/1
 tunnel destination 12.43.78.138
!
interface FastEthernet0/0
 description ***USER NETWORK***
 ip address 172.17.51.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 description ***TRANSPORT LINK1***
 ip address 12.43.78.122 255.255.255.252
 clock rate 2000000
!
interface Serial0/1
 description ***TRANSPORT LINK2***
 ip address 12.43.78.126 255.255.255.252
 clock rate 2000000
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface Tunnel0
 no passive-interface Tunnel1
 network 172.16.0.0 0.15.255.255 area 0
!
ip route 12.43.78.134 255.255.255.255 12.43.78.121 name R2_S0/0_IP
ip route 12.43.78.138 255.255.255.255 12.43.78.125 name R2_S0/1_IP
!
end

!!R2
hostname R2
!
logging buffered 4096 informational
!
interface Tunnel0
 description ***TUNNEL TO R1 OVER S0/0***
 ip address 172.18.1.2 255.255.255.252
 tunnel source Serial0/0
 tunnel destination 12.43.78.122
!
interface Tunnel1
 description ***TUNNEL TO R1 OVER S0/1***
 ip address 172.18.1.6 255.255.255.252
 tunnel source Serial0/1
 tunnel destination 12.43.78.126
!
interface FastEthernet0/0
 description ***SERVER NETWORK***
 ip address 172.17.100.1 255.255.255.0
 duplex auto
 speed auto
!
interface Serial0/0
 description ***TRANSPORT LINK1***
 ip address 12.43.78.134 255.255.255.252
 clock rate 2000000
!
interface Serial0/1
 description ***TRANSPORT LINK2***
 ip address 12.43.78.138 255.255.255.252
 clock rate 2000000
!
router ospf 1
 log-adjacency-changes
 passive-interface default
 no passive-interface Tunnel0
 no passive-interface Tunnel1
 network 172.16.0.0 0.15.255.255 area 0
!
ip route 12.43.78.122 255.255.255.255 12.43.78.133 name R1_S0/0_IP
ip route 12.43.78.126 255.255.255.255 12.43.78.137 name R2_S0/1_IP
!
end

Once configured, you should verify that OSPF was able to perform a neighbor adjacency over the tunnels with "show ip ospf neighbor."

R1#sho ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
12.43.78.141      0   FULL/  -        00:00:30    172.18.1.6      Tunnel1
12.43.78.141      0   FULL/  -        00:00:30    172.18.1.2      Tunnel0

If successful, you can verify that load balancing is working by performing a "show ip route" and ensuring two routes for the server network on the other side.  Then, perform a traceroute to that network from your client network interface.  If the router is load balancing you will see two next hop routers in the traceroute.

R1#sho ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

     172.17.0.0/24 is subnetted, 2 subnets
C       172.17.51.0 is directly connected, FastEthernet0/0
O       172.17.100.0 [110/11121] via 172.18.1.6, 1d03h, Tunnel1
                     [110/11121] via 172.18.1.2, 1d03h, Tunnel0
     172.18.0.0/30 is subnetted, 2 subnets
C       172.18.1.4 is directly connected, Tunnel1
C       172.18.1.0 is directly connected, Tunnel0
     12.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C       12.43.78.120/30 is directly connected, Serial0/0
C       12.43.78.124/30 is directly connected, Serial0/1
S       12.43.78.138/32 [1/0] via 12.43.78.125
S       12.43.78.134/32 [1/0] via 12.43.78.121
R1#
R1#traceroute 172.17.100.1 source fa0/0

Type escape sequence to abort.
Tracing the route to 172.17.100.1

  1 172.18.1.6 20 msec
    172.18.1.2 40 msec *

Answer to Puzzle #1

Previously, I had posted a puzzle:
http://ephemeralportal.blogspot.jp/2014/02/tunnel-puzzle-find-what-is-broken.html

First the easier part, what is happening? what can you do to fix the issue?

In this example, the network administrator who configured used several bad practices.  The big one that hit him was that he included the tunnel endpoints in the routing process.  The network statement "network 12.0.0.0 0.255.255.255 area 0" allowed OSPF to advertise the loopback address to the router on the other side.  If you would have had access to the logs in R1.  You would have seen:

%OSPF-5-ADJCHG: Process 1, Nbr 12.43.78.141 on Tunnel0 from LOADING to FULL, Loading Done
%TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down
%OSPF-5-ADJCHG: Process 1, Nbr 12.43.78.141 on Tunnel0 from FULL to DOWN, Neighbor Down: Interface down or detached

So as soon as the tunnel came up, OSPF formed an adjacency to the router on the other side of the tunnel.  It then advertised the loopback address to the other router.  This is a problem, because it is recursive routing.  The route for the other side of the tunnel must go over the transport network and not the tunnel or it will have no way to route the tunnel packets.  The router discovered this error and disabled the tunnel interface.

So our fix is to remove the network statement for the 12.0.0.0 network.

router ospf 1
  no network 12.0.0.0 0.255.255.255 area 0

In addition changing the static routes from a /30 to the /32 for the loopbacks would also fix the issue. This is a recommended practice along with the removal of the unnecessary network statement for the 12 network shown above.

The other part is a little more difficult, and is probably the question his boss will ask, why did this problem start when OSPF was introduced and not with EIGRP?  The answer lies in the mask used for the loopback.  Rather than using a /32, the network administrator used a /30, and made similar static routes over the transport network.  When EIGRP was implemented, EIGRP advertised the /30 network; the administrative distance of EIGRP, 90, was higher than the static routes created of 1 and 2 so the EIGRP advertisement was not put into the routing table.  With OSPF, all advertisements for loopback interfaces are always a /32, even if /30 is configured on the interface.  So it did not matter if the administrative distance of the static was lower, the OSPF route was most specific and the process would try to add the route to the routing table, creating a recursive routing error.

Additional:

OSPF loopback behavior can be changed:
http://www.cisco.com/en/US/tech/tk365/technologies_q_and_a_item09186a0080094704.shtml#qone

I have written a follow on article outlining a better way to configure the routers in this scenario.
http://ephemeralportal.blogspot.jp/2014/02/scenario-from-puzzle-1-configured-in.html