cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4322
Views
15
Helpful
18
Replies

Cannot Enable GRE Tunnel Keepalives

jpl861
Level 4
Level 4

Hi there,

 

I have 2 scenarios.

 

1. I have a router with 2 tunnels but the they have different tunnel source and destination IPs. Whenever I configure keepalives, it's bringing the protocol down which is expected if it doesn't reach the remote end. This is the AMER side router.

 

2. Another router in APAC also have 2 GRE tunnels. One going to AMER and one going local. The the source is the same for both tunnels which is loopback 0. The keepalive works if it's configured the tunnel facing AMER but the GRE to another local router does not.

 

It is sending keepalives based on debugs but I do not understand why it's not working in some tunnels. I did this in lab environment too but same results. The debug shows that the router is sending keepalives to both addresses.

1 Accepted Solution

Accepted Solutions

Hello, John,

 

I believe this post describes a similar problem to yours:
https://community.cisco.com/t5/mpls/gre-keepalives-with-vrf/td-p/1326442

 

In short, GRE keepalives do not integrate with VRFs out-of-the-box. That is why your lab config works (both tunnel src/dst interfaces and the tunnel itself are in the same VRF) while production one does not (different VRFs - no necessary routes between them)

Discovering the Why
https://braonle.wordpress.com/

View solution in original post

18 Replies 18

Hello,

 

post the configs of both routers, maybe we can spot something. Are these simple GRE tunnels, or GRE/IPSec tunnels ?

Here are the configs. There's full routing as the loopbacks are all advertised through EIGRP.
R1
interface Tunnel10000
ip address 10.200.12.9 255.255.255.252
keepalive 5 2
tunnel source Loopback2001
tunnel destination 2.0.0.2

interface Tunnel10001
ip address 10.200.12.13 255.255.255.252
keepalive 5 2
tunnel source Loopback2001
tunnel destination 3.0.0.3

interface Loopback2001
ip address 2.0.0.1 255.255.255.255


R2

ip address 10.200.12.10 255.255.255.252
tunnel source Loopback2002
tunnel destination 2.0.0.1

interface Tunnel10001
ip address 10.200.12.14 255.255.255.252
tunnel source Loopback3003
tunnel destination 2.0.0.1

interface Loopback2002
ip address 2.0.0.2 255.255.255.255

interface Loopback3003
ip address 3.0.0.3 255.255.255.255

This is just a regular GRE tunnel without IPSEC. Tunnel 10000 is ok, but tunnel 10001 is not.

Hello,

 

I have recreated your setup with the configs below. Both tunnels are up with keepalives configured. Can you indicate what config does NOT work ?

 

I am not sure I understand what you mean by:

 

-->  Another router in APAC also have 2 GRE tunnels. One going to AMER and one going local.

 

R1

interface Loopback2001
ip address 2.0.0.1 255.255.255.255
!
interface Tunnel10000
ip address 10.200.12.9 255.255.255.252
keepalive 5 2
tunnel source Loopback2001
tunnel destination 2.0.0.2
!
interface Tunnel10001
ip address 10.200.12.13 255.255.255.252
keepalive 5 2
tunnel source Loopback2001
tunnel destination 3.0.0.3
!
interface GigabitEthernet0/0
ip address 192.168.1.1 255.255.255.252
duplex auto
speed auto
media-type rj45
!
router eigrp 1
network 0.0.0.0

 

R2

interface Loopback2002
ip address 2.0.0.2 255.255.255.255
!
interface Loopback3003
ip address 3.0.0.3 255.255.255.255
!
interface Tunnel10000
ip address 10.200.12.10 255.255.255.252
keepalive 5 2
tunnel source Loopback2002
tunnel destination 2.0.0.1
!
interface Tunnel10001
ip address 10.200.12.14 255.255.255.252
keepalive 5 2
tunnel source Loopback3003
tunnel destination 2.0.0.1
!
interface GigabitEthernet0/0
ip address 192.168.1.2 255.255.255.252
duplex auto
speed auto
media-type rj45
!
router eigrp 1
network 0.0.0.0

Hi there. I was able to make the configurations work. I didn't realize that it was already working. However, that's just my lab running on 4400 routers.

The production routers are 3900 and it's running version 15. Here's the configuration. If I put a keeplive configuration on Tunnel 5 of APAC_R1, it will go down. However, Tunnel1 is ok. Both APAC_R1 and APAC_R2 also have GRE tunnels going to US_R1 (not shown).

APAC router:

APAC_R1:

interface Tunnel1
desc Tunnel to US
bandwidth 20000
ip vrf forwarding vrf1
ip address 10.20.20.53 255.255.255.252
ip tcp adjust-mss 1436
ip ospf dead-interval 6
ip ospf hello-interval 2
load-interval 30
keepalive 5 3
tunnel source Loopback0
tunnel destination 10.193.142.112
service-policy output EF-GRE-MARKING

