Networking-Blog

My WordPress Blog

Understanding MPLS IPVPN

Core Issue

A Virtual Private Network (VPN) is as a network in which connectivity a customer’s
multiple sites is deployed on a shared infrastructure with the same access or security
policies as in a private network. VPNs allow multiple customers to share a common

public infrastructure similar to the Internet, with the same level of security as in a
private network. This results in cost savings and flexibility in connectivity options for
the customer. VPNs can be implemented by using either an overlay or a peer-to-peer
model. Each model has its own advantages and disadvantages.

The Multiprotocol Label Switching (MPLS) VPN architecture provides the service
providers with a peer-to-peer model which combines the best features of overlay and
peer-to-peer models. The MPLS VPN terminology divides the overall network into a
customer controlled part (C-network) and a provider controlled part (P network). The
contiguous portions of the C-network are called sites and are linked with the P
network
through Customer Edge (CE) routers. The CE routers are connected to the
Provider Edge (PE) routers, which serve as the edge device of the P network. The core
devices, or the P-routers, in the P network provide the transit transport across the
service provider backbone. In MPLS VPN, PE routers participate in customer routing,
providing optimum routing between sites and easy provisioning of sites. It also allows
customers to use overlapping addresses. The PE routers contains separate set of routes
for each customer, which results in perfect isolation between them.

 

Resolution

The MPLS VPN architecture is designed to address these requirements:

The customer routers need not be MPLS-VPN aware.
The P routers should not carry customer routes (otherwise called as VPN routes) to
make the solution more scalable.

The PE routers should support MPLS VPN services.

 

These requirements are addressed in these ways:

The CE routers use static routing or run any standard IP routing protocol, such as Routing Information Protocol version 2 (RIPv2), Open Shortest Path First (OSPF) or Border Gateway Protocol (BGP) with the PE devices to exchange routing information.

The P routers do not carry VPN routes. They run Interior Gateway Protocol (IGP) with other P and PE devices to learn about the subnets within the P network and use MPLS for forwarding packets.

The PE routers learn about the VPN routes from CE routers through any of the above routing protocols. They provide isolation between different customers by installing these routes in separate routing tables called Virtual Routing and Forwarding (VRF) instances. The PE routers exchange these VPN routes with other PE devices using Multiprotocol BGP (MBGP) as the routing protocol. The PE routers also run an IGP with other P and PE devices in the P network and use MPLS for forwarding packets across the P network. The PE router still has a global routing table for forwarding packets to destinations in the P network.

Configuring MPLS VPN can be broken down into these sub-tasks:

 Configure an IGP and enable MPLS in the P network. Enable Cisco Express Forwarding (CEF) and MPLS on all the devices in the P network, and configure an IGP to exchange routes for networks available in the P network. These routes are stored in the global routing table on the PE devices and have a label associated with them. They are distributed using Label Distribution Protocol (LDP) or Tag Distribution Protocol (TDP).

Configure VRF on the PE devices. A VRF consists of an IP routing table, a derived CEF table, and a set of interfaces that use the forwarding table. There can be multiple VRFs on the same PE device. Sites that have identical routing requirements and are connected to the same PE router can use the same VRF. Each VRF should be configured with the Route Distinguisher (RD) and Route Target (RT) parameters.

Since the MPLS VPN architecture allows the customers to use overlapping IP addresses, the addresses from different customers must be distinguished when they are advertised across the P network using MBGP. RD is a 64-bit value, which is prefixed to the 32-bit Information Protocol version 4 (IPv4) routes. These are learned from the customer to make them a unique 96-bit address called a VPNv4 address, which is then advertised to other PE devices. Each VRF on the PE device must be assigned a unique value as an RD, and a VRF can have only one RD assigned.

The RT parameter indicates the VPN membership of a route. There can be complex VPN requirements where some customer sites could be part of a single VPN, but other sites of the same customer could be part of multiple or overlapping VPNs. Since the RD only makes the addresses unique and does not indicate VPN membership, the RT parameter is used for this purpose. RTs are represented using Extended BGP Community Attributes which are 64 bits long. Any number of RTs can be attached to a route to indicate membership in more than one VPN. RTs are attached to a route when they are converted from an IPv4 address to a VPNv4 address by the PE router. These RTs are called export RTs, and they are configured for each VRF on the PE device. When the VPNv4 routes are propagated to other PE devices, those routers should select the routes to be inserted into the appropriate VRF. This selection is based on import RTs, and it is configured for each VRF.

Configure MBGP between PE devices. While the VRFs provide the isolation between different customers, the routes in these routing tables need to be exchanged with other PE devices to enable data transfer between sites attached to different PE routers. A routing protocol which transports all the customer routes across the P network is needed. The P-routers should not know about the VPN routes to make it more scalable. This is one of the requirements to be addressed by the MPLS VPN architecture. Since the number of VPN routes can be large, BGP is the only protocol which provides the required scalability.

BGP is required in MPLS VPN setup to transport customer routes directly between PE routers and to use MPLS labels to exchange packets between PE routers. Since BGP was capable of carrying only traditional IPv4 prefixes, it has been enhanced to carry the 96-bit VPNv4 prefixes, along with extended community attributes like RTs. This enhanced version is called MBGP. Since the PE routers have multiple routing tables associated with different VRFs, the MPLS label called VPN label (carried in the MBGP update along with the prefix) is used for identifying the VRF that must be used while receiving packets to forward to the destination.

Configure the PE-CE routing protocol on PE and CE devices. Cisco devices support using either static routes or RIPv2, OSPF and BGP to exchange IPv4 routes between the PE and CE devices. These protocols are VRF aware which allow to run separate instances of the same protocol for each VRF on the PE device. The routes that are learned via the interface belonging to a particular VRF are populated in the routing table for that particular VRF and provide isolation.

