You need to pass a dynamic routing protocol through your tunnels.
Dynamic routing and tunnels can be a dangerous combination. It is critical to ensure that the routers never get confused and think that the best path to the tunnel destination is through the tunnel itself. We offer three different ways of resolving this problem.
The first is to use static routes for the tunnel destination address:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#interface Tunnel1 Router1(config-if)#ip address 192.168.35.6 255.255.255.252 Router1(config-if)#tunnel source 172.25.1.5 Router1(config-if)#tunnel destination 172.22.1.2 Router1(config-if)#exit Router1(config)#ip route 172.22.1.2 255.255.255.255 172.25.1.1 Router1(config)#router eigrp 55 Router1(config-router)#network 192.168.35.0 Router1(config-router)#end Router1#
The second method simply excludes the tunnel's IP address range from the routing protocol. You can then run a different routing protocol for the addresses that you want to pass through the tunnel:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#interface Tunnel1 Router1(config-if)#ip address 192.168.35.6 255.255.255.252 Router1(config-if)#tunnel source 172.25.1.5 Router1(config-if)#tunnel destination 172.22.1.2 Router1(config-if)#exit Router1(config)#router eigrp 55 Router1(config-router)#network 172.22.0.0 Router1(config-router)#network 172.25.0.0 Router1(config-router)#end Router1(config)#router rip Router1(config-router)#network 192.168.35.0 Router1(config-router)#end Router1#
The third solution is to filter the routes of the supporting network to prevent them from passing through the tunnel:
Router1#configure terminal Enter configuration commands, one per line. End with CNTL/Z. Router1(config)#interface Tunnel1 Router1(config-if)#ip address 192.168.35.6 255.255.255.252 Router1(config-if)#tunnel source 172.25.1.5 Router1(config-if)#tunnel destination 172.22.1.2 Router1(config-if)#exit Router11(config)#ip prefix-list TUNNELROUTES seq 10 permit 192.168.0.0/16 ge 17 Router1(config)#router eigrp 55 Router1(config-router)#network 172.22.0.0 Router1(config-router)#network 172.25.0.0 Router1(config-router)#network 192.168.35.0 Router1(config-router)#distribute-list prefix TUNNELROUTES out Tunnel1 Router1(config-router)#end Router1#
As we mentioned in Recipe 12.1, you have to be careful when using a dynamic routing protocol anywhere near a GRE tunnel to avoid the dreaded recursive routing error message, which brings down the tunnel. This happens because the routers need to have a good path through the network to carry the tunnel to its destination. In addition, this path cannot go through the tunnel itself. But the problem is that, because the tunnel forms a virtual connection that directly connects two routers, the path through the tunnel is almost always shorter than any path that goes through the real physical network.
The other way to look at the problem of recursive routing is to think about what the router has to do to a packet that it wants to send through the tunnel. It wraps this packet in the payload of a GRE packet and it puts the tunnel's destination address in the header of this GRE packet. Then it looks in its routing table to find out where to send this packet. If it finds that the best path is through the tunnel, then it must take this GRE packet and wrap it in the payload of a GRE packet whose destination address is the tunnel destination, and so on. This makes it difficult to deliver the original packet, so the router shuts down the tunnel interface to avoid having to stuff an infinite number of GRE headers onto the front of the packet.
There are two extremely simple solutions to this problem, but they aren't always applicable. You can use static routes to connect to the tunnel destination, which allows you to force the tunnel traffic to go the right way. Or you can prevent the routing protocol from passing through the tunnel either by using a separate IP address range or access lists. These two options are the first two examples in the solutions section of this recipe.
Note that we have used a specific host route for the destination IP address to ensure that it always uses the right path:
Router1(config)#ip route 172.22.1.2 255.255.255.255 172.25.1.1
The problem with this solution is that it might eliminate some of your network redundancy. For example, if there are several paths to the router that hold the tunnel's destination, using a static route like this might mean that your tunnel will fail if there is a topology change in the network that affects the manually selected path. In many cases, you can get around this problem by pointing the static route at a carefully selected downstream destination address. But then you run the risk that the router will learn about this downstream destination address through the tunnel, in which case we're back at square one.
The second simple solution is to simply exclude the tunnel from your routing protocol. In the example, we gave the tunnel an IP address that doesn't belong to the same address range as the source or destination addresses. This makes excluding the tunnel from the routing protocol relatively easy. By simply not including the 192.168.35.0/24 network in any of the EIGRP network commands, we prevent the tunnel from taking part in the routing protocol. We could also exclude the interface from the routing protocol using a distribute list. Please see Chapter 7 for more information about these EIGRP features.
However, sometimes these simple solutions are not appropriate. Some network topologies require that you use a routing protocol both inside and outside of the tunnel. For example, if you use VPNs to construct your WAN, through either a private or a public IP network, you will probably have to have both.
The best way to approach this type of situation is to start by ensuring that the ranges of IP addresses are distinct. For example, if the network that supports the tunnel uses public addressing, you could use private addressing for routes that need to be learned through the tunnel. Then you can apply a filter to prevent the routes for the supporting network from passing through the tunnel.
There are two ways to accomplish this. One is simply to use distinct routing protocols inside and outside of the tunnel, and not redistribute between the protocols. For example, the routing protocol outside of the tunnel could be BGP, while the tunneled network uses OSPF or EIGRP through the tunnel, or EIGRP and RIP as in the example above.
But another method is necessary if the two sets of routes use the same routing protocol, or if you need to redistribute. With distance vector-type interior routing protocols such as EIGRP and RIP, you can apply a route distribution filter to the tunnel interface to block the supporting network's routes. Note that EIGRP is much more sophisticated than a simple distance vector protocol like RIP. But this kind of route filtering is not possible with link state protocols such as OSPF, so this is one place where EIGRP's distance vector roots come in handy.
In the example, we have shown how to do route filtering using a prefix list with EIGRP. This will permit only the 192.168.0.0/16 range of IP addresses to pass through the tunnel, while information about the 172.22.0.0/16 and 172.25.0.0/16 networks that form the support network is never learned through the tunnel. You should apply this type of filter to both ends of the tunnel:
Router11(config)#ip prefix-list TUNNELROUTES seq 10 permit 192.168.0.0/16 ge 17 Router1(config)#router eigrp 55 Router1(config-router)#network 172.22.0.0 Router1(config-router)#network 172.25.0.0 Router1(config-router)#distribute-list prefix TUNNELROUTES out Tunnel1
For more information on EIGRP route distribution filters, please see Chapter 7. For more information on prefix lists, you can refer to either Chapter 7 or Chapter 9.
Recipe 12.1; Chapter 7 and Chapter 9
 |
|
|
| Top |