What is the abbreviated name for a tunnel interface in the output of VPN boot up sequence output?

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 of this is that, 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. The ability to mark an interface as down when the remote end of the link is not available is used in order to remove any routes (specifically 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, then any static routes that point out 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 can be:

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:

end

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

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 ip interface brief

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 0Router(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.0S*    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 the tunnel to be in an up state is a valid tunnel source (an mGRE tunnel can have many tunnel destinations, so that cannot be used to control the tunnel interface state):

Router#show ip interface brief | include Tunnel

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

shutdown

Router#show ip interface brief | include Tunnel

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 as shown in the previous section.

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 and 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, but are lost before they reach the other end of the tunnel. This causes data packets that go through the GRE tunnel to be "black holed", 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 can follow the IPsec Security Association (SA) state, so 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, since there is no fixed tunnel destination, some of the previous checks for P2P tunnels are not applicable. 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 none of the 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 added an additional 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:

RF debug mask = 0x0

<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 as shown here:

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

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