Facts to remember about MPLS - Part 1

VRF Lite

• VRF (Virtual Routing and Forwarding) tables turn a single router into multiple virtual routers
• Any router interface can be assigned to a VRF using the command "ip vrf forwarding <VRF_NAME>", this command will erase any ip address in the interface
• To create a new VRF, issue the command "ip vrf <VRF_NAME>"
• After this initial step, you must define a route distinguisher (RD) for this particular VRF using the command "rd X:Y", where X and Y are 32-bit numbers.
• A Route Distinguisher is a special 64-bit prefix prepended to every route in the respective VRF routing table. This is done for the purpose of distinguishing the prefixes inside the router and avoiding collisions if two VRFs contain the same prefixes.
• The syntax for a VRF-bound static route is "ip route vrf <NAME> PREFIX MASK [interface] [next-hop]", where [next-hop] is an IP address resolvable through the VRF

R6:
ip vrf VPN_A
 rd 100:1
!
ip vrf VPN_B
 rd 100:2
!
interface GigabitEthernet1.67
 ip vrf forwarding VPN_A
 ip address 155.1.67.6 255.255.255.0
!
interface GigabitEthernet1.76
 ip vrf forwarding VPN_B
 ip address 155.1.76.6 255.255.255.0
!
ip route vrf VPN_A 192.168.7.0 255.255.255.0 GigabitEthernet1.76 155.1.76.7
ip route vrf VPN_B 172.16.7.0 255.255.255.0 GigabitEthernet1.67 155.1.67.7




MPLS LDP

• Use the interface level configuration command "mpls ip" to enable MPLS in a interface
• If OSPF is the IGP then "mpls ldp autoconfig" will enable MPLS in all the OSPF interfaces
• At he begining the multicast address 224.0.0.2 on port 646 is used to find valid neighbors. after that a TCP connection is established on port 646
• "mpls ldp router-id <interface> force" will change  LDP Router IDs which is the highest loopback ip address by default
• "mpls ldp discovery transport-address interface" will use the physical ip address of the interface to establish the TCP connection if neighbor loopback  unreachable
• The hashing key is defined per-neighbor by using the command "mpls ldp neighbor <IP> password <password>". The IP address here is the neighbor’s LDP Router ID. To make the use of passwords mandatory, you need the global command "mpls ldp password required"
• After the transport connection has been established, the routers exchange prefix and label bindings, resulting in LFIB population. The exchange is performed over the TCP connection established previously

mpls ip
!
mpls ldp router-id Loopback0 force
!
interface GigabitEthernet1.146
 mpls ldp discovery transport-address interface
!
router ospf 1
 mpls ldp autoconfig
!
mpls ldp password required
mpls ldp neighbor 150.1.5.5 password CISCO
mpls ldp neighbor 150.1.6.6 password CISCO




MPLS Label Filtering

By default, LDP will generate and advertise labels for every prefix found in the local routing table. If you want to change this behavior and generate labels only for specific prefixes, you may use an access-list to select the prefixes eligible for label generation

R4, R5, R6:
access-list 10 permit 150.1.0.0 0.0.255.255
!
no mpls ldp advertise-labels
mpls ldp advertise-labels for 10

MP-BGP VPNv4

• The purpose of MPLS VPNs is to establish a full-mesh of dynamic MPLS LSRs between the PE (Provider Edge) routers and use those for tunneling VPN packets across the network core
• Two labels in the MPLS stack; one label (the topmost) is the transport label, which is being swapped along the entire path between the PEs, and the other label (innermost) is the VPN label, which is used to select the proper outgoing VRF CEF entry.
• A new special MP-BGP (multiprotocol BGP) address family named VPNv4 (VPN IPv4) has been added to BGP along with a new NLRI format. Every VPNv4 prefix has the RD associated with it and the corresponding MPLS label, in addition to the normal BGP attributes.
•  By default, when you create a new BGP neighbor using the command "neighbor <IP> remote-as <NR>", the default IPv4 unicast address-family is activated for this neighbor. If for some reason you don’t want this behavior and only need the VPNv4 prefixes to be sent, you may disable the default behavior via the command "no bgp default ipv4-unicast".
• There are special limitations for iBGP peering sessions that you want to enable for VPNv4 prefix exchange. First, they must be sourced from a Loopback interface, and second, this interface must have a /32 mask (this is not a strict requirement on all platforms)
• To inject a particular VRF’s routes into BGP, you must activate the respective address-family under the BGP process and enable route redistribution (such as static or connected). All the respective routes belonging to that particular VRF will be injected into the BGP table with their RDs and have their VPN labels generated. The import process is a bit more complicated and is based on the concept of Route Targets.
• A Route Target is a BGP extended community attribute. These BGP attributes are transitive and encoded as 64-bit values (as opposed to normal 32-bit communities). They are used for enhanced tagging of VPNv4 prefixes. The need for route-target arises from the fact that you cannot just use Route Distinguishers for prefix importing/exporting, because routes with the same RD may eventually belong to multiple VRFs, when you share their routes.
•  By default, all prefixes redistributed from a VRF into a BGP process are tagged with the extended community X:Y specified under the VRF configuration via the command "route-target export X:Y". On the receiving side, the VRF will import the BGP VPNv4 prefixes with the route-targets matching the local command "route-target import X:Y."

