What is vrf

hi,
can any one tell me what is VRF(virtual routeing and forwarding) ,how its works
Regards,
vishal

Hello Vishal,
Virtual Routing and Forwarding (VRF) is an IP technology that allows multiple instances of a routing table to co-exist on the same router at the same time. Because the routing instances are independent, the
same or overlapping IP addresses can be used without conflict. “VRF” is also used to refer to a routing table instance that can exist in one or multiple instances per each VPN on a Provider Edge (PE) router.
Basically you can have n number of customers and have each customer assigned a VRF with a unique RD. This will create a seperate instance for routing. The benefit for creating VRF would be you can over lapping IP address for your end customers. Internet service providers (ISPs) often take advantage of VRF to create separate virtual private networks (VPNs) for customers; thus the technology is also referred to as VPN routing and forwarding. Because the routing instances are independent, the same or overlapping IP addresses can be used without conflicting with each other.
HTH,
Nikhil

Similar Messages

What is VRF-Lite

Can anyone explain what is the difference between VRF and VRF Lite. What is the main purpose/application of VRF Lite?
Thanks in advance
AK

Vrf-lite is a leaner cut down version of MPLS-VRF.
Where in MPLS-VRF you need labels for VPN traffic switching, you dont need labels in VRF-lite.
VRF-lite mainly relies on routing using multiple virtual routing instances created for each vrf for switching traffic. There is no label switching for VRF-lite.
Since there is no label switching, you need to populate VRF's on every hop on your network. For example |Lan--PE1---PE2---PE3--Lan|
PE1 has 2 vrf's connected to a local lan, to route these VRF's to the other end(PE3), you will need to have dedicated interfaces(or subinterfaces on each hop and enable routing instances for each VRF on each hop.
But with MPLS-VRF you need to just enable the VRF's on PE1 and PE3 with MPBGP and Label Switching enabled.
So the advantage of VRF-Lite is to have virtualization of your sub-networks a smaller scale. If you have a big network, you may very well consider implementing MPLS (even though you may be an enterprise).
HTH-Cheers,
Swaroop

What's vrf

when i learned about the security of a case ,i met a word "VRF" and look for the answer for quite a while and couln't ,who can tell me what is the VRF

VRF is Virtual Route Forwarding.
Here is a good definition about it. Got from one of the google searches. :)
Virtual Routing and Forwarding
Virtual routing and forwarding (VRF) is a technology included in IP(Internet Protocol) network routers that allows multiple instances of a routing table to exist in a router and work simultaneously. This increases functionality by allowing network paths to be segmented without using multiple devices.
Because traffic is automatically segregated, VRF also increases network security and can eliminate the need for encryption and authentication. Internet service providers
(ISPs) often take advantage of VRF to create separate virtual private networks (VPNs) for customers; thus the technology is also referred to as VPN routing and forwarding.
VRF acts like a logical router, but while a logical router may include many routing tables, a VRF instance uses only a single routing table. In addition, VRF requires a forwarding table that designates the next
hop for each data packet, a list of devices that may be called upon to forward the packet, and a set of rules and routing protocols that
govern how the packet is forwarded. These tables prevent traffic from being forwarded outside a specific VRF path and also keep out traffic that should remain outside the VRF path.

Monitoring and Managenent in IPVPN's

Hi,
Could do with a bit of advice on monitoring and management of circuits and CPE's in L3IPVPNs
Graphing of circuits seems straight forward as I can just add PE's to Cacti and graph all customer circuits.
My thoughts when looking at Monitoring CPE is that I could use Central Services where I have a monitoring VRF with a NMS server sat on it, this monitoring vrf would import all the CPE loopbacks from all customer IPVPN's and then all customer IPVPN's would import the ip address of the NMS server, is this common?
The only issue or complexity I can see in this is the management of IP addressing as I would have to make sure all CPE's loopbacks across all IPVPN's have unique IP addresses that do not conflict with the customer IP addressing scheme and do not conflict with the monitoriong IP addressing scheme. This is because the monitoring VRF will hold the all CPE loopbacks routes and the monitoring subnet and then the customer overlap is a consideration as the CPE will be configured with that /32 and therefore it can't overlap with their IP addressing.
Any way to simplify this or work around this?
To make this easier is anyone utilising the 169.254.0.0/16 subnet for Central Services as we have a better chance of the customers not wanting to use this, can anyone see a potential issues using this?
For management I could just stick another server (maybe a terminal server or just use the NMS server) on the same monitoring subnet and again use the CPE loopbacks to ssh to them, although I worked at a previous (much larger ISP) and we had some sort of system that you could ssh to and choose what IPVPN/vrf you want to be in and then you were in that vrf - it was a long time ago that I worked there and didn't put much thought into how that worked at the time (wish I had now) but the only way I can see this working is something that could run MPBGP - all I am asking here is whether anyone has any suggestions/links/software or nice tricks of the trade etc for managemnet- I know it is a high level question and I don't expect anyone to spend a load of time walking me thorugh this.
Any input on this would help a lot, thanks in advance
BTW, my PE's are ASR 9001's

