Configuring GRE Tunnels
|
Feature Name |
Release Information |
Feature Description |
|---|---|---|
|
GRE over HSRP and VRRP |
Release 24.4.1 |
Introduced in this release on: NCS 5500 fixed port routers; NCS 5500 modular routers(NCS 5500 line cards) You can enhance network resilience, flexibility, and efficiency using GRE encapsulation with HSRP and VRRP. This capability provides network redundancy and high availability by allowing GRE tunnels to operate seamlessly over redundant paths, ensuring uninterrupted service during failovers. The protocol independence of GRE facilitates the integration of different network segments without compatibility issues, while its scalability supports the easy expansion of network connectivity across multiple remote sites. Additionally, leveraging existing infrastructure with GRE minimizes the need for new investments, making it cost-effective. GRE also supports network segmentation and better traffic management, enhancing Quality of Service (QoS). |
Tunneling provides a mechanism to transport packets of one protocol within another protocol. Generic Routing Encapsulation (GRE) is a tunneling protocol that provides a simple generic approach to transport packets of one protocol over another protocol with encapsulation. GRE encapsulates a payload, that is, an inner packet that needs to be delivered to a destination network inside an outer IP packet. The GRE tunnel behave as virtual point-to-point link that have two endpoints identified by the tunnel source and tunnel destination address. The tunnel endpoints send payloads through GRE tunnels by routing encapsulated packets through intervening IP networks. Other IP routers along the way do not parse the payload (the inner packet); they only parse the outer IP packet as they forward it towards the GRE tunnel endpoint. Upon reaching the tunnel endpoint, GRE encapsulation is removed and the payload is forwarded to the packet's ultimate destination.
Encapsulation by the outer packet takes place at the tunnel source whereas decapsulation of the outer packet takes place at the tunnel destination. Encapsulation and decapsulation data is collected periodically or on demand. Encapsulation statistics provide us the number of packets encapsulated at the tunnel source. Decapsulation statistics provide us the number of packets that are decapsulated at the tunnel destination. This data is stored as statistics in logical tables that are based on statistics type in the route processor. The different statistics types include L2 Interface TX Stats, L3 Interface TX Stats, TRAP stats, and so on. Encapsulation statistics can help you to infer the source of the traffic, and decapsulation statistics provide you the destination of the traffic. Decapsulation statistics also help you to detect the type of traffic as well.
L3VPN over GRE is supported for all the Cisco NCS 5700 fixed port routers and NCS 5700 line cards [Mode: Native]. For more information, refer to L3VPN over GRE Tunnels section in the L3VPN Configuration Guide for Cisco NCS 5500 Series Routers.
Guidelines and Restrictions for Configuring GRE Tunnels
The following restrictions apply while configuring GRE tunnels:
-
The router supports up to 500 GRE tunnels.
-
Only up to 16 unique source IP addresses are supported for the tunnel source.
-
2-pass to Single-pass migration, which means converting the same GRE tunnel, is not possible in a single configuration step. You must first delete the 2-pass tunnel and then add the Single-pass tunnel.
-
Configurable MTU is not supported on Single-pass GRE interface, but supported on 2-pass GRE interface.
-
From Release 24.2.11, the Cisco NCS 5700 fixed port routers and from Release 24.2.1, NCS 5700 line cards [Mode: Native] support L3VPN over GRE, but it is not supported in the Cisco NCS 5500 fixed port routers.
-
From Release 24.4.1, the Cisco NCS 5500 fixed port routers and NCS 5500 line cards support GRE over HSRP and VRRP in scale mode. Previously, GRE over HSRP and VRRP was supported only in the Cisco NCS 5700 fixed port routers and NCS 5700 line cards.
-
The Cisco NCS 5500 series router support only IPv4 GRE tunnels. IPv6 GRE tunnels are not supported.
-
The IPv4 GRE tunnels supports IPv4 and IPv6 payloads.
-
To use the outer IPv4 GRE header for IP tunnel decapsulation in the hashing algorithm for ECMP and bundle member selection, use the hw-module profile load-balance algorithm command.
|
Supported Hardware |
Profile Type |
Maximum Supported Profile |
|---|---|---|
|
NC55-36x100G NC55-18H18F NC55-24x100G-SE NC55-24H12F-SE NC55-36x100G-S NC55-6x200-DWDM-S |
MTU |
3 |
|
NC55-36x100G-A-SE NC55-MOD-A-S NC55-MOD-A-SE-S NC55-32T16Q4H |
MTU |
3 |
|
NC57-24DD NC57-18DD-SE NC57-36H-SE NC57-36H6D NC57-MOD-S |
MTU |
7 |
|
NC55-36x100G NC55-18H18F NC55-24x100G-SE NC55-24H12F-SE NC55-36x100G-S NC55-6x200-DWDM-S |
TOS |
8 |
|
NC55-36x100G-A-SE NC55-MOD-A-S NC55-MOD-A-SE-S NC55-32T16Q4H |
TOS |
8 |
 Note |
