Allied Telesis C613-16164-00 User Manual

Technical Guid e
How To |
Configure VRF-lite

Introduction

In IP-based networks, VRF stands for Virtual Routing and Forwarding. This technology allows multiple routing domains to co-exist within the same device at the same time. As the routing domains are independent, overlapping IP addresses can be used without causing conflict. In large service provider networks, virtual routing and forwarding is used in conjunction with MPLS - Multi Protocol Label Switching - to separate each customer’s traffic into its own wide area VPN. VRF is also known as VPN Routing and Forwarding (when used with MPLS), and is also known as Multi-VRF.

What is VRF-lite?

VRF-lite is VRF without the need to run MPLS in the network. VRF-lite is used for isolating customer networks - it allows multiple secure customer routing domains to co-exist in one physical device simultaneously, which remain completely isolated from each other.
VRF-lite also allows the re-use of IP addresses on the same physical device. An IP address range in one VLAN used in one VRF domain can simultaneously be used in another VLAN in a different VRF domain within the same device. While VRF-lite will segregate traffic from different customers/clients, VRF-lite can also allow for route leakage between VRF domains (inter-VRF communication), by using static inter-VRF routes and/or dynamic route leakage via BGP and associated route maps. This provides filtered access from one VRF routing domain to another where the IP address ranges do not overlap.
This How to Note begins with a description of VRF-lite’s key features and the generic commands used to configure VRF-lite. There are a number of simple configuration examples provided to illustrate its use with OSPF, RIP, and BGP routing protocols. This is followed with a configuration breakdown of a complex inter-VRF scenario, which includes overlapping IP addresses and a range of routing protocols. Dynamic inter-VRF communication between the global VRF domain and a VRF instance is also explained. Finally, a shor t list of diagnostics commands are provided to help troubleshoot VRF-related issues.
C613-16164-00 REV E
alliedtelesis.com
x
Introduction

Who should read this document?

This document is aimed at advanced network engineers.

Which products and software version does it apply to?

The information provided in this document applies to:
SwitchBlade AT-x908 and AT-x900 series switches running 5.4.1 and above.
x610 switches running AlliedWare+ version 5.4.2 and above.
Note: VRF -lite is not supported in the x600 series switch.

Software feature licenses

