cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
143075
Views
100
Helpful
12
Comments
Nicolas Meessen
Level 1
Level 1

 

What's a VRF?

 

  • A VRF is a Virtual Routing and Forwarding instance, it's basically a virtualization technique for IOS routers. Each VRF has its own interfaces (you cannot put a L3 interface in 2 different VRFs), it has its own routing table and everything.
  • You create a VRF by typing:
ip vrf my-out-vrf

 

  • You assign interfaces to a VRF using:
int fa0/0
ip vrf forwarding my-out-vrf

 

  • You create a static route and you look at the routing table for a VRF using:
ip route vrf my-out-vrf 10.1.1.0 255.255.255.0 192.168.5.5
sho ip route vrf my-out-vrf

 

  • lots of commands and features are "vrf-aware", just use the question mark to find out...
ping vrf my-vrf-out 10.1.1.2
sho ip cef vrf my-vrf-out 10.1.1.2
ip nat inside source list 199 interface fa0/0 vrf my-vrf-out overload

...

 

  • VPNs are MAGIC because they can have their encrypted traffic in 1 VRF and the decrypted traffic in another VRF.

The typical use case for this is an ISP that provides VPN service to multiple enterprise customers on the same box, the users and branches connect using internet for the encrypted traffic, but the decrypted traffic needs to go to the private network of each separate customer and this traffic cannot be mixed.

 

Terminology

  • ivrf : Inside VRF, the VRF that contains the clear-text traffic (before encryption for outbound flows and after decryption for inbound flows)
  • fvrf : Front-door VRF (or outside VRF), the VRF that contain the encrypted traffic
  • global VRF: the routing instance that is used if no specific VRF is defined. If no VRF-aware config is used, everything is done in the global VRF and all interfaces are in the global VRF.

 

 

Configuration

 

Crypto map-based with ivrf=cust1-vrf and fvrf=internet-vrf

 

ip cef
ip vrf cust1-vrf
!
ip vrf internet-vrf
!
!
crypto keyring internet-keyring vrf internet-vrf
pre-shared-key address 10.1.1.2 key cisco123
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2

crypto isakmp profile cust1-ike-prof
   vrf cust1-vrf
   keyring internet-keyring
   match identity address 10.1.1.2 255.255.255.255 internet-vrf
   isakmp authorization list default
!
crypto ipsec transform-set esp-3des-sha esp-3des esp-sha-hmac
!
crypto map mymap 10 ipsec-isakmp
set peer 10.1.1.2
set transform-set esp-3des-sha
set isakmp-profile cust1-ike-prof
match address 199
reverse-route

interface GigabitEthernet0/0
description internet WAN link
ip vrf forwarding internet-vrf
ip address 10.1.1.3 255.255.255.224
crypto map mymap
!
interface GigabitEthernet0/1
description cust1 private VRF
ip vrf forwarding cust1-vrf
ip address 192.168.88.20 255.255.255.0
!
interface loopback10
ip vrf forwarding cust1-vrf
ip address 1.1.1.1 255.255.255.255

ip route vrf internet-vrf 0.0.0.0 0.0.0.0 10.1.1.1
access-list 199 permit ip host 1.1.1.1 host 2.2.2.2

 

