-
- Downstream Interface Configuration
- Upstream Interface Configuration
- DOCSIS Interface and Fiber Node Configuration
- Service Group Based Configuration of the Cisco cBR Router
- DOCSIS Load Balancing Groups
- DOCSIS Load Balancing Movements
- DOCSIS 3.0 Downstream Bonding
- DOCSIS 2.0 A-TDMA Modulation Profiles
- Downstream Resiliency Bonding Group
- Downstream Channel ID Assignment
- Upstream Channel Bonding
- Spectrum Management and Advanced Spectrum Management
- Upstream Scheduler Mode
- Generic Routing Encapsulation
- Transparent LAN Service over Cable
- Downgrading Channel Bonding in Battery Backup Mode
- Upstream Bonding Support for D-PON
- Energy Management Mode
- Cable Modem Steering
-
- IP Access Control Lists
- Creating an IP Access List and Applying It to an Interface
- Creating an IP Access List to Filter IP Options, TCP Flags, Noncontiguous Ports
- Refining an IP Access List
- IP Named Access Control Lists
- IPv4 ACL Chaining Support
- IPv6 ACL Chaining with a Common ACL
- Commented IP Access List Entries
- Standard IP Access List Logging
- IP Access List Entry Sequence Numbering
- ACL IP Options Selective Drop
- ACL Syslog Correlation
- IPv6 Access Control Lists
- IPv6 Template ACL
- IPv6 ACL Extensions for Hop by Hop Filtering
-
- Call Home
- SNMP Support over VPNs—Context-Based Access Control
- SNMP Engine Enhancement
- Onboard Failure Logging
- Control Point Discovery
- IPDR Streaming Protocol
- Usage-Based Billing (SAMIS)
- Frequency Allocation Information for the Cisco CMTS Routers
- Flap List Troubleshooting
- Maximum CPE and Host Parameters
- SNMP Background Synchronization
- Online Offline Diagnostics
Cisco cBR Converged Broadband Routers DOCSIS Software Configuration Guide for Cisco IOS XE Everest 16.5.1
- Updated:
- June 6, 2017
Chapter: Generic Routing Encapsulation
- Finding Feature Information
- Hardware Compatibility Matrix for Cisco cBR Series Routers
- Restrictions for Implementing Tunnels
- Restrictions for GRE IPv6 Tunnels
- Information About Implementing Tunnels
- Information About IPv6 over IPv4 GRE Tunnels
- Information About GRE IPv6 Tunnels
- How to Implement Tunnels
- Configuration Examples for Implementing Tunnels
Generic Routing
Encapsulation
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.
- Finding Feature Information
- Hardware Compatibility Matrix for Cisco cBR Series Routers
- Restrictions for Implementing Tunnels
- Restrictions for GRE IPv6 Tunnels
- Information About Implementing Tunnels
- Information About IPv6 over IPv4 GRE Tunnels
- Information About GRE IPv6 Tunnels
- How to Implement Tunnels
- Configuration Examples for Implementing Tunnels
- How to Configure IPv6 over IPv4 GRE Tunnels
- Configuration Examples for IPv6 over IPv4 GRE Tunnels
- How to Configure GRE IPv6 Tunnels
- Configuration Examples for GRE IPv6 Tunnels
- Additional References
- Feature Information for Generic Routing Encapsulation
Finding Feature Information
Finding Feature Information
Your software release may not support all the features documented in this module. 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 Table at the end of this document.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://tools.cisco.com/ITDIT/CFN/. An account on http://www.cisco.com/ is not required.
Hardware Compatibility Matrix for Cisco cBR Series Routers
 Note | The hardware components introduced in a given Cisco IOS-XE Release are supported in all subsequent releases unless otherwise specified. |
