Contents

Introduction

Background Information

Four Different Tunnel States

P2P GRE Tunnel State

Line Protocol Down Locally on the Router

GRE Tunnel Keepalives

GRE Tunnels with Tunnel Protection

Multipoint GRE (mGRE) Tunnel Interfaces

Dependencies on Redundancy State

Troubleshoot

Related Information

Introduction

This document describes the different conditions that can affect the state of a Generic Routing Encapsulation (GRE) tunnel interface.

Background Information

GRE tunnels are designed to be completely stateless. This means that each tunnel endpoint does not keep any information about the state or availability of the remote tunnel endpoint.

A consequence is that, by default, the local tunnel endpoint router cannot bring the line protocol of the GRE Tunnel interface down if the remote end of the tunnel is unreachable.

The ability to mark an interface as "down" (in this situation) is used in order to remove any static routes in the routing table that use that interface as the outbound interface.

Specifically, if the line protocol for an interface is changed to "down", any static routes indicating that interface are removed from the routing table.

This allows for the installation of an alternate (floating) static route or for Policy Based Routing (PBR) in order to select an alternate next-hop or interface.

Also, there are other applications that trigger when an interface changes state; for example, 'backup interface <b-interface>'.

Four Different Tunnel States

There are four possible states in which a GRE tunnel interface exists:

1. Up/up - This implies that the tunnel is fully functional and passes traffic. It is both administratively up and its protocol is up as well.

2. Administratively down/down - This implies that the interface has been administratively shut down.

3. Up/down - This implies that, even though the tunnel is administratively up, something causes the line protocol on the interface to be down.

4. Reset/down - This is usually a transient state when the tunnel is reset by software. This usually happens when the tunnel is misconfigured with a Next Hop Server (NHS) that is its own IP address.

When a tunnel interface is first created and no other configuration is applied to it, the interface is not shut by default:

Router#show run interface tunnel 1

Building configuration...

Current configuration : 40 bytes

!

interface Tunnel1

no ip address

end

In this state, the interface is always up/down:

Router(config-if)#do show ip interface brief

Interface                  IP-Address      OK? Method Status                Protocol

GigabitEthernet0/0         172.16.52.1     YES NVRAM  administratively down down

GigabitEthernet0/1         10.36.128.49    YES NVRAM  down                  down

GigabitEthernet0/2         unassigned      YES NVRAM  down                  down

GigabitEthernet0/3         unassigned      YES NVRAM  down                  down

Loopback1                  192.168.2.1     YES NVRAM  up                    up

Tunnel1                    unassigned      YES unset  up                    down

This is because the interface is administratively enabled, but since it does not have a tunnel source or a tunnel destination, the line protocol is down.

In order to make this interface up/up, a valid tunnel source and tunnel destination must be configured:

Router#show run interface tunnel  1

Building configuration...

Current configuration : 113 bytes

!

interface Tunnel1

ip address 10.1.1.1 255.255.255.0

tunnel source Loopback1

tunnel destination 10.0.0.1

end

Router#show ip interface brief

Interface                  IP-Address      OK? Method Status                Protocol

GigabitEthernet0/0         172.16.52.1     YES NVRAM  up                    up

GigabitEthernet0/1         10.36.128.49    YES NVRAM  down                  down

GigabitEthernet0/2         unassigned      YES NVRAM  down                  down

GigabitEthernet0/3         unassigned      YES NVRAM  down                  down

Loopback0                  unassigned      YES unset  up                    up

Loopback1                  192.168.2.1     YES manual up                    up

Tunnel1                    10.1.1.1         YES manual up                    up

The previous sequence shows that:

- A valid tunnel source consists of any interface that is itself in the up/up state and has an IP address configured on it.

- For example, if the tunnel source was changed to Loopback0, the tunnel interface would go down even though Loopback0 is in the up/up state:

Router(config)#interface tunnel 1

Router(config-if)#tunnel source loopback 0

Router(config-if)#

*Sep  6 19:51:31.043: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to down

- A valid tunnel destination is one which is routable. However, it does not have to be reachable, which can be seen from this ping test:

Router#show ip route 10.0.0.1

% Network not in table

Router#show ip route | inc 0.0.0.0

Gateway of last resort is 172.16.52.100 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 172.16.52.100

Router#ping 10.0.0.1

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

So far, the tunnel has been configured as a point-to-point (P2P) GRE tunnel, which is the default.

If this tunnel were to be changed to a multipoint GRE (mGRE) tunnel, then all that is required for an up state is a valid tunnel source.

Note: An mGRE tunnel can have many tunnel destinations, so that cannot be used to control the tunnel interface state.

Router#show run interface tunnel 1

Building configuration...

Current configuration : 129 bytes

!

interface Tunnel1

ip address 10.1.1.1 255.255.255.0

no ip redirects

tunnel source Loopback1

tunnel mode gre multipoint

end

Router#show ip interface brief | include Tunnel

Tunnel1                    10.1.1.1         YES manual up                    up

At any point, if the tunnel interface is administratively shut down, the tunnel immediately goes into an administratively down/down state:

Router#show run interface tunnel 1

Building configuration...

Current configuration : 50 bytes

!

interface Tunnel1

no ip address

shutdown

end

Router#show ip interface brief | include Tunnel

Tunnel1                    unassigned      YES unset  administratively down down

P2P GRE Tunnel State

A P2P GRE Tunnel interface usually comes up as soon as it is configured with a valid tunnel source address or interface which is up and a tunnel destination IP address which is routable (shown previously).

Line Protocol Down Locally on the Router