To remember:

  • "vrf <ivrf>" on isakmp profile
  • fvrf on match statement of isakmp profile
  • keyring tagged with fvrf
  • RRI for route leaking (otherwise we don't hit the crypto map) or a static route like "ip route vrf cust1-vrf 2.2.2.2 255.255.255.255 GigabitEthernet0/0 10.1.1.1" (note that the route is on the ivrf routing table but points to an interface of the fvrf)
  • interfaces in their respective VRF
  • proper routes in each VRF

 

Tunnel-protection with ivrf=cust1-vrf and fvrf=internet-vrf

ip cef
ip vrf cust1-vrf
!
ip vrf internet-vrf
!
crypto keyring internet-keyring vrf internet-vrf
  pre-shared-key address 10.1.1.2 key cisco123
!
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
!
crypto isakmp profile cust1-ike-prof
   keyring internet-keyring
   match identity address 10.1.1.2 255.255.255.255 internet-vrf
   isakmp authorization list default
   local-address GigabitEthernet0/0
!
crypto ipsec transform-set esp-3des-sha esp-3des esp-sha-hmac
!
crypto ipsec profile cust1-ipsec-prof
set transform-set esp-3des-sha
set isakmp-profile cust1-ike-prof
!
!
interface Tunnel200
ip vrf forwarding cust1-vrf
ip address 172.16.4.4 255.255.255.0
tunnel source GigabitEthernet0/0
tunnel destination 10.1.1.2
tunnel mode ipsec ipv4
tunnel vrf internet-vrf
tunnel protection ipsec profile cust1-ipsec-prof
!
interface GigabitEthernet0/0
description internet WAN link
ip vrf forwarding internet-vrf
ip address 10.1.1.3 255.255.255.224
!
interface GigabitEthernet0/1
description cust1 private VRF
ip vrf forwarding cust1-vrf
ip address 192.168.88.20 255.255.255.0
!
ip route vrf internet-vrf 0.0.0.0 0.0.0.0 10.1.1.1

 

To remember:

  • "ip vrf forwarding <ivrf>" on the tunnel interface
  • "tunnel vrf <fvrf>" on the tunnel interface
  • crypto keyring tagged with fvrf
  • NO "vrf <ivrf>" on isakmp profile
  • fvrf on match statement of isakmp profile
  • no need to worry about RRI (tunnel destination needs to be reachable in fvrf), inside traffic gets routed to the tunnel interface
  • interfaces in their VRF and proper routes in each VRF as well

 

Which scenarios are supported?

 

crypto map

everything except fvrf=vrf1 and ivrf=global i.e.

ivrf=fvrf=global is OK (this is normal non-vrf aware ipsec)

ivrf=fvrf=vrf1 is OK (this is the example shown in the video)

ivrf=vrf1 and fvrf=vrf2 is OK

ivrf=vrf1 and fvrf=global is OK

 

tunnel protection

=> everything

 

Troubleshooting

 

Tunnel establishment

  • in ISAKMP debugs, scroll up and make sure that you match the expected profile!!!, don't focus too much on the errors that you see later on, if you don't match the right profile, start by verifying this.
  • is the PSK in a keyring and tagged to the right VRF? Does the profile we match have the keyring?

 

Tunnel is up but traffic not passing

  • Check the routes in each VRF
  • confirm with "show ip cef vrf <ivrf> <remote-subnet-ip>" the adjacency for the remote subnet and the interface it goes to
  • confirm with "show ip cef vrf <fvrf> <peer-ip>" the adjacency for the remote peer
  • look for "protected vrf" in "show crypto ipsec sa", are we protecting the expected VRF?

Known bugs:

CSCtg41606

 

Further references

Comments
rochopra
Cisco Employee
Cisco Employee

http://www.ccbootcamp.com/keith-cln.mov is not active anymore, do we have any other video available for this.

inetsystems
Level 1
Level 1

Why did you have "ip vrf forwarding" command applied to the interface with crypto map?

I tried this but it is not working in my lab.

Could you please help?

interface GigabitEthernet0/0
description internet WAN link
ip vrf forwarding internet-vrf
ip address 10.1.1.3 255.255.255.224
crypto map mymap
!

I have searched Cisco's document and there is not example with the above configuration. I understand that you are configuring iVRF and fVRF here.

It does work with VTI or without the "ip vrf forwarding" command.

Regards.

Adil.

Nicolas Meessen
Level 1
Level 1

Hi Adil, there are very few examples where the fvrf is configured, but I did include it in my example in order to show the most complete example. you can remove the fvrf from everywhere in the config and it will work just fine, but it will also work with it, you just need to make sure that you declare a default route in that VRF, so for example:

ip route vrf internet-vrf 0.0.0.0 0.0.0.0 10.1.1.1

If you post your entire lab config, I can have a look to see if I can figure out what's wrong.

inetsystems
Level 1
Level 1

Thanks Nicolas.

Mark Walters
Level 1
Level 1

great article!

arneolav83
Level 1
Level 1

Great article, but I am having some problems. The VPN tunnel is up i see the decaps packets come all the way to the computer behind the IVRF and the reply going from the computer(did some sniffing), but I never see the packets go back throught the tunnel in encap. And when i do a trace route i see that the packets go all the way to the router.

But it's like the crypto is not aware, I have tried to set a static route and with different versions of the OS, but still nothing.

When running the follwing commands I get this:

IVRF

sh ip cef vrf KOMASP 172.23.1.0   

172.23.1.0/24

  unresolved via x.x.x.x

sh ip route vrf KOMASP

      172.23.0.0/24 is subnetted, 1 subnets

S        172.23.1.0 [1/0] via 81.26.33.24

FVRF

sh ip cef vrf KOMASPVPN x.x.x.x

0.0.0.0/0

  nexthop 85.89.198.81 GigabitEthernet0/0.101

Anyone got a clue why it's not picking up the packets or not sending them through the crypto?

Nicolas Meessen
Level 1
Level 1

Looks like we're missing the CEF adjacency for outbound traffic in the IVRF. Could you be hitting

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCtg41606 ?

Have you tried configuring "reverse-route remote-peer <next-hop-ip>" to force RRI to install a route in the IVRF pointing to the next-hop on the WAN?

arneolav83
Level 1
Level 1

After I defined reverse-route remote-peer 85.89.x.x i get this:

#sh ip cef vrf KOMASP 172.23.1.0

172.23.1.0/32

  nexthop 85.89.x.x GigabitEthernet0/0.101

And the

#sh ip route vrf KOMASP 172.23.1.0

Routing Table: KOMASP

Routing entry for 172.23.1.0/32

  Known via "static", distance 1, metric 0

  Routing Descriptor Blocks:

  * 85.89.x.x, via GigabitEthernet0/0.101

      Route metric is 0, traffic share count is 1

So everything is looking a bit better, but I am still not hitting the cryptomap. no encaps.

But then I entered a static route

ip route vrf KOMASP 172.23.1.0 255.255.255.0 85.89.x.x  gig0/0.101

then it started to work...

I guess they have not fixed this bug, I have tried version

c2900-universalk9-mz.SPA.152-4.M1.bin and c2900-universalk9-mz.SPA.152-3.T1.bin

hansel.belen
Community Member

Any chance you can do a config for Cisco VPN Client connecting to a router with vrf ? Thanks!

Abaji Rawool
Level 3
Level 3

In Crypto map-based with ivrf=cust1-vrf and fvrf=internet-vrf case : when you have peer behind NAT IP, make sure to use the match identity address as actual IP of the peer (pre-nat address) if it is using default identity as the IP address

Andrew Edwards
Level 4
Level 4

I have a 2547oDMVPN setup and trying to apply crypto.


When I apply crypto, the SA seems active and eBGP over the DMVPN returns, vpnv4 labels swap, cef table looks right. However, no traffic flows from local IP to remote IP in the VRF after applying configurations.  

From what I can tell, it looks like there is no definition of the protected VRF (e.g. FVRF defined but IFRV is not).

basic crypto configs:


crypto isakmp policy 10
encryption 3des
authentication pre-share
hash md5
group 2
!

crypto keyring DMVPN_KEY_RING vrf FD_VRF
pre-shared-key address 0.0.0.0 key 0 cisco123

crypto isakmp profile DMVPN_ISAKMP
keyring DMVPN_KEY_RING
match identity address 0.0.0.0 FD_VRF

crypto ipsec transform-set 3DES_MD5 esp-3des esp-md5-hmac
mode transport
!
crypto ipsec profile DMVPN
set transform-set 3DES_MD5
set isakmp-profile DMVPN_ISAKMP
!

# apply to hub and spoke tunnels

interface Tunnel 0
tunnel protection ipsec profile DMVPN shared

tkitzky
Level 1
Level 1

What happens to this setup when you add a second DMVPN tunnel for a new customer? Can you share the source-interface for the additional DMVPN tunnel or do you need a new Internet interface to source the second tunnel?

I have a dual hub, single DMVPN setup supporting multiple customers. I am unable to get crypto endpoints established on the correct tunnel at the hub routers. Some do terminate properly while others are in limbo or terminate to the incorrect VRF.

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: