Thanks Rene
I like the way you teach, you are my mentor since CCNP 
Thanks Rizwan!
Hello Rene,
Its Ammar, just registered again 
The topic is excellent and thank you for the great explanation.
Ammar,
CCIE R&S ( written)
Thanks Ammar!
Rene ;
I didnt get it very well at first but after going through I get it now . it make sense.
thanks for the share
Thanks Rene, very nice and simple in language for easy and better understanding.
Gitesh
I noticed the discussion of âwhat about this and thatâ concerning metric and AD changes.
In my opinion you should NEVER need too, nor want too, advertise the tunnel destination networks thru the tunnel interface itself.
So the only corrective action should be some type of filtering. There is no reason whatsoever to advertise that network back thru the tunnel interface as far as I can see. Makes no sense even with higher cost or AD.
Hi Rene,
I'm not sure I quite get this ! Say in your previous lesson you have R2 as an HQ router, R3 as a Branch and R1 as an ISP Router, If we create a Tunnel between HQ and Branch as Described. Then say secure the tunnel between HQ and Branch with IPSEC so data can be secure between the 2 offices.
When you change the cost to make the Tunnel cost higher ( Say 3 if RIP or 50 if OSPF ) the tunnel wouldn't collapse, However the better path between the sites would then appear to be the UNENCRYPTED path via R1 ( or the ISP Router )
The Tunnel would stay up but wouldn't be used. In the previous lesson we set Static routes between R1 and R3 ( HQ and Branch ) and used EIGRP to add the Tunnel Routes. Static Routes have an AD of 1 so they stay in the table.
Static routes would be ok on a 3 router scenario but not so good if there were 20 or 30 Branch offices.
I'm sure I'm missing something@Daniel That is correct, normally you should never advertise the tunnel destination addresses through the tunnel itself. Filtering so they are not advertised is the best solution. However, understanding how to use the AD and/or metric is important in case you want to do the CCIE R&S labâŚyouâll have to know all your options.
@John To simplify this, letâs forget about IPsec for now. It doesnât matter if the tunnel is encrypted or notâŚrecursive routing is a routing issue.
The only destinations that you donât want to learn through the tunnel are the IP addresses that are used to establish the tunnel itself. In my example, thatâs 192.168.12.1 on R1 (HQ) and 192.168.23.3 on R3 (branch). R3 should never learn about 192.168.12.1 through the tunnel and R1 should never learn 192.168.23.3 through the tunnel. You can achieve this by filtering (best option) or by increasing the AD/metric.
Once that is solved, the tunnel will be up and remain upâŚ
Now you can run an IGP (RIP, OSPF or EIGRP) on the tunnel interface and advertise any networks that you have. Your routers will form a neighbor adjacency through the tunnel interface and advertise networks to each other. To reach these networks, the tunnel interface will be used.
Rene
1 Like
Makes Sense Now ! Itâs only the TUNNEL Addresses that should be advertised through the tunnel, The Router IP addresses should not I assume any Loopbacks / Networks can also be advertised through the tunnel !
Thatâs right
In other words, you can do whatever you want but you have to make sure that the IP addresses that are used to build the tunnel, are never advertised through the tunnel interfaces. In my example, thatâs 192.168.12.1 and 192.168.23.3.
If they are advertised, you have to make sure you change the AD or metric so they never get installed in the routing table.
19 posts were merged into an existing topic: GRE Tunnel Recursive Routing Error
I got ârecursive routingâ before applying the offset command.
However ; I noted that traceroute works, before and after applying offset. It, also, displays the same result (below).
**R1#traceroute 3.3.3.3**
Type escape sequence to abort.
Tracing the route to 3.3.3.3
1 192.168.12.2 56 msec 8 msec 12 msec
2 192.168.23.3 20 msec 20 msec 20 msecHello,
I have a question about the use of GRE
what I have understood that main use of GRE is to connect site to site via the Internet. If that is the case this problem (Recursive Routing Error) wonât appear because our connection is via the ISP and the tunnel source will be the interface that is connected to ISP and we will configure default static route so it wonât be advertised by the routing protocol.
another question do we use GRE tunnel in other cases?
Hello Rehab
If you implement GRE over the Internet in the way that you described, you are correct that you wouldnât run into the recursive routing error. However, there are many cases where a GRE tunnel would be implemented where the recursive routing error would be a problem. These involve situations where you have a large enterprise network that may span several campuses, for example, in a university.
Say you have a university network with several campuses and many buildings within each campus. All the buildings and campuses are interconnected using a private network of some sort.
Say the computer science department has itâs main offices in a particular building in campus A but has also been given two offices in campus B. The department wants to use a contiguous set of IP addresses so that communication between devices in campus A and those in the offices in campus B are on the same subnet. One way to do this is via a GRE tunnel, over the private network.
A GRE tunnel can be used any time you want to connect two particular networks over a third network, whether than third network is the Internet or some other private network.
I hope this has been helpful!
Laz
1 Like
Hello Rene,
Thanks for such a good explanation. I can understand properly what causes the recursive routing in tunnel.
Now i am trying to resolve the recursive routing issue by changing the Administrative distance but not exactly getting as which network to include in the access-list
R1(config)#interface tunnel 1
R1(config-if)#tunnel source fa0/0
R1(config-if)#ip address 192.168.13.1 255.255.255.0
R1(config-if)#tunnel destination 192.168.23.3
-
R3(config)#interface tunnel 1
R3(config-if)#tunnel source Fa0/0
R3(config-if)#ip address 192.168.13.3 255.255.255.0
R3(config-if)#tunnel destination 192.168.12.1
R1 has loopback interface which is advertising network 10.10.10.0 255.255.255.0
now iI am using OSPF in R1 and adverting as -
router ospf 2
network 192.168.12.0 0.0.0.255 area 0
network 192.168.13.0 0.0.0.255 area 0
network 10.10.10.0 0.0.0.255 area 0
R3 has loopback interface which is advertising network 20.20.20.0 255.255.255.0
Now on R3 also i am using OSPF in R3 and advertising networks as
router ospf 2
network 192.168.23.0 0.0.0.255 area 0
network 192.168.13.0 0.0.0.255 area 0
network 20.20.20.0 0.0.0.255 area 0
Now this will cause recursive routing issue, as advertising tunnel destination through the tunnel itself.
now to resolve this i changed the Administrative distance using the command router ospf 2
distance 255 0.0.0.0 255.255.255.255 tunnelprefix
This command is configured on both R1 and R3
now i created an access list
ip access-list standard tunnelprefix
permit 192.168.13.0 0.0.0.255
still getting the routing recursive error and the tunnel is flapping and ospf neighborship is breaking in tunnel.
I am not sure which networks to include in the access-list,
192.168.13.0 or 10.10.10.0 also
or network 192.168.12.0 and 192.168.23.0
I can see the administrative distance is changing using the command show ip route ospf
but routing recursive issue is not resolving.
Is it possible if you can create one example with ospf and EIGRP also as you created with RIP
so that we can understand how administrative distance can resolve this issue.
Rene, it will be very helpful for us.
Hello Tejpal
In order to achieve the correct configuration, you must specify the administrative distance of the specific destination subnet. To do this, you simply configure the following:
distance 200 192.168.13.0 0.0.0.255
This will cause the destination of 192.168.13.0/24 to have an AD of 200, and will override any other information received. The access list is not needed. It is only used it is applied when a network is being inserted into the routing table. This behavior allows you to filter networks based on the IP prefix supplying the routing information. So the access list would reject any routes for which AD has not been explicitly configured.
More info about this command can be found here:
Try it out and let us know. I hope this has been helpful!
Laz
In this topic with RIP, I donât understand, what is the purpose of the tunnel when the metric will be worse, than through R2 to reach the network 1.1.1.1 and 2.2.2.2 through tunnel using offset list.
Hello Jan
In the specific topology, using a GRE tunnel will make very little difference in the actual routing of traffic from one loopback to the other. In both cases, the packets go via R2. There really is no reason to create a GRE tunnel for such a topology, so you are right, the purpose of the tunnel is not immediately perceivable.
However, the point of the lesson is to show that when you do have a GRE tunnel, which in most cases will be over a much larger network like the Internet for example, you have this recursive routing error that can occur. Creating a GRE tunnel over the Internet is useful and does indeed have many useful applications.
It doesnât really matter what the actual metric is, as long as the routing between the routers over the GRE tunnel is achieved successfully. Because the recursive routing error for GRE tunnels is a real problem when used in a real world scenario, such as over the Internet, this lesson shows us how to resolve it.
I hope this has been helpful!
Laz
Hi Renè,
This is my topology:
Now, the configurations are these:
R1
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco123 address 0.0.0.0
crypto isakmp keepalive 10
!
!
crypto ipsec transform-set TSET esp-3des esp-sha-hmac
mode tunnel
!
crypto ipsec profile VTI
set transform-set TSET
!
!
interface Tunnel0
ip address 192.168.10.2 255.255.255.0
ip ospf cost 10
tunnel source 10.0.149.220
tunnel mode ipsec ipv4
tunnel destination 172.16.10.2
tunnel protection ipsec profile VTI
!
interface GigabitEthernet0/0
ip address 10.0.149.220 255.255.255.0
ip ospf cost 1000
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/1
ip address 192.168.100.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router ospf 1
router-id 1.1.1.1
network 10.0.149.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
network 192.168.100.0 0.0.0.255 area 0
!
R2
crypto isakmp policy 1
encr 3des
authentication pre-share
group 2
crypto isakmp key cisco123 address 0.0.0.0
crypto isakmp keepalive 10
!
!
crypto ipsec transform-set TSET esp-3des esp-sha-hmac
mode tunnel
!
crypto ipsec profile VTI
set transform-set TSET
!
interface Tunnel0
ip address 192.168.10.1 255.255.255.0
ip ospf cost 10
tunnel source 172.16.10.2
tunnel mode ipsec ipv4
tunnel destination 10.0.149.220
tunnel protection ipsec profile VTI
!
interface GigabitEthernet0/1
ip address 172.16.10.2 255.255.255.0
ip ospf cost 1000
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/2
ip address 192.168.200.1 255.255.255.0
duplex auto
speed auto
media-type rj45
!
router ospf 1
router-id 2.2.2.2
network 172.16.10.0 0.0.0.255 area 0
network 192.168.10.0 0.0.0.255 area 0
network 192.168.200.0 0.0.0.255 area 0
Router Internet
interface GigabitEthernet0/0
ip address 10.0.149.221 255.255.255.0
ip ospf cost 1000
duplex auto
speed auto
media-type rj45
!
interface GigabitEthernet0/1
ip address 172.16.10.1 255.255.255.0
ip ospf cost 1000
duplex auto
speed auto
media-type rj45
!
router ospf 1
router-id 3.3.3.3
network 10.0.149.0 0.0.0.255 area 0
network 172.16.10.0 0.0.0.255 area 0
Now the purpose of this lab is to test the OSPF multicast packets over an IPsec tunnel configured with VTI.
I wish that R1 and R2 become neighbors through the tunnel.
The problem now, as you already know, is the recursive routing that brings down my tunnel⌠how can I solve this issue?
I tried to disable the OSPF from the Internet router but the problem is still present.