Disappearing tunnel keepalives with tunnel interface in vrf

grischast · ‎01-26-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 255.255.255.252

speed 10

duplex full

no mop enabled

interface Tunnel813

ip vrf forwarding CUSTOMER

ip address 10.0.0.101 255.255.255.252

keepalive 5 3

tunnel source xx.yy.zz.241

tunnel destination xx.yy.zz.242

end

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

---------------------------

interface FastEthernet0

bandwidth 5000

ip address xx.yy.zz.242 255.255.255.252

speed 10

full-duplex

interface Tunnel0

ip address 10.0.0.102 255.255.255.252

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,

Grischa

Laurent Aubert · ‎01-26-2009

Hi Grischa,

GRE keepalives are not supported if vrf is configured:

http://www.cisco.com/en/US/docs/ios/12_4/interface/configuration/guide/inb_tun.html#wp1093703

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

HTH

Thanks

Laurent.

grischast · ‎01-27-2009

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?)

Regards,

Grischa

Laurent Aubert · ‎01-27-2009

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...

Thanks,

Laurent.

grischast · ‎01-28-2009

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. :)

Grischa

Laurent Aubert · ‎01-28-2009

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.

http://www.cisco.com/en/US/tech/tk827/tk369/technologies_tech_note09186a008040a17c.shtml

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

Thanks.

Laurent.

grischast · ‎01-28-2009

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 · ‎01-28-2009

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.

Thanks

Laurent.

Frederick Reimer · ‎07-02-2013

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:

PE:

vrf definition vrf1

rd 1:1

!

address-family ipv4

route-target export 1:1

route-target import 1:1

exit-address-family

!

interface Ethernet0/0

vrf forwarding vrf1

ip address 192.168.1.1 255.255.255.0

interface Tunnel1

vrf forwarding vrf1

ip address 1.1.1.1 255.255.255.252

keepalive 1 3

tunnel source Ethernet0/0

tunnel destination 192.168.1.2

tunnel vrf vrf1

!

router bgp 12345

bgp log-neighbor-changes

!

address-family vpnv4

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

exit-address-family

!

address-family ipv4 vrf vrf1

neighbor 1.1.1.2 remote-as 64512

neighbor 1.1.1.2 activate

neighbor 1.1.1.2 default-originate

exit-address-family

CE:

interface Ethernet0/0

ip address 192.168.1.2 255.255.255.0

interface Tunnel1

ip address 1.1.1.2 255.255.255.252

keepalive 1 3

tunnel source Ethernet0/0

tunnel destination 192.168.1.1

!

router bgp 64512

bgp log-neighbor-changes

! network statements perhaps

! redistribute static perhaps

neighbor 1.1.1.1 remote-as 12345

neighbor 1.1.1.1 update-source Tunnel1

neighbor 1.1.1.1 soft-reconfiguration inbound

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