cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8160
Views
24
Helpful
14
Replies

GRE Tunnel Source/Destination

rmujeeb81
Level 1
Level 1

Dear All,

I have a query regarding GRE Tunnel's source and destination. Let say there is a GRE tunnel between RouterA & RouterB,

RouterA:

interface tunnel 1

ip address 192.168.1.1 255.255.255.252

tunnel source 10.1.1.1

tunnel destination 20.1.1.1

RouterB:

interface tunnel 1

ip address 192.168.1.2 255.255.255.252

tunnel source 20.1.1.1

tunnel destination 10.1.1.1

Why tunnel source on one side should be same as tunnel destination on other side of tunnel ?

Why we cann't use different ip addresses/inetrfaces for tunnel source/destination combination if both ip addresses are reachable ? Kindly explain this behavior.

Thanks & Regards,

Mujeeb

1 Accepted Solution

Accepted Solutions

Hello Mujeeb,

yes it is correct : a pair (ip addr1, ipaddr2) identifies a tunnel instance on both routers and it is a logical point-to-point interface.

if a packet arrives with a SA, DA pair not defined in the local router the logical tunnel cannot be identified on the receiving router and the packet should be discarded

Hope to help

Giuseppe

Hope to help

Giuseppe

View solution in original post

14 Replies 14

Giuseppe Larosa
Hall of Fame
Hall of Fame

Hello Mujeeb,

a GRE tunnel interface is an envelope a way to encapsulate some traffic inside an external IP packet that uses tunnel source and tunnel destination

So when a packet is received the router to extract the internal traffic looks like on its configured tunnels.

So the source and destination addresses are used as a way to muliplex and demultiplex GRE traffic they need to decide and to agree to what tunnel they belong to take the correct forwarding actions.

It is like a TCP socket that involves source ip destination ip source TCP port and destination TCP port.

On the other hand if this constraint were removed some strange loops could be formed.

The GRE tunnel is point to point in nature.

To be noted a point-to-multipoint GRE called mGRE has been introduced to overcome the point to point nature of GRE

see for an example

http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00801982ae.shtml

multipoint GRE requires the usage of NHRP protocol to map the logical / internal ip address to the public/external ip address

Hope to help

Giuseppe

Hi Giuseppe,

Thanks for the quick resonse. I have still a confusion that GRE encapsulates traffic when it enters into router for a destination which would be reachable through this tunnel, ok this is right.

Now the thing is that if I want to configure some other interface's ip address (of remote Router ) as tunnel destination which is also reachable through local router than why it does not work ? Although IP connectivity is fine between all interfaces of both Routers.

Regards,

Mujeeb

Hello Mujeeb,

the key point is that GRE is a point-to-point service.

To reach other remote router's IP interfaces via the tunnel GRE what you need is a static ip route

local router

ip route remoterouter.ip.subnets mask tunnel XX

you can have one or multiple static routes using as outgoing interface the GRE tunnel

You need to think it in two steps: tunnel source and destination are used to encapsulate traffic.

on the remote end after the traffic is decapsulated and then can be routed out some other interface

We do in this way for some (one hundred) remote sites connecting using GRE tunnels inside IPSec packets

Hope to help

Giuseppe

Hi,

Yes, I don't have confusion regarding traffic routing through Tunnel interface, it could be static routing or dynamic routing which could use tunnel interface as an outgoing interface to reach a specific destination.

As far as 'Tunnel Source' & 'Tunnel Destination' parameters under tunnel interface configuration is concerned, I got understanding from your explanation that when GRE encapsulates a packet then External Header would contain source ip address of 'Tunnel Source' parameter and it should be same on the other side of tunnel(Remote Router) as 'Tunnel Destination' where de-encapsulation will take place. Am I right ?

Regards,

Mujeeb

Hello Mujeeb,

yes it is correct : a pair (ip addr1, ipaddr2) identifies a tunnel instance on both routers and it is a logical point-to-point interface.

if a packet arrives with a SA, DA pair not defined in the local router the logical tunnel cannot be identified on the receiving router and the packet should be discarded

Hope to help

Giuseppe

Hope to help

Giuseppe

Guys, i understand how GRE works and when to use it.. what i am struggling to understand is the significance of the tunnel ip address. In most examples i see that the tunnel ip address is used with a /30 mask and is on same subnet as tunnel ip address at far end.. is this required or just preferred? Or can you assign any unique IP address at both ends?

Thanks

Ray

Ray,

The tunnel itself is a network interface, despite being only a virtual interface. The situation here is the same as with, say, serial interfaces. Why do we actually set up IP addresses on point-to-point serial interfaces?