Configure redistribution between PE-CE routing protocol and MBGP on the PE devices. The PE devices learn about the VPN routes as IPv4 prefixes from the attached CE devices using a PE-CE routing protocol or through static routing. They are stored in the routing table of the corresponding VRF. These routes are then advertised to other PE devices as VPNv4 routes through MBGP. This is done by redistributing the static routes (or the PE-CE routing protocol) into MBGP. While redistributing from the PE-CE routing protocol to MBGP, the RD corresponding to the VRF is prefixed to the IPv4 routes and converted into VPNv4 routes. The RT value configured as export RT for the VRF is attached to the VPNv4 routes. These VPNv4 routes are then advertised to other PE routers through MBGP.

When a PE router receives VPNv4 routes from another PE router, it imports routes that have an RT value that matches at least one import RT configured for a VRF, into the routing table of that VRF as IPv4 routes learned through BGP. These routes are then advertised to the attached CE devices using the PE-CE routing protocol. This is achieved by redistributing MBGP into the PE-CE routing protocol. The VPN routes are propagated between different sites of the customers.

 

Since the P routers are not running BGP and do not learn about the VPN routes belonging to customers, they drop any packets that are received without any label or with just the VPN label. The packet forwarding from one site to another site still must be done through the PE devices, which are connected across the P network through the P routers. Label the packets with a second label, which is assigned by Tag Distribution Protocol (TDP) or Label Distribution Protocol (LDP) for reaching the BGP next-hop, which is the other PE to which the destination site is connected. The BGP next-hop reachability is known to all the routers in the P network through the IGP.

There are labels for that address through TDP and LDP. The outer label learned through TDP or LDP is used for forwarding packets across the P network to the other PE device. The P routers forward the packets from one PE to the other, based on this outer label. They do not know about the inner VPN label or the VPN destination address. When the packet reaches the other PE device, the inner VPN label advertised through MBGP is used for finding the outgoing interface or the VRF routing table to be used for forwarding the packets.

 

When a CE device of a site needs to send a packet to another site, it sends a normal, unlabeled packet to the attached PE device. The PE device acting as the ingress Label Switch Router (LSR), which receives this unlabeled packet, adds a label stack of two labels by looking at its Forwarding Information Base (FIB) table, and forwards it inside the P network. The inner label is the VPN label learned through MBGP from the egress PE device. It is used for tagging the data packets for that particular VPN destination. The outer label is the one learned through TDP or LDP, and it is learned from the next-hop P router used for reaching the egress PE device.

The P-router receives labeled packets, performs a lookup in the Incoming FIB (IFIB) table, swaps the incoming label in the outer label with the Outgoing label, and forward the packets towards the next-hop router. The P router, which is one hop before the egress PE device, removes the outer label due to Penultimate Hop Popping (PHP) and forwards the packet with just the VPN label to the egress PE device. The egress PE device uses the Label Forwarding Information Base (LFIB) table to perform the label lookup, removes the VPN label in the incoming packets, and forwards the unlabeled packets towards the destination site.

 

 

MBGP_OSPF VRF LAB 1

hostname CE1

interface Loopback0
ip address 4.4.4.4 255.255.255.255
!
interface Loopback1
ip address 10.0.0.1 255.255.255.0
!
interface FastEthernet0/0
ip address 172.16.0.1 255.255.255.252
speed 100
full-duplex
!
router bgp 64518
bgp log-neighbor-changes
neighbor 172.16.0.2 remote-as 34790
!
address-family ipv4
redistribute connected
neighbor 172.16.0.2 activate
no auto-summary
no synchronization
exit-address-family
!

 

hostname CE2

interface Loopback0
ip address 5.5.5.5 255.255.255.255
!
interface Loopback1
ip address 10.1.0.1 255.255.255.0
!
interface FastEthernet0/0
ip address 172.16.0.5 255.255.255.252
speed 100
full-duplex
!
router bgp 64518
bgp log-neighbor-changes
neighbor 172.16.0.6 remote-as 34790
!
address-family ipv4
redistribute connected
neighbor 172.16.0.6 activate
no auto-summary
no synchronization
exit-address-family

 

!

hostname PE1

ip vrf CE1
rd 100:1
route-target export 100:1
route-target import 100:1

interface Loopback0
ip address 1.1.1.1 255.255.255.255
!
interface Loopback1
ip vrf forwarding CE1
ip address 10.10.10.254 255.255.255.0
!
interface FastEthernet0/0
ip address 192.168.1.1 255.255.255.252
speed 100
full-duplex
mpls ip
!
interface FastEthernet0/1
ip vrf forwarding CE1
ip address 172.16.0.2 255.255.255.252
speed 100
full-duplex
!
router ospf 10
router-id 1.1.1.1
log-adjacency-changes
redistribute connected subnets
passive-interface default
no passive-interface FastEthernet0/0
no passive-interface Loopback0
network 10.10.10.10 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0
!
router bgp 34790
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 34790
neighbor 2.2.2.2 update-source Loopback0
! |
address-family ipv4
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community both
neighbor 2.2.2.2 soft-reconfiguration inbound
no auto-summary
no synchronization
exit-address-family

!
address-family ipv4 vrf CE1
redistribute connected
neighbor 172.16.0.1 remote-as 64518
neighbor 172.16.0.1 activate
neighbor 172.16.0.1 next-hop-self
no synchronization
exit-address-family

!

hostname PE2

ip vrf CE1
rd 100:1
route-target export 100:1
route-target import 100:1