The VRF-lite feature requires a special software license. Without a proper license installed, configuring VRFs is not possible. A VRF-lite feature license key is distributed in the Advanced Layer 3 License Bundle that allows up to 8 VRF-lite instances to be configured.
The number of configurable VRF-lite instances can be increased via an additional VRF-lite-63 license.
The Advanced Layer 3 License Bundle containing the VRF-lite feature and the additional VRF­lite-63 license are available through the AW+ licensing web portal (http:// licensing.alliedtelesis.com/).
A VRF-lite-63 license requires an Advanced Layer 3 License Bundle to work.
Note: Enabling multiple VRFs means there will be more routing entries on the device system-
wide. This may affect the number of routes used by BGP or OSPF specified by the licence key on the device.

Command summary

All the existing CLI commands available in the current non-VRF environment are available with no change.
Page 2 | Configure VRF-lite
Contents
Introduction
Introduction .............................................................................................................................................................................1
What is VRF-lite? .........................................................................................................................................................1
Who should read this document? .....................................................................................................................2
Which products and software version does it apply to?......................................................................2
Software feature licenses........................................................................................................................................2
Command summary .................................................................................................................................................2
Glossary.....................................................................................................................................................................................3
Understanding VRF-lite.....................................................................................................................................................4
VRF-lite security domains .......................................................................................................................................5
Route table and interface management with VRF-lite...........................................................................5
Inter-VRF communication....................................................................................................................................... 7
Static and dynamic inter-VRF routing...............................................................................................................8
VRF-lite features in AW+.......................................................................................................................................9
Route limiting per VRF instance.......................................................................................................................10
VRF-aware utilities within AW+...................................................................................................................... 10
Configuring VRF-lite .........................................................................................................................................................12
Static inter-VRF routing......................................................................................................................................... 16
Dynamic inter-VRF communication explained..................................................................................................17
The Forwarding Information Base (FIB) and routing protocols.....................................................17
Inter-VRF communication via BGP.................................................................................................................19
How VRF-lite security is maintained ............................................................................................................. 23
Simple VRF-lite configuration examples ...............................................................................................................24
Multiple VRFs without inter-VRF communication..................................................................................24
Dynamic inter-VRF communication with RIP routing to external peers..................................27
Dynamic inter-VRF communication with BGP routing to external peers ...............................28
Dynamic inter-VRF communication with OSPF routing to external peers ............................29
Inter-VRF configuration examples with Internet access ..............................................................................32
Configuring a complex inter-VRF solution..........................................................................................................43
Network description.............................................................................................................................................. 43
Configuration breakdown ...................................................................................................................................45
VCStack and VRF-lite ......................................................................................................................................................70
Sharing VRF routing and double tagging on the same port ............................................................ 74
Dynamic inter-VRF routing between the global VRF domain and a VRF instance...................... 77
BGP configuration tips...........................................................................................................................................78
Dynamic inter-VRF communication with i-BGP routing to external peer...............................80
Dynamic inter-VRF communication with e-BGP routing to external peer .............................81
Route Limits..........................................................................................................................................................................83
Configuring static route limits ...........................................................................................................................83
Configuring Dynamic route limits ................................................................................................................... 84
VRF-lite usage guidelines ...............................................................................................................................................86
Useful VRF-related diagnostics command list ................................................................................................... 87
Configure VRF-lite | Page 3

Glossary

ACRONYM DESCRIPTION
AS Autonomous System
ACL Access Control List
Glossary
BGP
FIB Forwarding Information Base
MPLS
OSPF Open Shortest Path First
RIP
VPN Virtual Private Network
VR
VRF Vir tual Routing and Forwarding
VRF-lite
CE Customer edge
PE
RD Route Distinguisher
RT
VCStack Virtual Chassis Stacking
Border Gateway Protocol
Multi-Protocol Label Switching
Routing Information Protocol
Virtual Router
VRF without MPLS network
Provider edge
Route Target
Page 4 | Configure VRF-lite
Understanding VRF-lite

Understanding VRF-lite

The purpose of VRF is to enable separate IP networks, possibly using overlapping IP addresses, to share the same links and routers. IP traffic is constrained to a set of separate IP Virtual Private Networks (VPNs). These VPNs provide a secure way for a service provider to carry multiple customers’ IP networks across a common infrastructure. The different customers’ IP networks are able to operate in complete isolation from each other, so there is no requirement for them to use separate IP address ranges, and there is no leakage of traffic from one VPN to another, unless specifically requested.
A full VRF solution commonly involves different portions of the IP networks being connected to each other by an MPLS backbone network. The separate IP networks will be allocated different tags in the MPLS network. So the full VRF solution involves not only managing multiple separate IP networks within the same routers, but also a network-to-MPLS tag mapping process.
In the full VRF solution a distinction is made between Customer Edge (CE) routers and Provider Edge (PE) routers. CE routers aggregate the separate IP networks of the ser vice provider’s different clients. PE routers connect the IP networks to the MPLS backbone.
VPN 1
Customer A
CE
VPN 2
Customer B
PE
MPLS
network
MPLS-VRF
device
CE = Customer edge device PE = Provider edge router
VRF-lite is a subset of the full VRF solution. In a VRF-l
PE
MPLS-VRF
device
CE
ite solution there are multiple IP
VPN 1
Customer A
VPN 2
Customer B
networks sharing the same routers, but no MPLS core is involved. So, VRF-lite is just the customer edge router part of VRF, without the provider edge router part.
VRF-lite facilitates multiple separate routing tables within a single router - one routing table associated with each of the customer VPNs connected to the device. Multiple VRF instances are defined within a router. One or more Layer 3 interfaces (VLAN) are associated with each VRF instance forming an isolated VRF routing domain. A Layer 3 interface cannot belong to more than one VRF instance at any time.
Configure VRF-lite | Page 5
Understanding VRF-lite
PC1
PC2
SW
PC5
PC6
vlan1 1.1.1.1/24
PC3
PC4
Company A
VRF green
VRF blue
VRF red
vlan2 10.1.1.1/8
vlan6 10.1.1.1/24
vlan5 1.1.1.1/24
vlan3 1.1.1.1/24
vlan4 10.1.1.1/16
Company B
Company C

VRF-lite security domains

VRF-lite provides network isolation on a single device at Layer 3. Each VRF domain can use the same or overlapping network addresses, as they have independent routing tables. This separation of the routing tables prevents communication to Layer 3 interfaces in other VRF domains on the same device. Each Layer 3 interface belongs to exactly one VRF instance and traffic between two Layer 3 interfaces on the same VRF instance is allowed as normal. But by default, interfaces in other VRF instances are not reachable as no route exits between the interfaces unless explicitly configured via Inter-VRF routing.
For example, on a device three VRF instances (VRF red, VRF green and VRF blue) are configured for three different companies. Devices PC1 and PC2 from Company A can communicate normally within the confines of VRF red, but none of PC1’s and PC2’s traffic can be seen by other devices in VRF green and VRF blue.

Route table and interface management with VRF-lite

A key feature that VRF-lite introduces to a router is the existence of multiple IP route tables within the one router.
By default, before any VRF is configured, a router IP interfaces of the router will be stored in this one table. As VRF instances are configured on the router, the original route table remains. This default route table, and its associated IP interfaces, are then referred to as the default global VRF domain.
Interface management with VRF
Each network interface can belong to only one VRF. As mentioned above, initially every interface is in the default global VRF domain. As Layer 3 interfaces are moved to the created VRF instances, they are removed from the global VRF domain, so the global VRF domain manages a decreasing set of Layer 3 interfaces.
will have one route table, and routes via all
Page 6 | Configure VRF-lite
Understanding VRF-lite
When a Layer 3 interface is moved to a VRF instance from the default global VRF domain, or when a Layer 3 interface is moved from one VRF instance to another via command, the interface name and id (ifindex) are never changed as a result of the interface movement. However IP configuration on the interface in the previous VRF is unset (removed) before moving the interface to a new VRF.
ARP entries associated with the Layer 3 interface are cleared when the interface is moved from one VRF instance to another. In addition (static and dynamic) ARP entries are VRF aware, as the same IP address can be used in other VRF instances.
Adding a VRF-aware static ARP
awplus(config)#arp ? A.B.C.D IP address of the ARP entry log Arp log vrf VRF instance
awplus(config)#arp vrf <name> ? A.B.C.D IP address of the ARP entry
Route management with VRF
Each VRF instance maintains its own IPv4 routing table independent from the routing table
of the global VRF domain or other VRFs.
Routing entries can be added statically by user command or dynamically by a routing
protocol module such as BGP, OSPF, or RIP within the VRF instance. Use of a dynamic routing protocol allows for each VRF network to maintain a consistent routing table across all the devices within the VRF network.
The way that each routing is able to define a separate instance of itself on multiple VRF
instances varies from protocol to protocol:
For BGP, one BGP routing instance will be running for an Autonomous System in the
global VRF domain and individual BGP routing tables will be managed per VRF by using the address-family feature. One address-family is created for each VRF instance.
For OSPF, one OSPF routing instance is configurable per VRF, and one OSPF instance
is configurable within the global VRF domain.
For RIP, one RIP routing instance will be running in the default global VRF domain and
individual RIP routing tables will be managed per VRF by using the address-family feature. One address-family is created for each VRF instance.
Note: The command show ip route displays the routes associated with each VRF instance.
gure VRF-lite | Page 7
Confi
Understanding VRF-lite
Internal Company
Network
VRF red
(Wi-Fi)
VRF green
(company)
VRF shared
Internet
Wi-Fi access

Inter-VRF communication

Whilst the prime purpose of VRF-lite is to keep routing domains separate from each other, there are cases where you do want some communication between VRFs.
An example to consider is multiple 'clients' requiring shared Internet access. In this case a VRF instance can be created for each, providing secure and separate routing. Whilst overlapping IP addresses could be used with this scenario, only one instance of each overlapping address range will be able to access the Internet for the simple reason that when return traffic comes back from the Internet to an address in one of the overlapped subnets, the VRF aware device must have only one choice for which instance of that subnet to send that return traffic to.
A distinct shared VRF is utilised to allow sharing of the Internet connection. The shared VRF is actually just another VRF instance; it has no special VRF properties.
In the example below, each of the red and green VRFs need inter-VRF communication with the shared VRF. This is achieved by selectively leaking routes between the shared VRF and the other two VRFs, and vice-versa. The selective leaking can use statically configured routes or dynamic route import/export via the BGP protocol.
For example, a company may wish to segregate their netw the Internet for visitors to the company, whilst preventing the visitors from accessing the internal company network. The users in internal company network and visitors in the Wi-Fi network are able to share a single common Internet connection.
Internal company and Wi-Fi networks are isolated in Layer 3 on the same device by using different VRFs, but they want to access the Internet by using the same network interface on VRF shared. To make it work with dynamic route import/export, VRF green (company VRF) needs to import routes from VRF shared to access the Internet and some selected routes from VRF green need to be exported to VRF shared. Similar configuration is needed for VRF red (Wi-Fi VRF) for importing/exporting routes between VRF red and VRF shared.
As a result traffic flows between VRF green and VRF shared and between VRF red and VRF shared but not between VRF green and VRF red.
Page 8 | Configure VRF-lite
ork and provide Wi-Fi access to
Understanding VRF-lite

Static and dynamic inter-VRF routing

As mentioned above, "Inter-VRF communication" on page 8, in some circumstances it is required to (selectively) allow traffic between two interfaces that are not in the same VRF. This will be useful if there is common network equipment (e.g. Internet connections or shared resources) that multiple VRFs need to share.
Inter-VRF routing is achieved by statically or dynamically taking a route entry and its next-hop interface from one VRF, and adding it into the routing table of another. A dynamic inter-VRF route can be added by using the BGP route import/expor t feature. A static inter-VRF route can be added by a user command. For more information on static routing, see "Static inter-
VRF routing" on page 17.
Static and dynamic inter-VRF communication can be used simultaneously or separately. Dynamic inter-VRF communication is only achieved via use of the BGP routing protocol. OSPF and RIP cannot be used to achieve inter-VRF communication.
Internally transferring routes between VRF instances is quite separate from the sharing of routes of a specific VRF routing domain, with external routers that are members of that same domain. As mentioned above, all dynamic routing protocols can be used to distribute routing information to external peer devices. OSPF, RIP, and BGP can all be used to dynamically distribute routes to external peers within VRF routing domains.
When BGP is used for dynamic inter-VRF communication, routes from other routing protocols (including connected routes, static routes, OSPF or RIP) are redistributed into a VRF instance’s BGP route table (BGP must be configured and associated with the VRF instance). Other VRF instances that are configured with BGP can selectively copy these routes into their own separate BGP route tables.
Inter-VRF route leakage interoperates with the exchange of route information. Routes learnt from external peers in one VRF domain can be leaked to other VRF instances and routes leaked into a VRF instance can then be advertised to external peers connected to that instance.
The details of dynamic inter-VRF routing are described in "Dynamic inter-VRF communication
explained" on page 18.
Configure VRF-lite | Page 9
Understanding VRF-lite

VRF-lite features in AW+

Here is a summary of the features provided by the AW+ VRF-lite implementation:
Multiple independent routing table instances may co-exist within the same device. The
same or overlapping IP addresses can be present in different route table instances without conflicting. All routing table instances remain securely isolated from those existing in other routing tables.
By default, no communication occurs between VRF instances, facilitating multiple secure
routing domains within the same VRF aware device.
However, inter-VRF communication between routing domains is possible by using either static inter-VRF routes and/or dynamic filtered route leakage via BGP and its associated route maps.
A single device configuration file simplifies management by providing the ability to create,
manage, and monitor all VRF instances.
Detailed diagnostic and debugging information is available.
Ability to view routing table information per VRF.
All appropriate VRF related information and error messages can be viewed in the
system wide log.
Separate instances of routing protocols can be mapped to VRF instances so that
distribution of route information can be performed on a per VRF domain basis. This enables route information to be distributed securely within each VRF routing domain.
For example:
VRF1 = OSPF routing instance1
VRF2 = OSPF routing instance2
All Layer 3 interfaces and associated switch ports remain in the default global VRF domain
until associated with a specific VRF instance.
VRF is supported in HW and SW (including Inter-VRF communications).
The default global VRF domain always exists and cannot be removed. Initially during
startup, every VLAN belongs to the default global VRF domain. Also, when a VLAN is removed from a VRF, it is automatically returned to the default global VRF domain. Only one default global VRF domain exists in each physical device.
Static and dynamic routes can be leaked from a VRF instance to the global default VRF.
Selected routes within a VRF instance can be dynamically leaked to other VRF routing
domains. This applies both to routes that have been statically configured, and to routes that have been learnt into a VRF instance on the device by routing protocol exchanges with external peer routers.
When a VRF instance has received routes leaked from other VRF instances, that instance
Page 10 | Configure VRF-lite
can advertise those routes to external peer routers connected to interfaces in that VRF instance, via the routing protocol operating within the VRF instance.
Understanding VRF-lite

Route limiting per VRF instance

In a multi-VRF network environment, it may be problematic if one VRF injects too many routes and fills up the hardware forwarding table (FIB) on the device, which can affect other VRFs as well as the global VRF. For more information see "Route Limits" on page 84

VRF-aware utilities within AW+

Some network utility and management features such as ping, traceroute, telnet client, SSH client, and tcpdump are supported in a VRF aware manner.
VRF aware services include
Ping
awplus#ping ? WORD Ping destination address or hostname ip IP echo ipv6 IPv6 echo vrf VRF instance (source VRF) <cr>
awplus#ping vrf <name> ? WORD Ping destination address or hostname ip IP echo
awplus#ping vrf <name> x.x.x.x
awplus#ping vrf <name> x.x.x.x ? broadcast Ping to a broadcast address df-bit Enable do-not-fragment bit in IP header interval Specify interval between pings pattern Specify data pattern repeat Specify repeat count size Specify datagram size source Specify source address or interface name timeout Specify timeout interval tos Specify type of service <cr>
Tr a c e r o u te
awplus#traceroute ? WORD Trace route to destination address or hostname ip IP Trace ipv6 IPv6 trace vrf VRF instance <cr>
awplus#traceroute vrf <name> ? WORD Trace route to destination address or hostname ip IP Trace
awplus#traceroute vrf <name> x.x.x.x
Configure VRF-lite | Page 11
Telnet client
awplus#telnet ? WORD IPv4/IPv6 address or hostname of a remote system ip IP telnet ipv6 IPv6 telnet vrf VRF instance
awplus#telnet vrf <name> ? WORD IPv4 address or hostname of a remote system ip IP telnet
awplus#telnet vrf <name> ip x.x.x.x
SSH client
awplus#ssh ? HOSTNAME IP/IPv6 address or hostname of a remote server client Configure global SSH client parameters ip IP SSH ipv6 IPv6 SSH port SSH server port user Login user version SSH client version vrf VRF instance
Understanding VRF-lite
awplus#ssh vrf <name> ? HOSTNAME IP/IPv6 address or hostname of a remote server ip IP SSH port SSH server port user Login user version SSH client version
awplus#ssh vrf <name> x.x.x.x
TCP dump
awplus#tcpdump ? LINE Execute tcpdump vrf VRF instance <cr>
awplus#tcpdump vrf <name> ? LINE Execute tcpdump <cr>
awplus#tcpdump vrf <name>
In this VRF-lite implementation, other Layer 4+ services and applications are not supported on a per-VRF basis - such as Telnet ser ver, SSH server, file copy, system log, SNMP server, DHCP server, DHCP relay, NTP server, etc. However, these services will remain suppor ted in the global VRF domain context, which is same as in a non-VRF environment.
Page 12 | Configure VRF-lite

Configuring VRF-lite

The following section describes the generic commands used to configure VRF-lite.
CONFIGURING ACLS PURPOSE
Configuring VRF-lite
Step 1 Enter Global Configuration mode.
Step 2 Optional. This command configures a standard
CONFIGURING VRFS PURPOSE
Step 1 Create a named Virtual Router Forwarding
awplus# con
awplus(config)# access-list standard
<access-list-name> {deny| permit}<network>
awplus(config)#ip vrf <vrf-name> <lo-
interface-number>
f t
named access-control-list (ACL). Matching networks (routes) are either impor ted to or exported from a VRF instance to BGP. Alternatively, matching networks are denied from being imported to or exported from a VRF instance to BGP. This command is optionally used in the context of VRF when using BGP to facilitate inter-VRF communications. These optional ACLs should be configured before any inter-VRF communication is configured, to prevent unnecessary routes from being leaked from one VRF to another
(VRF) instance. If the optional Local Interface (LO) parameter not specified, a local interface is automatically created and associated with the VRF instance. If the LO parameter is specified, it allows the user to control which LO is associated with a particular VRF instance.
.
Step 2 Optional. Create a route distinguisher (rd) in
Step 3
Step 4 Optional. Imports routes from BGP into the
Step 5
Step 6 Optional. Configure an export map, which
Step 7 Return to Global Configuration mode.
awplus(config-vrf)#rd <route
distinguisher>
awplus(config-vrf)#route-target export
<ASN>
awplus(config-vrf)#route-target import
<ASN>
awplus(config-vrf)#import map <route-
map-name>
awplus(config-vrf)#export map <route-
map-name>
awplus(config-vrf)#exit
the form of an ASN, which also references a specific VRF instance. Format is in the form ASN:VRF instance. This command is required if using BGP to facilitate inter-VRF communication.
Optional. Exports routes from the VRF instance to BGP.
VRF instance.
Optional. Configure an import map, which references a route map, and associated ACL. Used to selectively import routes into the VRF instance from BGP.
references a route map, and associated ACL. Used to selectively export routes from the VRF instance to BGP.
Configure VRF-lite | Page 13
Configuring VRF-lite
CONFIGURING VLANS AND VLAN DATABASE PURPOSE
Step 1 awplus(config)#vlan database VLANs are created in the VLAN database, and
ports are assigned to relevant VLANs.
Step 2 awplus(config-vlan)#vlan x state enable
Step 3 awplus(config-vlan)#exit
Step 4 awplus(config)#interface portx.x.x
Step 5 awplus(config-if)#switchport access vlanx
Step 6 awplus(config-if)#exit
CONFIGURING LOCAL LOOPBACK IP INTERFACE PURPOSE
Step 1 awplus(config-if)#interface lo1
Step 2 awplus(config-if)#ip address x.x.x.x/x Optional - IP network is associated with the LO
interface, to be used by upper layer routing protocols.
Step 3 awplus(config-if)#exit
CONFIGURING VLANS - IP AND VRF MEMBERSHIP PURPOSE
Step 1 awplus(config)#interface <vlan-name> VRF routing domains are formed by associating
a VLAN Layer 3 interface with a VRF instance.
Step 2 awplus(config-if)#ip vrf forwarding <vrf-
name>
Step 3 awplus(config-if)#ip address <subnet>
Step 4 awplus(config-if)#exit
DYNAMIC ROUTING PROTOCOL - OSPF INSTANCE PURPOSE
Step 1 awplus(config)#router osfp <1-65535>
<vrf-name>
Step 2 awplus(config-router)#network <x.x.x.x/
x> area <area-id>
<name>is the name of a VRF instance created by the IP VRF <name> command.
Optional. Associate an OSPF routing instance with a specific VRF instance, and enter router configuration mode.
Define a network on which the OSPF instance runs and the area ID for that network.
Step 3 awplus(config-router)#redistribute
<protocol>
Step 4 awplus(config-router)#exit
Page 14 | Configure VRF-lite
Configure the device to redistribute information from another routing protocol into OSPF. For example BGP can be specified, to allow OSPF to advertise inter-VRF routes to an OSPF peer.
Configuring VRF-lite
DYNAMIC ROUTING PROTOCOL - RIP ADDRESS-FAMILY PURPOSE
Step 1 awplus(config)#router rip Optional. Enter router configuration mode for
RIP.
Step 2 awplus(config-router)#address-family
ipv4 vrf <vrf-name>
Step 3 awplus(config-router-af)#network
x.x.x.x/x
Step 4 awplus(config-router-af)#redistribute
<protocol>
Associate a RIP address-family with a specific VRF instance.
Define a network on which the RIP address­family runs.
Configure the device to redistribute information from another routing protocol into the RIP address-family. For example BGP can be specified, to allow RIP to advertise inter-VRF routes to a RIP neighbor.
Step 5 awplus(config-router)#exit-address-
family
Step 6 awplus(config-router)#exit
DYNAMIC ROUTING PROTOCOL - BGP ADDRESS-FAMILY PURPOSE
Step 1 awplus(config)#router bgp <ASN> Mandatory if BGP is used for inter-VRF
communications. Not required if static inter­VRF routes are used instead of BGP to provide inter-VRF communications. Enter router configuration mode for BGP and assign the BGP ASN. Define a single BGP ASN for the device. Multiple ASNs not supported.
Step 2 awplus(config-router)#address-family
ipv4 vrf <vrf-name>
Step 3 awplus(config-router-af)#redistribute
<protocol>
Step 4 awplus(config-router-af)#neighbor
x.x.x.x <remote-ASN>
Step 5 awplus(config-router-af)#neighbor
x.x.x.x activate
Step 6
awplus(config-router-af)#exit-address-
family
Step 7 awplus(config-router)#exit
Associate a BGP address-family with a specific VRF instance.
Configure the device to redistribute information from another routing protocol into the BGP address-family. For example 1) connected, or static can be specified, to allow BGP to advertise connected or static routes to BGP neighbor - if external BGP neighbor is configured. 2) Ensure the connected or static routes are redistributed into BGP to be used for inter-VRF communications.
If required, define a BGP neighbor and its associated ASN.
Activate the BGP neighbor to allow the BGP Transport Layer TCP connection to establish to the specified BGP neighbor.
Configure VRF-lite | Page 15
STATIC ROUTES PURPOSE
Configuring VRF-lite
Step 1 awplus(config)# ip route vrf <name>
<network> {<gateway> <interface>| <interface>}
Optional. To add a static route into the Routing table for a VRF instance. This can be a route pointing externally to a nexthop reachable via an interface in this VRF instance, or it can be used to facilitate inter-VRF routing, in which case it would point to an interface in a different VRF instance. Static inter-VRF routes can be used instead of BGP, or in conjunction with BGP to provide inter-VRF communications.
ROUT E MAPS THAT REFERENCE ACLS AND VRFS PURPOSE
Step 1 awplus(config)#route-map word (deny|
permit) <1-65535>
Step 2 awplus(config-route-map)#match ip
address <ACL name>
Optional. Configure a route map name that is referenced by a VRF import or expor t map.
Configure a route map entry which references an ACL.
Step 3 awplus(config-route-map)#exit
Step 4 awplus(config)#exit
Page 16 | Configure VRF-lite
Configuring VRF-lite
192.1 68.1 .0/24
192.168.20.0/24 192.168.20.0/24
192.168.50.0/24
VRF red
VLAN20
global default VRF domain
VLAN10
VLAN10 VLAN30
VRF green
VRF blue
192.168.20.6
192.168.20.5192.168.1.5
192.168.50.10
Device A Device B

