GRE

GRE Tunnel Keepalive

• For an example of a keepalive packet that originates from Router A and is destined for Router B. The keepalive response that Router B returns to Router A is already inside the Inner IP Header. Router B simply decapsulates the keepalive packet and sends it back out the physical interface (S2). It processes the GRE keepalive packet just like any other GRE IP data packet. This mechanism causes the keepalive response to forward out the physical interface rather than the tunnel interface. This means that the GRE keepalive response packet is not affected by any output features on the tunnel interface, such as 'tunnel protection ...', QoS, Virtual Routing and Forwarding (VRF), and so forth.

• If an inbound Access Control List (ACL) on the GRE tunnel interface is configured, then the GRE tunnel keepalive packet that the opposite device sends must be permitted. If not, the opposite device GRE tunnel become down. (access-list permit gre host host )

Reference

• Understand GRE Tunnel Keepalives: https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/118370-technote-gre-00.html

• Keepalive mechanisms on Cisco IOS: https://www.cisco.com/c/en/us/support/docs/content-networking/keepalives/118390-technote-keepalive-00.html