interface Loopback0
ip address 3.3.3.3 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.1.5 255.255.255.252
speed 100
full-duplex
mpls ip
!
interface FastEthernet0/1
ip vrf forwarding CE1
ip address 172.16.0.6 255.255.255.252
speed 100
full-duplex
!
router ospf 10
router-id 3.3.3.3
log-adjacency-changes
redistribute connected subnets
passive-interface default
no passive-interface FastEthernet0/0
no passive-interface Loopback0
network 11.11.11.11 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0
!
router bgp 34790
bgp log-neighbor-changes
neighbor 2.2.2.2 remote-as 34790
neighbor 2.2.2.2 update-source Loopback0

address-family ipv4
neighbor 2.2.2.2 activate
neighbor 2.2.2.2 send-community both
neighbor 2.2.2.2 soft-reconfiguration inbound
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf CE1
redistribute connected
neighbor 172.16.0.5 remote-as 64518
neighbor 172.16.0.5 activate
neighbor 172.16.0.5 next-hop-self
no synchronization
exit-address-family

 

hostname P

mpls label protocol ldp

interface Loopback0
ip address 2.2.2.2 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.252
speed 100
full-duplex
mpls ip
!
interface FastEthernet0/1
ip address 192.168.1.6 255.255.255.252
speed 100
full-duplex
mpls ip
!

router ospf 10
router-id 2.2.2.2
log-adjacency-changes
redistribute connected subnets
passive-interface default
no passive-interface FastEthernet0/0
no passive-interface FastEthernet0/1
no passive-interface Loopback0
network 2.2.2.2 0.0.0.0 area 0
network 192.168.1.0 0.0.0.255 area 0
!
router bgp 34790
bgp log-neighbor-changes
neighbor 1.1.1.1 remote-as 34790
neighbor 1.1.1.1 update-source Loopback0
neighbor 3.3.3.3 remote-as 34790
neighbor 3.3.3.3 update-source Loopback0
!
address-family ipv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community both
neighbor 1.1.1.1 soft-reconfiguration inbound
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community both
neighbor 3.3.3.3 soft-reconfiguration inbound
no auto-summary
no synchronization
exit-address-family

!
address-family vpnv4
neighbor 1.1.1.1 activate
neighbor 1.1.1.1 send-community extended
neighbor 3.3.3.3 activate
neighbor 3.3.3.3 send-community extended
exit-address-family
!

ip bgp-community new-format

 

Understanding MPLS: Basic MPLS Configuration

 

The configuration of a basic MPLS network is actually very simple and only requires a few basic steps.

The requirements of such a network are the following:

  • Enable CEF: CEF is essentially what allows the imposition and disposition of labels in an MPLS network. You must make sure it is enabled globally, as well as on the specific interfaces participating in the MPLS network. When possible enable CEF in distributed mode, which is largely platform dependent. Unfortunately it does not to pertain to the platforms used in this lab.

Enable CEF Globally on the router:

R1(config)#ip cef

Enable CEF on the MPLS participating interfaces:

R1(configif)#ip route-cache cef

  • Configure IGP routing protocol: Interior Gateway Protocols are routing protocols such as RIP, IGRP, EIGRP, and OSPF. In this case OSPF was used on all the routers. IGP routing protocols are needed to populate the routing tables, which CEF operation takes over and label binding ensues.

Configure an IGP protocol on the Router:

R1(config)#router ospf 1
R1(config-router)#network 1.1.1.0 255.255.255.0 area 0

  •   (Optional) Define Label Distribution Protocol: LDP by default is the label distribution protocol. The only other option is TDP, which in the real world is a overwhelming minority, if used at all.

The command to manually do this is:

R1(config)#mpls label protocol {ldp|tdp}

  • (Optional) Assign LDP Router ID: LDP uses the highest IP address on a loopback interface. A loopback interface is a logical interface as opposed to an actual physical interface such as interface gigabit 0/1 of a router. Loopback interfaces are often used as management IPs for telnet sessions, monitoring, or other forms of maintenance or management. If there is no loopback interface defined, the highest IP address on the router becomes the LDP router ID.

To force an interface to be an LDP router interface simply type the command:

R1(config)#mpls ldp router -id [interface type] [number] for example,
R1(config)#mpls ldp router-id gigabit 0/1

The LDP router ID is important in setting up sessions between MPLS routers to exchange label information.

  • Configure MPLS or Label Forwarding on the Interface
  • This part of the configuration tells the specific interfaces that they are participating in MPLS or Label Forwarding.

Configure MPLS Label Forwarding on the interface:

R11(config)#interface GigabitEthernet 0/0
R1(config-if)#mpls ip
R1(config)#interface GigabitEthernet 0/1
R1(config-if)#mpls ip

CISCO MPLS VPN – VRF

 

PE Routers

(PE1)

PE Router configuration is the beefiest part of the lab.
hostname PE_1
!
ip vrf ClientA
rd 999:1
route-target export 64999:1
route-target import 64999:1
!
ip vrf ClientB
rd 999:2
route-target export 64999:2
route-target import 64999:2
!
!

interface Loopback0
ip address 172.16.1.1 255.255.255.255
!
interface FastEthernet0/0
ip vrf forwarding ClientA
ip address 10.1.1.2 255.255.255.252
speed 100
full-duplex
!
interface FastEthernet0/1
ip vrf forwarding ClientB
ip address 10.1.1.2 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 192.168.1.1 255.255.255.252
speed 100
full-duplex
mpls ip
!
router ospf 100
log-adjacency-changes
network 172.16.0.0 0.0.255.255 area 0
network 192.168.1.0 0.0.0.255 area 0
!
router rip
version 2
!
address-family ipv4 vrf ClientB
redistribute bgp 64999 metric 1
network 10.0.0.0
no auto-summary
version 2
exit-address-family
!
address-family ipv4 vrf ClientA
redistribute bgp 64999 metric 1
network 10.0.0.0
no auto-summary
version 2
exit-address-family
!
router bgp 64999
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 172.16.1.3 remote-as 64999
neighbor 172.16.1.3 update-source Loopback0
!
address-family vpnv4
neighbor 172.16.1.3 activate
neighbor 172.16.1.3 send-community extended
neighbor 172.16.1.3 next-hop-self
exit-address-family
!
address-family ipv4 vrf ClientB
redistribute rip metric 1
no synchronization
exit-address-family
!
address-family ipv4 vrf ClientA
redistribute rip metric 1
no synchronization
exit-address-family
!
!

