GRE With VRF

Unanswered Question
Jul 4th, 2010
User Badges:

Hi All


This should be pretty basic I have a scenario where i'm trying to simulate a vrf GRE tunnel. I'm sure you guys may have seen this problem before. I'm unable to ping across tunnel's 2 WAN link. I took tunnel one out of the vrf to test it and it worked as normal. what do you think?


CE-1#ping vrf vpn_2 204.134.84.26

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 204.134.84.26, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
CE-1#

configurations below,


##

CE-1

##


hostname CE-1
!
boot-start-marker
boot-end-marker
!
enable password cisco
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
ip vrf vpn_2
rd 65000:2
!
!
!
!
crypto isakmp policy 10
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key secretkey address 192.168.3.9
crypto isakmp key secretkey address 204.134.83.3
!
!
crypto ipsec transform-set TS esp-aes esp-md5-hmac
mode transport
!
crypto ipsec profile Secure_Tunnel
set transform-set TS
!
!
!
!
!
interface Loopback0
ip vrf forwarding vpn_2
ip address 192.168.1.1 255.255.255.255
!
interface Tunnel1
ip address 204.134.84.21 255.255.255.252
ip mtu 1532
tunnel source 192.168.3.10
tunnel destination 192.168.3.9
tunnel protection ipsec profile Secure_Tunnel
!
interface Tunnel2
ip vrf forwarding vpn_2
ip address 204.134.84.25 255.255.255.252
ip mtu 1532
tunnel source Loopback0
tunnel destination 204.134.83.3
tunnel vrf vpn_2
tunnel protection ipsec profile Secure_Tunnel
!
interface FastEthernet0/0
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/0
description *** Link to PE-1 ***
ip vrf forwarding vpn_2
ip address 192.168.3.14 255.255.255.252
no fair-queue
clock rate 2000000
!
interface FastEthernet0/1
no ip address
shutdown
duplex auto
speed auto
!
interface Serial0/1
description *** Link to PE-1 VRF2 ***
ip address 192.168.3.10 255.255.255.252
no fair-queue
clock rate 2000000
!
router bgp 65001
no synchronization
bgp log-neighbor-changes
network 192.168.1.1 mask 255.255.255.255
neighbor 192.168.3.9 remote-as 65000
no auto-summary
!
address-family ipv4 vrf vpn_2
  redistribute connected
  neighbor 192.168.3.13 remote-as 65000
  neighbor 192.168.3.13 activate
  neighbor 192.168.3.13 as-override
  neighbor 204.134.84.26 remote-as 65000
  neighbor 204.134.84.26 activate
  neighbor 204.134.84.26 as-override
  no synchronization
exit-address-family
!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login
!
!
end


###


##

PE-1

####


hostname PE-1
!
boot-start-marker
boot-end-marker
!
enable password cisco
!
no aaa new-model
!
!
ip cef
no ip domain lookup
!
!
ip vrf vpn_1
rd 65000:1
route-target export 65000:1
route-target import 65000:1
!
ip vrf vpn_2
rd 65000:2
route-target export 65000:2
route-target import 65000:2
!
mpls label protocol ldp
mpls ldp discovery hello interval 1
!
!
!
!
crypto isakmp policy 10
encr aes
hash md5
authentication pre-share
group 2
crypto isakmp key secretkey address 192.168.3.10
crypto isakmp key secretkey address 192.168.1.1
!
!
crypto ipsec transform-set TS esp-aes esp-md5-hmac
mode transport
!
crypto ipsec profile Secure_Tunnel
set transform-set TS
!
!
!
!
!
interface Loopback0
ip vrf forwarding vpn_2
ip address 204.134.83.3 255.255.255.255
!
interface Tunnel1
ip address 204.134.84.22 255.255.255.252
ip mtu 1500
tunnel source 192.168.3.9
tunnel destination 192.168.3.10
tunnel protection ipsec profile Secure_Tunnel
!
interface Tunnel2
ip vrf forwarding vpn_2
ip address 204.134.84.26 255.255.255.252
ip mtu 1532
tunnel source Loopback0
tunnel destination 192.168.1.1
tunnel vrf vpn_2
tunnel protection ipsec profile Secure_Tunnel
!
interface FastEthernet0/0
no ip address
shutdown
duplex half
!
interface Serial1/0
description *** Link to CE-1 ***
ip vrf forwarding vpn_2
ip address 192.168.3.13 255.255.255.252
serial restart-delay 0
!
interface Serial1/1
description *** Link to CE-1 ***
ip address 192.168.3.9 255.255.255.252
serial restart-delay 0
!
!
!
router ospf 101
log-adjacency-changes
network 204.134.83.0 0.0.0.255 area 0
network 204.134.84.0 0.0.0.255 area 0
!
router bgp 65000
bgp router-id 204.134.83.3
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 204.134.83.1 remote-as 65000
neighbor 204.134.83.1 description PE2
neighbor 204.134.83.1 update-source Loopback0
neighbor 204.134.83.8 remote-as 65000
neighbor 204.134.83.8 description PE3
neighbor 204.134.83.8 update-source Loopback0
!
address-family vpnv4
  neighbor 204.134.83.1 activate
  neighbor 204.134.83.1 send-community both
  neighbor 204.134.83.8 activate
  neighbor 204.134.83.8 send-community both
exit-address-family
!
address-family ipv4 vrf vpn_2
  redistribute connected
  neighbor 192.168.3.14 remote-as 65001
  neighbor 192.168.3.14 activate
  neighbor 192.168.3.14 as-override
  neighbor 204.134.84.25 remote-as 65001
  neighbor 204.134.84.25 activate
  neighbor 204.134.84.25 as-override
  no synchronization
exit-address-family
!
address-family ipv4 vrf vpn_1
  redistribute connected
  neighbor 192.168.3.10 remote-as 65001
  neighbor 192.168.3.10 activate
  neighbor 192.168.3.10 as-override
  no synchronization
exit-address-family

!

!
ip forward-protocol nd
!
!
ip http server
no ip http secure-server
!
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
login

end

PE-1#

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Carl Williams Mon, 07/05/2010 - 00:48
User Badges:

Its for VRF lite, The ideal scenario is for me to have vrf encryption on the PE. I created a VRF lite scenario to see if creating a VRF on the CE would stop the problem of not being able to ping between tunnel WAN addresses, but this did'nt work. Again the problem I'm having is not being able to ping between tunnel WAN addresses within the VRF. When i take the interfaces out of the tunnel it works fine. I've seen VRF encryption work before between two end points but don't know why it's not working here.

Carl Williams Tue, 07/06/2010 - 08:37
User Badges:

No Worries


I've solved this issue I just needed to ensure that the source and destination tunnel ip addresses were found in the global routing routing tables on both devices


regards


Carl Williams

Actions

This Discussion