Hi,
Could do with a bit of advice on monitoring and management of circuits and CPE's in L3IPVPNs
Graphing of circuits seems straight forward as I can just add PE's to Cacti and graph all customer circuits.
My thoughts when looking at Monitoring CPE is that I could use Central Services where I have a monitoring VRF with a NMS server sat on it, this monitoring vrf would import all the CPE loopbacks from all customer IPVPN's and then all customer IPVPN's would import the ip address of the NMS server, is this common?
The only issue or complexity I can see in this is the management of IP addressing as I would have to make sure all CPE's loopbacks across all IPVPN's have unique IP addresses that do not conflict with the customer IP addressing scheme and do not conflict with the monitoriong IP addressing scheme. This is because the monitoring VRF will hold the all CPE loopbacks routes and the monitoring subnet and then the customer overlap is a consideration as the CPE will be configured with that /32 and therefore it can't overlap with their IP addressing.
Any way to simplify this or work around this?
To make this easier is anyone utilising the 169.254.0.0/16 subnet for Central Services as we have a better chance of the customers not wanting to use this, can anyone see a potential issues using this?
For management I could just stick another server (maybe a terminal server or just use the NMS server) on the same monitoring subnet and again use the CPE loopbacks to ssh to them, although I worked at a previous (much larger ISP) and we had some sort of system that you could ssh to and choose what IPVPN/vrf you want to be in and then you were in that vrf - it was a long time ago that I worked there and didn't put much thought into how that worked at the time (wish I had now) but the only way I can see this working is something that could run MPBGP - all I am asking here is whether anyone has any suggestions/links/software or nice tricks of the trade etc for managemnet- I know it is a high level question and I don't expect anyone to spend a load of time walking me thorugh this.
Any input on this would help a lot, thanks in advance
BTW, my PE's are ASR 9001's

What target address does IPM select if the target IPSLA device is a multi-VRF CE?

What target address does IPM select if the target IPSLA device is a multi-VRF CE?
With IPM 4.2.1 it is not possible to select the correct target IP address when configuring a collector between two multi-VRF devices. It looks as if the primary management address for the target device is used in the collector configuration which, of course, belongs in a different VRF entirely.

One example, and there may be others, is the (free) DynDNS dynamic DNS service which publishes a domain name for the WAN port of your router which can then be resolved, like all other domain names, to the actual IP address of the WAn port of your router. This service provides a solution to the problem of having a proper domain name in cases where your public IP address changes over time. Unless you pay for a static IP address, virtually all ISPs change your public IP address over time.
So, you can register for a free DynDNS account at www.dyndns.com and that is how you come up with the User: and Password: information; use whatever User and Password you register at dyndns.com with.
The first part of the hostname you can define as you wish, subject only to someone else having used it previously, and the remaining parts of the domain name might be "dyndns.org" or one of the other domain names provided by the DynDNS service. So, you could publish, via DynDNS, the name of your public IP address as, for example, joehlam.dyndns.org however you might want something less descriptive or more vague.

What Image of 3750 supports VRF lite?

Folks,
I want to implement VRF lite in my network, we have a bunch of 3750's in out network at the edge. Cisco doc says that 3750 support vrf lite, but i tried to download
Base
ip services
advanced service image
for the 3750, and i still do not see the VRF lite commands?
Any ideas?

According to the IOS Feature Navigator, any EMI image from 12.1(11)EA1 supports VRF lite.
Please refer to the following URL to access the IOS Feature Navigator:
http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp
Hope this helps,

Getting "IPSEC(epa_des_crypt): decrypted packet failed SA identity check" messages on packets from only one of two far-end sources sharing the same tunnel, the other source works fine. What exactly does this error mean?

