Disappearing tunnel keepalives with tunnel interface in vrf

Unanswered Question
Jan 26th, 2009

Dear all

I have an annoying problem with a gre tunnel using keepalives and the tunnel interface on the PE residing in a vrf.

The background for my setup is an ethernet WAN link to our customer where the interface doesn't go down when the link fails.

Therefore I want to use an gre tunnel with keepalive in order to use static routes.

The tunnel setup is as follows:

1. PE, 6509, Sup720, IOS 12.2(18)SXF7


interface FastEthernet8/13

ip address xx.yy.zz.241

speed 10

duplex full

no mop enabled

interface Tunnel813

ip vrf forwarding CUSTOMER

ip address

keepalive 5 3

tunnel source xx.yy.zz.241

tunnel destination xx.yy.zz.242


2. CE, 1803, IOS 12.4(15)T8


interface FastEthernet0

bandwidth 5000

ip address xx.yy.zz.242

speed 10


interface Tunnel0

ip address

keepalive 5 3

tunnel source xx.yy.zz.242

tunnel destination xx.yy.zz.241

The problem is PE sends and receives keepalives and brings up the tunnel. CE on the other hand sends but doesn't receive keepalives.

As far as I have learned from former discussions the problem comes from tunnel and physical interface belonging to different routing instances. If I put the tunnel interface on PE into the global routing instance all the keepalives reach their destinations as expected.

I read about a solution involving "tunnel vrf" on th etunnel configuration. This command is not present in my IOS version but AFAIK it is only necessary for having the underlying physical interface in a vrf as well.

Furthermore I read about "mls mpls tunnel-recir" but I am not sure whether this might solve the issue here. And equally important: Can I safely turn on this feature on a running system with quite a lot of vrf customers without any trouble?

Any hint and/or advise is greatly appreciated here.

Thanks a lot in advance,


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Laurent Aubert Mon, 01/26/2009 - 18:19

Hi Grischa,

GRE keepalives are not supported if vrf is configured:


Object tracking for static routing is supported in 12.4(15)T8 but you need 12.2(33)SXH min on your PE so I think you should configure a dynamic routing protocol between the PE and the CE if you don't want to upgrade your PE for now.

Let me know if you have other questions




grischast Tue, 01/27/2009 - 02:24

Hi Lauren

Thank you for this information. That clarifies things a little bit.

If I do not use keepalives I should be able to use the tunnel interface within the vrf, right?

In this case the tunnel comes up and I can ping through the tunnel to the peers address.

But from the CE I cannot reach any IP within the vrf behind the tunnel endpoint. Do I need "mls mpls tunnel-recir" for this?

(And still: Is it safe to enable this feature on a running system?)



Laurent Aubert Tue, 01/27/2009 - 11:44

That's correct, you need the mls mpls tunnel-recir to support GRE and MPLS. This command should impact only your GRE tunnels but as we never know you should first try in your lab and then deploy it during a maintenance window.

But without keepalive, you still don't have any way to use static routing with link failure detection...



grischast Wed, 01/28/2009 - 01:17

Thanks again. Strange thing: In the lab I can reach other vrf loopback interfaces in completely different IP networks across the incoming gre tunnel. IOS on this 6509 is 12.2(18)SXF15a and it doesn't matter whether or not "mls mpls tunnel-recir" is enabled. And on this machine tunnel keepalives work from both sides which cannot be, right? ;) As to make things worse I have tried the older IOS as well and even here the GRE keepalives go back and forth as they should although the tunnel interface on the 6509 is in vrf.

Anyway on our productive system I can use keepalives from PE to CE but not vice versa. Thus, using the GRE tunnel without keepalive but with route tracking on the CE I get link failure detection from both ends. And I hope I can use this setup once "mls mpls tunnel-recir" is enabled here.

I have a second case with similar setup on a 7505 RSP4 12.3(21) as the PE where it works exactly like this. I need to be sure that we can safely replace this machine by a 6509 as well...

Thanks for the discussion. :)


Laurent Aubert Wed, 01/28/2009 - 07:44

No Problem !!

Did you try with a loopback configured on another PE ? If the loopback is locally configured there is no need to impose MPLS labels so mls mpls tunnel-recir is not required.

The issue is the PE may want to use the VRF to send back the received keepalive once de-encapsulated. The issue is the original IP Haeader belongs to the transport routing plan and not the overlay routing plan.

I did not really test it so can't confirm if it's systemic or not.


I'm still convinced going with a dynamic routing protocol is the easiest solution.



grischast Wed, 01/28/2009 - 08:28

I see, I already expected this explanation for the "tunnel-recir" issue, thanks.

As for the dynamic routing protocol: what do you suggest to keep it as simple as possible? AFAIK it is not possible to have just a simple routing process between the two peers which resides in the vrf layer on the PE without influencing the global OSPF and BGP processes, right?

Laurent Aubert Wed, 01/28/2009 - 12:08

BGP is the easiest one to implement in this case:

router bgp SP_AS

address-family ipv4 vrf CUSTOMER

neighbor xx.yy.zz.242 remote-as 65000

neighbor xx.yy.zz.242 activate


If you configured a RT export policy in the CUSTOMER vrf, all the prefixes received from the CE will be exported as MP-IBGP prefixes and can be imported by other PEs. In the same way, prefixes imported and installed in the vrf CUSTOMER will be send as eBGP update to your CE router.



Frederick Reimer Tue, 07/02/2013 - 17:17

Wow, this is old, but...

While they may or may not be officially supported, GRE tunnels do work with vrf's if you both put the tunnel interface in the VRF AND the physical interface the tunnel runs over, AND use the tunnel vrf command.  Then everything is in the same routing table and it works.  For example:


vrf definition vrf1

rd 1:1


address-family ipv4

  route-target export 1:1

  route-target import 1:1



interface Ethernet0/0

vrf forwarding vrf1

ip address

interface Tunnel1

vrf forwarding vrf1

ip address

keepalive 1 3

tunnel source Ethernet0/0

tunnel destination

tunnel vrf vrf1


router bgp 12345

bgp log-neighbor-changes


address-family vpnv4

! Provider stuff - i.e., route reflector for MPLS network



address-family ipv4 vrf vrf1

  neighbor remote-as 64512

  neighbor activate

  neighbor default-originate



interface Ethernet0/0

ip address

interface Tunnel1

ip address

keepalive 1 3

tunnel source Ethernet0/0

tunnel destination


router bgp 64512

bgp log-neighbor-changes

! network statements perhaps

! redistribute static perhaps

neighbor remote-as 12345

neighbor update-source Tunnel1

neighbor soft-reconfiguration inbound

Of course you don't need to run BGP, but you can.


This Discussion