Problems with GRE since adding VRF

Unanswered Question
Mar 2nd, 2010

Hi there

I am having real problems since adding a VRF to my existing setup. Currently we connect remote sites to head office via GRE tunnels with IPSec over the internet and then run OSPF. While limited in scalability this has proved to be a very relaible set up. The current set up uses a border router with one interface on the internet and another interface on the corporate LAN. I wanted to remove the Interente interface from the global routing table with the creation of a VRF. Since doing this our GRE tunnels do not appear to be working.

To simplify trouble shooting I have removed the crytomap from the public interface.

[Head end]

3745 IOS c3745-adventerprisek9-mz.124-15.T11.bin

!
ip vrf INTERNET
rd 64521:100
!
!
interface Tunnel1
description *** HBX to Site 3 ***
bandwidth 220
ip address 172.32.255.250 255.255.255.252
no ip proxy-arp
ip pim query-interval 10
ip pim sparse-dense-mode
ip tcp adjust-mss 1400
ip ospf message-digest-key 10 md5 7 <removed>
ip ospf network point-to-point
ip ospf hello-interval 3
qos pre-classify
keepalive 10 3
tunnel source FastEthernet0/0
tunnel destination 192.0.2.100
tunnel path-mtu-discovery
tunnel vrf INTERNET
!

!
interface FastEthernet0/0
description *** UPSTREAM PROVIDER -  ***
ip vrf forwarding INTERNET
ip address192.0.2.200 255.255.255.252
no ip redirects
no ip unreachables
no ip proxy-arp
ip virtual-reassembly
speed 100
full-duplex
no cdp enable
max-reserved-bandwidth 90
!

[Remote Site]

837 IOS c837-k9o3sy6-mz.124-25b.bin

!
interface Tunnel1
description *** To acc01-gw.hex ***
bandwidth 220
ip address 172.32.255.249 255.255.255.252
no ip proxy-arp
ip pim query-interval 10
ip pim sparse-dense-mode
ip tcp adjust-mss 1400
ip ospf message-digest-key 10 md5 7 <removed>
ip ospf network point-to-point
ip ospf hello-interval 3
ip ospf mtu-ignore
qos pre-classify
keepalive 10 3
tunnel source Dialer1
tunnel destination 192.168.0.200

tunnel path-mtu-discovery
!
!
interface Dialer1
description *** plusdsl.net 1MB ADSL ***
bandwidth 440
bandwidth receive 2000
ip address 192.0.2.100
ip access-group INBOUND-ACL in
ip access-group OUTBOUND-ACL out
ip verify unicast reverse-path
no ip unreachables
no ip proxy-arp
ip nat outside
ip virtual-reassembly
encapsulation ppp
dialer pool 1
dialer-group 1
no cdp enable
ppp authentication chap callin
ppp chap hostname <removed>

ppp chap password <removed>
max-reserved-bandwidth 90
service-policy output QoS-BRANCH-Router
!

The head end can see the tunnel interface as UP UP and I am able to ping the local tunnel IP address. I am not able to ping the remote tunnel IP address. A debug of tunnel keepalives shows that the router is sending and recieving keepalive ok.

The remote end can see the tunnel interface as UP DOWN. I am not able to ping the local tunnel IP address but I can ping the remote tunnel IP address (very strange!). A debug of tunnel keepalives shows the router sending keepalives but not recieving them. I can only assume the interface is UP DOWN because the keepalives are bringing the interface down and this is why I can not ping the local tunnel interface. If I remove the tunnel keepalives the interfaces comes UP UP and an OSPF relationship forms.

Is anyone able to explain to me what I have done wrong or how I fix tunnel keepalives for VRF?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Giuseppe Larosa Tue, 03/02/2010 - 08:44

Hello James,

>> If I remove the tunnel keepalives the interfaces comes UP UP and an OSPF relationship forms.

this is an acceptable workaround if you use OSPF you don't need the GRE keepalive: if the tunnel fails OSPF will fail.

If you really want to use GRE keepalives your next move can be to upgrade IOS image on HUB to 12.4(20)T or later and to see if behaviour changes

Hope to help

Giuseppe

james-worley Thu, 09/02/2010 - 07:29

In the end this is what we did and have removed keepalives from the tunnel config. I also had to do a lot of work redoing all the crypto stuff to get that VRF aware.

Actions

This Discussion

Related Content