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 *

EEM Applet - Dynamic Tunnel Source Interface Changing

Previously, I had been faced with a problem with DMVPN; how to make it easy to switch between DHCP and static IP addresses for spokes that often change Internet providers?

In this scenario, I have dedicated interfaces, fa0/0 to use for static IP address assignment, and fa0/1 for DHCP.  Whenever, fa0/1 obtains a DHCP address, it cleans up the static routes, changes the tunnel source to fa0/1, and ensures the static route to the DMVPN hub, 172.31.84.67, is present.  Whenever, fa0/1 looses its link (including at boot time), the applet will cleanup the static routes, and change the tunnel source to fa0/0.  Someone with access to the spoke router will still have to assign the static IP to fa0/0 and add a route to the DMVPN hub, 172.31.84.67, to their gateway to gain connectivity, but that should be easier for the novice.

The applet can be used for other swapping the source interfaces of other types of tunnels but usually you would be able to use a loopback interface for this; in the case of DMVPN, however, the spoke router often cannot have the ISP create a route for the loopback's IP address destined to the spoke router.

!Tested with a Cisco 1841 running 15.1T Advanced Enterprise Services.
event manager applet DHCP_CONFIG
 event syslog pattern "DHCP-6-ADDRESS_ASSIGN: Interface FastEthernet0/1 assigned DHCP address"
 action 1.0010 cli command "enable"
 action 1.0020 cli command "configure terminal"
 action 1.0030 cli command "no ip route 0.0.0.0 0.0.0.0"
 action 1.0040 cli command "no ip route 172.31.84.67 255.255.255.255"
 action 1.0050 cli command "ip route 172.31.84.67 255.255.255.255 dhcp"
 action 1.0060 cli command "interface Tunnel 1"
 action 1.0070 cli command "tunnel source FastEthernet0/1"
 action 1.0080 cli command "end"
 action 1.0090 puts "TUNNEL SOURCE HAS BEEN SET TO FA0/1 FOR DHCP"
 action 1.0100 exit

event manager applet STATIC_CONFIG
 event syslog pattern "LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/1, changed state to down"
 action 1.0010 cli command "enable"
 action 1.0020 cli command "configure terminal"
 action 1.0030 cli command "no ip route 0.0.0.0 0.0.0.0"
 action 1.0040 cli command "no ip route 172.31.84.67 255.255.255.255 dhcp"
 action 1.0060 cli command "interface Tunnel 1"
 action 1.0070 cli command "tunnel source FastEthernet0/0"
 action 1.0080 cli command "end"
 action 1.0090 puts "TUNNEL SOURCE HAS BEEN SET TO FA0/0 FOR STATIC"
 action 1.0100 exit

This applet works similarly to the BACKUP-TO-USB applet, in that it looks for a pattern in logging to execute.  The applet, however, does not need to parse any command output; this makes it a very easy script to write.  Finally, it outputs what the script has done onto the console.  This output also shows up in "show log" so long as "logging buffered informational" has been turned on.