GRE Tunnel interfaces

[learner4397]

Hello,

Could someone please help me understand why do we really need 2 interfaces at both ends of a GRE tunnel?
Once we create a virtual tunnel interface, why is that interface not used as a source interface? Why we need to use another interface as source interface?

learner

[omz]

By design, GRE tunnels are completely stateless. Each tunnel endpoint does not keep any information about the state of the remote tunnel endpoint. By default, the local tunnel endpoint router does not have the ability to bring the line protocol of the GRE Tunnel interface down if the remote end of the tunnel is unreachable. 

[paul driver]

Hello

---

@omz wrote:

By design, GRE tunnels are completely stateless. Each tunnel endpoint does not keep any information about the state of the remote tunnel endpoint. By default, the local tunnel endpoint router does not have the ability to bring the line protocol of the GRE Tunnel interface down if the remote end of the tunnel is unreachable. 

---

However this can be easily negated by enabling keepalive on each tunnel so if either was to go down the opposite would also transition into a down state.

[learner4397]

Thank you for your reply Paul!

When you say tunnel endpoint, is it the tunnel interface or the source interface that acts as a tunnel endpoint?

Learner

[paul driver]

Hello

The physical interface of the tunnel will be the endpoint (specified tunnel source) However note that if this interface goes down it will ONLY shutdown the tunnel interface its related to locally not the far side of the tunnel interface unless keepalive is enabled on both tunnels then as I said if one tunnel interface goes down then its opposite will also.

[Julio E. Moisa]

Hi

The tunnels are used to encapsulate traffic passing from a point A to B and passing through networks where you could not have access or restricted like Internet, so basically the source and destination addresses are associated to broadcast or physical interfaces. A golden key is that the source and destination must have communication (making ping) before to create the tunnel. Now the Tunnel ip address (not meaning to source and destination address) can be an own IP (new network) or you can use a loopback for example through the command: 

interface tunnel 0

ip unnumbered loopback 0

tunnel source 190.5.47.8

tunne destination 200.47.47.93

<...others configs...>

Hope it is useful

:-)

[learner4397]

Thank you for explaining that.
However, as you also mentioned, a loopback can also be used as source interface. I wonder how and why is loopback used for this instead of a physical interface. It is also a logical int just like a tunnel int. How does it differs from a tunnel interface then? Or, why do we even need a loopback for in such scenario?

Learner.

[Julio E. Moisa]

Hi,

You are welcome, the Tunnel IP and source IP cannot be the same because it can generate layer 3 loops or recursive troubles when you are using routing protocols to route traffic from the point A to B.

Example: https://www.cisco.com/c/en/us/support/docs/ip/enhanced-interior-gateway-routing-protocol-eigrp/22327-gre-flap.html

:-)

[Joseph W. Doherty]

A loopback interface can be used if it's routable. If it is, than any physical interface that can get to the tunnel's destination address might be used, of course the one with the best path is used first.

How it differs from the tunnel IP is explained by Julio's reply.

[Joseph W. Doherty]

Because without a source interface, the tunnel doesn't know how to "route" itself. Effectively, the source interface is the logical next/first hop for the outbound tunnel packets.