Static inter-VRF routing

Static inter-VRF routing involves creating static routes in one VRF instance whose egress VLAN is in a different egress VLAN. These static routes must specify both the egress VLAN and next hop IP address.
The following diagram illustrates use of static routing to achieve inter- VRF communication in VRF-lite.
DEVICE A STATIC ROUTES CONFIGURATION DEVICE B STATIC ROUTES CONFIGURATION
ip route vrf red 192.168.20.0/24 vlan10
From source vrf red, create a static route to
192.168.20.0/24 to access target vlan10. Target vlan is required when performing static IVR.
ip route 192.168.1.0/24 vlan20
From the source global VRF domain, create a static route to
192.168.1.0/24 to access target vlan20. Target vlan is required when performing static IVR.
ip route vrf red 192.168.50.0/24 192.168.20.6 vlan10
From source vrf red, create a static route to
192.168.50.0/24 with a next hop of 192.168.20.6
egressing target vlan10. Target vlan is required when
ip route vrf blue 192.168.20.0/24 vlan10
From source vrf blue, create a static route to 192.168.20.0/24
to access target vlan10. Target vlan is required when performing static IVR.
ip route vrf green 192.168.50.0/24 vlan30
From the source vrf green, create a static route to
192.168.50.0/24 to access target vlan30. Target vlan is required when performing static IVR.
ip route vrf blue 192.168.1.0/24 192.168.20.5 vlan10
From source vrf blue, create a static route to 192.168.1.0/24 with a next hop of 192.168.20.5 egressing target vlan10.
Target vlan is required when performing static IVR.
performing static IVR.
ip route 192.168.50.0/24 192.168.20.6
From the global VRF domain, create a static route to
192.168.50.0/24 with a next hop of 192.168.20.6.
Static routes to networks within a VRF instance do
ip route vrf green 192.168.1.0/24 192.168.20.5
From the source vrf green, create a static route to 192.168.1.0/ 24 with a next hop of 192.168.20.5. Static routes to networks within a VRF instance do not require the target vlan.
not require target vlan.
Configure VRF-lite | Page 17
Dynamic inter-VRF communication explained
VRF Device
VRF
blue
FIB
BGP
address-
family
blue
RIP
address-
family
blue
OSPF 2
VRF
red
FIB
BGP
address-
family
red
RIP
address-
family
red
OSPF 1
BGP routes copied between BGP address-families to facilitate inter-VRF communication

