A Simple Network
The figure above shows a simple network prior to implementing a GRE tunnel.
Below shows the routing tables on RT1 and RT3:
RT1#sh ip route Gateway of last resort is not set 23.0.0.0/24 is subnetted, 1 subnets D 23.23.23.0 [90/30720] via 12.12.12.2, 00:00:26, FastEthernet0/0 172.16.0.0/24 is subnetted, 2 subnets C 172.16.1.0 is directly connected, FastEthernet1/0 D 172.16.2.0 [90/33280] via 12.12.12.2, 00:00:14, FastEthernet0/0 12.0.0.0/24 is subnetted, 1 subnets C 12.12.12.0 is directly connected, FastEthernet0/0 RT1# ================================================================================ RT3#sh ip route Gateway of last resort is not set 23.0.0.0/24 is subnetted, 1 subnets C 23.23.23.0 is directly connected, FastEthernet0/0 172.16.0.0/24 is subnetted, 2 subnets D 172.16.1.0 [90/33280] via 23.23.23.2, 00:00:17, FastEthernet0/0 C 172.16.2.0 is directly connected, FastEthernet1/0 12.0.0.0/24 is subnetted, 1 subnets D 12.12.12.0 [90/30720] via 23.23.23.2, 00:00:17, FastEthernet0/0 RT3#
A Simple GRE Tunnel Network
The figure above shows how a GRE tunnel between RT1 and RT3 is implemented.
Loopback interfaces are often being preferred to establish GRE tunnels.
Below verifies that the GRE tunnel is operational on RT1:
RT1#sh ip route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/158720] via 12.12.12.2, 00:00:35, FastEthernet0/0 23.0.0.0/24 is subnetted, 1 subnets D 23.23.23.0 [90/30720] via 12.12.12.2, 00:15:42, FastEthernet0/0 172.16.0.0/24 is subnetted, 2 subnets C 172.16.1.0 is directly connected, FastEthernet1/0 D 172.16.2.0 [90/33280] via 12.12.12.2, 00:15:30, FastEthernet0/0 12.0.0.0/24 is subnetted, 1 subnets C 12.12.12.0 is directly connected, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Tunnel0 RT1# RT1#ping 192.168.1.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 20/43/80 ms RT1# RT1#sh int tu0 Tunnel0 is up, line protocol is up Hardware is Tunnel Internet address is 192.168.1.1/24 MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation TUNNEL, loopback not set Keepalive not set Tunnel source 1.1.1.1 (Loopback0), destination 2.2.2.2 Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled Tunnel TTL 255 Checksumming of packets disabled, fast tunneling enabled Last input 00:02:40, output 00:02:40, output hang never Last clearing of "show interface" counters never Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/0 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 17 packets input, 2540 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 17 packets output, 2108 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out RT1#
Below shows that RT1 and RT3 became EIGRP neighbors through the directly connected tunnel interface after implemented the network 192.168.1.0 EIGRP router subcommand on both of them. However, the Ethernet networks 172.16.1.0/24 and 172.16.2.0/24 which were known through RT2, are still known through RT2; the path through the GRE tunnel is not being preferred.
This is because tunnel interfaces have extremely low speed (bandwidth) and high delay by default.
Tunnels are logical software constructs in which the processing delay is variable compared to physical interfaces; and hence should not be the most desirable paths by default.
RT1#sh ip eigrp neighbors IP-EIGRP neighbors for process 100 H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num 1 192.168.1.2 Tu0 13 00:00:06 1 3000 0 7 0 12.12.12.2 Fa0/0 12 00:25:49 402 2412 0 14 RT1# RT1#sh ip eigrp topology IP-EIGRP Topology Table for AS(100)/ID(172.16.1.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply, r - reply Status, s - sia Status --- output omitted --- P 172.16.2.0/24, 1 successors, FD is 33280 via 12.12.12.2 (33280/30720), FastEthernet0/0 via 192.168.1.2 (297246976/28160), Tunnel0 RT1#
The introduction of a routing protocol across a GRE tunnel can cause an interesting problem known as recursive routing.
GRE Tunnel Recursive Routing
The network topology and configuration have been modified as shown in the figure above.
The routers are exchanging routes through RIPv2.
Note that RIPv2 exchange the routes for the loopback interfaces used for establishing the GRE tunnel.
This may look a bit odd at the first glance. Consider the possibility that RT2 is owned and operated by a service provider, in which we cannot control them, and it only run RIPv2.
EIGRP is running on RT1 and RT3 to exchange routes for the Ethernet networks 172.16.1.0/24 and 172.16.2.0/24 between them.
The GRE tunnel comes up shortly after RT1 and RT3 learnt the RIPv2 routes for the loopback interfaces used for establishing the GRE tunnel.
But shortly after the tunnel came up, an error message is received upon the console.
RT1#sh ip route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/2] via 12.12.12.2, 00:00:19, FastEthernet0/0 23.0.0.0/24 is subnetted, 1 subnets R 23.23.23.0 [120/1] via 12.12.12.2, 00:00:19, FastEthernet0/0 172.16.0.0/24 is subnetted, 1 subnets C 172.16.1.0 is directly connected, FastEthernet1/0 12.0.0.0/24 is subnetted, 1 subnets C 12.12.12.0 is directly connected, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Tunnel0 RT1# 00:03:08: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up 00:03:12: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.2 (Tunnel0) is up: new adjacency RT1#sh ip route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets D 2.2.2.2 [90/297372416] via 192.168.1.2, 00:00:02, Tunnel0 23.0.0.0/24 is subnetted, 1 subnets R 23.23.23.0 [120/1] via 12.12.12.2, 00:00:25, FastEthernet0/0 172.16.0.0/24 is subnetted, 2 subnets C 172.16.1.0 is directly connected, FastEthernet1/0 D 172.16.2.0 [90/297246976] via 192.168.1.2, 00:00:02, Tunnel0 12.0.0.0/24 is subnetted, 1 subnets C 12.12.12.0 is directly connected, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Tunnel0 RT1# 00:03:17: %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing 00:03:18: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to down 00:03:18: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 100: Neighbor 192.168.1.2 (Tunnel0) is down: interface down RT1# RT1#sh ip route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 23.0.0.0/24 is subnetted, 1 subnets R 23.23.23.0 [120/1] via 12.12.12.2, 00:00:04, FastEthernet0/0 172.16.0.0/24 is subnetted, 1 subnets C 172.16.1.0 is directly connected, FastEthernet1/0 12.0.0.0/24 is subnetted, 1 subnets C 12.12.12.0 is directly connected, FastEthernet0/0 RT1#
The %TUN-5-RECURDOWN: Tunnel0 temporarily disabled due to recursive routing error message is a result of the tunnel destination address is being learned through the tunnel itself. The main underlying reason of this problem is the administrate distances of the routing protocols. When the routing protocol with a better AD learns a route, it is being placed into the routing table. The tunnel relies upon the RIPv2 routes to the remote loopback interfaces, but the tunnel is also learning routes to the remote loopback interfaces – the next-hop of the tunnel is inside the tunnel!
The router that first recognizes this routing loop problem would shut down the tunnel immediately.
The EIGRP route is then lost, and the RIPv2 route returns; the tunnel is then being brought up again; the cycle continues indefinitely until a configuration change is made.
Below are the possible solutions for this problem:
i) Stopping RT1 and RT3 from advertising the EIGRP routes to their loopback interfaces using the no network 1.0.0.0 and no network 2.0.0.0 EIGRP router subcommands on both of them.
ii) Implement outbound EIGRP distribute lists on RT1 and RT3 to prevent them from advertising the EIGRP routes to their loopback interfaces.
Finally, the routes to the remote loopback interfaces are learnt through RIPv2 only; while the routes to the remote Ethernet networks 172.16.1.0/24 and 172.16.2.0/24 are learnt through EIGRP only.
RT1#sh ip route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets R 2.2.2.2 [120/2] via 12.12.12.2, 00:00:05, FastEthernet0/0 23.0.0.0/24 is subnetted, 1 subnets R 23.23.23.0 [120/1] via 12.12.12.2, 00:00:05, FastEthernet0/0 172.16.0.0/24 is subnetted, 2 subnets C 172.16.1.0 is directly connected, FastEthernet1/0 D 172.16.2.0 [90/297246976] via 192.168.1.2, 00:00:25, Tunnel0 12.0.0.0/24 is subnetted, 1 subnets C 12.12.12.0 is directly connected, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Tunnel0 RT1# ================================================================================ RT3#sh ip route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets R 1.1.1.1 [120/2] via 23.23.23.2, 00:00:03, FastEthernet0/0 2.0.0.0/32 is subnetted, 1 subnets C 2.2.2.2 is directly connected, Loopback0 23.0.0.0/24 is subnetted, 1 subnets C 23.23.23.0 is directly connected, FastEthernet0/0 172.16.0.0/24 is subnetted, 2 subnets D 172.16.1.0 [90/297246976] via 192.168.1.1, 00:00:35, Tunnel0 C 172.16.2.0 is directly connected, FastEthernet1/0 12.0.0.0/24 is subnetted, 1 subnets R 12.12.12.0 [120/1] via 23.23.23.2, 00:00:03, FastEthernet0/0 C 192.168.1.0/24 is directly connected, Tunnel0 RT3#
Thanks For Your valuable posting, it was very informative
ReplyDeleteArticle submission sites
Guest posting sites