Downloads |
Table Of Contents
Restrictions for Implementing Tunnels
Information About Implementing Tunnels
Tunneling Versus Encapsulation
GRE Tunnel IP Source and Destination VRF Membership
GRE/IPv4 Tunnel Support for IPv6 Traffic
IPv6 Manually Configured Tunnels
Configuring GRE on IPv6 Tunnels
Configuring GRE Tunnel IP Source and Destination VRF Membership
Manually Configuring IPv6 Tunnels
Verifying Tunnel Configuration and Operation
Configuration Examples for Implementing Tunnels
Examples: Configuring GRE/IPv4 Tunnels
Example: Configuring GRE/IPv6 Tunnels
Example: Configuring GRE Tunnel IP Source and Destination VRF Membership
Example: Configuring EoMPLS over GRE
Example: Manually Configuring IPv6 Tunnels
Example: Configuring 6to4 Tunnels
Example: Configuring ISATAP Tunnels
Example: Configuring QoS Options on Tunnel Interfaces
Feature Information for Implementing Tunnels
Implementing Tunnels
First Published: May 2, 2005
Last Updated: June 26, 2010This module describes the various types of tunneling techniques that are available using the Cisco IOS XE software. Configuration details and examples are provided for the tunnel types that use physical or virtual interfaces. Many tunneling techniques are implemented using technology-specific commands, and links are provided to the appropriate technology modules.
Tunneling provides a way to encapsulate arbitrary packets inside a transport protocol. Tunnels are implemented as a virtual interface to provide a simple interface for configuration. The tunnel interface is not tied to specific "passenger" or "transport" protocols, but rather is an architecture to provide the services necessary to implement any standard point-to-point encapsulation scheme.
NoteCisco ASR 1000 Series Aggregation Services Routers support VPN routing and forwarding (VRF)-aware generic routing encapsulation (GRE) tunnel keepalive features.
Finding Feature Information
For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Implementing Tunnels" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
•
•
•
Restrictions for Implementing Tunnels
•
•
•
For example, in the topology shown in Figure 1, packets from Host 1 will appear to travel across networks w, t, and z to get to Host 2 instead of taking the path w, x, y, and z because the tunnel hop count appears shorter. In fact, the packets going through the tunnel will still be traveling across Router A, B, and C, but they must also travel to Router D before coming back to Router C.Figure 1 Tunnel Precautions: Hop Counts
•
–
–
–
When you have recursive routing to the tunnel destination, the following error is displayed:
%TUN-RECURDOWN Interface Tunnel 0temporarily disabled due to recursive routingInformation About Implementing Tunnels
•
•
•
Tunneling Versus Encapsulation
To understand how tunnels work, it is important to distinguish between the concepts of encapsulation and tunneling. Encapsulation is the process of adding headers to data at each layer of a particular protocol stack. The Open Systems Interconnection (OSI) reference model describes the functions of a network as seven layers stacked on top of each other. When data has to be sent from one host (a PC for example) on a network to another host, the process of encapsulation is used to add a header in front of the data at each layer of the protocol stack in descending order. The header must contain a data field that indicates the type of data encapsulated at the layer immediately above the current layer. As the packet ascends the protocol stack on the receiving side of the network, each encapsulation header is removed in the reverse order.
Tunneling encapsulates data packets from one protocol inside a different protocol and transports the data packets unchanged across a foreign network. Unlike encapsulation, tunneling allows a lower-layer protocol, or same-layer protocol, to be carried through the tunnel. A tunnel interface is a virtual (or logical) interface. Although many different types of tunnels have been created to solve different network problems, tunneling consists of three main components:
•
•
•
Figure 2 illustrates IP tunneling terminology and concepts.
Figure 2 IP Tunneling Terminology and Concepts
Tunnel ToS
Tunnel type of service (ToS) allows you to tunnel your network traffic and group all your packets in the same specific ToS byte value. The ToS byte values and Time-to-Live (TTL) hop-count value can be set in the encapsulating IP header of tunnel packets for an IP tunnel interface on a router. The Tunnel ToS feature is supported for Cisco Express Forwarding (CEF), fast switching, and process switching.
The ToS and TTL byte values are defined in RFC 791. RFC 2474 and RFC 2780 obsolete the use of the ToS byte as defined in RFC 791. RFC 791 specifies that bits 6 and 7 of the ToS byte (the first two least significant bits) are reserved for future use and should be set to 0. For Cisco IOS XE Release 2.1, the Tunnel ToS feature does not conform to this standard and allows you to set the whole ToS byte value, including bits 6 and 7, and to decide to which RFC standard the ToS byte of your packets should conform.
Generic Routing Encapsulation
Generic routing encapsulation (GRE) is defined in RFC 2784. GRE is a carrier protocol that can be used with a variety of underlying transport protocols and that can carry a variety of passenger protocols. RFC 2784 also covers the use of GRE with IPv4 as the transport protocol and the passenger protocol. The Cisco IOS XE software supports GRE as the carrier protocol with many combinations of passenger and transport protocols such as:
•
•
GRE tunnels are described in the following sections:
•
•
GRE Tunnel IP Source and Destination VRF Membership
The GRE Tunnel IP Source and Destination VRF Membership feature allows you to configure the source and destination of a tunnel to belong to any VPN routing and forwarding (VRFs) tables. A VRF table stores routing data for each VPN. The VRF table defines the VPN membership of a customer site attached to the network access server (NAS). Each VRF table comprises an IP routing table, a derived CEF table, and guidelines and routing protocol parameters that control the information that is included in the routing table.
Prior to Cisco IOS XE Release 2.2, GRE IP tunnels required the IP tunnel destination to be in the global routing table. The implementation of this feature allows you to configure a tunnel source and destination to belong to any VRF. As with existing GRE tunnels, the tunnel becomes disabled if no route to the tunnel destination is defined.
GRE/IPv4 Tunnel Support for IPv6 Traffic
IPv6 traffic can be carried over IPv4 GRE tunnels using the standard GRE tunneling technique that is designed to provide the services necessary to implement any standard point-to-point encapsulation scheme. As in IPv6 manually configured tunnels, GRE tunnels are links between two points, with a separate tunnel for each link. The tunnels are not tied to a specific passenger or transport protocol, but in this case, IPv6 is the passenger protocol, GRE is the carrier protocol, and IPv4 is the transport protocol.
The primary use of GRE tunnels is for stable connections that require regular secure communication between two edge routers or between an edge router and an end system. The edge routers and the end systems must be dual-stack implementations.
GRE has a protocol field that identifies the passenger protocol. GRE tunnels allow intermediate system to intermediate system (IS-IS) or IPv6 to be specified as a passenger protocol, allowing both IS-IS and IPv6 traffic to run over the same tunnel. If GRE did not have a protocol field, it would be impossible to distinguish whether the tunnel was carrying IS-IS or IPv6 packets. The GRE protocol field is why it is desirable that you tunnel IS-IS and IPv6 inside GRE.
EoMPLS over GRE
Ethernet over MPLS (EoMPLS) is a tunneling mechanism that allows you to tunnel Layer 2 traffic through a Layer 3 MPLS network. EoMPLS is also known as Layer 2 tunneling.
EoMPLS effectively facilitates the Layer 2 extension over long distances. EoMPLS over GRE helps you to create the GRE tunnel as hardware-based switched, and encapsulates EoMPLS frames within the GRE tunnel. The GRE connection is established between the two core routers, and then the MPLS label switched path (LSP) is tunneled over.
GRE encapsulation is used to define a packet that has header information added to it prior to being forwarded. De-encapsulation is the process of removing the additional header information when the packet reaches the destination tunnel endpoint.
When a packet is forwarded through a GRE tunnel, two new headers are added to the front of the packet, and hence the context of the new payload changes. After encapsulation, what was originally the data payload and separate IP header are now known as the GRE payload. A GRE header is added to the packet to provide information on the protocol type and provides information on the recalculated checksum. A new IP header is also added to the front of the GRE header. This IP header contains the destination IP address of the tunnel.
The GRE header is added to the packet such as IP, L2VPN, and L3VPN before the header enters into the tunnel. All routers along the path that receives the encapsulated packet uses the new IP header to determine how the packet can reach the tunnel endpoint.
In IP forwarding, on reaching the tunnel destination endpoint, the new IP header and the GRE header are removed from the packet and the original IP header is then used to forward the packet to the final destination.
The EoMPLS over GRE feature removes the new IP header and GRE header from the packet at the tunnel destination and the MPLS label is used to forward the packet to the appropriate Layer 2 attachment circuit or Layer 3 VRF.
The scenarios in the following sections describe the L2VPN and L3VPN over GRE deployment on provider edge (PE) or provider (P) routers:
PE to PE GRE Tunnels
In the PE to PE GRE tunnels scenario, a customer does not generally transition any part of the core to MPLS but prefers to offer EoMPLS and basic MPLS VPN services. Hence GRE tunneling of the MPLS labeled traffic is done between PEs. This is the most common scenario used in customer networks.
P to P GRE Tunnels
The P to P GRE tunnels scenario is one where MPLS is enabled between PE and P routers, but the network core may have no- MPLS-aware routers or IP encryption boxes. In this scenario, GRE tunneling of the MPLS labeled packets is done between P routers.
PE to P GRE Tunnels
In PE to P GRE tunnels scenario, a network P to P nodes are MPLS-aware while GRE tunneling is done between a PE to P non-MPLS network segment.
The features shown in the following lists are required for the deployment of scenarios described:
Features Specific to GRE
•
•
•
•
•
•
•
•
•
•
•
Features Specific to EoMPLS
•
•
•
•
•
•
•
Features Specific to MPLS VPN
•
•
•
•
•
See the "Example: Configuring EoMPLS over GRE" for a sample configuration sequence of EoMPLS over GRE. For more details on EoMPLS over GRE, see the Deploying and Configuring MPLS Virtual Private Networks In IP Tunnel Environments document.
Overlay Tunnels for IPv6
Overlay tunneling encapsulates IPv6 packets in IPv4 packets for delivery across an IPv4 infrastructure (a core network or the Internet). (See Figure 3.) By using overlay tunnels, you can communicate with isolated IPv6 networks without upgrading the IPv4 infrastructure between them. Overlay tunnels can be configured between border routers or between a border router and a host; however, both tunnel endpoints must support both the IPv4 and IPv6 protocol stacks. Cisco IOS XE IPv6 supports the following types of overlay tunneling mechanisms:
•
•
•
•
•
Figure 3 Overlay Tunnels
NoteUse Table 1 to help you determine which type of tunnel you want to configure to carry IPv6 packets over an IPv4 network.
Individual tunnel types are discussed in detail in the following concepts, and we recommend that you review and understand the information on the specific tunnel type that you want to implement. When you are familiar with the type of tunnel, you need to consult Table 2 for a summary of the tunnel configuration parameters that you may find useful.
IPv6 Manually Configured Tunnels
A manually configured tunnel is equivalent to a permanent link between two IPv6 domains over an IPv4 backbone. The primary use is for stable connections that require regular secure communication between two edge routers or between an end system and an edge router, or for connection to remote IPv6 networks.
An IPv6 address is manually configured on a tunnel interface, and manually configured IPv4 addresses are assigned to the tunnel source and the tunnel destination. The host or router at each end of a configured tunnel must support both the IPv4 and IPv6 protocol stacks. Manually configured tunnels can be configured between border routers or between a border router and a host. CEF switching can be used for IPv6 manually configured tunnels, or the switching can be disabled if process switching is needed.
Automatic 6to4 Tunnels
An automatic 6to4 tunnel allows isolated IPv6 domains to be connected over an IPv4 network to remote IPv6 networks. The key difference between automatic 6to4 tunnels and manually configured tunnels is that the tunnel is not point-to-point, it is point-to-multipoint. In automatic 6to4 tunnels, routers are not configured in pairs because they treat the IPv4 infrastructure as a virtual nonbroadcast multiaccess (NBMA) link. The IPv4 address embedded in the IPv6 address is used to find the other end of the automatic tunnel.
An automatic 6to4 tunnel may be configured on a border router in an isolated IPv6 network, which creates a tunnel on a per-packet basis to a border router in another IPv6 network over an IPv4 infrastructure. The tunnel destination is determined by the IPv4 address of the border router extracted from the IPv6 address that starts with the prefix 2002::/16, where the format is 2002:border-router-IPv4-address::/48. Following the embedded IPv4 address are 16 bits that can be used to number networks within the site. The border router at each end of a 6to4 tunnel must support both the IPv4 and IPv6 protocol stacks. 6to4 tunnels are configured between border routers or between a border router and a host.
The simplest deployment scenario for 6to4 tunnels is to interconnect multiple IPv6 sites, each of which has at least one connection to a shared IPv4 network. This IPv4 network could be the global Internet or a corporate backbone. The key requirement is that each site have a globally unique IPv4 address; the Cisco IOS XE software uses this address to construct a globally unique 6to4/48 IPv6 prefix. As with other tunnel mechanisms, appropriate entries in a Domain Name System (DNS) that map between hostnames and IP addresses for both IPv4 and IPv6 allow the applications to choose the required address.
ISATAP Tunnels
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) is an automatic overlay tunneling mechanism that uses the underlying IPv4 network as an NBMA link layer for IPv6. ISATAP is designed for transporting IPv6 packets within a site where a native IPv6 infrastructure is not yet available, for example, when sparse IPv6 hosts are deployed for testing. ISATAP tunnels allow individual IPv4/IPv6 dual-stack hosts within a site to communicate with other such hosts on the same virtual link, basically creating an IPv6 network using the IPv4 infrastructure.
The ISATAP router provides standard router advertisement network configuration support for the ISATAP site. This feature allows clients to automatically configure themselves as they would if they were connected to an Ethernet. It can also be configured to provide connectivity out of the site. ISATAP uses a well-defined IPv6 address format composed of any unicast IPv6 prefix (/64), which can be link local or global (including 6to4 prefixes), enabling IPv6 routing locally or on the Internet. The IPv4 address is encoded in the last 32 bits of the IPv6 address, enabling automatic IPv6-in-IPv4 tunneling.
Although the ISATAP tunneling mechanism is similar to other automatic tunneling mechanisms, such as IPv6 6to4 tunneling, ISATAP is designed for transporting IPv6 packets within a site, but not between sites.
ISATAP uses unicast addresses that include a 64-bit IPv6 prefix and a 64-bit interface identifier. The interface identifier is created in modified EUI-64 format in which the first 32 bits contain the value 000:5EFE to indicate that the address is an IPv6 ISATAP address. Table 3 shows the layout of an ISATAP address.
Table 3 ISATAP Address Example
Link local or global IPv6 unicast prefix
0000:5EFE
IPv4 address of the ISATAP link
As shown in Table 3, an ISATAP address consists of an IPv6 prefix and the ISATAP interface identifier. This interface identifier includes the IPv4 address of the underlying IPv4 link. The following example shows what an actual ISATAP address would look like if the prefix is 2001:0DB8:1234:5678::/64 and the embedded IPv4 address is 10.173.129.8. In the ISATAP address, the IPv4 address is expressed in hexadecimal as 0AAD:8108.
2001:0DB8:1234:5678:0000:5EFE:0AAD:8108
Path MTU Discovery
Path MTU Discovery (PMTUD) can be enabled on a GRE or IP-in-IP tunnel interface. When PMTUD (RFC 1191) is enabled on a tunnel interface, the router performs PMTUD processing for the GRE (or IP-in-IP) tunnel IP packets. The router always performs PMTUD processing on the original data IP packets that enter the tunnel. When PMTUD is enabled, packet fragmentation is not permitted for packets that traverse the tunnel because the Don't Fragment (DF) bit is set on all the packets. If a packet that enters the tunnel encounters a link with a smaller MTU, the packet is dropped and an Internet Control Message Protocol (ICMP) message is sent back to the sender of the packet. This message indicates that fragmentation was required (but not permitted) and provides the MTU of the link that caused the packet to be dropped.
NoteUse the tunnel path-mtu-discovery command to enable PMTUD for the tunnel packets, and use the show interfaces tunnel command to verify the tunnel PMTUD parameters. PMTUD works only on GRE and IP-in-IP tunnel interfaces.
QoS Options for Tunnels
A tunnel interface supports many of the same quality of service (QoS) features as a physical interface. QoS provides a way to ensure that mission-critical traffic has an acceptable level of performance. QoS options for tunnels include support for applying generic traffic shaping (GTS) directly on the tunnel interface and support for class-based shaping using the modular QoS CLI (MQC). Tunnel interfaces also support class-based policing, but they do not support committed access rate (CAR).
GRE tunnels allow the router to copy the IP precedence bit values of the ToS byte to the tunnel or the GRE IP header that encapsulates the inner packet. Intermediate routers between the tunnel endpoints can use the IP precedence values to classify the packets for QoS features such as policy routing, weighted fair queueing (WFQ), and weighted random early detection (WRED).
When packets are encapsulated by tunnel or encryption headers, QoS features are unable to examine the original packet headers and correctly classify the packets. Packets that travel across the same tunnel have the same tunnel headers, so the packets are treated identically if the physical interface is congested. Tunnel packets can, however, be classified before tunneling and encryption can occur by using the QoS preclassify feature on the tunnel interface or on the crypto map.
NoteFor examples of how to implement some QoS features on a tunnel interface, see the "Example: Configuring QoS Options on Tunnel Interfaces" section.
How to Implement Tunnels
This section contains the following tasks:
•
•
•
•
•
•
•
•
Determining the Tunnel Type
Before configuring a tunnel, you must determine what type of tunnel you need to create.
SUMMARY STEPS
•
•
DETAILED STEPS
1.
2.
Table 4 shows how to determine the appropriate keyword to use with the tunnel mode command. In the following tasks, only the relevant keywords for the tunnel mode command are displayed.
•
•
•
•
What to Do Next
•
•
–
–
–
–
Configuring a GRE Tunnel
Perform this task to configure a GRE tunnel. A tunnel interface is used to pass protocol traffic across a network that does not normally support the protocol. To build a tunnel, you must define a tunnel interface on each of two routers and the tunnel interfaces must reference each other. At each router, the tunnel interface must be configured with a Layer 3 address. The tunnel endpoints, tunnel source, and tunnel destination must be defined, and the type of tunnel must be selected. Optional steps can be performed to customize the tunnel.
Remember to configure the router at each end of the tunnel. If only one side of a tunnel is configured, the tunnel interface may still come up and stay up (unless keepalive is configured), but packets going into the tunnel will be dropped.
GRE Tunnel Keepalive
Keepalive packets can be configured to be sent over IP-encapsulated GRE tunnels. You can specify the rate at which keepalives will be sent and the number of times that a device will continue to send keepalive packets without a response before the interface becomes inactive. GRE keepalive packets may be sent from both sides of a tunnel or from just one side.
Prerequisites
Ensure that the physical interface to be used as the tunnel source in this task is up and configured with the appropriate IP address. For hardware technical descriptions and information about installing interfaces, see the hardware installation and configuration publication for your product.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
interface type number
Example:Router(config)# interface tunnel 0
Specifies the interface type and number and enters interface configuration mode.
•
Step 4
bandwidth kb/s
Example:Router(config-if)# bandwidth 1000
Sets the current bandwidth value for an interface and communicates it to higher-level protocols, and specifies the tunnel bandwidth to be used to transmit packets.
•
Note
Step 5
keepalive [period [retries]]
Example:Router(config-if)# keepalive 3 7
(Optional) Specifies the number of times that the device will continue to send keepalive packets without response before bringing the tunnel interface protocol down.
•
•
Note
Step 6
tunnel source {ip-address | interface-type interface-number}
Example:Router(config-if)# tunnel source GigabitEthernet 0/0/0
Configures the tunnel source.
•
•
Note
Step 7
tunnel destination {hostname | ip-address}
Example:Router(config-if)# tunnel destination 172.17.2.1
Configures the tunnel destination.
•
•
Note
Step 8
tunnel key key-number
Example:Router(config-if)# tunnel key 1000
(Optional) Enables an ID key for a tunnel interface.
•
•
Note
Step 9
tunnel mode {gre ip | gre multipoint}
Example:Router(config-if)# tunnel mode gre ip
Specifies the encapsulation protocol to be used in the tunnel.
•
•
Step 10
ip mtu bytes
Example:Router(config-if)# ip mtu 1400
(Optional) Sets the MTU size of IP packets sent on an interface.
•
•
•
Note
Step 11
ip tcp mss mss-value
Example:Router(config-if)# ip tcp mss 250
(Optional) Specifies the maximum segment size (MSS) for TCP connections that originate or terminate on a router.
•
Step 12
tunnel path-mtu-discovery [age-timer {aging-mins | infinite}]
Example:Router(config-if)# tunnel path-mtu-discovery
(Optional) Enables PMTUD on a GRE or IP-in-IP tunnel interface.
•
Step 13
end
Example:Router(config-if)# end
Exits interface configuration mode and returns to privileged EXEC mode.
What to Do Next
Proceed to the "Verifying Tunnel Configuration and Operation" section.
Configuring GRE on IPv6 Tunnels
This task explains how to configure a GRE tunnel on an IPv6 network. GRE tunnels can be configured to run over an IPv6 network layer and to transport IPv6 packets in IPv6 tunnels and IPv4 packets in IPv6 tunnels.
Prerequisites
When GRE/IPv6 tunnels are configured, IPv6 addresses are assigned to the tunnel source and the tunnel destination. The tunnel interface can have either IPv4 or IPv6 addresses assigned (this is not shown in the following task). The host or router at each end of a configured tunnel must support both the IPv4 and IPv6 protocol stacks.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
interface tunnel tunnel-number
Example:Router(config)# interface tunnel 0
Specifies a tunnel interface and number and enters interface configuration mode.
Step 4
tunnel source {ipv6-address | interface-type interface-number}
Example:Router(config-if)# tunnel source GigabitEthernet 0/0/0
Specifies the source IPv6 address or the source interface type and number for the tunnel interface.
•
Note
Step 5
tunnel destination ipv6-address
Example:Router(config-if)# tunnel destination 2001:0DB8:0C18:2::300
Specifies the destination IPv6 address for the tunnel interface.
Note
Step 6
tunnel mode gre ipv6
Example:Router(config-if)# tunnel mode gre ipv6
Specifies a GRE IPv6 tunnel.
Note
Step 7
ipv6 mtu bytes
Example:Router(config-if)# ipv6 mtu 1400
(Optional) Sets the MTU size of IPv6 packets sent on an interface.
Step 8
end
Example:Router(config-if)# end
Exits interface configuration mode and returns to privileged EXEC mode.
What to Do Next
Proceed to the "Verifying Tunnel Configuration and Operation" section.
Configuring GRE Tunnel IP Source and Destination VRF Membership
This task explains how to configure the source and destination of a tunnel to belong to any VRF tables.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
What to Do Next
Proceed to the "Verifying Tunnel Configuration and Operation" section.
Manually Configuring IPv6 Tunnels
This task explains how to manually configure a IPv6 overlay tunnel.
Prerequisites
With manually configured IPv6 tunnels, an IPv6 address is configured on a tunnel interface and manually configured IPv4 addresses are assigned to the tunnel source and the tunnel destination. The host or router at each end of a configured tunnel must support both the IPv4 and IPv6 protocol stacks.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
interface tunnel tunnel-number
Example:Router(config)# interface tunnel 0
Specifies a tunnel interface and number and enters interface configuration mode.
Step 4
ipv6 address ipv6-prefix/prefix-length [eui-64]
Example:Router(config-if)# ipv6 address 2001:0DB8:1234:5678::3/126
Specifies the IPv6 network assigned to the interface and enables IPv6 processing on the interface.
Note
Step 5
tunnel source {ip-address | interface-type interface-number}
Example:Router(config-if)# tunnel source GigabitEthernet 0/0/0
Specifies the source IPv4 address or the source interface type and number for the tunnel interface.
•
Step 6
tunnel destination ip-address
Example:Router(config-if)# tunnel destination 192.168.30.1
Specifies the destination IPv4 address for the tunnel interface.
Step 7
tunnel mode ipv6ip
Example:Router(config-if)# tunnel mode ipv6ip
Specifies a manually configured IPv6 tunnel.
Note
Step 8
end
Example:Router(config-if)# end
Exits interface configuration mode and returns to privileged EXEC mode.
What to Do Next
Proceed to the "Verifying Tunnel Configuration and Operation" section.
Configuring 6to4 Tunnels
This task explains how to configure a 6to4 overlay tunnel.
Prerequisites
With 6to4 tunnels, the tunnel destination is determined by the border-router IPv4 address, which is concatenated to the prefix 2002::/16 in the format 2002:border-router-IPv4-address::/48. The border router at each end of a 6to4 tunnel must support both the IPv4 and IPv6 protocol stacks.
Restrictions
The configuration of only one IPv4-compatible tunnel and one 6to4 IPv6 tunnel is supported on a router. If you choose to configure both of these tunnel types on the same router, we strongly recommend that they not share the same tunnel source.
The reason that a 6to4 tunnel and an IPv4-compatible tunnel cannot share the same interface is that both of them are NBMA "point-to-multipoint" access links and only the tunnel source can be used to reorder the packets from a multiplexed packet stream into a single packet stream for an incoming interface. therefore, when a packet with an IPv4 protocol type of 41 arrives on an interface, that packet is mapped to an IPv6 tunnel interface on the basis of the IPv4 address. However, if both the 6to4 tunnel and the IPv4-compatible tunnel share the same source interface, the router cannot determine the IPv6 tunnel interface to which it should assign the incoming packet.
IPv6 manually configured tunnels can share the same source interface because a manual tunnel is a "point-to-point" link, and both the IPv4 source and IPv4 destination of the tunnel are defined.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Step 1
enable
Example:Router> enable
Enables privileged EXEC mode.
•
Step 2
configure terminal
Example:Router# configure terminal
Enters global configuration mode.
Step 3
interface tunnel tunnel-number
Example:Router(config)# interface tunnel 0
Specifies a tunnel interface and number and enters interface configuration mode.
Step 4
ipv6 address ipv6-prefix/prefix-length [eui-64]
Example:Router(config-if)# ipv6 address 2002:c0a8:6301:1::1/64
Specifies the IPv6 address assigned to the interface and enables IPv6 processing on the interface.
•
Note
Step 5
tunnel source {ip-address | interface-type interface-number}
Example:Router(config-if)# tunnel source GigabitEthernet 0/0/0
Specifies the source IPv4 address or the source interface type and number for the tunnel interface.
Note
Step 6
tunnel mode ipv6ip 6to4
Example:Router(config-if)# tunnel mode ipv6ip 6to4
Specifies an IPv6 overlay tunnel using a 6to4 address.
Step 7
exit
Example:Router(config-if)# exit
Exits interface configuration mode and returns to global configuration mode.
Step 8
ipv6 route ipv6-prefix/prefix-length tunnel tunnel-number
Example:Router(config)# ipv6 route 2002::/16 tunnel 0
Configures a static route for the IPv6 6to4 prefix 2002::/16 to the specified tunnel interface.
Note
•
What to Do Next
Proceed to the "Verifying Tunnel Configuration and Operation" section.
Configuring ISATAP Tunnels
This task describes how to configure an ISATAP overlay tunnel.
Prerequisites
The tunnel source command used in the configuration of an ISATAP tunnel must point to an interface that is configured with an IPv4 address. The ISATAP IPv6 address and prefix (or prefixes) advertised are configured for a native IPv6 interface. The IPv6 tunnel interface must be configured with a modified eui-64 address because the last 32 bits in the interface identifier are constructed using the IPv4 tunnel source address.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Step 4
ipv6 address ipv6-prefix/prefix-length [eui-64]
Example:Router(config-if)# ipv6 address 2001:0DB8:6301::/64 eui-64
Specifies the IPv6 address assigned to the interface and enables IPv6 processing on the interface.
Note
Step 5
no ipv6 nd suppress-ra
Example:Router(config-if)# no ipv6 nd suppress-ra
Enables sending of IPv6 router advertisements to allow client autoconfiguration.
•
Step 6
tunnel source {ip-address | interface-type interface-number}
Example:Router(config-if)# tunnel source GigabitEthernet 0/0/1
Specifies the source IPv4 address or the source interface type and number for the tunnel interface.
Note
Step 7
tunnel mode ipv6ip isatap
Example:Router(config-if)# tunnel mode ipv6ip isatap
Specifies an IPv6 overlay tunnel using an ISATAP address.
Step 8
end
Example:Router(config-if)# end
Exits interface configuration mode and returns to privileged EXEC mode.
What to Do Next
Proceed to the "Verifying Tunnel Configuration and Operation" section.
Verifying Tunnel Configuration and Operation
This optional task explains how to verify tunnel configuration and operation. The show and ping commands contained in the task steps can be used in any sequence and may need to be repeated. The following commands can be used for GRE tunnels, IPv6 manually configured tunnels, and IPv6 over IPv4 GRE tunnels.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Step 1
Enables privileged EXEC mode. Enter your password if prompted.
Router> enableStep 2
Assuming a generic example suitable for both IPv6 manually configured tunnels and IPv6 over IPv4 GRE tunnels, two routers are configured to be endpoints of a tunnel. Router A has GigabitEthernet interface 0/0/0 configured as the source for tunnel interface 0 with an IPv4 address of 10.0.0.1 and an IPv6 prefix of 2001:0DB8:1111:2222::1/64. Router B has Gigabit Ethernet interface 0/0/0 configured as the source for tunnel interface 1 with an IPv4 address of 10.0.0.2 and an IPv6 prefix of 2001:0DB8:1111:2222::2/64.
To verify that the tunnel source and destination addresses are configured, use the show interfaces tunnel command on Router A.
RouterA# show interfaces tunnel 0Tunnel0 is up, line protocol is upHardware is TunnelMTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,reliability 255/255, txload 1/255, rxload 1/255Encapsulation TUNNEL, loopback not setKeepalive not setTunnel source 10.0.0.1 (GigabitEthernet0/0/0), destination 10.0.0.2, fastswitch TTL 255Tunnel protocol/transport GRE/IP, key disabled, sequencing disabledTunnel TTL 255Checksumming of packets disabled, fast tunneling enabledLast input 00:00:14, output 00:00:04, output hang neverLast clearing of "show interface" counters neverInput queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0Queueing strategy: fifoOutput queue :0/0 (size/max)5 minute input rate 0 bits/sec, 0 packets/sec5 minute output rate 0 bits/sec, 0 packets/sec4 packets input, 352 bytes, 0 no bufferReceived 0 broadcasts, 0 runts, 0 giants, 0 throttles0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort8 packets output, 704 bytes, 0 underruns0 output errors, 0 collisions, 0 interface resets0 output buffer failures, 0 output buffers swapped outStep 3
To check that the local endpoint is configured and working, use the ping command on Router A.
RouterA# ping 2001:0DB8:1111:2222::2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 2001:0DB8:1111:2222::2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 msStep 4
To check that a route exists to the remote endpoint address, use the show ip route command.
RouterA# show ip route 10.0.0.2Routing entry for 10.0.0.0/24Known via "connected", distance 0, metric 0 (connected, via interface)Routing Descriptor Blocks:* directly connected, via GigabitEthernet0/0/0Route metric is 0, traffic share count is 1Step 5
To check that the remote endpoint address is reachable, use the ping command on Router A.
NoteRouterA# ping 10.0.0.2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 20/21/28 msTo check that the remote IPv6 tunnel endpoint is reachable, use the ping command again on Router A. The same note on filtering also applies to this example.
RouterA# ping 1::2Type escape sequence to abort.Sending 5, 100-byte ICMP Echos to 1::2, timeout is 2 seconds:!!!!!Success rate is 100 percent (5/5), round-trip min/avg/max = 20/20/20 msThese steps may be repeated at the other endpoint of the tunnel.
Configuration Examples for Implementing Tunnels
•
•
•
•
•
•
•
•
Examples: Configuring GRE/IPv4 Tunnels
The following example shows a simple configuration of GRE tunneling. Note that Gigabit Ethernet interface 0/0/1 is the tunnel source for Router A and the tunnel destination for Router B. Fast Ethernet interface 0/0/1 is the tunnel source for Router B and the tunnel destination for Router A.
Router A
interface Tunnel 0ip address 10.1.1.2 255.255.255.0tunnel source GigabitEthernet 0/0/1tunnel destination 192.168.3.2tunnel mode gre ip!interface GigabitEthernet 0/0/1ip address 192.168.4.2 255.255.255.0Router B
interface Tunnel 0ip address 10.1.1.1 255.255.255.0tunnel source FastEthernet 0/0/1tunnel destination 192.168.4.2tunnel mode gre ip!interface FastEthernet 0/0/1ip address 192.168.3.2 255.255.255.0The following example configures a GRE tunnel running both IS-IS and IPv6 traffic between Router A and Router B:
Router A
ipv6 unicast-routingclns routing!interface Tunnel 0no ip addressipv6 address 2001:0DB8:1111:2222::1/64ipv6 router isistunnel source GigabitEthernet 0/0/0tunnel destination 10.0.0.2tunnel mode gre ip!interface GigabitEthernet 0/0/0ip address 10.0.0.1 255.255.255.0!router isisnetwork 49.0000.0000.000a.00Router B
ipv6 unicast-routingclns routing!interface Tunnel 0no ip addressipv6 address 2001:0DB8:1111:2222::2/64ipv6 router isistunnel source GigabitEthernet 0/0/0tunnel destination 10.0.0.1tunnel mode gre ip!interface GigabitEthernet 0/0/0ip address 10.0.0.2 255.255.255.0!router isisnetwork 49.0000.0000.000b.00address-family ipv6redistribute staticexit-address-familyExample: Configuring GRE/IPv6 Tunnels
The following example shows how to configure a GRE tunnel over an IPv6 transport. Gigabit Ethernet interface 0/0/0 has an IPv6 address configured, and this is the source address used by the tunnel interface. The destination IPv6 address of the tunnel is specified directly. In this example, the tunnel carries both IPv4 and IS-IS traffic.
interface Tunnel 0ip address 10.1.1.1 255.255.255.0ip router isistunnel source GigabitEthernet 0/0/0tunnel destination 2001:DB8:1111:2222::1tunnel mode gre ipv6!interface FastEthernet 0/0no ip addressipv6 address 2001:DB8:1111:1111::1/64!router isisnet 49.0001.0000.0000.000a.00Example: Configuring GRE Tunnel IP Source and Destination VRF Membership
In this example, packets received on Fast Ethernet interface 0 using VRF green, will be forwarded out of the tunnel through fast ethernet interface 1 using VRF blue. Figure 4 shows a simple tunnel scenario.
Figure 4 GRE Tunnel Diagram
The following example shows the configuration for the tunnel in Figure 4:
ip vrf bluerd 1:1ip vrf greenrd 1:2interface loopback 0ip vrf forwarding vrf blueip address 10.7.7.7 255.255.255.255interface tunnel 0ip vrf forwarding vrf greenip address 10.3.3.3 255.255.255.0tunnel source loopback 0tunnel destination 10.5.5.5tunnel vrf blueinterface GigabitEthernet 0/0/0ip vrf forwarding vrf greenip address 10.1.1.1 255.255.255.0interface GigabitEthernet 0/0/1ip vrf forwarding vrf blueip address 10.2.2.2 255.255.255.0ip route vrf blue 10.5.5.5 255.255.255.0 GigabitEthernet 0/0/1Example: Configuring EoMPLS over GRE
The following sample provides the EoMPLS over GRE configuration sequence:
Router A Configuration
vrf definition VPN1rd 100:1address-family ipv4route-target both 100:1exit-address-family!mpls label protocol ldpmpls ldp neighbor 209.165.200.224 targetedmpls ldp router-id Loopback0 force!interface Tunnel 0ip address 209.165.200.225 255.255.255.224mpls label protocol ldpmpls ipkeepalive 10 3tunnel source TenGigabitEthernet 2/1/0tunnel destination 209.165.200.226!interface Loopback 0ip address 209.165.200.230 255.255.255.224!interface TenGigabitEthernet 2/1/0mtu 9216ip address 209.165.200.235 255.255.255.224!interface TenGigabitEthernet 9/1no ip address!interface TenGigabitEthernet 9/1.11vrf forwarding VPN1encapsulation dot1Q 300ip address 209.165.200.237 255.255.255.224!interface TenGigabitEthernet 9/2mtu 9216no ip addressxconnect 209.165.200.239 200 encapsulation mpls!router bgp 65000bgp log-neighbor-changesneighbor 209.165.200.240 remote-as 65000neighbor 209.165.200.240 update-source Loopback0neighbor 209.165.200.245 remote-as 100!address-family vpnv4neighbor 209.165.200.240 activateneighbor 209.165.200.240 send-community extended!address-family ipv4 vrf VPN1no synchronizationneighbor 209.165.200.247 remote-as 100neighbor 209.165.200.248 activateneighbor 209.165.200.249 send-community extended!ip route 209.165.200.251 255.255.255.224 Tunnel 0ip route 209.165.200.254 255.255.255.224 209.165.200.256Router B Configurationvrf definition VPN1rd 100:1address-family ipv4route-target both 100:1exit-address-family!mpls ldp neighbor 209.165.200.229 targetedmpls label protocol ldpmpls ldp router-id Loopback0 force!interface Tunnel 0ip address 209.165.200.230 255.255.255.224mpls label protocol ldpmpls ipkeepalive 10 3tunnel source TenGigabitEthernet 3/3/0tunnel destination 209.165.200.232!interface Loopback 0ip address 209.165.200.234 255.255.255.224!interface TenGigabitEthernet 2/1mtu 9216no ip addressxconnect 209.165.200.237 200 encapsulation mpls!interface TenGigabitEthernet 2/3mtu 9216no ip address!interface TenGigabitEthernet 2/3.11vrf forwarding VPN1encapsulation dot1Q 300ip address 209.165.200.239 255.255.255.224!interface TenGigabitEthernet 3/3/0mtu 9216ip address 209.165.200.240 255.255.255.224!router bgp 65000bgp log-neighbor-changesneighbor 209.165.200.241 remote-as 65000neighbor 209.165.200.241 update-source Loopback0neighbor 209.165.200.244 remote-as 200!address-family vpnv4neighbor 209.165.200.241 activateneighbor 209.165.200.241 send-community extendedexit-address-family!address-family ipv4 vrf VPN1no synchronizationneighbor 209.165.200.246 remote-as 200neighbor 209.165.200.246 activateneighbor 209.165.200.246 send-community extendedexit-address-family¡ip route 209.165.200.226 255.255.255.224 Tunnel 0ip route 209.165.200.229 255.255.255.224 209.165.200.235Example: Manually Configuring IPv6 Tunnels
The following example shows how to manually configure a IPv6 tunnel between Router A and Router B. In the example, tunnel interface 0 for both Router A and Router B is manually configured with a global IPv6 address. The tunnel source and destination addresses are also manually configured.
Router A
interface GigabitEthernet 0/0/0ip address 192.168.99.1 255.255.255.0interface tunnel 0ipv6 address 2001:0db8:c18:1::3/126tunnel source GigabitEthernet 0/0/0tunnel destination 192.168.30.1tunnel mode ipv6ipRouter B
interface GigabitEthernet 0/0/0ip address 192.168.30.1 255.255.255.0interface tunnel 0ipv6 address 2001:0db8:c18:1::2/126tunnel source GigabitEthernet 0/0/0tunnel destination 192.168.99.1tunnel mode ipv6ipExample: Configuring 6to4 Tunnels
The following example configures a 6to4 tunnel on a border router in an isolated IPv6 network. The IPv4 address is 192.168.99.1, which translates to the IPv6 prefix of 2002:c0a8:6301::/48. The IPv6 prefix is subnetted into 2002:c0a8:6301::/64 for the tunnel interface: 2002:c0a8:6301:1::/64 for the first IPv6 network and 2002:c0a8:6301:2::/64 for the second IPv6 network. The static route ensures that any other traffic for the IPv6 prefix 2002::/16 is directed to tunnel interface 0 for automatic tunneling.
interface GigabitEthernet 0/0/0description IPv4 uplinkip address 192.168.99.1 255.255.255.0!interface GigabitEthernet 0/0/1description IPv6 local network 1ipv6 address 2002:c0a8:6301:1::1/64!interface GigabitEthernet 0/0/2description IPv6 local network 2ipv6 address 2002:c0a8:6301:2::1/64!interface Tunnel 0description IPv6 uplinkno ip addressipv6 address 2002:c0a8:6301::1/64tunnel source GigabitEthernet 0/0/0tunnel mode ipv6ip 6to4!ipv6 route 2002::/16 Tunnel0Example: Configuring ISATAP Tunnels
The following example shows the tunnel source defined on Gigabit Ethernet interface 0/0/0 and the tunnel mode command used to configure the ISATAP tunnel. Router advertisements are enabled to allow client autoconfiguration.
interface Tunnel 1tunnel source GigabitEthernet 0/0/0tunnel mode ipv6ip isatapipv6 address 2001:0DB8::/64 eui-64no ipv6 nd suppress-raExample: Configuring QoS Options on Tunnel Interfaces
The following sample configuration applies GTS directly on the tunnel interface. In this example, the configuration shapes the tunnel interface to an overall output rate of 500 kb/s.
interface Tunnel 0ip address 10.1.2.1 255.255.255.0traffic-shape rate 500000 125000 125000 1000tunnel source 10.1.1.1tunnel destination 10.2.2.2The following sample configuration shows how to apply the same shaping policy to the tunnel interface with the modular QoS CLI (MQC) commands:
policy-map tunnelclass class-defaultshape average 500000 125000 125000!interface Tunnel 0ip address 10.1.2.1 255.255.255.0service-policy output tunneltunnel source 10.1.35.1tunnel destination 10.1.35.2Policing Example
When an interface becomes congested and packets start to queue, you can apply a queueing method to packets that are waiting to be transmitted. Cisco IOS XE logical interfaces—tunnel interfaces in this example—do not inherently support a state of congestion and do not support the direct application of a service policy that applies a queueing method. Instead, you need to apply a hierarchical policy. Create a "child" or lower-level policy that configures a queueing mechanism, such as low latency queueing with the priority command and CBWFQ with the bandwidth command.
policy-map childclass voicepriority 512Create a "parent" or top-level policy that applies class-based shaping. Apply the child policy as a command under the parent policy because admission control for the child class is done according to the shaping rate for the parent class.
policy-map tunnelclass class-defaultshape average 2000000service-policy childApply the parent policy to the tunnel interface.
interface tunnel 0service-policy tunnelIn the following example, a tunnel interface is configured with a service policy that applies queueing without shaping. A log message is displayed noting that this configuration is not supported.
Router(config)# interface tunnel1Router(config-if)# service-policy output childClass Based Weighted Fair Queueing not supported on this interfaceAdditional References
Related Documents
Cisco IOS commands
Tunnel commands: complete command syntax, command mode, defaults, command history, usage guidelines, and examples
Cisco IOS Interface and Hardware Component Command Reference
IPv6 commands: complete command syntax, command mode, defaults, command history, usage guidelines, and examples
Cisco IOS XE Interface and Hardware Component configuration modules
Cisco IOS XE Interface and Hardware Component Configuration Guide, Release 2
Cisco IOS XE IPv6 configuration modules
Cisco IOS XE Quality of Service Solutions configuration modules
Cisco IOS XE Quality of Service Solutions Configuration Guide, Release 2
Cisco IOS XE Multiprotocol Label Switching configuration modules
Cisco IOS XE Multiprotocol Label Switching Configuration Guide, Release 2
Configuration example for a VRF-aware dynamic multipoint VPN (DMVPN)
"Dynamic Multipoint VPN (DMVPN)" configuration module in the Cisco IOS XE Security Configuration Guide: Secure Connectivity, Release 2
Standards
No new or modified standards are supported, and support for existing standards has not been modified.
—
MIBs
RFCs
Technical Assistance
Feature Information for Implementing Tunnels
Table 5 lists the features in this module and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS XE software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 5 Feature Information for Implementing Tunnels
GRE Tunnel IP Source and Destination VRF Membership
Cisco IOS XE Release 2.2
This feature allows you to configure the source and destination of a tunnel to belong to any VPN VRF table.
The following sections provide information about this feature:
•
•
•
The following command was introduced or modified: tunnel vrf.
GRE Tunnel Keepalive
Cisco IOS XE Release 2.1
The GRE Tunnel Keepalive feature provides the capability of configuring keepalive packets to be sent over IP-encapsulated GRE tunnels. You can specify the rate at which keepalives will be sent and the number of times that a device will continue to send keepalive packets without a response before the interface becomes inactive. GRE keepalive packets may be sent from both sides of a tunnel or from just one side.
The following section provides information about this feature:
The following command was introduced by this feature: keepalive (tunnel interfaces).
IP over IPv6 Tunnels
Cisco IOS XE Release 2.4
The following sections provide information about this feature:
•
•
The following commands were modified by this feature: tunnel destination, tunnel mode, and tunnel source.
IP Precedence for GRE Tunnels
Cisco IOS XE Release 2.1
This feature was introduced on Cisco ASR 1000 Aggregation Services Routers.
Tunnel ToS
Cisco IOS XE Release 2.1
The Tunnel ToS feature allows you to configure the ToS and Time-to-Live (TTL) byte values in the encapsulating IP header of tunnel packets for an IP tunnel interface on a router. The Tunnel ToS feature is supported in
Cisco Express Forwarding, fast switching, and process switching forwarding modes.The following section provides information about this feature:
The following commands were introduced or modified by this feature: show interfaces tunnel, tunnel tos, tunnel ttl.
EoMPLS over GRE
Cisco IOS XE Release 2.5
The EoMPLS over GRE feature allows you to tunnel Layer 2 traffic through a Layer 3 MPLS network. This feature also helps to create the GRE tunnel as hardware-based switched, and with high performance that encapsulate EoMPLS frames within the GRE tunnel.
The following section provides information about this feature:
No new commands were introduced or modified by this feature.
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2005-2010 Cisco Systems, Inc. All rights reserved.