PE2

hostname PE_2
!
ip vrf ClientA
rd 999:1
route-target export 64999:1
route-target import 64999:1
!
ip vrf ClientB
rd 999:2
route-target export 64999:2
route-target import 64999:2
!
!

interface Loopback0
ip address 172.16.1.3 255.255.255.255
!
interface FastEthernet0/0
ip vrf forwarding ClientA
ip address 10.1.1.6 255.255.255.252
speed 100
full-duplex
!
interface FastEthernet0/1
ip vrf forwarding ClientB
ip address 10.1.1.6 255.255.255.252
speed 100
full-duplex
!
interface FastEthernet1/0
ip address 192.168.1.5 255.255.255.252
speed 100
full-duplex
mpls ip
!
!
router ospf 100
log-adjacency-changes
network 172.16.0.0 0.0.255.255 area 0
network 192.168.1.0 0.0.0.255 area 0
!
interface Loopback0
ip address 172.16.1.3 255.255.255.255
!
interface FastEthernet0/0
ip vrf forwarding ClientA
ip address 10.1.1.6 255.255.255.252
speed 100
full-duplex
!
interface FastEthernet0/1
ip vrf forwarding ClientB
ip address 10.1.1.6 255.255.255.252
speed 100
full-duplex
!
interface FastEthernet1/0
ip address 192.168.1.5 255.255.255.252
speed 100
full-duplex
mpls ip
!
router ospf 100
log-adjacency-changes
network 172.16.0.0 0.0.255.255 area 0
network 192.168.1.0 0.0.0.255 area 0
!

router rip
version 2
!
address-family ipv4 vrf ClientB
redistribute bgp 64999 metric 1
network 10.0.0.0
no auto-summary
version 2
exit-address-family
!
address-family ipv4 vrf ClientA
redistribute bgp 64999 metric 1
network 10.0.0.0
no auto-summary
version 2
exit-address-family
!
router bgp 64999
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 172.16.1.1 remote-as 64999
neighbor 172.16.1.1 update-source Loopback0
!
address-family vpnv4
neighbor 172.16.1.1 activate
neighbor 172.16.1.1 send-community extended
neighbor 172.16.1.1 next-hop-self
exit-address-family
!

address-family ipv4 vrf ClientB
redistribute rip metric 1
no synchronization
exit-address-family
!
address-family ipv4 vrf ClientA
redistribute rip metric 1
no synchronization
exit-address-family
!
!

P Router (MPLS) 

The P router is a very simple configuration, not caring about VRFs or anything, only making label
switching decisions based on the top label.

 

ip cef
mpls label protocol ldp
!
!

interface Loopback0
ip address 172.16.1.2 255.255.255.255
!
interface FastEthernet0/0
ip address 192.168.1.2 255.255.255.252
speed 100
full-duplex
mpls ip
!
interface FastEthernet0/1
ip address 192.168.1.6 255.255.255.252
speed 100
full-duplex
mpls ip
!
router ospf 100
log-adjacency-changes
network 172.16.0.0 0.0.255.255 area 0
network 192.168.1.0 0.0.0.255 area 0
!
!

CE Routers

CE routers are a very basic config. They are completely unaware that MPLS/VPN is going on.
All they really know is that their full mesh WAN is costing them a whole lot less then it used to 😉

I am only including the configuration for one CE router in an effort to keep this short.
All four are configured in a similar way.

hostname CE_A1
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.252
speed 100
full-duplex
!
router rip
version 2
network 10.0.0.0
no auto-summary

!
!

hostname CE_A2
!
interface FastEthernet0/0
ip address 10.1.1.5 255.255.255.252
speed 100
full-duplex
!
router rip
version 2
network 10.0.0.0
no auto-summary

!
!

hostname CE_B1
!
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.252
speed 100
full-duplex
!
router rip
version 2
network 10.0.0.0
no auto-summary

!
!

hostname CE_B2
!
interface FastEthernet0/0
ip address 10.1.1.5 255.255.255.252
speed 100
full-duplex
!
router rip
version 2
network 10.0.0.0
no auto-summary

!
!

 

 

 

 

 

Intro to VRF lite

 

VRFs, or VPN Routing and Forwarding instances, are most commonly associated with MPLS
service providers. In such networks, MPLS encapsulation is used to isolate individual customers’
traffic and an independent routing table (VRF) is maintained for each customer. Most often, MP-BGP
is employed to facilitate complex redistribution schemes to import and export routes to and from VRFs to
provide Internet connectivity.

However, VRF configuration isn’t at all dependent on MPLS (the two components just work well together).
In Cisco terminology, deployment of VRFs without MPLS is known as VRF lite, and this article discusses a
scenario where such a solution could come in handy.

Assume the topology illustrated below is a network owned by an enterprise. As you would expect, normal
company traffic must pass through the firewall so that company policy can be enforced. However, this a
secondary Internet connection has been added to this network: an unrestricted ADSL circuit designated for
guests visiting the company campus.

The 10.0.0.0/16 network is used for trusted traffic
The 192.168.0.0/16 is used for guest traffic.

All router interfaces which provide transport for both types of traffic have been configured with
two subinterfaces performing 802.1Q encapsulation; .