If the configured MTU and Tunnel TOS profile exceeds the supported hardware limit, the system displays SDK-Out of Memory error. |
Configuration Example
Configuring a GRE tunnel involves creating a tunnel interface and defining the tunnel source and destination. This example shows how to configure a GRE tunnel between Router1 and Router2. You need to configure tunnel interfaces on both the routers. Tunnel source IP address on Router1 will be configured as the tunnel destination IP address on Router2. Tunnel destination IP address on Router1 will be configured as the tunnel source IP address on Router2. In this example, OSPF is used as the routing protocol between the two routers. You can also configure BGP or IS-IS as the routing protocol.
RP/0/RP0/CPU0:Router1# configure
RP/0/RP0/CPU0:Router1(config)# interface tunnel-ip 30
RP/0/RP0/CPU0:Router1(config-if)# tunnel mode gre ipv4
RP/0/RP0/CPU0:Router(config-if)# ipv4 address 10.1.1.1 255.255.255.0
RP/0/RP0/CPU0:Router1(config-if)# tunnel source 192.168.1.1
RP/0/RP0/CPU0:Router1(config-if)# tunnel destination 192.168.2.1
RP/0/RP0/CPU0:Router1(config-if)# exit
RP/0/RP0/CPU0:Router1(config)# interface Loopback 0
RP/0/RP0/CPU0:Router1(config-if)# ipv4 address 10.10.10.1
RP/0/RP0/CPU0:Router1(config-if)# exit
RP/0/RP0/CPU0:Router1(config)# router ospf 1
RP/0/RP0/CPU0:Router1(config-ospf)# router-id 192.168.4.1
RP/0/RP0/CPU0:Router1(config-ospf)# area 0
RP/0/RP0/CPU0:Router1(config-ospf-ar)# interface tunnel-ip 30
RP/0/RP0/CPU0:Router1(config-ospf-ar)# interface Loopback 0
RP/0/RP0/CPU0:Router1(config-ospf-ar)# commit
RP/0/RP0/CPU0:Router2# configure
RP/0/RP0/CPU0:Router2(config)# interface tunnel-ip 30
RP/0/RP0/CPU0:Router2(config-if)# tunnel mode gre ipv4
RP/0/RP0/CPU0:Router2(config-if)# ipv4 address 10.1.1.2 255.255.255.0
RP/0/RP0/CPU0:Router2(config-if)# tunnel source 192.168.2.1
RP/0/RP0/CPU0:Router2(config-if)# tunnel destination 192.168.1.1
RP/0/RP0/CPU0:Router2(config-if)# exit
RP/0/RP0/CPU0:Router2(config)# interface Loopback 0
RP/0/RP0/CPU0:Router2(config-if)# ipv4 address 2.2.2.2
RP/0/RP0/CPU0:Router2(config)# router ospf 1
RP/0/RP0/CPU0:Router2(config-ospf)# router-id 192.168.3.1
RP/0/RP0/CPU0:Router2(config-ospf)# area 0
RP/0/RP0/CPU0:Router2(config-ospf-ar)# interface tunnel-ip 30
RP/0/RP0/CPU0:Router2(config-ospf-ar)# interface Loopback 0
RP/0/RP0/CPU0:Router2(config-if)# commit
Feedback