cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
485
Views
15
Helpful
7
Replies

Tunnel

suthomas1
Level 6
Level 6

When using a gre tunnel, we identify the source as one of the physical interfaces on the device.1)What is the significance if the source interface being used is the lan interface or if it is Wan interface.Would there be any problems in this.

2)If the tunnel source is undefined, but destination is defined, what could be the result & would the traffic still pass through? if no, why.

If yes, would it take the same path or go via another path?

Thanks.

1 Accepted Solution

Accepted Solutions

Victor

When I first read your post I interpreted it as advocating the WAN interface, especially since it does not mention using any other interface. But I agree that your post makes the point very clearly that what is required is that the destination address and the source address must be reachable.

HTH

Rick

HTH

Rick

View solution in original post

7 Replies 7

Edison Ortiz
Hall of Fame
Hall of Fame

On the GRE tunnel configuration, using the WAN interface at both ends will avoid relying on routing to bring up the tunnel as the source and destination are directly connected interfaces.

An undefined tunnel source isn't a complete GRE tunnel configuration and the tunnel will never come up. This value is mandatory.

HTH,

__

Edison.

Hi, Edison:

If I can just fine tune a bit....

It's not so much that the WAN interfaces on both peer routers (source and destination) are directly connected interfaces, but that they are reachable independent of a dynamic routing protocol, which of course wouldn't produce any routing information until the tunnel comes up in the first place.

Typically, I use static routes at both ends to point to the tunnel destination.

HTH

Victor

sunny

While I agree with Edison and Victor that using the WAN interface is the most common implementation, I will take a slightly different approach in answering your question.

As long as the configured tunnel destination address is reachable from the configured tunnel source address without using any information learned through the tunnel, then the tunnel should work. This means that the address could be the WAN interface, could be the LAN interface, or could be a loopback interface. In practical terms it is frequently easier (or simpler) to use the WAN interface but that is not required.

The GRE tunnel will encapsulate the original packet using the configured source address and destination address. So as Edison points out, if the tunnel is not configured with a source address then the configuration is incomplete and the tunnel will not operate.

HTH

Rick

HTH

Rick

Rick:

"As long as the configured tunnel destination address is reachable from the configured tunnel source address without using any information learned through the tunnel, then the tunnel should work."

That was precisely my point. I was actually not making a recommendation regarding which interface to use. I just added a point of clarification to something Edison wrote.

Victor

Victor

When I first read your post I interpreted it as advocating the WAN interface, especially since it does not mention using any other interface. But I agree that your post makes the point very clearly that what is required is that the destination address and the source address must be reachable.

HTH

Rick

HTH

Rick

Thanks all for that great explaination which helped me understand this better!

Its heard that mtu on gre causes issues.Can you all throw some light on actually how this affects and why so only on gre interfaces?

& how to isolate the cause to be this.

Thanks.

Sunny,

This URL has a great example on how GRE can affect connectivity to the outside world. It also answers your question with more detail than we can explain here.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a0080093f1f.shtml

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco