01-26-2009 04:03 AM
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
01-26-2009 06:19 PM
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.
01-27-2009 02:24 AM
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
01-27-2009 11:44 AM
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.
01-28-2009 01:17 AM
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
01-28-2009 07:44 AM
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.
01-28-2009 08:28 AM
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?
01-28-2009 12:08 PM
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.
07-02-2013 05:17 PM
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.
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: