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:
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
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
%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
