How to configure GRE Tunnel on Cisco IOS Router

(Adam M) #35

Hi Rene,

Is the reason that you are not seeing recursive routing issues in this case because you have used static routes which have a lower cost than an eigrp route? It appears that you are advertising the tunnel network in this case. Which I thought you said not to do. I’m just a little confused.

0 Likes

(Rene Molenaar) #36

Hi Adam,

Did you see this tutorial?

This explains exactly how the recursive routing occurs.

Rene

0 Likes

(Victor F) #37

How i can do the same thing but with real LAN with 2 PC connected to a switch in each Router (HQ - BRANCH)?.

Thanks

0 Likes

(Rene Molenaar) #38

Hi Victor,

The configuration of the routers would be the exact same thing. If you have real routers, just connect the computers directly to your routers (or put a switch in between). If you want to try this in GNS3 then you can use the “cloud” icon to connect your virtual routers to physical NICs.

Rene

0 Likes

(Shantel - Networklessons.com) split this topic #39

19 posts were merged into an existing topic: How to configure GRE Tunnel on Cisco IOS Router

0 Likes

(ADRIAN T) #40

Dear Rene,

  1. Can you please tell why did you used:

tunnel source fastEthernet 0/0

and not:

tunnel source 192.168.12.1

instead? What would be the difference ?

  1. Now, this might sound silly but anyway … Given the below config:
HQ(config)#interface tunnel 1
HQ(config-if)#tunnel source fastEthernet 0/0
HQ(config-if)#tunnel destination 192.168.23.3
HQ(config-if)#ip address 192.168.13.1 255.255.255.0

what I still cannot understand (I have read a couple of articles on GRE) and seems very strange to me is how the ip address of the tunnel is 192.168.13.1 and the source is the ip of another (??) interface (which is fa 0/0 - 192.168.12.1).
To my common sense the source should be 192.168.13.1.

  1. Why do some tunnels are mentioning loopback interfaces as source interfaces, instead of serial0 or its ip?