Restrictions for Implementing Tunnels
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.
A tunnel may have a recursive routing problem if routing is not configured accurately. The best path to a tunnel destination is via the tunnel itself; therefore recursive routing causes the tunnel interface to flap. To avoid recursive routing problems, keep the control-plane routing separate from the tunnel routing by using the following methods: - Use a different autonomous system number or tag.
- Use a different routing protocol.
- Ensure that static routes are used to override the first hop (watch for routing loops).
%TUN-RECURDOWN Interface Tunnel 0 temporarily disabled due to recursive routing
Restrictions for GRE IPv6 Tunnels
Information About Implementing Tunnels
Tunneling Versus Encapsulation
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 ToS
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
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.
QoS Options for Tunnels
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.
Information About IPv6 over IPv4 GRE Tunnels
Overlay Tunnels for IPv6
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. |
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 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.
Information About GRE IPv6 Tunnels
Overview of GRE IPv6 Tunnels
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.
How to Implement Tunnels
- Determining the Tunnel Type
- Configuring an IPv4 GRE Tunnel
- Configuring 6to4 Tunnels
- Verifying Tunnel Configuration and Operation
Determining the Tunnel Type
Before configuring a tunnel, you must determine the type of tunnel you want to create.
Configuring an IPv4 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 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.
GRE Tunnel Keepalive
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: 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.
| ||||
| Step 5 |
keepalive
[period
[retries]]
Example: Router(config-if)# keepalive 3 7 |
(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: Router(config-if)# tunnel source TenGigabitEthernet 4/1/0 |
Configures the tunnel source.
| ||||
| Step 7 |
tunnel
destination
{hostname |
ip-address}
Example: Router(config-if)# tunnel destination 10.0.2.1 |
Configures the tunnel destination.
| ||||
| Step 8 |
tunnel
key
key-number
Example: Router(config-if)# tunnel key 1000 |
(Optional) Enables an ID key for a tunnel interface.
| ||||
| Step 9 |
tunnel
mode
gre {
ip |
multipoint}
Example: Device(config-if)# tunnel mode gre ip |
Specifies the encapsulation protocol to be used in the tunnel. | ||||
| Step 10 |
ip
mtu
bytes
Example: Device(config-if)# ip mtu 1400 |
(Optional) Sets the MTU size of IP packets sent on an interface.
| ||||
| Step 11 |
ip
tcp
mss
mss-value
Example: Device(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: Device(config-if)# tunnel path-mtu-discovery |
(Optional) Enables PMTUD on a GRE or IP-in-IP tunnel interface. | ||||
| Step 13 |
end
Example: Device(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
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: 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.
| ||
| Step 5 |
tunnel
source
{ip-address |
interface-type
interface-number}
Example: Router(config-if)# tunnel source TenGigabitEthernet 4/1/0 |
Specifies the source IPv4 address or the source interface type and number for the tunnel interface.
| ||
| 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 to the specified tunnel interface.
| ||
| Step 9 |
end
Example: Router(config)# end |
Exits global 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
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: Device> enable | ||
| 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:
Device A# show interfaces tunnel 0
Tunnel0 is up, line protocol is up
Hardware is Tunnel
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.0.0.1 (TenGigabitEthernet4/1/0), destination 10.0.0.2, fastswitch TTL 255
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Tunnel TTL 255
Checksumming of packets disabled, fast tunneling enabled
Last input 00:00:14, output 00:00:04, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
4 packets input, 352 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
8 packets output, 704 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
| ||
| Step 3 |
ping
[protocol]
destination
To check that the local endpoint is configured and working, use the ping command on Device A. Example: DeviceA# ping 2001:0DB8:1111:2222::2 Type 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 ms | ||
| 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:
DeviceA# show ip route 10.0.0.2
Routing entry for 10.0.0.0/24
Known via "connected", distance 0, metric 0 (connected, via interface)
Routing Descriptor Blocks:
* directly connected, via TenGigabitEthernet4/1/0
Route metric is 0, traffic share count is 1
| ||
| Step 5 |
ping
[protocol]
destination
To check that the remote endpoint address is reachable, use the ping command on Device A.
Example: DeviceA# ping 10.0.0.2 Type 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 ms 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: DeviceA# ping 2001:0DB8:1111:2222::2 Type 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 ms These steps may be repeated at the other endpoint of the tunnel. |
Configuration Examples for Implementing Tunnels
Example: Configuring a GRE IPv4 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.
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
Router B
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:
Router A
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
Router B
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-family
Configuring QoS Options on Tunnel Interfaces Examples
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 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.2
Policing 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. 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 interface
How to Configure IPv6 over IPv4 GRE Tunnels
Configuring GRE on IPv6 Tunnels
GRE 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: Device> enable |
Enables privileged EXEC mode. | ||
| Step 2 |
configure terminal
Example: Device# configure terminal |
Enters global configuration mode. | ||
| Step 3 |
interface tunnel
tunnel-number
Example: Device(config)# interface tunnel 0 |
Specifies a tunnel interface and number, and enters interface configuration mode. | ||
| Step 4 | Enter one of the following commands:
Example: Device(config-if)# ipv6 address 3ffe:b00:c18:1::3/127 |
| ||
| Step 5 |
tunnel source {ip-address |
ipv6-address |
interface-type
interface-number}
Example: Device(config-if)# tunnel source Tengigabitethernet 4/1/0 |
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: Device(config-if)# tunnel destination 2001:DB8:1111:2222::1/64 |
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: Device(config-if)# tunnel mode gre ipv6 |
Specifies a GRE IPv6 tunnel.
| ||
| Step 8 |
end
Example: Device(config-if)# end |
Returns to privileged EXEC mode. |
Configuration Examples for IPv6 over IPv4 GRE Tunnels
- Example: GRE Tunnel Running IS-IS and IPv6 Traffic
- Example: Tunnel Destination Address for IPv6 Tunnel
Example: GRE Tunnel Running IS-IS and IPv6 Traffic
The following example configures a GRE tunnel running both IS-IS and IPv6 traffic between Router A and Router B:
Router A Configuration
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
Router B Configuration
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
Example: Tunnel Destination Address for IPv6 Tunnel
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
How to Configure GRE IPv6 Tunnels
Configuring GRE IPv6 Tunnels
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: Device> enable |
Enables privileged EXEC mode. | ||
| Step 2 |
configure
terminal
Example: Device# configure terminal |
Enters global configuration mode. | ||
| Step 3 |
interface
tunnel
tunnel-number
Example: Device(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: Device(config-if)# tunnel source ethernet 0 |
Specifies the source IPv6 address or the source interface type and number for the tunnel interface.
| ||
| Step 5 |
tunnel
destination
ipv6-address
Example: Device(config-if)# tunnel destination 2001:0DB8:0C18:2::300 |
Specifies the destination IPv6 address for the tunnel interface.
| ||
| Step 6 |
tunnel
mode
gre
ipv6
Example: Device(config-if)# tunnel mode gre ipv6 |
Specifies a GRE IPv6 tunnel.
| ||
| Step 7 |
end
Example: Device(config-if)# end |
Exits interface configuration mode and returns to privileged EXEC mode. |
Configuration Examples for GRE IPv6 Tunnels
Example: Configuring GRE IPv6 Tunnels
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.00
Additional References
The following sections provide references related to the GRE feature.
Related Documents
|
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 |
Standards
|
Standard |
Title |
|---|---|
|
Data-over-Cable Service Interface Specifications Radio Frequency Interface Specification, version 1.1 ( http://www.cablemodem.com ) |
MIBs
|
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: |
RFCs
|
RFC |
Title |
|---|---|
|
RFC 1701 |
|
|
RFC 1702 |
|
|
RFC 1853 |
|
|
RFC 2003 |
|
|
RFC 2784 |
|
|
RFC 2890 |
Technical Assistance
|
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. |
Feature Information for Generic Routing Encapsulation
Use Cisco Feature Navigator to find information about 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 http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note | The table below lists only the software release that introduced support for a given feature in a given software release train. 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 Everest 16.5.1 |
This feature was integrated into Cisco IOS XE Everest 16.5.1 on the Cisco cBR Series Converged Broadband Routers. |
Feedback