10 for VLAN 10 (blue)
20 for VLAN 20 (red).

Note that although 802.1Q encapsulation is used to tag frames across the link, each link is a
routed segment
with an IP interface at either end. For example, here is R1’s F2/0 configuration

 

R1

interface FastEthernet2/0
description R1
no ip address
!
interface FastEthernet2/0.10
encapsulation dot1Q 10
description VRF_BLUE
ip address 10.0.12.1 255.255.255.252

!
interface FastEthernet2/0.20
encapsulation dot1Q 20
description VRF_RED
ip address 192.168.12.1 255.255.255.252
!

We employ VRFs here to segment the single physical infrastructure into two virtual, isolated networks.
VRFs employ essentially the same concept as VLANs and trunking, but at layer three. 

VRF lite is simple: each routed interface (whether physical or virtual) belongs to exactly one VRF.
Unless import/export maps have been applied, routes (and therefore packets) cannot move from one
VRF to another, much like the way VLANs work at layer two.

Packets entering VRF A can only follow routes in routing table A, as we’ll see shortly.

To begin, let’s create VRFs BLUE and RED on R1:

R1(config)# ip vrf BLUE
R1(config-vrf)# description Trusted Traffic
R1(config-vrf)# ip vrf RED
R1(config-vrf)# description Guest Traffic

!

Next, we’ll add interface F1/0 (which connects to the guest-use ADSL uplink) to VRF RED:

R1(config)# int f1/0
R1(config-if)# ip vrf forwarding RED
!

% Interface FastEthernet1/0 IP address 192.168.0.2 removed due to enabling VRF RED
Wait a tick, what just happened?

When assigning an interface to a VRF, IOS automatically deletes any preconfigured IP address
to remove that route from the global table. Now when an IP address is assigned to this interface,
its network gets added to the specific routing table for that VRF.

So, we reapply our IP to F1/0.

R1(config-if)# ip add 192.168.0.2 255.255.255.252


 Current configuration of F1/0
!
interface FastEthernet1/0
description RX
ip vrf forwarding RED
ip address 192.168.0.2 255.255.255.252
!
The 192.168.0.0/30 route is gone from the global table; it now resides in the VRF RED table,
which we have to inspect separately by appending the vrf argument to show ip route:

R1# show ip route vrf RED

[…]

192.168.0.0/30 is subnetted, 1 subnets
C 192.168.0.0 is directly connected, FastEthernet1/0

 As you can imagine, this extra step of reapplying an IP address must be repeated for every interface
we add to a VRF.

Relevant finished configuration of R1:

interface FastEthernet1/0
description RX
ip vrf forwarding RED
ip address 192.168.0.2 255.255.255.252
!
interface FastEthernet1/1
description FW
ip vrf forwarding BLUE
ip address 10.0.0.2 255.255.255.252
!
!

!
interface FastEthernet2/0
description R2
no ip address
!
interface FastEthernet2/0.10
encapsulation dot1Q 10
ip vrf forwarding BLUE
ip address 10.0.12.1 255.255.255.252
!
interface FastEthernet2/0.20
encapsulation dot1Q 20
ip vrf forwarding RED
ip address 192.168.12.1 255.255.255.252
!
!
!
interface FastEthernet2/1
description R3
no ip address
!
interface FastEthernet2/1.10
encapsulation dot1Q 10
ip vrf forwarding BLUE
ip address 10.0.13.1 255.255.255.252
!
interface FastEthernet2/1.20
encapsulation dot1Q 20
ip vrf forwarding RED
ip address 192.168.13.1 255.255.255.252
!
As all interfaces now belong to isolated VRFs, our global routing table is completely empty.
We can verify that all 10.0.0.0/16 routes are stored in VRF BLUE, and all 192.168.0.0/16 routes
are stored in VRF RED:

show ip route vrf BLUE
show ip route vrf RED

At this point, although only R1 has been configured with VRFs, it can still route traffic to R2 and R3
with no problem. This is because, like VLANs, VRFs are only locally significant to the router.

##########################

R2 VRF Configuration :

ip vrf BLUE
description Trusted Traffic
!
ip vrf RED
description GUEST
!
!
interface FastEthernet0/0
no ip address
!

interface FastEthernet0/0.10
encapsulation dot1Q 10
ip vrf forwarding BLUE
ip address 10.0.12.2 255.255.255.252
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip vrf forwarding RED
ip address 192.168.12.2 255.255.255.252
!
!
R3 VRF Configuration :

ip vrf BLUE
description Trusted Traffic
!
ip vrf RED
description GUEST
!
!

interface FastEthernet0/0
no ip address
!
interface FastEthernet0/0.10
encapsulation dot1Q 10
ip vrf forwarding BLUE
ip address 10.0.13.2 255.255.255.252
!
interface FastEthernet0/0.20
encapsulation dot1Q 20
ip vrf forwarding RED
ip address 192.168.13.2 255.255.255.252
!
!
##########################

Now configure our IGP. For this example, we’ll be running an OSPF instance per VRF.
We do this by appending the vrf argument to each router statement:

R1(config)# router ospf 1 vrf BLUE
R1(config-router)# router-id 0.0.1.1
R1(config-router)# network 10.0.0.0 0.0.255.255 area 0
!
R1(config-router)# router ospf 2 vrf RED
R1(config-router)# router-id 0.0.1.2
R1(config-router)# network 192.168.0.0 0.0.255.255 area 0
!
These are completely independent OSPF processes; as such, a unique router ID must be used for each.
(If you’re used to using IPv4 addresses as router ID, the IDs used above might seem strange.

Remember that the OSPF router ID is in fact an arbitrary 32-bit value simply expressed
in dotted-decimal.

Here, the third “octet” represents the router number and the fourth octet represents the VRF.)

After configuring the other two routers with two OSPF processes each,
we see two adjacencies formed per link, one per VRF:

R1 :

 

router ospf 1 vrf BLUE
router-id 0.0.2.1
log-adjacency-changes
network 10.0.0.0 0.0.255.255 area 0
!
router ospf 2 vrf RED
router-id 0.0.2.2
log-adjacency-changes
network 192.168.0.0 0.0.255.255 area 0

R3 :

router ospf 1 vrf BLUE
router-id 0.0.3.1
log-adjacency-changes
network 10.0.0.0 0.0.255.255 area 0
!
router ospf 2 vrf RED
router-id 0.0.3.2
log-adjacency-changes
network 192.168.0.0 0.0.255.255 area 0


Assuming our edge routers aren’t running OSPF, we’ll also create two static default routes
on R1, one for each VRF:

R1(config)# ip route vrf BLUE 0.0.0.0 0.0.0.0 10.0.0.1
R1(config)# ip route vrf RED 0.0.0.0 0.0.0.0 192.168.0.1


We can verify that our static routes exist along with their OSPF-learned companions in their
respective VRFs:

Finally we just need to advertise a default route in both OSPF processes from R1 so
R2 and R3 can learn them:

R1(config)# router ospf 1
R1(config-router)# default-information originate
!
R1(config-router)# router ospf 2
R1(config-router)# default-information originate

Note that when entering OSPF process configuration, we no longer need to append the
vrf keyword as it has already been applied.

Over to R2 we see that each VRF now has its own complete routing table:

show ip route vrf BLUE
O*E2 0.0.0.0/0 [110/1] via 10.0.12.1, 00:03:33, FastEthernet1/0.10

show ip route vrf RED
O*E2 0.0.0.0/0 [110/1] via 192.168.12.1, 00:01:41, FastEthernet1/0.20

 

 

IP prefix-list

ip prefix-list provides the most powerful prefix based filtering mechanism

Here is a quick little tutorial on Prefix-lists for you.

A normal access-list CANNOT check the subnet mask of a network. It can only check bits to make
sure they match, nothing more. A prefix-list has an advantage over an access-list in that it CAN
check BOTH bits and subnet mask – both would have to match for the network to be either

permitted or denied
.

For checking bits a prefix list ALWAYS goes from left to right and CANNOT skip any bits.

A basic example would be this:

172.16.8.0/24

ip prefix-list OSPF_Redist seq 5 permit 172.16.8.0/24
ip prefix-list OSPF_Redist seq 10 permit 0.0.0.0/0 l
e 32

If there is only a / after the network (no le or ge) then the number after the / is BOTH bits checked and
subnet mask. So in this case it will check the 24 bits from left to right (won’t care about the last 8 bits)
AND it will make sure that it has a 24 bit mask. BOTH the 24 bits checked and the 24 bit
subnet mask must match for the network to be permitted or denied
.

!
Now we can do a range of subnet masks also that could be permitted or denyed:

172.16.8.0/24 ge 25

If we use either the le or ge (or both le and ge) after the /, then the number directly after the /
becomes ONLY bits checked and the number after the
ge or le (or both) is the subnet mask.
So in this case we are still going to check the first 24 bits of the network from left to right.
If those match we are then going to check the subnet mask, which in this case can be

GREATER THAN OR EQUAL TO 25 bitsmeaning that as long as the first 24 bits of the
network match the
subnet mask could be 25,26,27,28,29,30,31,or 32 bits. They would all match.

!
We can also do:

172.16.8.0/24 le 28

Again this will check the first 24 bits of the network to make sure that they match.
Then it will check to make sure that the subnet mask is
LESS THAN OR EQUAL TO 28 bits.
Now this isn’t going to be 28 bits down to 0 bits
, the subnet mask can’t be any lower than the
bits we are checking
. So the valid range of subnet masks for this one would be 28 bits down to
24 bits (24,25,26,27,and 28)
. All of those would match.

!
Again this will check the first 24 bits of the network to make sure that they match. Then it
will check to make sure that the
subnet mask is LESS THAN OR EQUAL TO 28 bits.
Now this isn’t going to be 28 bits down to 0 bits, the subnet mask can’t be any lower than the
bits we are checking. So the valid range of subnet masks for this one would be

28 bits down to 24 bits (24,25,26,27,and 28)
. All of those would match.

We can also do both ge and le:

172.16.8.0/24 ge 25 le 27

!
Here again we are checking the first 24 bits to make sure they match. Then our subnet mask must be
GREATER THAN OR EQUAL TO 25 bits LESS THAN OR EQUAL TO 27 bits
.
Meaning that 25,26,and 27 bit subnet masks would match.

Now for a couple of examples:

If we have the following networks:

172.16.8.0/28
172.16.8.16/28
172.16.8.32/28
172.16.8.48/28
172.16.8.64/28

We could permit all of these networks with on prefix-list statement:

172.16.8.0/24 ge 28 le 28

Cisco VRF Routing

Create VRF :

ip vrf comms
rd 34790:1002
route-target export 34790:1002
route-target import 34790:1002

!
!