Enable VPN route exchange between R5 and R6, using R4 as the BGP route-reflector. R6 was already configured with the VRF

R4:
router bgp 100
 no bgp default ipv4-unicast
 neighbor 150.1.5.5 remote-as 100
 neighbor 150.1.5.5 update-source Loopback0
 neighbor 150.1.6.6 remote-as 100
 neighbor 150.1.6.6 update-source Loopback0
!
address-family vpnv4 unicast
 neighbor 150.1.5.5 activate
 neighbor 150.1.6.6 activate
 neighbor 150.1.5.5 send-community extended
 neighbor 150.1.6.6 send-community extended
 neighbor 150.1.5.5 route-reflector-client
 neighbor 150.1.6.6 route-reflector-client

R5:
ip vrf VPN_A
 rd 100:1
 route-target both 100:1
!
ip vrf VPN_B
 rd 100:2
 route-target both 100:2
!
interface GigabitEthernet1.58
 ip vrf forwarding VPN_A
 ip address 155.1.58.5 255.255.255.0
!
interface GigabitEthernet1.5
 ip vrf forwarding VPN_B
 ip address 155.1.5.5 255.255.255.0

R6:
ip vrf VPN_A
 rd 100:1
 route-target both 100:1
!
ip vrf VPN_B
 rd 100:2
 route-target both 100:2

R5 , R6:
router bgp 100
 no bgp default ipv4-unicast
 neighbor 150.1.4.4 remote-as 100
 neighbor 150.1.4.4 update-source Loopback0
!
address-family vpnv4 unicast
 neighbor 150.1.4.4 activate
 neighbor 150.1.4.4 send-community extended
!
 address-family ipv4 vrf VPN_A
  redistribute connected
  redistribute static
! 
 address-family ipv4 vrf VPN_B
  redistribute connected
  redistribute static

MP-BGP Prefix Filtering

• [import|export] map <ROUTE_MAP_NAME> allows a more granular control over route tagging than route-target
• export/import maps are configured under the VRF configuration context and they could match prefixes based on the prefix-lists, access-lists, or extended-communities.
• All routes not permitted in an export/import route-map are not exported/import into the BGP process

R6:
interface Loopback102
 ip vrf forwarding VPN_B
 ip address 192.168.6.6 255.255.255.0
!
ip prefix-list LO102 permit 192.168.6.0/24
!
route-map VPN_B_EXPORT permit 10
 match ip address prefix-list LO102
 set extcommunity rt 100:66
!
route-map VPN_B_EXPORT permit 20
 set extcommunity rt 100:2
!
ip vrf VPN_B
 export map VPN_B_EXPORT
 route-target import 100:55

PE-CE Routing with RIP

• With RIPv2, you may enable the respective address family under the process configuration mode using the command address-family ipv4 vrf <VRF_NAME>
• You can't create a separate RIP process for each VRF, the whole RIP process is shared among VRF's
• To redistribute MP-BGP routes into RIP, use the command "redistribute bgp <N> metric [X|transparent]" under the respective address family. Here, N is the BGP process number (AS#) and X is the metric assigned to the RIP routes. With the keyword transparent, the RIP metrics will be recovered from the BGP MED attribute, which in turn is copied from RIP metrics learned at the remote site. This allows for transparent preservation of RIPv2 metric values across the VPN and better path selection in case of backdoor links

R6:
router rip
 version 2
 address-family ipv4 vrf VPN_B
  redistribute bgp 100 metric transparent
  network 155.1.0.0
  network 192.168.6.0
!
router bgp 100
 address-family ipv4 vrf VPN_B
  redistribute rip

PE-CE Routing with OSPF

• When using OSPF as the PE-CE routing protocol in combination with MP-BGP, the ISP MPLS VPN backbone is considered by OSPF as a “super area 0” or "OSPF Super backbone area"
• The result is we can have non-zero OSPF areas at different sites connecting via the MP-BGP mesh without the need for area 0 at any site
•  All OSPF routes redistributed into MP-BGP are treated as inter-area routes as they enter the super-backbone from other areas even if they belong to the same area number at different sites because all PEs are seen as Area Border Router (ABR) from the CE router perspective
•  MP-BGP uses three extended communities in order to transparently transport OSPF prefix over the MPLS VPN backbone which are implemented automatically after you configure route redistribution between a VRF process and BGP.

OSPF domain-id: It is the OSPF process number on PE It is assumed that you configured all OSPF process number for the same VPN using the same process number. If the domain-id is different, OSPF will interpret all such prefixes as if they are Type-5 External LSAs

OSPF Route Type which has 3 significant fields: source area, route-type and option and has the following format: X:Y:Z.. X represents the area number and Y represents the LSA type (LSA 3, 5,7). Z is the option field and defines the metric type for LSA Type-5 or Type-7 (E1, E2, N1, N2). This attribute helps the BGP process to track the originating OSPF LSA type in order to make the correct redistribution from MP-BGP into OSPF. So if the origination LSA is type 5, MP-BGP will encode that and when doing redistribution on the other end of the MPLS VPN backbone, the PE will know that it should redistribute this route has LSA Type-5 E2 into OSPF.

OSPF router ID. Identifies the router ID of the PE in the relevant VRF instance of OSPF.

• The BGP MED attribute is used to carry the OSPF metric
•  OSPF implements some basic loop prevention rules. Down bit and Route Tagging
  

Down bit
If a router receives a summary-LSA with the down bit set on an interface that belongs to a VRF, it simply drops this LSA. In the example PE-3 has to choose between a prefix learned by iBGP and another one learned by OSPF (VRF interface), It will choose OSPF cause a lower AD. Here comes the loop cause R3 will redistribute the prefix again into BGP

However, this feature may have an undesirable effect when you have a CE router configured with multiple VRFs. In this case, you may want to enter the OSPF process command "capability vrf-lite" on the CE router. This will disable the default loop-prevention capability. Some IOS versions do not support this feature (such as older IOSs or some Catalyst IOS revisions). If you have such a router configured for multi-VRF and experience route black holing, configure the PE routers with different domain-IDs; this will force all redistributed routes to become external and bypass the down-bit check

Route Tagging
The DN bit helps preventing routing loops when summary Type-3 LSAs are redistributed, but not when external routes are announced (the DN bit is not set on LSA Type 5/7). All routes redistributed via a particular PE will carry the OSPF route tag which by default is the BGP AS number.
This tag is preserved when the external route is propagated across the entire OSPF domain (including redistribution into another OSPF domains). When another PE receives this route and it sees that the local AS number matches the AS number in the tag, it will ignore this LSA. Use the OSPF command "redistribute bgp N subnets tag Y"

OSPF Sham-Link
Situation/problem description: when there is a backup link between sites (backdoor), this link will be always used for inter-site traffic because intra-area routes (LSAs received via backdoor) are preferred to the inter-area (LSA 3 received from PE).
The solution to this problem is the usage of OSPF sham-links = special tunnel similar to virtual-links between PE routers and configured in the same area as the PEs.

Sham-links have the following characteristics:

• OSPF adjacency established via MPLS cloud
• Routes in the OSPF database are now seen as intra-area (even though they are received via the super-backbone)
• The information across the sham-link is ONLY used for SPF calculations – the actual forwarding is being done based on the info learned via MP-BGP
• Sham endpoints IP addresses (usually loopback interfaces) should be advertised into the VRF by means other than OSPF (commonly via BGP) – known before creating the sham-links.

R5:
router ospf 100 vrf VPN_A
 area 1 sham-link 150.1.55.55 150.1.66.66 cost 1
 no network 0.0.0.0 255.255.255.255 area 1
 network 155.1.58.5 0.0.0.0 area 1
!
interface Loopback 200
 ip vrf forwarding VPN_A
 ip address 150.1.55.55 255.255.255.255
!
router bgp 100
 address-family ipv4 vrf VPN_A
  network 150.1.55.55 mask 255.255.255.255