Interface and Hardware Component Configuration Guide for Cisco 8000 Series Routers, IOS XR Release 7.0.x
Bias-Free Language
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 chapter provides conceptual and configuration information for IP-in-IP tunnels.
Table 1. Feature History for Configure Tunnels
Release 7.0.11
This feature was introduced.
Release 7.0.14
Support for the following feature was introduced in Configure Tunnels:
Extended ACL must match on the outer header for IP-in-IP Decapsulation.
Controlling the TTL Value of Inner Payload Header
Cisco 8000 Routers allow you to control the TTL value of inner payload header of IP-in-IP tunnel packets before it gets forwarded
to the next-hop router. This feature enables a router to forward custom formed IP-in-IP stacked packets even if the inner
packet TTL is 1. Therefore, this feature enables you to measure the link-state and path reachability from end to end in a
network.
Note
After you enable or disable the decrement of the TTL value of the inner payload header of a packet, you do not need to reload
the line card.
Configuration
To disable the decrement of the TTL value of inner payload header of an IP-in-IP packet, use the following steps:
Enter the global configuration mode.
Disable the decrement of TTL value of inner payload header of an IP-in-IP packet.
Configuration Example
/* Enter the Global Configuration mode. */
Router# configure
/* Disable the decrement of TTL value of inner payload header of an IP-in-IP packet. */
Router(config)# hw-module profile cef ttl tunnel-ip decrement disable
Router(config)# commit
IP-in-IP encapsulation involves the insertion of an outer IP header over the existing IP header. The source and destination
address in the outer IP header point to the endpoints of the IP-in-IP tunnel. The stack of IP headers is used to direct the
packet over a predetermined path to the destination, provided the network administrator knows the loopback addresses of the
routers transporting the packet. This tunneling mechanism can be used for determining availability and latency for most network
architectures. It is to be noted that the entire path from source to the destination does not have to be included in the headers,
but a segment of the network can be chosen for directing the packets.
Note
The router only supports decapsulation and no encapsulation. Encapsulation is done by remote routers.
The following topology describes a use case where IP-in-IP encapsulation and decapsulation are used for different segments
of the network from source to destination. The IP-in-IP tunnel consists of multiple routers that are used to decapsulate and
direct the packet through the data center fabric network.
The following illustration shows how the stacked IPv4 headers are decapsulated as they traverse through the decapsulating
routers.
Stacked IP Header in an Encapsulated Packet
The encapsulated packet has an outer IPv4 header that is stacked over the original IPv4 header, as shown in the following
illustration.
Configuration
You can use the following sample configuration in the routers to decapsulate the packet as it traverses the IP-in-IP tunnel:
tunnel source: indicates the source address for the IP-in-IP decap tunnel with respect to the router interface.
Note
You can configure the tunnel destination only if you want to decapsulate packets from a particular destination. If no tunnel
destination is configured, then all the ip-in-ip ingress packets on the configured interface are decapsulated.
Extended ACL to Match the Outer Header for IP-in-IP Decapsulation
Starting with Cisco IOS XR Software Release 7.0.14, extended ACL has to match on the outer header for IP-in-IP Decapsulation.
Extended ACL support reduces mirrored traffic throughput. This match is based only on the IPv4 protocol, and extended ACL
is applied to the received outermost IP header, even if the outer header is locally terminated.
Router#show access-lists ipv4 ExtACL_IPinIP hardware ingress location$
Tue May 26 12:11:55.940 UTC
ipv4 access-list ExtACL_IPinIP
10 permit ipv4 192.168.0.0 0.0.255.255 any ttl gt 150
11 deny ipv4 172.16.0.0 0.0.255.255 any fragments
12 permit ipv4 any any
ECMP Hashing Support for Load Balancing
The system inherently supports the n-tuple hash algorithm. The first inner header in the n-tuple hashing includes the source
port and the destination port of UDP / TCP protocol headers.
The load balancing performs these functions:
Incoming data traffic is distributed over multiple equal-cost connections.
Incoming data traffic is distributed over multiple equal-cost connections member links within a bundle interface.
Layer 2 bundle and Layer 3 (network layer) load-balancing decisions are taken on IPv4, and IPv6. If it is an IPv4 or an IPv6
payload, then an n-tuple hashing is done.
An n-tuple hash algorithm provides more granular load balancing and used for load balancing over multiple equal-cost Layer
3 (network layer) paths. The Layer 3 (network layer) path is on a physical interface or on a bundle interface.
The n-tuple load-balance hash calculation contains:
Source IP address
Destination IP address
IP Protocol type
Router ID
Source port
Destination port
Input interface
Configure Tunnel Destination with an Object Group
Table 2. Feature History Table
Feature Name
Release Information
Description
Configure Tunnel Destination with an Object Group
Release 7.5.4
You can now assign an object group as the destination for an IP-in-IP decapsulation tunnel. With this functionality, you could
configure an IPv4 or IPv6 object group consisting of multiple IPv4 or IPv6 addresses as the destination for the tunnel instead
of a single IPv4 or IPv6 address. Using an object group instead of a singular IP address. This helps reduce the configuration
complexity in the router by replacing the multiple tunnels with one destination with a single decapsulation tunnel that supports
a diverse range of destinations
YANG Data Model: New object-group option supported in Cisco-IOS-XR-um-if-tunnel-cfg.yang Cisco native model (see GitHub).
In IP-in-IP Decapsulation, the router accepts a packet on a tunneled interface only when the tunnel IP address matches the
source IP address of the incoming packets. With this implementation, the user needs to configure separate interface tunnels
for each IP address that the router needs to receive the traffic packets. This limitation often leads to configuration overload
on the router.
You can eliminate the configuration overload on the router by assigning an object group as the tunnel destination for IPv4
and IPv6 traffic types. That is, the router matches the source IP address of the incoming packet against the object group
available as the tunnel destination. The decapsulation tunnel accepts the incoming traffic packets when there’s a match between
the packet source and the object group. Otherwise, the router drops the packets.
Restrictions
The following restrictions are applicable to the tunnel destination with an object group feature:
GRE tunnels don’t support configuring object groups as the tunnel destination.
The router supports configuring tunnel destination with an object group only when the tunnel source is tunnel source direct.
You can configure the object group as tunnel destination only on default VRF.
Configuring object groups as the tunnel destination isn’t applicable to tunnel encapsulation.
Subinterfaces don’t support configuring object groups as the tunnel destination.
Configuring object groups as the tunnel destination feature is mutually exclusive with ACL and QoS features.
The tunnel destination feature supports only IPv4 and IPv6 object groups.
The router does not support changing tunnel configuration after its creation. Configure the tunnel source direct and tunnel
destination with an object group while creating the tunnel only.
Prerequisites
Define an object group including the network elements for the tunnel destination.
Enable the tunnel source direct feature. For more information, see decapsulation using tunnel source direct.
Configuration Example
This section provides an example for configuring the tunnel destination with an object group:
Configuration
IPv4:
Router# configure
/* Configure the IPv4 object group */
Router(config)# object-group network ipv4 Test_IPv4
Router(config-object-group-ipv4)# 192.0.2.0/24
Router(config-object-group-ipv4)# 198.51.100.0/24
Router(config-object-group-ipv4)# 203.0.113.0/24
Router(config-object-group-ipv4)# commit
Router(config-object-group-ipv4)# exit
/* Enters the tunnel configuration mode */
Router(config)# interface tunnel TestIPv4
/* Configures the tunnel mode */
Router(config-if)# tunnel mode ipv4 decap
/* Configures the tunnel to accept all packets with destination address matching the IP addresses on the router */
Router(config-if)# tunnel source direct
/* Configures the tunnel to accept all packets with destination address that are in the specified object group */
Router(config-if)# tunnel destination object-group ipv4 Test_IPv4
Router(config-if)# no shutdown
Router(config-if)# commit
Router(config-if)# exit
IPv6:
Router# configure
/* Configure the IPv6 object group */
Router(config)# object-group network ipv6 Test_IPv6
Router(config-object-group-ipv6)# 2001:DB8::/32
Router(config-object-group-ipv6)# 2001:DB8::/48
Router(config-object-group-ipv6)# commit
Router(config-object-group-ipv6)# exit
/* Enters the tunnel configuration mode */
Router(config)# interface tunnel TestIPv6
/* Configures the tunnel mode */
Router(config-if)# tunnel mode ipv6 decap
/* Configures the tunnel to accept all packets with destination address matching the IP addresses on the router */
Router(config-if)# tunnel source direct
/* Configures the tunnel to accept all packets with destination address that are in the specified object group */
Router(config-if)# tunnel destination object-group ipv6 Test_IPv6
Router(config-if)# no shutdown
Router(config-if)# commit
Router(config-if)# exit