Dynamic inter-VRF communication explained

The following section explains how VRF routing domain isolation is maintained, and how routes that exist in one VRF instance are leaked to another VRF instance via BGP. can be used to dynamically leak routes from one VRF instance to another.

The Forwarding Information Base (FIB) and routing protocols

Associated with each VRF instance is an IP route table, also known as the Forwarding Information Base (FIB). When BGP address-families (associated with VRF instances) are configured, a corresponding BGP route table is created for each VRF instance on which a BGP address-family is configured.
Similarly, when RIP address-families (associated with VRF instances) are configured, a corresponding RIP route table is created for each VRF instance on which a RIP address-family is configured.
Similarly, when OSPF instances (associated with VRF instances) are configured, a corresponding OSPF route table is created for each VRF instance on which an OSPF instance is configured.
Only BGP
Each dynamic routing protocol automatically selects appropriate routes and copies them to the FIB.
Static and connected routes are automatically added to the FIB when they are created.
Page 18 | Configure VRF-lite
Dynamic inter-VRF communication explained
The command redistribute <protocol> can be configured in an OSPF instance, BGP address-family, or RIP address-family. Via this command, routes are imported from the FIB associated with the VRF instance into the dynamic routing protocol table. Any routing protocol (OSPF, BGP, RIP static, connected, etc.) can be redistributed.
For example, if OSPF instance1 is configured on VRF red, and if OSPF 1 contains the
command redistribute BGP, then BGP routes will be copied from VRF red FIB to OSPF instance1.
Similarly, if BGP address-family is configured on VRF red, and if the address-family contains
the command redistribute OSPF, then OSPF instance1 routes will be copied from the VRF red FIB into the BGP red address-family route table.
Dual role of
BGP
The first role that BGP plays in a VRF-lite environment is to facilitate BGP peering to an external router operating within the VRF routing domain via the neighbor x.x.x.x command configured in a BGP address-family.
The second role that BGP plays is to facilitate route leakage between VRF routing domains.
Dynamic routing protocols (RIP and OSPF) do not facilitate route leakage. RIP and OSPF only operate within a VRF routing domain.
Configure VRF-lite | Page 19
Dynamic inter-VRF communication explained

