VRF
VRF Basic Configuration
IOS
ip vrf VPN-A
rd 100:1
route-target export 100:1
route-target import 100:1
!
vrf definition VPN-B
rd 100:2
address-family ipv4
route-target export 100:2
route-target import 100:2
exit-address-family
address-family ipv6
route-target export 100:2
route-target import 100:2
exit-address-family
IOS-XR
vrf VPN-C
address-family ipv4 unicast
import route-target
100:3
export route-target
100:3
address-family ipv6 unicast
import route-target
100:3
export route-target
100:3
!
router bgp 100
vrf VPN-C
rd 100:3
Prefer to use the "vrf definition" command to configure VRFs. Always include an address-family, most probably the ipv4 one.
You can have different import/export RTs per address family. If you have common ones, then you can define them directly under the vrf definition.
IOS-XR requires the VRF RD config under the BGP process.
You can use the "rd auto" command in IOS -XR in order to automatically create unique RDs per VRF.
IOS-XR
router bgp 100
vrf VPN
rd auto
If you don't define any export RTs for a VRF on the local PE, then the prefixes will by default get dropped when they are transferred to the remote PE.
You can view all routing tables (global and VRF ones) by using the command "sh ip route vrf *".
On a router that acts as a default gateway, the following can be configured if the next-hop is in the global routing table and you want to have the static route inside the VRF but pointing to the global routing table.
IOS
ip route vrf VPN 0.0.0.0 0.0.0.0 1.1.1.1 global
You can change the default label allocation (if you want to decrease label usage) for all VRFs or a specific VRF using the following command:
IOS
R1(config)#mpls label mode vrf VPN protocol bgp-vpnv4 ?
per-prefix Per prefix label (default)
per-vrf Per VRF label for entire VRF
vrf-conn-aggr Per VRF label for connected and BGP aggregates in VRF
Export RT per Prefix
You can use an export map in order to set different export RTs per prefix.
IOS
vrf definition VPN-A
rd 100:1
!
address-family ipv4
export map R1-MAP
exit-address-family
!
route-map R1-MAP permit 10
match ip address R1-ACL
set extcommunity rt 2.2.2.2:11 2.2.2.2:111
!
ip access-list standard R1-ACL
permit 1.1.1.1
!
IOS-XR
vrf VPN-A
address-family ipv4 unicast
export route-policy R1-RPOLICY
!
route-policy R1-RPOLICY
if destination in (1.1.1.1/32) then
set extcommunity rt (2.2.2.2:11, 2.2.2.2:111)
endif
end-policy
In the IOS-XR route-policy you must use destination in order to match the required prefix. Also you can use parenthesis whenever you need to group parameters, like the multiple RTs.
If you initially have no export RTs and later decide to add some through an export map, then you must reset the VPNv4 BGP sessions in order to have the BGP routes get the new RTs immediately.
Import global routes into VRF
You have the option of importing various global routes into a specific VRF, while at the same time limiting the number of them.
IOS
vrf definition VPN_A
rd 100:1
route-target export 100:1
route-target import 100:1
!
address-family ipv4
import ipv4 unicast 5 map GLOBAL-TABLE-ROUTEMAP
exit-address-family
!
route-map GLOBAL-TABLE-ROUTEMAP permit 10
match ip address prefix-list PREFIX-LIST
!
ip prefix-list PREFIX-LIST seq 5 permit 4.4.4.4/32
match ip address prefix-list PREFIX-LIST
IOS
R2#sh bgp vpnv4 unicast all
BGP table version is 8, local router ID is 2.2.2.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, m multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:1 (default for vrf VPN_A)
Import Map: GLOBAL-TABLE-ROUTEMAP, Address-Family: IPv4 Unicast, Pfx Count/Limit: 1/5
*> 1.1.1.1/32 10.1.2.1 0 32768 i
*> 4.4.4.4/32 20.2.4.4 10 32768 i
*> 10.1.2.0/24 0.0.0.0 0 32768 i
*>i10.19.20.0/24 19.19.19.19 0 100 0 i
*>i20.20.20.20/32 19.19.19.19 0 100 0 i
R2#sh bgp vpnv4 unicast all 4.4.4.4/32
BGP routing table entry for 100:1:4.4.4.4/32, version 8
Paths: (1 available, best #1, table VPN_A)
Not advertised to any peer
Local, imported path from 4.4.4.4/32
20.2.4.4 from 0.0.0.0 (2.2.2.2)
Origin IGP, metric 10, localpref 100, weight 32768, valid, external, no-import, best
The global route to be imported must exist in the global BGP table (existence in RIB doesn't matter).
No RTs or other attributes will be assigned to the imported prefixes. Use the route-map set commands to configure those.
In latest IOS releases (>15.x) you have to option of doing the opposite too, export prefixes from a VRF into the global BGP table.
The commands "import/export map" (which are different from the above) are used to filter the VRF <=> MP-BGP prefixes, while the commands "import/export ipv4 unicast" are used to leak routes between the VRF and the global BGP table.
Inbound VPN Prefix Filtering due to RTs
In VPNv4/v6 BGP setups, all BGP VPN prefixes are checked against the local RT import policies and if there is no match found, then the prefix is discarded (in order to keep the BGP table small).
Route-Reflectors have this filter disabled by default, because they need all the prefixes to accommodate all possible PEs. In order to disable it manually on other routers, you can use the following commands.
IOS
router bgp 100
no bgp default route-target filter
IOS-XR
router bgp 100
address-family vpnv4 unicast
retain route-target all
IOS-XR supports also the selective filtering of RTs by using a policy that matches specific RTs.
IOS-XR
router bgp 100
address-family vpnv4 unicast
retain route-target route-policy RT-POLICY
!
route-policy RT-POLICY
if extcommunity rt matches-any (100:1, 100:2) then
pass
else
drop
endif
Multi-VRF (VRF-Lite)
It allows a logical separation of a CE router into multiple VRFs, without the need for MPLS/MP-BGP. Using MPLS Multi-VRF you can extend the LSPs to the CE and all routing domains that the CE supports.
Usually, a router with Multi-VRF is shared by several customers and each customer has their own routing table.
Characteristics
- one or more VRFs configured and assigned to interfaces
- no MPLS configured
- no BGP VPNv4 configured
- no RTs under "vrf definition" required on IOS
- no RDs under "bgp vrf" required on IOS-XR
Configuration Steps
- Configure VRFs on the PE and the CE
- Configure the routing protocol for each VRF on the CE towards each customer
- Configure BGP or IGP as PE-CE protocol for each VRF
- Configure labeling either with BGP+Label or IGP+LDP (if required)
Special care must be taken in case of using OSPF as PE-CE protocol, because due to setting the DN bit by default on specific routes advertised from PE to CE, these routes wouldn't be installed in the Multi-VRF CE's routing table.
Always prefer to use BGP as PE-CE, due to its simpler configuration and better filtering.
Traffic classification into a VRF
- One VRF per interface
- Classic method (IOS, IOS-XR)
- Multiple VRFs per interface
- Multi-VRF Selection Using Policy-Based Routing (IOS)
- match an ip access-list
- VRF Selection Based on Source IP Address (IOS)
- match the source ip address
- VRF-Autoclassify (IOS)
- match the directly connected prefix
- ACL Based Forwarding with VRF Next-Hop (IOS-XR)
- match an ip access-list
Classic Method
IOS
interface X
ip vrf forwarding VPN-A
!
interface X
vrf forwarding VPN-B
IOS-XR
interface X
vrf VPN-C
Multi-VRF Selection Using Policy-Based Routing
It allows a specific interface on a PE router to route packets to different VPNs based on various match criteria defined in an ip access list or on packet length.
IOS
interface X
ip vrf receive VPN-A
ip vrf receive VPN-B
ip vrf receive VPN-C
ip address 1.1.1.1 255.255.255.0
ip policy route-map VRF-SELECTION-PBR
ip access-list standard VPN-A-ACL
permit 1.1.2.2
ip access-list standard VPN-B-ACL
permit 1.1.3.3
ip access-list standard VPN-C-ACL
permit 1.1.4.4
!
route-map VRF-SELECTION-PBR permit 10
match ip address VPN-A-ACL
set vrf VPN-A
!
route-map VRF-SELECTION-PBR permit 20
match ip address VPN-B-ACL
set vrf VPN-B
!
route-map VRF-SELECTION-PBR permit 30
match ip address VPN-C-ACL
set vrf VPN-C
Limitations
- multicast is not usually supported by PBR
VRF Selection Based on Source IP Address
It allows a specific interface on a PE router to route packets to different VPNs based upon the source IP address of the packets. It's supported only on very specific hardware.
IOS
vrf selection source 1.1.1.0 255.255.255.0 vrf VPN-A
vrf selection source 2.2.2.0 255.255.255.0 vrf VPN-B
!
int X
ip vrf select source
ip vrf receive VPN-A
ip vrf receive VPN-B
Limitations
- supported by limited hardware
- performance can degrade with longer subnet masks
If it's not supported by the router, you'll get the following output:
R1(config)#vrf selection source 1.1.1.0 255.255.255.0 vrf VPN-A
% VRF Select: failed to add config
VRF-Autoclassify
It allows a specific interface on a PE router to route packets to different VPNs based on the ip addresses assigned to directly connected hosts.
At the same time it also enables certain types of Policy Based Routing (PBR) to be created dynamically without configuring all the related route maps and access lists. More specifically it enables the dynamic configuration of policies that are required for the mapping of packets to the VRFs, depending on whether the source address of the packet belongs to those connected routes.
IOS
interface X
ip address 1.1.1.1 255.255.255.0 secondary vrf VPN-A
ip address 1.1.2.1 255.255.255.0 secondary vrf VPN-B
ip address 2.2.2.2 255.255.255.0
ip vrf autoclassify source
!
interface Y
ip vrf forwarding VPN-A
ip address 10.10.10.1 255.255.255.0
!
interface Z
ip vrf forwarding VPN-B
ip address 20.20.20.1 255.255.255.0
Limitations
- any directly connected hosts must not run routing protocols
- the router that is enabled with the VRF-Autoclassify feature must not run routing protocols
- applies only to unicast packets
ACL Based Forwarding (ABF) with VRF Next-Hop
It allows packet arriving on ingress VRF to get routed on an egress interface which is in a different VRF based on various match criteria defined in an ip access list.
So you actually specify a nexthop VRF instead of a specific IP address for the nexthop. When this config is enabled, packet destination lookup will be performed in the ABF Nexthop VRF.
IOS-XR
interface X
ipv4 address 10.10.10.10 255.255.255.0
vrf VPN-A
ipv4 access-group ABF-ACL ingress
!
ipv4 access-list ABF-ACL
permit ipv4 1.1.2.2 0.0.0.0 any nexthop1 vrf VPN-A
permit ipv4 1.1.3.3 0.0.0.0 any nexthop1 vrf VPN-B
permit ipv4 1.1.4.4 0.0.0.0 any nexthop1 vrf VPN-C
Limitations
- applies only to ASR9k and CRS running IOS-XR
