Untitled document
& Switching v5 Workbook -
Advanced Technology Labs - IP
CCIE Routing
CCIE R&S v5
Routing
GRE Tunneling and Recursive Routing
A Note On Section Initial Configuration Files: You must load the
initial configuration files for the section, named Basic IP Addressing,
which can be found in
. Reference the Advanced Technology Labs With
Addressing Diagram to complete this task.
Task
Create a GRE tunnel between R3 and R4 using the IPv4 addresses 155.34.0.Y/24,
where Y is the router number.
The tunnel should be sourced from and destined to these devices’ Loopback0 IPv4
addresses.
Configure Loopback1 on R3 and R4 with IPv4 addresses 150.1.YY.YY/32, where Y
is the router number.
Configure RIP version 2 on R1, R3. and R4 as follows:
Enable it on VLAN 13 and VLAN 146.
Enable it on the GRE tunnel.
Advertise Loopback0 and Loopback1 prefixes of R3 and R4.
Use traceroute on R3 and R4 to verify connectivity between Loopback1 networks of
R3 and R4 through the GRE tunnel.
Configure distribute-list filtering on R3 and R4 to fix the recursive routing error for the
GRE tunnel.
Configuration
R1:
router rip
version 2
no auto-summary
network 155.1.0.0
R3:
interface Tunnel34
ip address 155.34.0.3 255.255.255.0
tunnel mode gre ip
tunnel source 150.1.3.3
tunnel destination 150.1.4.4
no shutdown
!
interface Loopback1
ip address 150.1.33.33 255.255.255.255
!
ip prefix-list STOP_RECURSIVE_ERROR seq 5 deny 150.1.3.3/32
ip prefix-list STOP_RECURSIVE_ERROR seq 10 permit 0.0.0.0/0 le 32
!
router rip
version 2
no auto-summary
network 155.1.0.0
network 150.1.0.0
network 155.34.0.0
distribute-list prefix STOP_RECURSIVE_ERROR out Tunnel34
R4:
interface Tunnel34
ip address 155.34.0.4 255.255.255.0
tunnel mode gre ip
tunnel source 150.1.4.4
tunnel destination 150.1.3.3
no shutdown
!
interface Loopback1
ip address 150.1.44.44 255.255.255.255
!
ip prefix-list STOP_RECURSIVE_ERROR seq 5 deny 150.1.4.4/32
ip prefix-list STOP_RECURSIVE_ERROR seq 10 permit 0.0.0.0/0 le 32
!
router rip
version 2
no auto-summary
network 155.1.0.0
network 150.1.0.0
network 155.34.0.0
distribute-list prefix STOP_RECURSIVE_ERROR out Tunnel34
Verification
Verify the RIP routing table on R3 and R4 before enabling RIP on Tunnel34, and
note that there is IPv4 connectivity between Loopback0 and Loopback1 prefixes.
R4#show ip route rip | b Gateway
Gateway of last resort is not set
150.1.0.0/32 is subnetted, 4 subnets
R150.1.3.3 [120/2] via 155.1.146.1, 00:00:09, GigabitEthernet1.146
R150.1.33.33 [120/2] via 155.1.146.1, 00:00:09, GigabitEthernet1.146
155.1.0.0/16 is variably subnetted, 9 subnets, 2 masks
R155.1.13.0/24 [120/1] via 155.1.146.1, 00:00:09, GigabitEthernet1.146
R155.1.23.0/24 [120/2] via 155.1.146.1, 00:00:09, GigabitEthernet1.146
R155.1.37.0/24 [120/2] via 155.1.146.1, 00:00:09, GigabitEthernet1.146
!R3#show ip route rip | b Gateway
Gateway of last resort is not set
150.1.0.0/32 is subnetted, 4 subnets
R150.1.4.4 [120/2] via 155.1.13.1, 00:00:16, GigabitEthernet1.13
R150.1.44.44 [120/2] via 155.1.13.1, 00:00:16, GigabitEthernet1.13
155.1.0.0/16 is variably subnetted, 10 subnets, 2 masks
R155.1.45.0/24 [120/2] via 155.1.13.1, 00:00:16, GigabitEthernet1.13
R155.1.146.0/24 [120/1] via 155.1.13.1, 00:00:16, GigabitEthernet1.13
!R3#ping 150.1.4.4 source loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.4.4, timeout is 2 seconds:
Packet sent with a source address of 150.1.3.3 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/3 ms
!R3#ping 150.1.44.44 source loopback1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.44.44, timeout is 2 seconds:
Packet sent with a source address of 150.1.33.33 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/8/23 ms
When RIP is enabled on the GRE tunnel of R3 and R4, a recursive routing error will
happen on either R3 or R4, based on the order of configuration. A recursive routing
error is when a lookup for prefix X points at prefix Y for the next-hop, and a lookup
for prefix Y points at prefix X for the next-hop. For tunnel interfaces, this occurs
when the tunnel destination is dynamically learned through the tunnel interface
itself. This problem can be easily identified by the IOS log message %TUN-5-
RECURDOWN: Tunnel34 temporarily disabled due to recursive routing. The
step-by-step process by which this error occurs is as follows. First, the GRE tunnel
interface is enabled and goes into UP state as the router has a route for tunnel
destination learned through RIP; IOS logs the message %LINEPROTO-5-
UPDOWN: Line protocol on Interface Tunnel34, changed state to up to signal
this. At this moment, let’s enable RIP over the tunnel interface, which will determine
both routers, R3 and R4, to prefer routes learned over the GRE tunnel against
routes learned over the physical Ethernet path, because of the lower metric/hop-
count of 1 on the GRE tunnel versus the metric/hop-count of 2 on the physical
Ethernet path:
R4#show ip route rip | b Gateway
Gateway of last resort is not set
150.1.0.0/32 is subnetted, 4 subnetsR150.1.3.3 [120/1] via 155.34.0.3, 00:00:02, Tunnel34
R150.1.33.33 [120/1] via 155.34.0.3, 00:00:02, Tunnel34
155.1.0.0/16 is variably subnetted, 9 subnets, 2 masks
R155.1.13.0/24 [120/1] via 155.34.0.3, 00:00:02, Tunnel34
[120/1] via 155.1.146.1, 00:00:22, GigabitEthernet1.146
R155.1.23.0/24 [120/1] via 155.34.0.3, 00:00:02, Tunnel34
R155.1.37.0/24 [120/1] via 155.34.0.3, 00:00:02, Tunnel34
Because at this moment R4 learns about the GRE tunnel destination through the
GRE tunnel itself, a route-recursive error is triggered, and the Tunnel interface goes
to DOWN state. This will allow the router to re-learn the RIP routes over the physical
path, but this process will repeat itself when R4 will bring UP again the GRE tunnel
interface:
R4:
%ADJ-5-PARENT: Midchain parent maintenance for IP midchain out of Tunnel34 - looped chain attempting to stack
%TUN-5-RECURDOWN: Tunnel34 temporarily disabled due to recursive routing
%LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel34, changed state to down
!R4#show ip route rip | b Gateway
Gateway of last resort is not set
150.1.0.0/32 is subnetted, 4 subnets
R150.1.3.3 [120/2] via 155.1.146.1, 00:00:05, GigabitEthernet1.146
R150.1.33.33 [120/2] via 155.1.146.1, 00:00:05, GigabitEthernet1.146
155.1.0.0/16 is variably subnetted, 9 subnets, 2 masks
R155.1.13.0/24 [120/1] via 155.1.146.1, 00:00:05, GigabitEthernet1.146
R155.1.23.0/24 [120/2] via 155.1.146.1, 00:00:05, GigabitEthernet1.146
R155.1.37.0/24 [120/2] via 155.1.146.1, 00:00:05, GigabitEthernet1.146
In general, there are several solutions to the problem, depending on the IPv4
addressing scheme, routing protocol being used, and network design:
Do not advertise in the routing protocol the same networks over both the
physical/Ethernet path and the tunneling/GRE path.
Do not advertise in the routing protocol used over the tunneling/GRE path the tunnel
endpoints.
Use route filtering techniques to filter tunnel endpoints IPv4 addresses from being
learned over the GRE tunnel.
Do not use same routing protocol over both the physical and tunneling paths; this is
recommended but it requires correct routing protocol configuration.
In this case, one of multiple route filtering solutions has been selected, basically
configuring R3 and R4 to not advertise Loopback0 prefix over the GRE tunnel. After
applying the filtering, the network is stable and routes are correctly learned over
both physical and tunneling paths. Note that route filtering was configured strictly to
fix the recursive routing problem; some Ethernet link subnets will be learned over the
GRE tunnel, which is functional but maybe not optimal.
R3#show ip route rip | b Gateway
Gateway of last resort is not set
150.1.0.0/32 is subnetted, 4 subnets
R150.1.4.4 [120/2] via 155.1.13.1, 00:00:01, GigabitEthernet1.13
R150.1.44.44 [120/1] via 155.34.0.4, 00:00:15, Tunnel34
155.1.0.0/16 is variably subnetted, 10 subnets, 2 masks
R155.1.45.0/24 [120/1] via 155.34.0.4, 00:00:15, Tunnel34
R155.1.146.0/24 [120/1] via 155.34.0.4, 00:00:15, Tunnel34
[120/1] via 155.1.13.1, 00:00:01, GigabitEthernet1.13
!R4#show ip route rip | b Gateway
Gateway of last resort is not set
150.1.0.0/32 is subnetted, 4 subnets
R150.1.3.3 [120/2] via 155.1.146.1, 00:00:23, GigabitEthernet1.146
R150.1.33.33 [120/1] via 155.34.0.3, 00:00:04, Tunnel34
155.1.0.0/16 is variably subnetted, 9 subnets, 2 masks
R155.1.13.0/24 [120/1] via 155.34.0.3, 00:00:04, Tunnel34
[120/1] via 155.1.146.1, 00:00:23, GigabitEthernet1.146
R155.1.23.0/24 [120/1] via 155.34.0.3, 00:00:04, Tunnel34
R155.1.37.0/24 [120/1] via 155.34.0.3, 00:00:04, Tunnel34
Verify there is IPv4 connectivity between Loopback0 and Loopback1 prefixes of R3
and R4, and that traffic for Loopback1 is routed over the GRE tunnel.
R4#ping 150.1.3.3 source loopback0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.3.3, timeout is 2 seconds:
Packet sent with a source address of 150.1.4.4 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 2/10/23 ms
!R4#ping 150.1.33.33 source loopback1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.33.33, timeout is 2 seconds:
Packet sent with a source address of 150.1.44.44 !!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/13 ms
!R4#traceroute 150.1.33.33
Type escape sequence to abort.
Tracing the route to 150.1.33.33
VRF info: (vrf in name/id, vrf out name/id)1 155.34.0.3 18 msec * 3 msec
!R3#traceroute 150.1.44.44
Type escape sequence to abort.
Tracing the route to 150.1.44.44
VRF info: (vrf in name/id, vrf out name/id)1 155.34.0.4 6 msec * 3 msec