One computer at COMPANY-A is attempting to communicate with two
computers located at COMPANY-B, via an IPsec tunnel between the
two companies.
All communications are via TCP protocol.
All devices present public IP addresses to one another, although they
may have RFC 1918 addresses on other interfaces, and NAT may be in use
on the COMPANY-B side. (NAT is not being used on the COMPANY-A side.)
The players:(Note: first three octets have been changed for security reasons)
COMPANY-A computer      1.2.3.161
COMPANY-A router        1.2.3.8 (also IPsec peer)
COMPANY-A has 1.2.3.0/24 with no subnetting.
COMPANY-B router        4.5.6.228 (also IPsec peer)
COMPANY-B computer #1   4.5.7.94 (this one has no issues)
COMPANY-B computer #2   4.5.7.29 (this one fails)
COMPANY-B has 4.5.6.0/23 subnetted in various ways.
COMPANY-B also has 9.10.11.0/24, but it is not involved in the issue.
What works:
The COMPANY-A computer 1.2.3.161 can communicate via the single IPsec
tunnel to COMPANY-B computer #1 4.5.7.94 without problems.
The "show crypto session detail" command shows Inbound/Outbound packets
flowing in the dec'ed and enc'ed positions.
What doesn't:
When the COMPANY-A computer 1.2.3.161 attempts to communicate
via the single IPsec tunnel with the COMPANY-B computer #2 4.5.7.29,
the COMPANY-A router eventually reports five of these messages:
Oct 9 15:24:54.327: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Oct 9 15:24:57.327: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Oct 9 15:25:03.327: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Oct 9 15:25:15.328: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Oct 9 15:25:39.329: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
Oct 9 15:26:27.328: IPSEC(epa_des_crypt): decrypted packet failed SA identity check
and the "show crypto session detail" shows inbound packets being dropped.
The COMPANY-A computer that opens the TCP connection never gets past the
SYN_SENT phase of the TCP connection whan trying to communicate with the
COMPANY-B computer #2, and the repeated error messages are the retries of
the SYN packet.
On the COMPANY-A side, this IPsec configuration has been set up on a 3745,
a 3725, and some 76xx routers were tried, all with similar behavior,
with packets from one far-end computer passing fine, and packets from
another far-end computer in the same netblock passing through the same
IPsec tunnel failing with the "failed SA identity" error.
The COMPANY-A computer directs all packets headed to COMPANY-B via the
COMPANY-A router at 1.2.3.8 with this set of route settings:
netstat -r -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window irtt Iface
4.5.7.0         1.2.3.8         255.255.255.0   UG        0 0          0 eth3
1.2.3.8.0       0.0.0.0         255.255.255.0   U         0 0          0 eth3
10.1.0.0        0.0.0.0         255.255.240.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth3
10.0.0.0        10.1.1.1        255.0.0.0       UG        0 0          0 eth0
0.0.0.0         1.2.3.1         0.0.0.0         UG        0 0          0 eth3
The first route line shown is selected for access to both COMPANY-B computers.
The COMPANY-A router (IPsec tunnel endpoint, 1.2.3.8) has this
configuration:
crypto isakmp policy 10
encr 3des
authentication pre-share
group 2
lifetime 28800
crypto isakmp key XXXXXXXXXXXXXXXXXXXXXXX address 4.5.6.228
crypto ipsec security-association lifetime seconds 86400
crypto ipsec transform-set COMPANY-B01 esp-3des esp-sha-hmac
crypto map COMPANY-BMAP1 10 ipsec-isakmp
description COMPANY-B VPN
set peer 4.5.6.228
set transform-set COMPANY-B01
set pfs group2
match address 190
interface FastEthernet0/0
ip address 1.2.3.8 255.255.255.0
no ip redirects
ip virtual-reassembly
duplex auto
speed auto
no cdp enable
crypto map COMPANY-BMAP1
ip forward-protocol nd
ip route 0.0.0.0 0.0.0.0 1.2.3.1
ip route 10.0.0.0 255.0.0.0 10.1.1.1
ip route 1.2.3.8.0 255.255.255.0 FastEthernet0/0
access-list 190 permit ip host 1.2.3.161 4.5.7.0 0.0.0.255
access-list 190 permit ip host 1.2.3.161 9.10.11.0 0.0.0.255
bridge 1 protocol ieee
One of the routers tried had this IOS/hardware configuration:
Cisco IOS Software, 3700 Software (C3725-ADVIPSERVICESK9-M), Version 12.4(25c),
RELEASE SOFTWARE (fc2)
isco 3725 (R7000) processor (revision 0.1) with 115712K/15360K bytes of memory.
Processor board ID XXXXXXXXXXXXXXX
R7000 CPU at 240MHz, Implementation 39, Rev 3.3, 256KB L2 Cache
2 FastEthernet interfaces
4 ATM interfaces
DRAM configuration is 64 bits wide with parity disabled.
55K bytes of NVRAM.
31296K bytes of ATA System CompactFlash (Read/Write)
250368K bytes of ATA Slot0 CompactFlash (Read/Write)
Configuration register is 0x2102
#show crypto sess
Crypto session current status
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 4.5.6.228 port 500
IKE SA: local 1.2.3.8/500 remote 4.5.6.228/500 Active
IPSEC FLOW: permit ip host 1.2.3.161 4.5.7.0/255.255.255.0
        Active SAs: 2, origin: crypto map
IPSEC FLOW: permit ip host 1.2.3.161 9.10.11.0/255.255.255.0
        Active SAs: 0, origin: crypto map
#show crypto sess det
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 4.5.6.228 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 4.5.6.228
      Desc: (none)
IKE SA: local 1.2.3.8/500 remote 4.5.6.228/500 Active
          Capabilities:(none) connid:1 lifetime:06:26:27
IPSEC FLOW: permit ip host 1.2.3.161 4.5.7.0/255.255.255.0
        Active SAs: 2, origin: crypto map
        Inbound: #pkts dec'ed 651 drop 16 life (KB/Sec) 4496182/23178
        Outbound: #pkts enc'ed 574 drop 2 life (KB/Sec) 4496279/23178
IPSEC FLOW: permit ip host 1.2.3.161 9.10.11.0/255.255.255.0
        Active SAs: 0, origin: crypto map
        Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
        Outbound: #pkts enc'ed 0 drop 0 life (KB/Sec) 0/0
The COMPANY-B device on their end of the IPsec VPN is a Juniper SSG1000
Version 6.1 (ScreenOS)
We only have a limited view into the Juniper device configuration.
What we were allowed to see was:
COMPANY-B-ROUTER(M)-> sh config | incl COMPANY-A
set address "Untrust" "oss-COMPANY-A-1.2.3.161" 1.2.3.161 255.255.255.255
set ike gateway "COMPANY-A-1-GW" address 1.2.3.8 Main outgoing-interface "ethernet2/1" preshare xxxxxxxxxxxxxxxxxxxxxx proposal "pre-g2-3des-sha"
set vpn "COMPANY-A-1-IKE" gateway "COMPANY-A-1-GW" no-replay tunnel idletime 0 proposal "g2-esp-3des-sha-28800"
set policy id 2539 from "Untrust" to "Trust" "oss-COMPANY-A-1.2.3.161" "9.10.11.0-24" "ANY" tunnel vpn "COMPANY-A-1-IKE" id 0x309a pair-policy 2500
set policy id 2500 from "Trust" to "Untrust" "9.10.11.0-24" "oss-COMPANY-A-1.2.3.161" "ANY" tunnel vpn "COMPANY-A-1-IKE" id 0x309a pair-policy 2539
set policy id 2541 from "Trust" to "Untrust" "4.5.7.0-24" "oss-COMPANY-A-1.2.3.161" "ANY" tunnel vpn "COMPANY-A-1-IKE" id 0x309b pair-policy 2540
set policy id 2540 from "Untrust" to "Trust" "oss-COMPANY-A-1.2.3.161" "4.5.7.0-24" "ANY" tunnel vpn "COMPANY-A-1-IKE" id 0x309b pair-policy 2541
COMPANY-B-ROUTER(M)->
I suspect that this curious issue is due to a configuration setting on the
Juniper device, but neither party has seen this error before. COMPANY-B
operates thousands of IPsec VPNs and they report that this is a new error
for them too. The behavior that allows traffic from one IP address to
work and traffic from another to end up getting this error is also unique.
As only the Cisco side emits any error message at all, this is the only
clue we have as to what is going on, even if this isn't actually an IOS
problem.
What we are looking for is a description of exactly what the Cisco
IOS error message:
IPSEC(epa_des_crypt): decrypted packet failed SA identity check
is complaining about, and if there are any known causes of the behavior
described that occur when running IPsec between Cisco IOS and a Juniper
SSG device. Google reports many other incidents of the same error
message (but not the "I like that IP address but hate this one" behavior),
and not just with a Juniper device on the COMPANY-B end, but for those cases,
not one was found where the solution was described.
It is hoped that with a better explanation of the error message
and any known issues with Juniper configuration settings causing
this error, we can have COMPANY-B make adjustments to their device.
Or, if there is a setting change needed on the COMPANY-A router,
that can also be implemented.
Thanks in advance for your time in reading this, and any ideas.

Hello Harish,
It is believed that:
COMPANY-B computer #1   4.5.7.94 (this one has no issues)
COMPANY-B computer #2   4.5.7.29 (this one fails)
both have at least two network interfaces, one with a public IP address
(which we are supposedly conversing with) and one with a RFC 1918 type
address.   COMPANY-B is reluctant to disclose details of their network or
servers setup, so this is not 100% certain.
Because of that uncertainty, it occurred to me that perhaps COMPANY-B
computer #2 might be incorrectly routing via the RFC 1918 interface.
In theory, such packets should have been blocked by the access-list on both
COMPANY-A router, and should not have even made it into the IPsec VPN
if the Juniper access settings work as it appears they should. So I turned up
debugging on COMPANY-A router so that I could see the encrypted and
decrypted packet hex dumps.
I then hand-disassembled the decoded ACK packet IP header received just
prior to the "decrypted packet failed SA check" error being emitted and
found the expected source and destination IP addresses (4.5.7.29 and 1.2.3.161),
in the unecapsulated packet. I also found the expected port numbers of the TCP
conversation that was trying to be established in the TCP header. So, it
looks like COMPANY-B computer #2 is emitting the packets out the right
interface.
The IP packet header of the encrypted packet showed the IP addresses of the
two routers at each terminus of the IPsec VPN, but since I don't know what triggers
the "SA check" error message or what it is complaining about, I don't know what
other clues to look for in the packet dumps.
As to your second question, "can you check whether both encapsulation and
decapsulation happening in 'show crypto ipsec sa'",   the enc'ed/dec'ed
counters were both going up by the correct quantities. When communicating
with the uncooperative COMPANY-B computer #2, you would also see the
received Drop increment for each packet decrypted. When communicating
with the working COMPANY-B computer #1, the Drop counters would not
increment, and the enc'ed/dec'ed would both increment.
#show crypto sess det
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 4.5.6.228 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 4.5.6.228
      Desc: (none)
IKE SA: local 1.2.3.8/500 remote 4.5.6.228/500 Active
          Capabilities:(none) connid:1 lifetime:07:59:54
IPSEC FLOW: permit ip host 1.2.3.161 4.5.7.0/255.255.255.0
        Active SAs: 2, origin: crypto map
        Inbound: #pkts dec'ed 376 drop 5 life (KB/Sec) 4458308/28784
        Outbound: #pkts enc'ed 401 drop 3 life (KB/Sec) 4458308/28784
Attempt a TCP communication to COMPANY-B computer #2...
show crypto sess det
Crypto session current status
Code: C - IKE Configuration mode, D - Dead Peer Detection
K - Keepalives, N - NAT-traversal, X - IKE Extended Authentication
Interface: FastEthernet0/0
Session status: UP-ACTIVE
Peer: 4.5.6.228 port 500 fvrf: (none) ivrf: (none)
      Phase1_id: 4.5.6.228
      Desc: (none)
IKE SA: local 1.2.3.8/500 remote 4.5.6.228/500 Active
          Capabilities:(none) connid:1 lifetime:07:59:23
IPSEC FLOW: permit ip host 1.2.3.161 4.5.7.0/255.255.255.0
        Active SAs: 2, origin: crypto map
        Inbound: #pkts dec'ed 376 drop 6 life (KB/Sec) 4458307/28753
        Outbound: #pkts enc'ed 402 drop 3 life (KB/Sec) 4458307/28753
Note Inbound "drop" changed from 5 to 6. (I didn't let it sit for all
the retries.)
#show crypto ipsec sa
interface: FastEthernet0/0
    Crypto map tag: COMPANY-BMAP1, local addr 1.2.3.8
   protected vrf: (none)
   local ident (addr/mask/prot/port): (1.2.3.161/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (4.5.7.0/255.255.255.0/0/0)
   current_peer 4.5.6.228 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 402, #pkts encrypt: 402, #pkts digest: 402
    #pkts decaps: 376, #pkts decrypt: 376, #pkts verify: 376
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 3, #recv errors 6
     local crypto endpt.: 1.2.3.8, remote crypto endpt.: 4.5.6.228
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0/0
     current outbound spi: 0xDF2CC59C(3744253340)
inbound esp sas:
      spi: 0xD9D2EBBB(3654478779)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2004, flow_id: SW:4, crypto map: COMPANY-BMAP1
        sa timing: remaining key lifetime (k/sec): (4458307/28600)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0xDF2CC59C(3744253340)
        transform: esp-3des esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2003, flow_id: SW:3, crypto map: COMPANY-BMAP1
        sa timing: remaining key lifetime (k/sec): (4458307/28600)
        IV size: 8 bytes
        replay detection support: Y
        Status: ACTIVE
     outbound ah sas:
     outbound pcp sas:
The "send" errors appear to be related to the tunnel reverting to a
DOWN state after periods of inactivity, and you appear to get one
each time the tunnel has to be re-negotiated and returned to
an ACTIVE state. There is no relationship between Send errors
incrementing and working/non-working TCP conversations to the
two COMPANY-B servers.
Thanks for pondering this very odd behavior.

How to configure OSPFv3 with VRF in IOS (a guide)

Hi everybody,
I recently found myself in need of configuring VRF segregated IPv6 routing with OSPFv3 in a pair of IOS 6500s. After a bit of research, I found that although the latest IOS releases for the 6500 (15.1(1)SY for the Sup720 and Sup2T) support configuring OSPFv3 on VRFs, Cisco has yet to release any documentation pertaining to its configuration other then command references. So, I thought I would share some of the pertinent and important details I discovered along the way to getting this working and collect them all in one place to help out anyone else who is trying to do this.
1. The first thing you need to do is turn it on. Make sure you have enabled IPv6 routing with the "ipv6 unicast-routing" command and IPv6 VRFs with the "mls ipv6 vrf" command. Without these enabled, everything you try that seems like it should work will fail.
2. You must use the new style VRF definition commands, the old "ip vrf <name>" commands are for IPv4 only. The new style of configuring the VRFs is "vrf definition <name>", under these VRFs you must specify the IP versions you want to run with the "address-family ipv4" and "address-family ipv6" commands. Also the command to place an interface into these VRFs is slightly different as well. On an interface, you must use the "vrf forwarding <name>" command instead of the old "ip vrf forwarding <name>" command.
3. For OSPFv3 instances, the VRF is defined after you enter the proccess by using the "address-family ipv6 unicast vrf <name>" command. OSPFv2 instances are still define the VRF at the same time as the process using the traditional "router ospf <proccess> vrf <name>" command.
4. After you get this all configured the "show ipv6 ospf" commands will no longer work. You need to use the "show ospfv3 vrf" commands instead.
I have attached a sample configuration of what I did. If anyone out there knows this better than I do, please correct anything I got wrong and/or add anything you think would be helpful. I would just like there to be a good source of info available for this subject, so people don't have to waste their time figuring this out the hard way.
Best Regards,
Greg

Greg,
Greate information.
Thanks for posting This!!!
Reza

VRF Lite running in the enterprise network

Hello everybody
Altough VRF lite (or Mulit VRF) seems to be a Service Provider Tecnology.
Does it make sense to use it in an Enterprise Network to isolate Networks from others ?
I cant find any design paper which describes if this would make sense.
What do you think. Is someone using it ? Does Cisco recommend it ?

Yes, VRF-lite SHOULD be used in an Enterprise environment to isolate the different security classes of devices.
In the past you would isolate different groups of users using Layer1, i.e. separate hubs either totally isolated or connected together by a router with ACLs. Since the PCs were only connected at shared 10 Mbit and the routers were such low performance and worms weren't really prevalent, this was not a big security issue at the time.
Then we migrated to VLANs, which essentially allowed Layer2 isolation within the same switch to provide the same functionality of separating different classes of users and to break up broadcast domains. Unfortunately, everyone connected the VLANs together at Layer3 with a router (or SVI) which essentially connected everything together again! And almost no one gets the ACLs right (if at all) to isolate the VLANs from each other. In fact, in most cases every VLAN can automatically reach every other VLAN from a Layer3 or IP perspective. This is a huge security problem.
Enter VRF-lite, essentially created by Cisco as their tag switching migrated to standards based MPLS and had a need to isolate Layer3 security domains from each other within the same switch (or router). Think of VLANs for routing tables. VRF stands for 'Virtual Route Forwarding', which basically means separate routing tables. Since VRF-lite is a per-switch feature (running locally to the switch) you will need to use other technologies to connect multiple VRF-lite switches together and keep the traffic isolated, see below.
What makes this so secure is that there is no command within the switch to connect different VRFs together within the same switch. You would need to connect a cable between two ports on the same switch configured in different VRFs to be able to communicate between them (recent IOS 12.2SR allows tunnels with different source VRFs but that is a corner case). The reason for this is simple, remember the basis for VRF (and VRF-lite) is for a service provider to isolate multiple customers from each other within the same switch. Just like an ATM, Frame-Relay, SONET, or Optical switch, the command line makes it very difficult (or impossible) to accidentally connect 2 different customers together.
Think about that. Even if someone was able to get ssh enable access to your switch (you aren't running telnet anymore, right?!), they CAN'T connect 2 VRFs together with any command.
And, yes, this is highly recommended by Cisco Engineers and is actually deployed far more than you think. I have VRF-lite running on at least 10 client's networks and those are LARGE networks. VRF-lite was integrated into the environment purely to solve a Layer3 security class isolation issue. I have used Layer3 dot1q trunks on c6500 switches and tunnels to keep isolated connectivity between VRFs between switches.
In Cisco speak, VRF-lite falls under the topic of 'Path Isolation' which is combined with other features that isolate traffic within the same network such as dot1q trunking, tunneling, VPN, policy-routing, and MPLS. Do a search on Cisco's web site for 'path isolation' and you will find a bunch of info.
See the following URLs for a good start:
http://www.cisco.com/en/US/netsol/ns658/networking_solutions_design_guidances_list.html
http://www.cisco.com/en/US/netsol/ns658/netbr0900aecd804a17db.html
http://www.cisco.com/en/US/netsol/ns658/networking_solutions_white_paper0900aecd804a17c9.shtml
As always, rate all posts appropriately, particularly those that provide value and don't be shy about following up with additional questions or comments.
Good luck!

VRF not work

Hello!
We have cat3550 12.1(19)EA1a and we want to setup VRF in next scheme:
cat3550------(inside)PIX(dmz)----r2600
------------tunnel1-------
r2600 is a exit point of all tunnels and is a point of connection VRF and global routing.
There are two subnets,which we want to connect each other and connect these subnets to the rest net.
we are using two tunnels to 2600 router and VRF
that are a VRF and EIGRP parts from our config:
ip vrf MMM
rd 1016:247
interface Tunnel1
ip vrf forwarding MMM
ip unnumbered Vlan247
tunnel source Loopback0
tunnel destination 192.168.240.254
interface Vlan247
ip vrf forwarding MMM
ip address 192.168.247.46 255.255.255.240
no ip redirects
router eigrp 1016
network 192.168.0.37 0.0.0.0
network 192.168.37.0 0.0.0.255
network 192.168.40.128 0.0.0.15
network 192.168.252.32 0.0.0.3
network 192.168.252.36 0.0.0.3
no auto-summary
eigrp router-id 192.168.0.37
no eigrp log-neighbor-changes
ip route 0.0.0.0 0.0.0.0 192.168.252.33
ip route 0.0.0.0 0.0.0.0 192.168.252.37 2
ip route vrf MMM 0.0.0.0 0.0.0.0 Tunnel1
ip route vrf MMM 192.168.247.48 255.255.255.248 Tunnel1
where 192.168.247.48 255.255.255.248 - another subnet in VRF
All nodes from cat3550 in vlan247 must go to inside nodes using VRF and tunnel, all others using usual routing (EIGRP).
So,we want to access mail server 192.168.7.33, which is located in inside net (not VRF), but not successfull.
As I see all packets from node in VLAN247 are go straight on to server (not via tunnel),and back packets go via PIX (because there are no subnets 192.168.247.48 255.255.255.248 and 192.168.247.32 255.255.255.240 in EIGRP routing, and PIX is a default routing point)
and I see PIX log message like this:
Deny tcp src inside:192.168.7.33/110 dst dmz:192.168.247.35/49384 by access-group "acl_inside"
(permit clause is from DMZ to INSIDE zone, not vice versa)
However when i do
telnet 192.168.7.33 110 /vrf MMM
from cat3550
it works fine!
and I see that packets go correctly via tunnel and then via PIX to server.
Accessing between subnets 192.168.247.48 255.255.255.248 and 192.168.247.32 255.255.255.240 is fine too! (why???)
I tried set
ip route vrf MMM 192.168.7.33 255.255.255.255 Tunnel1
but no effect.
What I do wrong? Why does it not work?
I hope I explain clearly.
Thanks!

I found that VRF work correctly when and only when destination host not in global routing (EIGRP in my case). But this happen with ip of nodes within VLAN, ip address of VLAN on cisco is access correctly anytime.
Why? Does anybody knows it?
help me,please!

VRF Best Practice: LAN only VRF, Mgmt VRF, Global Routing table or VRF?

I am setting up a routed LAN (not a WAN) environment on two 6500 switches (sup-720). My goal is to create 32 routed environments separated by logical firewalls (multi-context ASA's). So I want a âcoreâ router in each environment, and don't want to buy 32 pairs of 6500's-sorry Cisco.
Each of these environments are tied together by a core routing environment, running on the same pair of 6500's. No WAN MPLS is going on and I am trying to use VRF for each of the routed environments core router. The management functions of the 6500 shall run off the VRF Core router and ip range (the one that ties all the other VRF's together. Here is a simple diagram:
VRF1
||
FW1
||
VRFCOR
||
FW2
||
VRF2
So to go from VRF1 to VRF2, you traverse two firewalls and VRFCOR.
Several questions related to this design:
1) Am I nuts to use VRF's in this application?
2) Is there a better choice than VRF's to do what I want?
3) Should VRFCOR be the global routing table (IOW, not a VRF)? Or should be its own VRF? Another way to ask this is: Shall a router ever run entirely in VRF tables, or should there be at least one global table in use?
4) Are there problems with any management protocols on a VRF, such as NTP, AAA, SNMP, LOGGING, TELNET? Or have all those been worked out?
5) Any other suggestions?
TIA, Will

VRF is suited for such kind of an application. Refer to URL http://cisco.com/application/pdf/en/us/guest/netsol/ns171/c649/ccmigration_09186a0080851cc6.pdf to get an idea about the

VPDN PPTP server doesn't work after put it into an VRF instance

Originally we have one internet connection for our router which served as a PPTP server at the same time and everything worked well. Recently we got another internet connection, and we want it as a dedicated PPTP server interface. That means all the traffic except the PPTP data goes to the first internet connection. So we decide to use VRF (virtual routing forwarding) for the PPTP.
First attachment is the configuration that worked,
then is the broken configuration.
When connecting from a Windows client, the process would hang up at "verifying username and password". What's more, I used Wireshark and found that for the broken config, after pptp negotiations, the GRE data that contain ppp data cannot be exchanged, it seems the router cannot find way back for the GRE.

Thank you for your reminding me of this. I'am newly here, and I am really sorry that I've made you uneasy. But firstly, I doesn't think GFW is something officially documented in China's legislation. In fact, it is something the government tried to conceal but already known to all. So breaking through it is not illegal.
And what I want is just to get access to gmail, wikipedia, twitter, facebook, instagram and so on. And what's more, GFW has once blocked github and now, it blocks google entirely. I am a technical ecstasy not a politician. I just want to learn more freely.
Thank you all the way. And I feel fairly good with such a warm-hearted community. The arch wiki has really teached me a lot. Thank you.