interface Tunnel5
description Tunnel to APAC_R2
bandwidth 50000
ip vrf forwarding vrf1
ip address 10.20.20.57 255.255.255.252
ip tcp adjust-mss 1436
ip ospf dead-interval 6
ip ospf hello-interval 2
load-interval 30
tunnel source Loopback0
tunnel destination 10.19.255.111
service-policy output EF-GRE-MARKING

interface Loopback0
ip address 10.19.255.118 255.255.255.255


APAC_R2:

interface Tunnel5
bandwidth 50000
ip vrf forwarding vrf1
ip address 10.20.20.58 255.255.255.252
ip tcp adjust-mss 1436
ip ospf dead-interval 6
ip ospf hello-interval 2
load-interval 30
tunnel source Loopback0
tunnel destination 10.19.255.118
service-policy output EF-GRE-MARKING


interface Loopback0
ip address 10.19.255.111 255.255.255.255

Hello,

 

I am lost to be honest, as the configs you posted last look completely different than in your original post ? VRFs and OSPF ? Either way, if it works now, I guess it is ok...

The first config I pasted are from my lab so just ignore that. The second configs are all from production.

The production network is actually not working yet. The lab environment is running 4400 on version 16s while the production is 3900 on 15s.

Hello John,

if you are running OSPF on the GRE p2p tunnels with aggressive timers like the following:

 

>> ip ospf dead-interval 6
ip ospf hello-interval 2

 

I don't see any advantage on adding GRE keepalives on production networks. If the tunnel fails in 6 seconds OSPF detects it and after other 5 seconds performs a new SPF calculation.

 

Hope to help

Giuseppe

 

The timers are different story. That one was configured for routing purposes. However, it's not sending alarms to our NMS server that's why we need to see the tunnel go down, that's why we are resorting to keepalives. It has happened couple of times where in there was a problem with the tunnel path but we didn't know it because the interface stayed up. It's quite strange that it worked on some interfaces and some not although end to end reachability between the source and destination interfaces are good.

Hello, John,

 

I believe this post describes a similar problem to yours:
https://community.cisco.com/t5/mpls/gre-keepalives-with-vrf/td-p/1326442

 

In short, GRE keepalives do not integrate with VRFs out-of-the-box. That is why your lab config works (both tunnel src/dst interfaces and the tunnel itself are in the same VRF) while production one does not (different VRFs - no necessary routes between them)

Discovering the Why
https://braonle.wordpress.com/

Using the same lab setup, I changed everything to VRF and everything worked just fine. Our US routers are not running VRF too. Just plain global routing. For some reason, not one tunnel came up when keepalives were configured. In APAC where we used VRF, one out of the two came up with keepalives. Not sure if this is a hardware limitation or an IOS bug.


Hello John,

thanks for your feedback, now I understand why you would like to enable GRE keepalives in your production network.

 

Best Regards

Giuseppe

 

Could you please confirm the following part:

interface Tunnel5
description Tunnel to APAC_R2
bandwidth 50000
ip vrf forwarding vrf1
ip address 10.20.20.57 255.255.255.252
ip tcp adjust-mss 1436
ip ospf dead-interval 6
ip ospf hello-interval 2
load-interval 30
tunnel source Loopback0
tunnel destination 10.19.255.111
service-policy output EF-GRE-MARKING

As far as I know, tunnel endpoints are looked up in default RIB. Loopback0, however, is in VRF vrf1. Shouldn't there a command 'tunnel vrf vrf1'? Otherwise I have tested the following setup with IOS 15.2(4)M11 and it works:
R1 ---(192.168.12.0/24) --- R2

R1#sho run | s 0/0|Tunnel
interface Tunnel0
 vrf forwarding A
 ip address 192.168.21.1 255.255.255.0
 keepalive 10 3
 tunnel source FastEthernet0/0
 tunnel destination 192.168.12.2
 tunnel vrf A
interface FastEthernet0/0
 vrf forwarding A
 ip address 192.168.12.1 255.255.255.0
R2#sho run | s 0/0|Tunn
interface Tunnel0
 vrf forwarding A
 ip address 192.168.21.2 255.255.255.0
 keepalive 10 3
 tunnel source FastEthernet0/0
 tunnel destination 192.168.12.1
 tunnel vrf A
interface FastEthernet0/0
 vrf forwarding A
 ip address 192.168.12.2 255.255.255.0
Discovering the Why
https://braonle.wordpress.com/

Only the tunnels are under VRF. The loopbacks are all in default RIB.
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: