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 VRFlite-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.
What is VRF-lite? .........................................................................................................................................................1
Who should read this document? .....................................................................................................................2
Which products and software version does it apply to?......................................................................2
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
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
Useful VRF-related diagnostics command list ................................................................................................... 87
Configure VRF-lite | Page 3
Glossary
ACRONYMDESCRIPTION
ASAutonomous System
ACLAccess Control List
Glossary
BGP
FIBForwarding Information Base
MPLS
OSPFOpen Shortest Path First
RIP
VPNVirtual Private Network
VR
VRFVir tual Routing and Forwarding
VRF-lite
CECustomer edge
PE
RDRoute Distinguisher
RT
VCStackVirtual 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 ACLSPURPOSE
Configuring VRF-lite
Step 1Enter Global Configuration mode.
Step 2Optional. This command configures a standard
CONFIGURING VRFSPURPOSE
Step 1Create 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). Matchingnetworks (routes) are either imported to or exported from a VRF instance to BGP.Alternatively,matching networks aredenied from being imported to or exported from a VRF instance to BGP. This command isoptionally used in the context of VRF when using BGP to facilitate inter-VRF communications. These optional ACLsshouldbe configured before any inter-VRF communication is configured, to preventunnecessary routes from beingleaked fromone 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 2Optional. Create a route distinguisher (rd) in
Step 3
Step 4Optional. Imports routes from BGP into the
Step 5
Step 6Optional. Configure an export map, which
Step 7Return 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 formof an ASN,which also references a specific VRF instance. Format isin the formASN:VRF instance. This command isrequired if using BGP tofacilitate 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 DATABASEPURPOSE
Step 1awplus(config)#vlan databaseVLANs are created in the VLAN database, and
ports are assigned to relevant VLANs.
Step 2awplus(config-vlan)#vlan x state enable
Step 3awplus(config-vlan)#exit
Step 4awplus(config)#interface portx.x.x
Step 5awplus(config-if)#switchport access vlanx
Step 6awplus(config-if)#exit
CONFIGURING LOCAL LOOPBACK IP INTERFACEPURPOSE
Step 1awplus(config-if)#interface lo1
Step 2awplus(config-if)#ip address x.x.x.x/xOptional - IP network is associated with the LO
interface, to be used by upper layer routing
protocols.
Step 3awplus(config-if)#exit
CONFIGURING VLANS - IP AND VRF MEMBERSHIPPURPOSE
Step 1awplus(config)#interface <vlan-name>VRF routing domains are formed by associating
a VLAN Layer 3 interface with a VRF instance.
Step 2awplus(config-if)#ipvrf forwarding <vrf-
name>
Step 3awplus(config-if)#ip address <subnet>
Step 4awplus(config-if)#exit
DYNAMIC ROUTING PROTOCOL - OSPF INSTANCEPURPOSE
Step 1awplus(config)#router osfp <1-65535>
<vrf-name>
Step 2awplus(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 3awplus(config-router)#redistribute
<protocol>
Step 4awplus(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.
Step 1awplus(config)#router rip Optional. Enter router configuration mode for
RIP.
Step 2awplus(config-router)#address-family
ipv4 vrf <vrf-name>
Step 3awplus(config-router-af)#network
x.x.x.x/x
Step 4awplus(config-router-af)#redistribute
<protocol>
Associate a RIP address-family with a specific
VRF instance.
Define a network on which the RIP addressfamily 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 1awplus(config)#router bgp <ASN>Mandatory if BGP is used for inter-VRF
communications. Not required if static interVRF 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 2awplus(config-router)#address-family
ipv4 vrf <vrf-name>
Step 3awplus(config-router-af)#redistribute
<protocol>
Step 4awplus(config-router-af)#neighbor
x.x.x.x <remote-ASN>
Step 5awplus(config-router-af)#neighbor
x.x.x.x activate
Step 6
awplus(config-router-af)#exit-address-
family
Step 7awplus(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 ROUTESPURPOSE
Configuring VRF-lite
Step 1awplus(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 VRFSPURPOSE
Step 1awplus(config)#route-map word (deny|
permit) <1-65535>
Step 2awplus(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 3awplus(config-route-map)#exit
Step 4awplus(config)#exit
Page 16 | Configure VRF-lite
Configuring VRF-lite
192.1 68.1 .0/24
192.168.20.0/24192.168.20.0/24
192.168.50.0/24
VRF red
VLAN20
global default VRF domain
VLAN10
VLAN10VLAN30
VRF green
VRF blue
192.168.20.6
192.168.20.5192.168.1.5
192.168.50.10
Device ADevice 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 CONFIGURATIONDEVICE 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
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 interVRF 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 extendedcommunity 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
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:
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:
*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:2Copied 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
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.