cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
5860
Views
6
Helpful
6
Replies

GRE keepalives with VRF

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

6 Replies 6

Peter Paluch
Cisco Employee
Cisco Employee

Hello,

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

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

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

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,

Peter

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 10.1.2.1 which is reachable through interface Gi1 in vrf RED then by simply issuing the following:

ip route 10.1.2.1 255.255.255.255 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

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,

Peter

I have tested GRE keepalives with VRF on 4400 routers running version 16. For some reason it can understand how to route back traffic to the originator with no need of static route. I tested exactly the same setup on IOU running version 15 and encountered the problem. 3900 routers running version 15 also showed the same problem.

Same issue with ESRs.

Levi Guzman
Level 1
Level 1
Hello, please consider this scenario, built as simple as possible.
Considerations:
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.
Configuration:
!! 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 10.255.255.1 255.255.255.252
end
!! 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 192.168.0.1 255.255.255.252
tunnel source 10.255.255.1
tunnel destination 10.255.255.2
!! This is the VRF where the source and destination of the tunnel belongs.
tunnel vrf WAN
end
----
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 1.0.0.1 255.255.255.255
!
router bgp 65000
 no auto
bgp log
no sync
address-family ipv4 vrf WAN
!! Advertise the WAN network into BGP 65000
network 10.255.255.0 mask 255.255.255.252
!
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
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
B 10.255.255.0/30 is directly connected (WAN), 00:00:10, Ethernet0/0
L 10.255.255.1/32 is directly connected, Ethernet0/0
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/30 is directly connected, Tunnel0
L 192.168.0.1/32 is directly connected, Tunnel0
For the Router 2, the loopback will be 1.0.0.2/32, 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.
Regards,
Levi Guzman
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: