Thursday, February 6, 2014

NTS: VRF

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



No comments:

Post a Comment