I know I am wrong but I still cannot understand it … :((

Thank you!

1 Like

(Rene Molenaar) #41

Hi Adrian,

When you use the tunnel source command, you can define an interface or an IP address. When you use the interface, the router will check for the IP address on the interface and use that so the end result is the same.

The tunnel source and destination addresses are only used to build the tunnel, that’s it. When you use this to tunnel something over the Internet, we typically use the public IP address on the outside interfaces for this.

You can use loopbacks as the source addresses if you want redundancy. Let’s say we have two routers that are connected with two physical interfaces. You could establish a tunnel using the IP addresses of one of the physical interfaces but that means that when that link goes down, the tunnel also goes down. In this case, you could establish the tunnel using loopback addresses. Your routing protocol will make sure that when one of the physical links goes down, it will reroute it using the other physical link.

About the IP addresses that we use, take a look at this wireshark capture:

https://www.cloudshark.org/captures/368dcd1ddc06

The IP packet with the outer header uses the IP addresses on the outside interfaces, this is what we use to route the packet. You can see it has a GRE header, the second IP header is for the ping between the loopback interfaces. We use the IP addresses on the tunnel interfaces as the next hops.

Hope this helps, if not just ask :slight_smile:

Rene

1 Like

(ADRIAN T) #42

Thank you a lot Rene! It’s clear now.

One more thing though: I expected to see somewhere ( I am not sure where :slight_smile: ) in the Wireshark capture, the IP of the tunnel interface 192.168.13.1 … Should’t it exist somewhere? Do I miss something? Thank you!

0 Likes

(ADRIAN T) #43

(contd.)
probably related:
We know that both sides of the tunnel should be in the same subnet. But why? Remote side of the tunnel receive a packet that doesn’t seem to include ip address of the HQ side of the tunnel (192.168.13.1), so why does remote end cares? Thank you!

0 Likes

(Rene Molenaar) #44

Hi Adrian,

Once the GRE tunnel is up, it acts like a regular interface. With normal interfaces we also don’t see the next hop IP address within the IP packet.

Here’s the logic of the router:

  1. When HQ sends a packet with destination 172.16.3.3 it has to check its routing table for a match:
HQ#show ip route eigrp 

      172.16.0.0/16 is variably subnetted, 3 subnets, 2 masks
D        172.16.3.0/24 [90/27008000] via 192.168.13.3, 00:00:07, Tunnel1
  1. Above you can see that the next hop is the remote IP address of the tunnel. Now it has to do another lookup to figure out how to get there:
HQ#show ip route 192.168.13.3
Routing entry for 192.168.13.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Redistributing via eigrp 13
  Routing Descriptor Blocks:
  * directly connected, via Tunnel1
      Route metric is 0, traffic share count is 1
  1. To the router, the tunnel interface is “directly connected”. With regular interfaces (FastEthernet / Gigabit etc) this means we can do an ARP for the IP address and reach it directly. However this time, the router knows we are using a GRE interface so it will encapsulate the IP packet…its puts a GRE header in front of it and a new IP header with the source/destination IP addresses that we used to build the tunnel:
HQ#show interfaces tunnel 1 | include source
  Tunnel source 192.168.12.1, destination 192.168.23.3
  1. Now the router will have to figure out how to get to 192.168.23.3, the tunnel destination so it does another lookup:
HQ#show ip route 192.168.23.3
Routing entry for 192.168.23.3/32
  Known via "static", distance 1, metric 0
  Routing Descriptor Blocks:
  * 192.168.12.2
      Route metric is 0, traffic share count is 1
  1. It sees there is a static route for 192.168.23.3/3 with 192.168.12.2 as the next hop. Time to figure out how to get there:
HQ#show ip route 192.168.12.2
Routing entry for 192.168.12.0/24
  Known via "connected", distance 0, metric 0 (connected, via interface)
  Routing Descriptor Blocks:
  * directly connected, via GigabitEthernet0/1
      Route metric is 0, traffic share count is 1

This IP address can be reached directly since we have an interface that is directly connected to 192.168.12.0/24. Time to figure out the L2 address:

HQ#show ip arp 192.168.12.2
Protocol  Address          Age (min)  Hardware Addr   Type   Interface
Internet  192.168.12.2           10   fa16.3e73.b9df  ARPA   GigabitEthernet0/1

Now we have the L2 address and the Ethernet frame will be on its way…

Hope this helps!

Rene

0 Likes

(ADRIAN T) #45

Thank you Rene! It really helped a lot!

0 Likes

(Cristian C) #46

Hi Rene, thanks for this great explanation :slight_smile: can you tell me what software are you using to connect to the routers?

0 Likes

(Rene Molenaar) #47

Hi Cristian,

Do you mean to access the consoles? I used Xshell for awhile but nowadays I use secureCRT for everything.

Rene

0 Likes

(Nanu N) #48

Hi Rene,

In the above example, when we ping Branch loopback 172.16.3.3 from HQ without specifying any source in ping command, then in the wireshark I can see the source IP of the ICMP ping packet is the IP address of tunnel interface i.e. 192.168.13.1 and same thing in the EIGRP Hello packet.

So can we say that any packet going out of f0/0 of R1 will have source IP 192.168.13.1 (i.e. IP address of tunnel for which f0/0 is configured as source)? as we have configured f0/0 as tunnel source.

And also I think we cannot configure one interface as a source for more than one tunnel…right?

Regards,
Nanu

0 Likes

(Andrew P) #49

Hi Nanu,

So can we say that any packet going out of f0/0 of R1 will have source IP 192.168.13.1 (i.e. IP address of tunnel for which f0/0 is configured as source)?

The answer to this is No. A simple counter-example would be any packet going from HQ to the ISP. Presumably, the ISP has no idea that the Tunnel IP space exists, so the packet must be sourced from 192.168.12.1. The key for HQ figuring out whether to use the 192.168.12.1 or 192.168.13.1 address would be what its routing table says is the next hop of the destination. If the next hop is in the Tunnel address space, it will use that.

I think we cannot configure one interface as a source for more than one tunnel…right?

You are correct. While you can have a single interface be the source of a tunnel with multiple destinations (DMVPN does this), technically, this is just a single tunnel. In order to have multiple tunnels, you will need to create loopbacks and source the tunnels from there.

0 Likes

(Nanu N) #50

Hi Andrew,

Your explanation has cleared my doubts…thanks a lot…:slight_smile:

Regards,
Nanu

0 Likes

(Trevor H) #51

Rene

Will you do / explain how to do this lab with the IGP being iBGP, with the loopbacks being redistributed into BGP?

Thank you.

Trevor

0 Likes

(Rene Molenaar) #52

Hi Trevor,

The goal of this example is to demonstrate how GRE tunneling works, you could use any other routing protocol. Here’s a quick example though how you can use BGP instead.

First we create an access-list that matches the loopback interface and we create a route-map:

R1(config)#ip access-list standard L0
R1(config-std-nacl)#permit 172.16.1.0 0.0.0.255

R1(config)#route-map L0_ONLY permit 10
R1(config-route-map)#match ip address L0

R1(config)#route-map L0_ONLY permit 20

Now you can configure BGP, configure the remote neighbor and redistribute only the loopback interface:

R1(config)#router bgp 13
R1(config-router)#neighbor 192.168.13.3 remote-as 13
R1(config-router)#redistribute connected route-map L0_ONLY

Hope this helps!

Rene

0 Likes

(Shantel - Networklessons.com) split this topic #53

19 posts were merged into an existing topic: How to configure GRE Tunnel on Cisco IOS Router

0 Likes

(Vitaly K) #54

Hello Rene,

I was not able to advertise Lo via tunnel Eigrp process with the given /24 config of yours. I fixed it using /32 bit prefix. It seems LOs cant build adjacency till 32 bit prefix is configured on loopback interface. Also I used successfully a source on one side of the setup as MLPPP and testes tunnel stability when flapped one of the PPP link.

0 Likes