Inter-VRF communication via BGP

Dynamic inter-VRF route leakage is achieved by making copies of BGP routes that exist in one BGP address-family associated with one VRF instance, to another BGP address-family associated with a different VRF instance.
OSFP peer router
Redistribute BGP
BGP
from VRF red FIB
VRF
blue
FIB
Redistribute OSPF from VRF blue FIB
Redistribute BGP from VRF blue FIB
OSPF 2
OSFP peer router
Redistribute OSPF from VRF red FIB
address-
family
red
BGP
OSPF 1
FIB
VRF
red
address-
family
blue
BGP routes copied between BGP address-families to facilitate inter-VRF communication
VRF Device
In the diagram above, the following is configured:
OSPF1 is configured in VRF-red, and OSPF1 contains redistribute BGP
OSPF2 is configured in VRF-blue, and OSPF2 contains redistribute BGP
BGP is configured and contains BGP address-families red and blue
Both BGP address-families contain redistribute OSPF
Then route leakage of routes from VRF red to VRF blue occurs as follows:
1. OSPF1 selects appropriate OSPF routes learned from external VRF red OSPF peer and
automatically adds them to red FIB route table.
2. OSPF1 routes are imported from red FIB route table into BGP address-family red BGP
route table (via the BGP redistribute OSPF command).
3. Via the route-target import command, BGP address-family red BGP routes are selected
and copied into BGP address-family blue BGP route table.
4. Appropriate BGP address-family blue BGP routes are selected and automatically added to
the VRF blue FIB route table.
5. OSPF2 then imports and redistributes the BGP routes (learned originally from VRF red
6. Those OSPF routes are then advertised to external VRF blue OSPF peer.
And the same process is used to leak routes from VRF b
Page 20 | Configure VRF-lite
OSPF peer) into OSPF2 from VRF blue FIB route table (via OSPF redistribute BGP command).
lue to VRF red.
Dynamic inter-VRF communication explained
Using the route-target command
When BGP is used for inter-VRF communication, dynamic route leakage of BGP routes from one VRF instance to another is achieved via the VRF route-target command.
There are three variations of the route-target command:
1. route-target export <ASN:VRFinstance>
for example:
ip vrf red rd 100:1 route-target export 100:1
2. route-target import <ASN:VRFinstance>
for example:
ip vrf red rd 100:1 route-target import 100:2
3. route-target both <ASN:VRFinstance>*
for example:
ip vrf red rd 100:1 route-target export 100:1 route-target export 100:2 route-target export 100:3 route-target import 100:2
can be replaced with:
ip vrf red rd 100:1 route-target export 100:1 route-target export 100:3 route-target both 100:2
*Use of the command route-target both is uncommon in a VRF-lite environment.
The command route-target export applies a BGP extended community attribute to each BGP prefix stored in the BGP route table of the address-family associated with the VRF instance. The content of this attribute is the (ASN) that was specified in the route-target
export command.
Configure VRF-lite | Page 21
Dynamic inter-VRF communication explained
The following three examples demonstrate how the route-target command facilitates inter­VRF communication:
1. If VRF red configuration includes:
ip vrf red rd 100:1 route-target export 100:1
And if VRF red initially has routes to networks 10.0.0.0/24, 20.0.0.0/24, then the entries in the address-family red BGP route table for each of those two routes would have the extended­community attribute applied as follows:
10.0.0.0/24 100:1
20.0.0.0/24 100:1
Also, if VRF shared configuration includes:
ip vrf shared rd 100:2 route-target import 100:1
then VRF shared will check all other VRFs’ BGP tables searching for routes with the extended-community attribute 100:1, and those specific routes will be copied into the VRF shared BGP route table from the other VRFs, and they will be marked as copied BGP routes.
VRF shared will then have copied BGP routes that have been leaked from VRF red:
(copy)10.0.0.0/24 100:1 (copy)20.0.0.0/24 100:1
2. If VRF red initially includes:
ip vrf red rd 100:1 route-target export 100:1 route-target import 100:2
10.0.0.0/24 100:1
20.0.0.0/24 100:1
And if VRF shared initially includes:
ip vrf shared rd 100:2 route-target export 100:2 route-target import 100:1
30.0.0.0/24 100:2
40.0.0.0/24 100:2
Then via BGP inter-VRF routing (IVR), VRF red will end up with the routes:
10.0.0.0/24 100:1
20.0.0.0/24 100:1 (copy)30.0.0.0/24 100:2 (copy)40.0.0.0/24 100:2
And via BGP IVR, VRF shared will end up with the routes:
(copy)10.0.0.0/24 100:1 (copy)20.0.0.0/24 100:1
30.0.0.0/24 100:2
40.0.0.0/24 100:2
Each VRF instance now contains dynamic inter-VRF routes.
Page 22 | Configure VRF-lite
Dynamic inter-VRF communication explained
3. If VRF red configuration includes*:
ip vrf red rd 100:1 route-target export 100:1 route-target export 100:2 route-target export 100:3 route-target export 100:4 route-target import 100:5 route-target import 100:6
And if VRF red initially has routes to networks 10.0.0.0/24, 20.0.0.0/24, then each of those two routes would have multiple extended community attributes (as defined in the route- target export command configured in the VRF instance) as follows:
10.0.0.0/24 100:1 100:2 100:3 100:4
20.0.0.0/24 100:1 100:2 100:3 100:4
And If VRF shared configuration includes:
ip vrf shared rd 100:5 route-target export 100:5 route-target import 100:2
And if VRF shared initially has routes to networks 30.0.0.0/24, 40.0.0.0/24, then each of those two routes would have an extended community attribute applied (as defined in the route- target export command) as follows:
30.0.0.0/24 100:5
40.0.0.0/24 100:5
Then via BGP IVR, VRF red will end up with the routes:
10.0.0.0/24 100:1 100:2 100:3 100:4
20.0.0.0/24 100:1 100:2 100:3 100:4 (copy)30.0.0.0/24 100:5 (copy)40.0.0.0/24 100:5
And via BGP IVR, VRF shared will end up with the routes:
(copy)10.0.0.0/24 100:1 100:2 100:3 100:4 (copy)20.0.0.0/24 100:1 100:2 100:3 100:4
30.0.0.0/24 100:5
40.0.0.0/24 100:5
*Use of the command route-target export, as per example 3 above, to tag routes in a VRF instance with ASNs associated with other VRF instances is uncommon in a VRF-lite environment.
Configure VRF-lite | Page 23
Dynamic inter-VRF communication explained