interface Loopback0
ip vrf forwarding comms ( Bind to Interface )
ip address ( public ip address )
!
interface GigabitEthernet0/0
description comms hq circuit
ip vrf forwarding comms
ip address 192.168.250.18 255.255.255.252
!
interface GigabitEthernet0/1
description comms hq_sw1
ip vrf forwarding
comms
ip address 172.31.31.62 255.255.255.252   ( primary link )
ip ospf network point-to-point
ip ospf demand-circuit
ip ospf 1 area 1
!
interface FastEthernet0/0/0
description comms hq_sw2
ip vrf forwarding
comms
ip address 172.31.31.66 255.255.255.252   ( backup link )
ip ospf network point-to-point
ip ospf demand-circuit
ip ospf 1 area 1
!
router ospf 1 vrf
comms
redistribute connected subnets
redistribute bgp 64514 subnets
distribute-list prefix cust_routes in
!
router bgp 64514
bgp router-id 1.1.1.1
bgp log-neighbor-changes
no auto-summary
!
address-family ipv4 vrf comms
redistribute connected
redistribute static
redistribute ospf 1 vrf comms match internal external 1 external 2
neighbor 192.168.250.17 remote-as 34790
neighbor 192.168.250.17 activate
neighbor 192.168.250.17 soft-reconfiguration inbound
exit-address-family
!
ip route vrf genesis 10.0.2.240 255.255.255.255 172.31.31.61
ip route vrf genesis 10.0.2.240 255.255.255.255 172.31.31.65 200
!
ip tacacs source-interface Loopback0
!
!
ip prefix-list cust_routes seq 10 permit 10.200.20.0/24 le 32
ip prefix-list cust_routes seq 20 permit 10.200.21.0/24 le 32
ip prefix-list cust_routes seq 30 permit 10.200.22.0/24 le 32
ip prefix-list cust_routes seq 40 permit 10.200.23.0/24 le 32
ip prefix-list cust_routes seq 50 permit 10.194.0.0/22 le 32
!
line vty 0 4
access-class 23 in vrf-also ( Same access list is applied for all VRFs )
privilege level 15
logging synchronous
transport input telnet ssh

VRF Route Target

MPLS VPN implementation requires VRF and also exporting and importing routes for that VRF.
I mentioned on my previous posts about VRF that the VRF name is locally significant and even the RD number.
What counts is what you import and export.

Importing and exporting route targets use the same syntax as the RD and it is ASN:NN
as shown by the example below
:

ip vrf ALL-VRF
rd 123:4
route-target export 123:4
route-target import 123:1
route-target import 123:2
route-target import 123:3

By definition the routes that you “export” are only the routes you advertise on the
vrf address family in BGP. The routes that you import are the cummulative routes with
the same label that were exported from the other routers participating in the MPLS VPN.
Remember that you don’t export what you have learned through importation
.

In a VRF you can export and import as many route-targets as needed.
Lets see if RR can see the routes now :

RR

!
ip vrf ALL-VRF
rd 123:4
route-target export 123:4
route-target import 123:1
route-target import 123:2
route-target import 123:3

RR#sh ip route vrf ALL-VRF

Routing Table: ALL-VRF
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
    D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
    N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
    E1 - OSPF external type 1, E2 - OSPF external type 2
    i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
    ia - IS-IS inter area, * - candidate default, U - per-user static route
    o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

  1.0.0.0/32 is subnetted, 1 subnets
B       1.1.1.1 [200/0] via 123.123.123.1, 00:46:26
  2.0.0.0/32 is subnetted, 1 subnets
B       2.2.2.2 [200/0] via 123.123.123.2, 00:46:26
  33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 00:46:26
  3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 00:46:26
  22.0.0.0/32 is subnetted, 1 subnets
B       22.22.22.22 [200/0] via 123.123.123.2, 00:46:26
  11.0.0.0/32 is subnetted, 1 subnets
B       11.11.11.11 [200/0] via 123.123.123.1, 00:46:28
  123.0.0.0/32 is subnetted, 1 subnets
C       123.123.123.14 is directly connected, Loopback40

Scenario Conditions :

1. EMEA should have full ip reachability to APAC and AMERICAS but APAC and AMERICAS
should not see each other.
2. RR should only see the all the routes but will not be seen by the routers
.

Below are the VRF configurations on the 3 clients.

APAC#

!
ip vrf APAC
rd 123:1
route-target export 123:1
route-target import 123:2

AMERICAS#

!
ip vrf AMERICAS
rd 123:2
route-target export 123:2
route-target import 123:2

EMEA#
!
ip vrf EMEA
rd 123:3
route-target export 123:3
route-target export 123:2
route-target import 123:4
route-target import 123:2

APAC is exporting route-target 123:1 and its importing 123:3 which is exported by EMEA.

EMEA on the other hand is importing 123:1 and exporting 123:3. There should be full ip
reachability between the two.

By the way the route-target ID doesn’t necessarily match with the RD. Normally for networks that should
see each other in MPLS VPN both the export and import route target ID’s are the same.
It will get rid of any unnecessary confusion created by using different RT ID’s.
Take into consideration AMERICAS and EMEA routers
.

As you can see on the config above,
AMERICAS is importing and exporting 123:2.
One command can generate the both export and import and that is “route-target both 123:2“.
EMEA
is importing and exporting also 123:2 which means they will reach each other.
Let’s test if we have accomplished the condition, we will show the routing table in
APAC and AMERICAS and let’s ping the networks in EMEA
.

The ping should be sourced on the loopback interfaces where we configured the VRF’s.

APAC#sh ip route vrf APAC

Routing Table: APAC
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
    D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
    N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
    E1 - OSPF external type 1, E2 - OSPF external type 2
    i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
    ia - IS-IS inter area, * - candidate default, U - per-user static route
    o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

  1.0.0.0/32 is subnetted, 1 subnets
C       1.1.1.1 is directly connected, Loopback0
  33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 01:04:51
  3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 01:04:51
  11.0.0.0/32 is subnetted, 1 subnets
C       11.11.11.11 is directly connected, Loopback10

APAC#ping vrf APAC 3.3.3.3 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 248/346/436 ms

AMERICAS#sh ip route vrf AMERICAS