Not all Prefixes in VRF Tables are Reachable?

Hello,
During my studies with an MPLS VPN [MP-BGP] lab I found something unexpected. I wonder if I am mistaken in my comprehension or if this normal:
Not all prefixes in a VRF Table are pingable/reachable ?
Seems that in the standard routing tables, if a prefix is there, then it is pingable/reachable.
I've attached a sketch to help illustrate the lab I have set up and what I found.
Below is output from ABR2 in the lab showing inability to ping 154.0.0.154, even though it is in the VRF IT table. After "mpls ip" is configured on the "*" interface of Core2 the LDP Adjacency between Core2 and ABR2 comes up and ABR2 can ping everything in the VRF IT table, including 154.0.0.154
Just seems like this is a "Gotcha" for one just coming into the world of MPLS VPN. Just because a Prefix is in the VRF Table does not mean it is reachable?
Thanks for any input.

Hello Greg,
Behavior which you have experienced is completly normal in MPLS environment. There is big difference between forwarding IP packets and MPLS frames.
If you disable "mpls ip" on some interface along your LSP, LSP is broken and traffic is lost. MPLS VPN packets have two labels:
- IGP label - according this label, packet is forwarded from ingress PE to egress PE
- VPN label - based on this label, egress PE can put packet to particular VRF
VPN label is known only to ingress and egress PE, if LSP is broken, IGP label is stripped off in the middle of the LSP and packet is forwarded based on VPN label. But as I said, intermediate routers do not know what to do with this packet, because label is unknow to them so packet is discarded.
I hope this cleared some things for you.
To further studies I would recommend this book:
http://www.ciscopress.com/store/mpls-fundamentals-9781587051975
Best Regards
Please rate all helpful posts and close solved questions

VRF and FTP Server

I have a weird problem with VRF and FTP Server. I have a lab setup whereby two VRFs Client1 and Client2 are created. Both the VRFs are in the same subnet. I have configured FTP-Server and TFTP-Server on this router. TFTP-Server works perfectly fine from both the networks. But for FTP-Server, I can login in to the FTP Server and authenticate positively. But when I try to do listing of directory, it gives a error "can't bind data".
The web access to this router also works perfectly fine.
Any idea why FTP fails.
Before configuring vrf, the FTP server did work fine.
Any idea why. here's the config :
interface FastEthernet0/0.371
description Client1
encapsulation dot1Q 371
ip vrf forwarding client1
ip address 10.0.1.1 255.255.255.0
interface FastEthernet0/0.372
description Client2
encapsulation dot1Q 372
ip vrf forwarding client2
ip address 10.0.1.1 255.255.255.0

Ohhhhhhhh!!!
I'm even more convinced its a passive/active problem with the ftp control channel. Did you try the gentleman's suggestion of passive ftp?? What's happening is that from a client on one vrf, you're attempting to terminate the ftp session in a router whom is in the second vrf. The ftp data session isn't vrf-aware from the sound of it, hence my question about what device models and IOS you're using.
But I agree, it's getting complicated enough that sounds like TAC-time. My bet is something isn't vrf-aware to the point that the data is lost. For instance, to ping from one device to another from _within_ a vrf router instance, you have to use the keyword "vrf" like "ping vrf VRF_Name src dest".
In your situation, your source is on one vrf while the destination is _within_ the second vrf, not just simply the IP packet being routed from vrf1-client (like a Windows PC) to vrf2-server (like a Unix ftp server).
I'd be interested in hearing their solution.
-Jeff