Under normal circumstances, there are only three reasons for a GRE tunnel to be in the up/down state:

- There is no route, which includes the default route, to the tunnel destination address.

- The interface that anchors the tunnel source is down.

- The route to the tunnel destination address is through the tunnel itself, which results in recursion.

These three rules (missing, route, interface down, and misrouted tunnel destination) are problems local to the router at the tunnel endpoints.

They do not cover problems in the intervening network or other features related to the GRE tunnel that can be configured. This document describes scenarios where other factors can influence the state of the GRE tunnel.

GRE Tunnel Keepalives

The basic rules do not cover the case in which the GRE tunneled packets are successfully forwarded yet lost before they reach the other end of the tunnel.

This causes data packets that go through the GRE tunnel to be lost, even though an alternate route that uses PBR or a floating static route via another interface is potentially available.

Keepalives on the GRE tunnel interface are used in order to solve this issue in the same way keepalives are used on physical interfaces.

With Cisco IOS® Software Release 12.2(8)T, it is possible to configure keepalives on a P2P GRE tunnel interface. With this change, the tunnel interface dynamically shuts down if the keepalives fail for a certain period of time.

In order to better understand how GRE tunnel keepalives work, refer to GRE Tunnel Keepalives.

Note: GRE tunnel keepalives are only valid and have an effect on P2P GRE tunnels; they are not valid and do not have any effect on mGRE tunnels.

GRE Tunnels with Tunnel Protection

In Cisco IOS® Software Releases 15.4(3)M/15.4(3)S and later, the GRE tunnel line protocol state follows the IPsec Security Association (SA) state. Therefore, the line protocol can remain down until the IPsec session is fully established.

This was committed with Cisco bug ID CSCum34057 (initial attempt with Cisco bug ID CSCuj29996 and then backed out with Cisco bug ID CSCuj99287).

Multipoint GRE (mGRE) Tunnel Interfaces

For mGRE tunnel interfaces, some of the previous checks for P2P tunnels are not applicable (because there is no fixed tunnel destination).

Here are the reasons an mGRE tunnel line protocol can be in a down state:

- The tunnel source interface is in a down state.

- If the Interface State Control feature is enabled for Dynamic Multipoint VPN (DMVPN) and no NHSs respond, then the line protocol is put in a down state.

- For details on the Interface State Control Feature, see the DMVPN Tunnel Health Monitoring and Recovery Configuration Guide.

Dependencies on Redundancy State

When a tunnel source IP address is configured as a redundancy IP address (for example, a Hot Standby Router Protocol Virtual IP (HSRP VIP) address), then the tunnel interface state tracks the redundancy state.

This adds another check which keeps such tunnel interfaces in the line protocol down state until the redundancy state changes to ACTIVE.

In this example, a misconfigured ipc zone default configuration causes redundancy to be in the NEGOTIATION state and keeps such tunnel interfaces in a down state:

Router#show redundancy state

my state = 3  -NEGOTIATION

peer state = 1  -DISABLED

Mode = Simplex

Unit ID = 0

Maintenance Mode = Disabled

Manual Swact = disabled (system is simplex (no peer unit))

Communications = Down      Reason: Simplex mode

client count = 16

client_notification_TMR = 60000 milliseconds

RF debug mask = 0x0

Router#show interface tunnel100

Tunnel100 is up, line protocol is down

Hardware is Tunnel

Internet address is 172.16.1.100/24

MTU 17912 bytes, BW 100 Kbit/sec, DLY 50000 usec,

reliability 255/255, txload 1/255, rxload 1/255

Encapsulation TUNNEL, loopback not set

Keepalive not set

Tunnel source 10.122.162.254 (GigabitEthernet0/1)

Tunnel Subblocks:

src-track:

Tunnel100 source tracking subblock associated with GigabitEthernet0/1

Set of tunnels with source GigabitEthernet0/1, 2 members (includes

iterators), on interface <OK>

Tunnel protocol/transport multi-GRE/IP

<SNIP>

Troubleshoot

In addition to the reasons previously outlined, the tunnel line state evaluation for the tunnel down reason can be seen with the show tunnel interface tunnel x hidden command:

Router#show tunnel interface tunnel 100

Tunnel100

Mode:multi-GRE/IP, Destination UNKNOWN, Source GigabitEthernet0/1

Application ID 1: unspecified

Tunnel Subblocks:

src-track:

Tunnel100 source tracking subblock associated with GigabitEthernet0/1

Set of tunnels with source GigabitEthernet0/1, 2 members (includes

iterators), on interface <OK>

Linestate - current down

Internal linestate - current down, evaluated down - interface not up

Tunnel Source Flags: Local

Transport IPv4 Header DF bit cleared

OCE: IP tunnel decap

Provider: interface Tu100, prot 47

Performs protocol check [47]

Performs Address save check

Protocol Handler: GRE: key 0x64, opt 0x2000

ptype: ipv4 [ipv4 dispatcher: drop]

ptype: ipv6 [ipv6 dispatcher: drop]

ptype: mpls [mpls dispatcher: drop]

ptype: otv [mpls dispatcher: drop]

ptype: generic [mpls dispatcher: drop]

Note: There is an open enhancement to make the tunnel down reason more explicit in order to indicate that it is due to the redundancy state because it is not active. This is tracked by Cisco bug ID CSCuq31060.

Related Information

- RFC 1701, Generic Router Encapsulation (GRE)

- RFC 2890, Key and Sequence Number Extensions to GRE

- Generic Routing Encapsulation (GRE) Tunnel Keepalive

- IP Fragmentation and PMTUD

- Technical Support & Documentation - Cisco Systems