The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the Generic Routing Encapsulation (GRE) feature. This feature is a tunneling protocol that enables the encapsulation of a wide variety of protocol packet types inside IP tunnels, creating a virtual point-to-point link to Cisco routers at remote points over an IP internetwork.
Your software release may not support all the features that are documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. The Feature Information Table at the end of this document provides information about the documented features and lists the releases in which each feature is supported.
 Note |
The hardware components that are introduced in a given Cisco IOS-XE Release are supported in all subsequent releases unless otherwise specified. |
|
Cisco CMTS Platform |
Processor Engine |
Interface Cards |
|---|---|---|
|
Cisco cBR-8 Converged Broadband Router |
Cisco IOS-XE Release 16.5.1 and Later Releases Cisco cBR-8 Supervisor:
|
Cisco IOS-XE Release 16.5.1 and Later Releases Cisco cBR-8 CCAP Line Cards:
Cisco cBR-8 Downstream PHY Modules:
Cisco cBR-8 Upstream PHY Modules:
|
It is important to allow the tunnel protocol to pass through a firewall and access control list (ACL) check.
Multiple point-to-point tunnels can saturate the physical link with routing information if the bandwidth is not configured correctly on a tunnel interface.
A tunnel looks like a single hop link, and routing protocols may prefer a tunnel over a multihop physical path. The tunnel, despite looking like a single hop link, may traverse a slower path than a multihop link. A tunnel is as robust and fast, or as unreliable and slow, as the links that it actually traverses. Routing protocols that make their decisions based only on hop counts will often prefer a tunnel over a set of physical links. A tunnel might appear to be a one-hop, point-to-point link and have the lowest-cost path, but the tunnel may actually cost more in terms of latency when compared to an alternative physical topology. For example, in the topology shown in the figure below, 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.
%TUN-RECURDOWN Interface Tunnel 0
temporarily disabled due to recursive routingGRE tunnel keepalive packets are not supported.
Multipoint GRE (mGRE) IPv6 tunneling is not supported.
There is limited support for tunnel transport in virtual routing and forwarding (VRF). The limited support in VRF is applicable to IPv6 point-to-point GRE without tunnel protection.
To understand how tunnels work, you must be able to distinguish between 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. To send a data packet from one host (for example, a PC) to another on a network, encapsulation is used to add a header in front of the data packet 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 reverse order.
Tunneling encapsulates data packets from one protocol within a different protocol and transports the packets on a foreign network. Unlike encapsulation, tunneling allows a lower-layer protocol and a same-layer protocol to be carried through the tunnel. A tunnel interface is a virtual (or logical) interface. Tunneling consists of three main components:
Passenger protocol—The protocol that you are encapsulating. For example, IPv4 and IPv6 protocols.
Carrier protocol—The protocol that encapsulates. For example, generic routing encapsulation (GRE) and Multiprotocol Label Switching (MPLS).
Transport protocol--The protocol that carries the encapsulated protocol. The main transport protocol is IP.
Tunnel type of service (ToS) allows you to tunnel network traffic and group all packets in the same 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. Tunnel ToS feature is supported for Cisco Express Forwarding (formerly known as 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.
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.
Note |
PMTUD on a tunnel interface requires that the tunnel endpoint be able to receive ICMP messages generated by routers in the path of the tunnel. Ensure that ICMP messages can be received before using PMTUD over firewall connections. |
Use 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.
A tunnel interface supports various 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 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 when a user applies the QoS preclassify feature on the tunnel interface or on the crypto map.
Note |
Class-based WFQ (CBWFQ) inside class-based shaping is not supported on a multipoint interface. |
For examples of how to implement some QoS features on a tunnel interface, see the section“Configuring QoS Options on Tunnel Interfaces Examples” on page 32.
Overlay tunneling encapsulates IPv6 packets in IPv4 packets for delivery across an IPv4 infrastructure (a core network or the figure below). 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 devices or between a border device and a host; however, both tunnel endpoints must support both the IPv4 and IPv6 protocol stacks. IPv6 supports the following types of overlay tunneling mechanisms:
Manual
Generic routing encapsulation (GRE)
IPv4-compatible
6to4
Intrasite Automatic Tunnel Addressing Protocol (ISATAP)
Note |
Overlay tunnels reduce the maximum transmission unit (MTU) of an interface by 20 octets (assuming that the basic IPv4 packet header does not contain optional fields). A network that uses overlay tunnels is difficult to troubleshoot. Therefore, overlay tunnels that connect isolated IPv6 networks should not be considered a final IPv6 network architecture. The use of overlay tunnels should be considered as a transition technique toward a network that supports both the IPv4 and IPv6 protocol stacks or just the IPv6 protocol stack. |
Use the table below to help you determine which type of tunnel that you want to configure to carry IPv6 packets over an IPv4 network.
|
Tunneling Type |
Suggested Usage |
Usage Notes |
|---|---|---|
|
Manual |
Simple point-to-point tunnels that can be used within a site or between sites. |
Can carry IPv6 packets only. |
|
GRE- and IPv4- compatible |
Simple point-to-point tunnels that can be used within a site or between sites. |
Can carry IPv6, Connectionless Network Service (CLNS), and many other types of packets. |
|
IPv4- compatible |
Point-to-multipoint tunnels. |
Uses the ::/96 prefix. We do not recommend using this tunnel type. |
|
6to4 |
Point-to-multipoint tunnels that can be used to connect isolated IPv6 sites. |
Sites use addresses from the 2002::/16 prefix. |
|
6RD |
IPv6 service is provided to customers over an IPv4 network by using encapsulation of IPv6 in IPv4. |
Prefixes can be from the SP’s own address block. |
|
ISATAP |
Point-to-multipoint tunnels that can be used to connect systems within a site. |
Sites can use any IPv6 unicast addresses. |
Individual tunnel types are discussed in detail in this document. We recommend that you review and understand the information about the specific tunnel type that you want to implement. When you are familiar with the type of tunnel you need, see the table below for a summary of the tunnel configuration parameters that you may find useful.
|
Tunneling Type |
Tunnel Configuration Parameter |
|||
|---|---|---|---|---|
|
Tunnel Mode |
Tunnel Source |
Tunnel Destination |
Interface Prefix or Address |
|
|
Manual |
ipv6ip |
An IPv4 address, or a reference to an interface on which IPv4 is configured. |
An IPv4 address. |
An IPv6 address. |
|
GRE/IPv4 |
gre ip |
An IPv4 address. |
An IPv6 address. |
|
|
IPv4- compatible |
ipv6ip auto-tunnel |
Not required. These are all point-to-multipoint tunneling types. The IPv4 destination address is calculated, on a per-packet basis, from the IPv6 destination. |
Not required. The interface address is generated as :: tunnel-source /96. |
|
|
6to4 |
ipv6ip 6to4 |
An IPv6 address. The prefix must embed the tunnel source IPv4 address. |
||
|
6RD |
ipv6ip 6rd |
An IPv6 address. |
||
|
ISATAP |
ipv6ip isatap |
An IPv6 prefix in modified eui-64 format. The IPv6 address is generated from the prefix and the tunnel source IPv4 address. |
||
IPv6 traffic can be carried over IPv4 GRE tunnels using the standard GRE tunneling technique that is designed to provide the services 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, carry IPv6 as the passenger protocol with the GRE as the carrier protocol and IPv4 or IPv6 as the transport protocol.
The primary use of GRE tunnels is for stable connections that require regular secure communication between two edge devices or between an edge device and an end system. The edge devices and the end systems must be dual-stack implementations.
The GRE IPv6 Tunnels feature enables the delivery of packets from other protocols through an IPv6 network and allows the routing of IPv6 packets between private networks across public networks with globally routed IPv6 addresses.
For point-to-point GRE tunnels, each tunnel interface requires a tunnel source IPv6 address and a tunnel destination IPv6 address when being configured. All packets are encapsulated with an outer IPv6 header and a GRE header.
Before configuring a tunnel, you must determine the type of tunnel you want to create.
|
Step 1 |
Determine the passenger protocol. A passenger protocol is the protocol that you are encapsulating. |
||||||||||||||||
|
Step 2 |
Determine the tunnel mode command keyword, if appropriate. The table below shows how to determine the appropriate keyword to be used with the tunnel mode command.
|
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 the 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.
Keepalive packets can be configured to be sent over IP-encapsulated GRE tunnels. You can specify the rate at which keepalives are 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.
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.
| Command or Action | Purpose | |||||
|---|---|---|---|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
||||
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
||||
|
Step 3 |
interface type number Example: |
Specifies the interface type and number, and enters interface configuration mode.
|
||||
|
Step 4 |
bandwidth kb/s Example: |
Sets the current bandwidth value for an interface and communicates it to higher-level protocols.
|
||||
|
Step 5 |
keepalive [period [retries ]] Example: |
(Optional) Specifies the number of times the device will continue to send keepalive packets without response before bringing the tunnel interface protocol down.
|
||||
|
Step 6 |
tunnel source {ip-address | interface-type interface-number } Example: |
Configures the tunnel source.
|
||||
|
Step 7 |
tunnel destination {hostname | ip-address } Example: |
Configures the tunnel destination.
|
||||
|
Step 8 |
tunnel key key-number Example: |
(Optional) Enables an ID key for a tunnel interface.
|
||||
|
Step 9 |
tunnel mode gre { ip | multipoint } Example: |
Specifies the encapsulation protocol to be used in the tunnel. |
||||
|
Step 10 |
ip mtu bytes Example: |
(Optional) Sets the MTU size of IP packets sent on an interface.
|
||||
|
Step 11 |
ip tcp mss mss-value Example: |
(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: |
(Optional) Enables PMTUD on a GRE or IP-in-IP tunnel interface.
|
||||
|
Step 13 |
end Example: |
Exits interface configuration mode and returns to privileged EXEC mode. |
Proceed to the “Verifying Tunnel Configuration and Operation” section.
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.
Note |
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, Cisco recommends that they not share the same tunnel source. A 6to4 tunnel and an IPv4-compatible tunnel cannot share the same interface because 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. When a packet with an IPv4 protocol type of 41 arrives on an interface, the 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. Manually configured IPv6 tunnels can share the same source interface because a manual tunnel is a “point-to-point” link, and both IPv4 source and the IPv4 destination of the tunnel are defined. |
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
||
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
||
|
Step 3 |
interface tunnel tunnel-number Example: |
Specifies a tunnel interface and number and enters interface configuration mode. |
||
|
Step 4 |
ipv6 address ipv6-prefix/prefix-length [eui-64 ] Example: |
Specifies the IPv6 address assigned to the interface and enables IPv6 processing on the interface.
|
||
|
Step 5 |
tunnel source {ip-address | interface-type interface-number } Example: |
Specifies the source IPv4 address or the source interface type and number for the tunnel interface.
|
||
|
Step 6 |
tunnel mode ipv6ip 6to4 Example: |
Specifies an IPv6 overlay tunnel using a 6to4 address. |
||
|
Step 7 |
exit Example: |
Exits interface configuration mode and returns to global configuration mode. |
||
|
Step 8 |
ipv6 route ipv6-prefix / prefix-length tunnel tunnel-number Example: |
Configures a static route to the specified tunnel interface.
|
||
|
Step 9 |
end Example: |
Exits global configuration mode and returns to privileged EXEC mode. |
Proceed to the “Verifying Tunnel Configuration and Operation” section.
The show and ping commands in the steps below can be used in any sequence. The following commands can be used for GRE tunnels, IPv6 manually configured tunnels, and IPv6 over IPv4 GRE tunnels.
|
Step 1 |
enable Enables privileged EXEC mode. Enter your password if prompted. Example: |
||
|
Step 2 |
show interfaces tunnel number [accounting ] Two routers are configured to be endpoints of a tunnel. Device A has TenGigabit Ethernet interface 4/1/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. Device B has TenGigabit Ethernet interface 4/1/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 Device A. Example: |
||
|
Step 3 |
ping [protocol ] destination To check that the local endpoint is configured and working, use the ping command on Device A. Example: |
||
|
Step 4 |
show ip route [address [mask ]] To check that a route exists to the remote endpoint address, use the show ip route command. Example: |
||
|
Step 5 |
ping [protocol ] destination To check that the remote endpoint address is reachable, use the ping command on Device A.
Example:To check that the remote IPv6 tunnel endpoint is reachable, use the ping command again on Device A. The note regarding filtering earlier in step also applies to this example. Example:These steps may be repeated at the other endpoint of the tunnel. |
The following example shows a simple configuration of GRE tunneling. Note that TenGigabit Ethernet interface 4/1/0 is the tunnel source for Router A and the tunnel destination for Router B. TenGigabit Ethernet interface 4/1/1 is the tunnel source for Router B and the tunnel destination for Router A.
interface Tunnel 0
ip address 10.1.1.2 255.255.255.0
tunnel source TenGigabitEthernet 4/1/0
tunnel destination 192.168.3.2
tunnel mode gre ip
!
interface TenGigabitEthernet 4/1/0
ip address 192.168.4.2 255.255.255.0
interface Tunnel 0
ip address 10.1.1.1 255.255.255.0
tunnel source TenGigabitEthernet 4/1/1
tunnel destination 192.168.4.2
tunnel mode gre ip
!
interface TenGigabitEthernet 4/1/1
ip address 192.168.3.2 255.255.255.0
The following example configures a GRE tunnel running both IS-IS and IPv6 traffic between Router A and Router B:
ipv6 unicast-routing
clns routing
!
interface Tunnel 0
no ip address
ipv6 address 2001:0DB8:1111:2222::1/64
ipv6 router isis
tunnel source TenGigabitEthernet 4/1/0
tunnel destination 10.0.0.2
tunnel mode gre ip
!
interface TenGigabitEthernet 4/1/0
ip address 10.0.0.1 255.255.255.0
!
router isis
network 49.0000.0000.000a.00
ipv6 unicast-routing
clns routing
!
interface Tunnel 0
no ip address
ipv6 address 2001:0DB8:1111:2222::2/64
ipv6 router isis
tunnel source TenGigabitEthernet 4/1/0
tunnel destination 10.0.0.1
tunnel mode gre ip
!
interface TenGigabitEthernet 4/1/0
ip address 10.0.0.2 255.255.255.0
!
router isis
network 49.0000.0000.000b.00
address-family ipv6
redistribute static
exit-address-familyThe 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 0
ip address 10.1.2.1 255.255.255.0
traffic-shape rate 500000 125000 125000 1000
tunnel source 10.1.1.1
tunnel destination 10.2.2.2
The following sample configuration shows how to apply the same shaping policy to the tunnel interface with the MQC commands:
policy-map tunnel
class class-default
shape average 500000 125000 125000
!
interface Tunnel 0
ip address 10.1.2.1 255.255.255.0
service-policy output tunnel
tunnel source 10.1.35.1
tunnel destination 10.1.35.2When an interface becomes congested and packets start to queue, you can apply a queueing method to packets that are waiting to be transmitted. 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 must 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 child
class voice
priority 512
Create 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 tunnel
class class-default
shape average 2000000
service-policy child
Apply the parent policy to the tunnel interface.
interface tunnel 0
service-policy tunnel
In 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 tunnel1
Router(config-if)# service-policy output child
Class Based Weighted Fair Queueing not supported on this interfaceGRE tunnels can be configured to run over an IPv6 network layer and to transport IPv4 and IPv6 packets in IPv6 tunnels.
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 addresses or IPv6 addresses assigned (this is not shown in the task). The host or device at each end of a configured tunnel must support both the IPv4 and IPv6 protocol stacks.
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
||
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
||
|
Step 3 |
interface tunnel tunnel-number Example: |
Specifies a tunnel interface and number, and enters interface configuration mode. |
||
|
Step 4 |
Enter one of the following commands:
Example: |
|
||
|
Step 5 |
tunnel source {ip-address | ipv6-address | interface-type interface-number} Example: |
Specifies the source IPv4 address, IPv6 address, or the source interface type and number for the tunnel interface.
|
||
|
Step 6 |
tunnel destination {hostname | ip-address | ipv6-address} Example: |
Specifies the destination IPv4 address, IPv6 address, or hostname for the tunnel interface. |
||
|
Step 7 |
tunnel mode {aurp | cayman | dvmrp | eon | gre | gre multipoint | gre ipv6 | ipip [decapsulate-any] | iptalk | ipv6 | mpls | nos} Example: |
Specifies a GRE IPv6 tunnel.
|
||
|
Step 8 |
end Example: |
Returns to privileged EXEC mode. |
The following example configures a GRE tunnel running both IS-IS and IPv6 traffic between Router A and Router B:
ipv6 unicast-routing
clns routing
!
interface tunnel 0
no ip address
ipv6 address 3ffe:b00:c18:1::3/127
ipv6 router isis
tunnel source TenGigabitEthernet 4/1/0
tunnel destination 2001:DB8:1111:2222::1/64
tunnel mode gre ipv6
!
interface TenGigabitEthernet4/1/0
ip address 10.0.0.1 255.255.255.0
!
router isis
net 49.0000.0000.000a.00
ipv6 unicast-routing
clns routing
!
interface tunnel 0
no ip address
ipv6 address 3ffe:b00:c18:1::2/127
ipv6 router isis
tunnel source TenGigabitEthernet 4/1/0
tunnel destination 2001:DB8:1111:2222::2/64
tunnel mode gre ipv6
!
interface TenGigabitEthernet4/1/0
ip address 10.0.0.2 255.255.255.0
!
router isis
net 49.0000.0000.000b.00
address-family ipv6
redistribute static
exit-address-family
Router(config)#interface Tunnel0
Router(config-if)#ipv6 address 2001:1:1::1/48
Router(config-if)#tunnel source TenGigabitEthernet 4/1/0
Router(config-if)#tunnel destination 10.0.0.2
Router(config-if)#tunnel mode gre ipv6
Router(config-if)#exit
!
Router(config)#interface TenGigabitEthernet4/1/0
Router(config-if)#ip address 10.0.0.1 255.255.255.0
Router(config-if)#exit
!
Router(config)#ipv6 unicast-routing
Router(config)#router isis
Router(config)#net 49.0000.0000.000a.00
Perform this task to configure a GRE tunnel on an IPv6 network. GRE tunnels can be configured to run over an IPv6 network layer and transport IPv6 and IPv4 packets through IPv6 tunnels.
Note |
You must enable IPv6 or configure IPv6 MTU size more than 1500 on a tunnel's exit interface to avoid receiving warning messages. |
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 (this is not shown in the task below). The host or device at each end of the configured tunnel must support both IPv4 and IPv6 protocol stacks.
| Command or Action | Purpose | |||
|---|---|---|---|---|
|
Step 1 |
enable Example: |
Enables privileged EXEC mode.
|
||
|
Step 2 |
configure terminal Example: |
Enters global configuration mode. |
||
|
Step 3 |
interface tunnel tunnel-number Example: |
Specifies a tunnel interface and number and enters interface configuration mode. |
||
|
Step 4 |
tunnel source {ipv6-address | interface-type interface-number } Example: |
Specifies the source IPv6 address or the source interface type and number for the tunnel interface.
|
||
|
Step 5 |
tunnel destination ipv6-address Example: |
Specifies the destination IPv6 address for the tunnel interface.
|
||
|
Step 6 |
tunnel mode gre ipv6 Example: |
Specifies a GRE IPv6 tunnel.
|
||
|
Step 7 |
end Example: |
Exits interface configuration mode and returns to privileged EXEC mode. |
The following example shows how to configure a GRE tunnel over an IPv6 transport. In this example, Ethernet0/0 has an IPv6 address, 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 Tunnel0
ip address 10.1.1.1 255.255.255.0
ip router isis
tunnel source Ethernet0/0
tunnel destination 2001:DB8:1111:2222::1
tunnel mode gre ipv6
!
interface Ethernet0/0
no ip address
ipv6 address 2001:DB8:1111:1111::1/64
!
router isis
net 49.0001.0000.0000.000a.00The following sections provide references related to the GRE feature.
|
Related Topic |
Document Title |
|---|---|
|
CMTS Command Reference |
Cisco CMTS Cable Command Reference, at the following URL: http://www.cisco.com/c/en/us/td/docs/cable/cmts/cmd_ref/b_cmts_cable_cmd_ref.html |
|
Configuring GRE Tunnel over Cable |
Configuring GRE Tunnel over Cable, at the following URL: http://www.cisco.com/en/US/tech/tk86/tk89/technologies_configuration_example09186a008011520d.shtml |
|
Standard |
Title |
|---|---|
|
Data-over-Cable Service Interface Specifications Radio Frequency Interface Specification, version 1.1 ( http://www.cablemodem.com ) |
|
MIB |
MIBs Link |
|---|---|
|
No new or modified MIBs are supported by this feature. |
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: |
|
RFC |
Title |
|---|---|
|
RFC 1701 |
|
|
RFC 1702 |
|
|
RFC 1853 |
|
|
RFC 2003 |
|
|
RFC 2784 |
|
|
RFC 2890 |
|
Description |
Link |
|---|---|
|
The Cisco Technical Support & Documentation website contains thousands of pages of searchable technical content, including links to products, technologies, solutions, technical tips, and tools. Registered Cisco.com users can log in from this page to access even more content. |
Use Cisco Feature Navigator to find information about the platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to the https://cfnng.cisco.com/ link. An account on the Cisco.com page is not required.
Note |
The following table lists the software release in which a given feature is introduced. Unless noted otherwise, subsequent releases of that software release train also support that feature. |
|
Feature Name |
Releases |
Feature Information |
|---|---|---|
|
Generic Routing Encapsulation |
Cisco IOS XE Fuji 16.7.1 |
This feature was integrated on the Cisco cBR Series Converged Broadband Routers. |
Feedback