The reasons are multifold. First, if you want any interface to transport IP traffic, it must be IP-enabled. This is done by assigning an IP address to it. Second, whenever your router originates a packet and sends it out an interface, the sender IP address in the packet header will be set to the IP of the outgoing interface. Third, if you want that interface to participate in routing protocols (sending and receiving routing updates), it must have an IP address so that you can include it in the routing protocol configuration using the "network" command.

The tunnel interfaces are beautiful examples of confusion with transit links. Normally, we would say that transit links like point-to-point serial interfaces or tunnels do not need IP addresses, and for the most part, it is true. That is why the IP Unnumbered feature was designed for point-to-point links. But even with a tunnel, a situation may arise that a tunnel endpoint is the originator or the intended recipient of a traffic (for example, routing protocol traffic or simply pinging/telnetting/whatever to the other tunnel endpoint). Therefore we also need to set up IP addresses of tunnel interfaces themselves - to make them behave exactly as any other IP interfaces.

Best regards,

Peter

cool, I was just studying about this topics.

3 more questions

1)can you setup gre tunnel if you've a dynamic interface. Let's say a company that wants to connect a remote office to a campus via ADSL?

>As all messages from branch office will require the ADSL IP

2)if I use GRE, there's no need to NAT, packets will have source IP/ destination IP as defined in tunnel

3)If I want to do GRE over IPsec and IPsec in tunneled mode. What will be the source address for this?

Hello,

Regarding your questions:

1.) It is possible to create a tunnel where one endpoint has a dynamically assigned IP address. However, this requires the use of a supporting protocol called NHRP (Next Hop Resolution Protocol) through which the dynamic endpoint registers its current IP address at the central router. This type of tunnels is called multipoint GRE tunnel and you can find documentation about it on Cisco website by searching for "Dynamic Multipoint VPN".

2.) Correctly - if you are using GRE you do not need NAT because the tunnelled packets with private IP addresses in their headers will be encapsulated into GRE and further into a new IP header whose sender and recipient will be the set according to the "tunnel source" and "tunnel destination" command on the outgoing tunnel interface. The intermediate network will not have to deal with the encapsulated IP header.

3.) If you are doing the GRE over IPsec and IPsec in tunnel mode, you need first to consider the order of encapsulation. A packet will first be GRE-encapsulated and it gets a new IP header whose sender and recipient will be set according to the "tunnel source" and "tunnel destination" commands. This packet will be further IPsec-encrypted and a new IP header will be put onto it whose source IP will be taken from the interface through which the packet is being sent out, and the destination will be set according to the "set peer" in the crypto map.

Best regards,

Peter

thank you very much

Thanks very much for that Peter. I have been searching and unable to find a positive answer. You're explanation is is exactly what i was looking for.

Thanks

Ray

1) a packet which is GRE over IPSEC encapsulated (IPSEC in tunnel mode) contains 3 IP address fields from which 2 are encrypted?

2) a packet that is GRE over IPSEC (tunnel mode)

encapsulated, what will be in the routing table?

via tunnelx or via ATMx

does the GRE tunnel source/dest IP matter in that case (beside it must match on the other side of the tunnel) - does it need to be public - as IPSEC interface IP will be used+ destination peer IP.

3) Is it possible to setup GRE/ IPSEC over GRE/ IPsec tunnel to different branch offices when the HQ as only 1 public IP available for tunnels. I think it is.

As long the source/destination matches on the branch and HQ. source IP will be the same on the HQ but the destination IP will vary

Hello,

1.) Yes. The innermost IP header is the original header. The second IP header is the one added by the GRE tunnel interface. Both these headers are considered a payload for the IPsec which will encrypt them and add a third IP header that will not be encrypted anymore.

2.) I am not sure what exactly are you asking about in this question. The tunnel will always be present in the routing table whether it is a pure GRE or IPsec-protecteed. The GRE tunnel destination matters very much even with IPsec because the "tunnel destination" address will determine through which interface will the original (not yet encrypted) GRE packet be sent out. That interface must have a crypto map attached to it in order to encrypt the GRE using IPsec. However, of course, after the GRE packet is encrypted in IPsec packet, its new destination is the determined by the "set peer" command in the crypto map.

3.) I assume you are talking about a hub-and-spoke logical topology with a HQ being a hub and the branch offices being spokes. Yes, it possible and routinely used to use a single IP address as "tunnel source" for all tunnels on the HQ site leading to branches. However, the approach of creating multiple tunnels, one for each branch office, is not scalable and an improved approach is used in these circumstances - a so-called multipoint GRE tunnels (also called Dynamic Multipoint VPN, DMVPN).

Best regards,

Peter

interesting

is it a good idea to connect a bunch of remote site to a hq with DMVPN.

most of the times the remote sites have also a backup line which makes that each remote site has two 'dynamic' tunnels to a hq

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: