GRE keepalives with VRF

Unanswered Question
Sep 5th, 2009

GRE keeplives enabled under tunnel interfaces will put the line protocol of tunnel to down... I have tested this in LAB !!!

why is it so , what is the workaround to use keepalives with VRF ........

I have this problem too.
1 vote
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Peter Paluch Sat, 09/05/2009 - 15:34


It is caused by the way how the GRE keepalives work. I suggest reading these two documents first:

In short, a router sending keepalive in essence constructs an IP packet whose source is the remote endpoint and recipient is the router itself. It then encapsulates it using GRE and attaches another IP header to it with the send being itself and destination being the remote end. This packet will be sent to the remote end, there it will be decapsulated and afterwards it will be routed as usual, thereby returning the inner IP packet back to the original sender.

Obviously, this keepalive mechanism is not integrated with the VRF feature. The keepalive packet may arrive at the remote endpoint but after it is decapsulated the association with the receiving Tunnel interface is obviously lost and the remote endpoint tries to route that packet back using the global routing table, not the VRF in which the tunnel resides. This in turn causes the keepalive packet to never return.

I am unfortunately not aware of any backup keepalive mechanism for this, apart of running routing protocols over the tunnel with more aggresive hello and dead intervals.

Best regards,


terence.scott Thu, 01/30/2014 - 01:47

Hi Peter,

Thanks for pointing out the cause of this problem. The solution, apart from routing protocols over the tunnel, is to put a static route in the global routing table to allow the keepalives to be correctly routed back to the originating router. Thus if you have a tunnel with destination which is reachable through interface Gi1 in vrf RED then by simply issuing the following:

ip route Gi1

you will enable the router to route the keepalives back to the remote end of the tunnel.

I grant that it is not a very elegant solution (I dislike static routes on principle) but it allows the keepalives to work until Cisco get round to fixing the issue

Peter Paluch Sat, 02/08/2014 - 10:10

Hi Terence,

Thanks for joining this thread! Man, it's been a while since I posted my response

Your solution is spot-on. As you admit yourself, it is not the most elegant way of solving the problem, and it would ultimately fail it you had overlapping or identical remote tunnel endpoint addresses in different VRFs - but it still can be a workaround in simple scenarios.

Please keep on having these great suggestions!

Best regards,


Levi Guzman Tue, 08/30/2016 - 08:13
Hello, please consider this scenario, built as simple as possible.
1- Router 1 and Router 2 are directly connected
2- We stablish a Tunnel between these two routers
3- We use 2 VRF, one for the physical interface (WAN VRF), and one for the tunnel interface (TUNNEL VRF).
4- We are going to use BGP-MP to communicate these 2 VRF. We are going to use the AS 65000
5- We can use the same RD (route distinguishers) on both routers, hence we are not going to stablish a BGP session between them.
6- We are only going to use GRE, but combination of GRE + IPSec is perfectly possible.
!! Router 1
!! Configuration of the physical interface:
!! 65000 is the ASN of the BGP MP, 1 and 2 are the numbers we choose to identify the VRF.
ip vrf TUNNEL
 rd 65000:2
ip vrf WAN
 rd 65000:1
interface Ethernet0/0
!! This is the VRF where the physical interface belongs.
ip vrf forwarding WAN
ip address
!! Configuration of the tunnel interface:
interface Tunnel0
!! This is the VRF where the traffic sent over the tunnel belongs.
ip vrf forwarding TUNNEL
ip address
tunnel source
tunnel destination
!! This is the VRF where the source and destination of the tunnel belongs.
tunnel vrf WAN
Lets consider the scenario, Router 1 sends a keep alive to Router 2, it sends it inside the Tunnel, as you read in the links from the other post, the keep alive packed will require Router 2, to reply to it's tunnel source IP address, but because in Router 2, that route is in the VRF WAN, and the traffic, is being sent back over Tunnel 0, which belongs to VRF TUNNEL, Router 2, will drop the reply, because it doesn't have a valid route back.
For this case, we are going to advertise for VRF TUNNEL, the necessary route from VRF WAN, so he can send the traffic back.
We are going to export VRF WAN routes , and then import them in VRF TUNNEL. To do this, we are going to add the following commands: 
** This configuration can be applied to both Router 1 and 2, because of the 5th consideration at the begin of the document.
ip vrf TUNNEL
rd 65000:2
!! Import WAN RIB
route-target import 65000:1
ip vrf WAN
rd 65000:1
!! Export ourselves 
route-target export 65000:1
Then we configure the BGP MP
!! We need at least one interface in the VRF default, so BGP can take it's router-id
interface loopback 0
 ip address
router bgp 65000
 no auto
bgp log
no sync
address-family ipv4 vrf WAN
!! Advertise the WAN network into BGP 65000
network mask
After doing this, you'll be able to see the WAN network in the VRF TUNNEL
R1#show ip route vrf TUNNEL

Routing Table: TUNNEL
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
a - application route
+ - replicated route, % - next hop override
Gateway of last resort is not set is variably subnetted, 2 subnets, 2 masks
B is directly connected (WAN), 00:00:10, Ethernet0/0
L is directly connected, Ethernet0/0 is variably subnetted, 2 subnets, 2 masks
C is directly connected, Tunnel0
L is directly connected, Tunnel0
For the Router 2, the loopback will be, and the same configuration (VRF and BGP).
After doing this, you can configure the keep-alive on both Tunnels (Router 1 and 2)
This should solve your problem.
Levi Guzman


This Discussion