How VRF-lite security is maintained

Incidentally, only the original routes can be copied from one VRF to another. Copied routes cannot be subsequently copied to another VRF, to ensure VRF security domains are enforced.
For example:
VRFred----VRFshared----VRFgreen
If VRF red routes are copied into the route table of VRF shared, VRF red routes will not be able to subsequently be copied from VRF shared into the VRF green route table. This ensures that while VRF green, and VRF red can access VRF shared, there is no inter-VRF communication between VRF red and VRF green - unless additional route leakage is configured.
Similarly, routes learnt by the default global VRF domain from a VRF instance via internal BGP peering cannot be subsequently advertised from the default global VRF domain to another VRF instance.
VRFred---default_global_VRF---VRFgreen
Viewing source VRF and attribute information for a prefix
The command show ip bgp < prefix> can be used to display source VRF and extended community attribute information for a route.
For example:
VRF_device#show ip bgp 192.168.120.0
[VRF: green]
BGP routing table entry for 192.168.120.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer
192.168.20.1 from 192.168.20.10 (192.168.20.10) Origin IGP metric 0, localpref 100, valid, external, best Extended Community: RT:500:2 Last update: Thu Nov 18 03:51:06 2010
[VRF: common]
BGP routing table entry for 192.168.120.0/24 Paths: (1 available, best #1, table Default-IP-Routing-Table) Not advertised to any peer
192.168.20.1 from 192.168.20.10 (192.168.20.10) Origin IGP metric 0, localpref 100, valid, external, best Extended Community: RT:500:2 Copied from VRF: green Last update: Thu Nov 18 03:51:06 2010
Page 24 | Configure VRF-lite
Simple VRF-lite configuration examples

Simple VRF-lite configuration examples

The following section contains simple configuration examples to explain the basics of VRF-lite configuration used in conjunction with a variety of routing protocols.
Firstly, always create a clear VRF communication plan. This includes researching the v
arious routing protocols and likely IP network plans for each VRF, and the likely content of each VRF routing table. Also confirm any overlapping IP address space requirements, and if there are any inter-VRF communication requirements.

Multiple VRFs without inter-VRF communication

The partial configuration example below shows the key components required to support multiple VRF instances with OSPF peering to external neighbors within each VRF instance. There is no inter-VRF communication used in this first example.
Two interfaces, vlan11 and vlan12 are configured for Customer1 (VRF red), and two other interfaces, vlan13 and vlan14 are configured for Customer2 (VRF green). In this example, overlapping IP addresses are used. OSPF is used as the routing protocol within each VRF instance.
PC3
PC4
R3
R1
PC1
PC2
Customer1 (VRF red)
... ! ip vrf red description Customer1 ! ip vrf green description Customer2 ! interface vlan11 ip vrf forwarding red ip address 10.1.1.1/24 [cont...]
VRF
vlan 11
vlan 12
R2
vlan 13
R4
vlan 14
Customer2 (VRF green)
Configure VRF-lite | Page 25
! interface vlan12 ip vrf forwarding red ip address 10.2.2.1/24 ! interface vlan13 ip vrf forwarding green ip address 10.1.1.1/24 ! interface vlan14 ip vrf forwarding green ip address 10.2.2.1/16 ! router ospf 1 red network 10.1.1.0/24 area 0 network 10.2.2.0/24 area 0 redistribute connected ! router ospf 2 green network 10.1.1.0/24 area 0 network 10.2.0.0/16 area 0 redistribute connected ! ...
Simple VRF-lite configuration examples
Page 26 | Configure VRF-lite
Simple VRF-lite configuration examples
100.100.100.0/24
- Inter VRF (IVR) communications via static IVR routes
VRF red
VRF green
Global default
VRF domain
vlan 100
1.20.1.0/24
vlan 14
1.10.1.0/24
vlan 12
VRFs accessing a shared network. An example of static inter-VRF routing
The partial configuration example below shows the key components required to support static inter-VRF routing.
Two companies (VRF red and VRF green) are able to access shared vlan100. Shared vlan100 exists in the Global default VRF. Static inter-VRF routing is used in this example to facilitate inter-VRF communication. There are no overlapping IP addresses. As there is no external router in vlan100 and there is no Internet access via vlan100, ACLs are not required.
... ! ip vrf red ! ip vrf green ! interface vlan12 ip vrf forwarding red ip address 1.10.1.1/24 ! interface vlan14 ip vrf forwarding green ip address 1.20.1.1/24 ! interface vlan100 ip address 100.100.100.100/24 ! ip route vrf red 0.0.0.0/0 vlan100 ip route vrf green 0.0.0.0/0 vlan100 ip route 1.10.1.0/24 vlan12 ip route 1.20.1.0/24 vlan14 ! ...
Configure VRF-lite | Page 27
Simple VRF-lite configuration examples

Dynamic inter-VRF communication with RIP routing to external peers

The partial configuration example below shows the key components required to support dynamic inter-VRF communication between two VRF instances using BGP, with RIP routing to external peers.
RIP address-families are created, and each RIP address-family is associated with a VRF instance. To achieve inter-VRF communications, BGP is redistributed into each RIP family. Conversely, BGP address-families are created and each BGP address-family is associated with a VRF instance, and RIP is redistributed into each BGP address-family. Connected routes are also redistributed into BGP to be leaked between VRF instances.
... ! ip vrf red rd 100:1 route-target export 100:1 route-target import 100:2 ! ip vrf green rd 100:2 route-target export 100:2 route-target import 100:1 ! router rip ! address-family ipv4 vrf red network vlan20 redistribute bgp exit-address-family ! address-family ipv4 vrf green network vlan60 redistribute bgp exit-address-family ! router bgp 100 address-family ipv4 vrf red redistribute connected redistribute rip exit-address-family ! address-family ipv4 vrf green redistribute connected redistribute rip exit-address-family ! ...
Page 28 | Configure VRF-lite
Loading...
+ 63 hidden pages