Routing Table: AMERICAS
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
    D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
    N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
    E1 - OSPF external type 1, E2 - OSPF external type 2
    i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
    ia - IS-IS inter area, * - candidate default, U - per-user static route
    o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

  2.0.0.0/32 is subnetted, 1 subnets
C       2.2.2.2 is directly connected, Loopback0
  33.0.0.0/32 is subnetted, 1 subnets
B       33.33.33.33 [200/0] via 123.123.123.3, 00:56:20
  3.0.0.0/32 is subnetted, 1 subnets
B       3.3.3.3 [200/0] via 123.123.123.3, 00:56:20
  22.0.0.0/32 is subnetted, 1 subnets
C       22.22.22.22 is directly connected, Loopback10

AMERICAS#ping vrf AMERICAS 3.3.3.3 source lo0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 3.3.3.3, timeout is 2 seconds:
Packet sent with a source address of 2.2.2.2
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 184/593/1020 ms

EMEA#sh ip route vrf EMEA

Routing Table: EMEA
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
    D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
    N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
    E1 - OSPF external type 1, E2 - OSPF external type 2
    i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
    ia - IS-IS inter area, * - candidate default, U - per-user static route
    o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

  1.0.0.0/32 is subnetted, 1 subnets
B       1.1.1.1 [200/0] via 123.123.123.1, 00:00:00
  2.0.0.0/32 is subnetted, 1 subnets
B       2.2.2.2 [200/0] via 123.123.123.2, 01:07:06
  33.0.0.0/32 is subnetted, 1 subnets
C       33.33.33.33 is directly connected, Loopback10
  3.0.0.0/32 is subnetted, 1 subnets
C       3.3.3.3 is directly connected, Loopback0
  22.0.0.0/32 is subnetted, 1 subnets
B       22.22.22.22 [200/0] via 123.123.123.2, 01:07:06
  11.0.0.0/32 is subnetted, 1 subnets
B       11.11.11.11 [200/0] via 123.123.123.1, 00:00:03


It will take a while to get used to VRF Route-target if you are just learning it but this
should be pretty easy. Remember, you can’t reach a network that you have imported unless
it exported your network. In MPLS VRF, entries in your VRF routing table doesn’t assure
reachability, the router in the destination network should also have your network in its
VRF routing table.

VRF Basics

When we hear about VRF, its almost synonymous to MPLS VPN. Virtual Routing and Forwarding is
commonly used by Service Providers to provide services within an MPLS cloud with multiple customers.

The most interesting feature of this is that, VRF allows creation of multiple routing tables within a
single router. This means that overlapping use of IP addresses from different customers is possible
.

Through the network setup below, we will see how to configure VRF and check if its really possible for
duplicate ip addresses
.

We have 3 customers in the figure connected to a Provider Edge router.
We will name the VRF’s Blue, Red and Yellow.

Now let’s configure RD’s on the PE router.

Router(config)#host PE
PE(config)#ip vrf blue
PE(config-vrf)#rd 1:1
PE(config-vrf)#ip vrf red
PE(config-vrf)#rd 2:2
PE(config-vrf)#ip vrf yellow
PE(config-vrf)#rd 3:3

Basically the “rd” command is in the format ASN:nn or IP-address:nn. The VRF names and rd values
are actually locally significant which means that it doesn’t matter what name you create.

What really matters is the “route target” value because this is what you will import or export.

Now we have created VRF’s, lets configure interfaces and apply the VRF’s to the interfaces.

PE(config)#int fa0/0.2
PE(config-subif)#encapsulation dot1q 2
PE(config-subif)#ip vrf forwarding blue
PE(config-subif)#ip address 1.1.1.1 255.255.255.252
PE(config-subif)#int fa0/0.3
PE(config-subif)#encapsulation dot1q 3
PE(config-subif)#ip vrf forwarding red
PE(config-subif)#ip address 1.1.1.1 255.255.255.252
PE(config-subif)#int fa0/0.4
PE(config-subif)#encapsulation dot1q 4
PE(config-subif)#ip vrf forwarding yellow
PE(config-subif)#ip address 1.1.1.1 255.255.255.252

If you notice above all interfaces have the same ip address which is 1.1.1.1.
Normally without VRF, the router will give a warning message that

overlapping ip addresses are not allowed
.

The commandip vrf forwardingwill add the vrf to a specific interface.

Blue#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/35/80 ms

Red#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/48/156 ms

Yellow#ping 1.1.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/60/136 ms

It’s good! We have ip reachability to PE from the CE routers. Now, from PE point of view,
how will
PE know which one to ping if we use 1.1.1.2 since all Blue, Red and Yellow
routers use the same ip
?

This can be accomplished using the “ping vrf ” command. See below.

PE#ping vrf blue 1.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/28/68 ms

PE#ping vrf red 1.1.1.2 

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/28/88 ms

PE#ping vrf yellow 1.1.1.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 1.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/31/68 ms

Now, we have proven that duplicate IP addresses is possible using VRF. Be reminded that VRF’s are
usually
and by standard configured on PE routers. CE routers normally don’t make use of VRF’s but
there are  always exceptions

To make this work you do require a switch between the PE and the CE Routers.
You must set the Switch port mode for the PE Router-to-Switch to dot1q (i.e trunk) and the
Switch port mode for each
CE Router-to-Swith to access with the respective vlan
(i.e blue=2,red=3, yellow=4).

Hope that helps!

ASA – Group Object

Create a Object-Group icmp-type ICMP traffic :

object-group icmp-type INBOUND
description Permit necessary inbound ICMP traffic
icmp-object echo
icmp-object echo-reply
icmp-object unreachable
icmp-object time-exceeded

Create a Object-Group service for TCP traffic :

object-group service INBOUND tcp
description Inbound Access
port-object eq 3389
port-object range 9998 9999