NAT is not working for VRF partially

Hello!
I have a diagram like this:
VRF_A and VRF_B have overlapping addressing plans from series 192.168.x.x.
As routing protocol in both of VRFs adopted RIP (I tried all, but effect much the same).
The closest to PE1 network is 172.16.0.0/24.
PE1:
ip vrf VRF_A rd 65001:1 route-target export 65001:1 route-target import 65001:1ip vrf VRF_B rd 65001:2 route-target export 65001:2 route-target import 65001:2ip nat inside source list 10 interface FastEthernet0/0 vrf VRF_A overloadip nat inside source list 10 interface FastEthernet0/0 vrf VRF_B overloadip route vrf VRF_A 0.0.0.0 0.0.0.0 FastEthernet0/0 172.16.0.1 globalip route vrf VRF_B 0.0.0.0 0.0.0.0 FastEthernet0/0 172.16.0.1 globalinterface FastEthernet0/0 ip address 172.16.0.24 255.255.255.0 ip nat outside duplex fullinterface FastEthernet1/0 ip vrf forwarding VRF_A ip address 192.168.0.2 255.255.255.0 ip nat inside duplex full
interface FastEthernet4/0 ip vrf forwarding VRF_B ip address 192.168.0.2 255.255.255.0 ip nat inside duplex full
When I try ti ping 172.16.0.1 from CE11, CE21 and from VRF_A and VRF_B on PE1 - all if fine! NAT is performed and ping is OK.
But when I tried to ping from others (PE2 and CE21 and CE22) NAT is not performed, I see 192.168.x.x at Internet Router and ping is failled.
I'm in stupor. What could it be??? And how to avoid this situation? Are there "exits"?
I forgot to mention that there is a full connectivity inside both of VRFs. Routing protocols and redistribution work fine.
Kind regard,
Ellad

It's wrong:
PE1interface toward P1 ip nat insideinterface toward P2 ip nat inside
Here is PE1:Current configuration : 2829 bytes
version 12.3
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
hostname PE1
boot-start-marker
boot-end-marker
no aaa new-model
ip subnet-zero
ip vrf VRF_A
rd 65001:1
route-target export 65001:1
route-target import 65001:1
ip vrf VRF_B
rd 65001:2
route-target export 65001:2
route-target import 65001:2
ip cef
ip audit po max-events 100
mpls label protocol ldp
interface Loopback0
ip address 10.0.2.1 255.255.255.255
interface FastEthernet0/0
ip address 172.16.0.24 255.255.255.0
ip nat outside
duplex full
interface FastEthernet1/0
ip vrf forwarding VRF_A
ip address 192.168.0.2 255.255.255.0
ip nat inside
duplex full
interface FastEthernet2/0 ip address 10.0.23.1 255.255.255.0
duplex full
tag-switching mtu 1512
tag-switching ip
interface FastEthernet3/0
ip address 10.0.24.1 255.255.255.0
duplex full
tag-switching mtu 1512
tag-switching ip
interface FastEthernet4/0
ip vrf forwarding VRF_B
ip address 192.168.0.2 255.255.255.0
ip nat inside
duplex full
router ospf 1
log-adjacency-changes
network 10.0.0.0 0.255.255.255 area 0
router rip
version 2
no auto-summary
address-family ipv4 vrf VRF_B
redistribute bgp 65001 metric 1
network 192.168.0.0
no auto-summary
exit-address-family
router bgp 65001
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.0.5.1 remote-as 65001
neighbor 10.0.5.1 update-source Loopback0
address-family vpnv4
neighbor 10.0.5.1 activate
neighbor 10.0.5.1 next-hop-self
neighbor 10.0.5.1 send-community both
exit-address-family
address-family ipv4 vrf VRF_B
redistribute static
redistribute rip
no auto-summary
no synchronization
exit-address-family
address-family ipv4 vrf VRF_A
no auto-summary
no synchronization
exit-address-family
ip nat inside source list 10 interface FastEthernet0/0 vrf VRF_A overload
ip nat inside source list 10 interface FastEthernet0/0 vrf VRF_B overload
ip classless
ip route vrf VRF_A 0.0.0.0 0.0.0.0 FastEthernet0/0 172.16.0.1 global
ip route vrf VRF_B 0.0.0.0 0.0.0.0 FastEthernet0/0 172.16.0.1 global
no ip http server
no ip http secure-server
ip extcommunity-list 1 permit soo 65002:901
access-list 1 deny   10.1.8.1
access-list 1 deny   10.0.8.1
                          access-list 1 deny   10.1.2.1
access-list 1 deny   10.0.2.1
access-list 1 permit any
access-list 10 permit 192.168.0.0 0.0.255.255
access-list 10 permit 192.168.1.0 0.0.0.255
route-map rm-soo permit 10
set extcommunity soo 65002:901!
route-map rm-soo-action deny 10
match extcommunity 1
route-map rm-soo-action permit 20
match ip address 1
gatekeeper
shutdown
line con 0
exec-timeout 144 0
logging synchronous
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
end
1.0.5.1 is Loopback0 of P3. It's a route-reflector for all PEs. I study.
And all what you see above - Dynamipses. Internet router - real Ubuntu server.

What is vrf

Similar Messages

Maybe you are looking for