Multiprotocol Label Switching (MPLS)

Tunneling protocols encapsulate packets of a different protocol as the payload of a larger frame for delivery within networks utilizing the encapsulating protocol. Tunneling facilitates the delivery of payload over an incompatible delivery network and creates a secure path through an untrusted network. Protocols that this chapter describes include MPLS, Decap Groups, and Nexthop Groups.

sections in this chapter include:

MPLS

These sections describe the Arista MPLS implementation:

MPLS Description

MPLS Overview

Multiprotocol Label Switching (MPLS) is a networking process that replaces complete network addresses with short path labels for directing data packets to network nodes. The labels identify virtual links (paths) between distant nodes rather than endpoints. MPLS is scalable and protocol-independent. Data packets are assigned labels, which are used to determine packet forwarding destinations without examining the packet.

Arista switches utilize MPLS to improve efficiency and control from servers through data centers and to the WAN. The MPLS implementation supports static MPLS tunneling that is manually configured on each switch or established over a network by an SDN controller. The configuration is specified by a set of rules that filter packets based on matching criteria. Each rule applies MPLS-related actions to packets that match the rule's criteria. Each rule includes a metric that the switch uses to select an action when multiple rules match a packet.

MPLS Implementation

MPLS static rule parameters contain the following:

  • A 20-bit value that is compared to the top header label of each MPLS packet. Other rule parameters may be applied to packets whose top label match this value.
  • A nexthop location that specifies the packet’s next destination (IPv4 or IPv6) and the interface through which the switch forwards the packet.
  • An MPLS label stack management action that is performed on filtered packets:

    • pop-payload: removes the top label from stack; this terminates an LSP (label-switched path).
    • swap-label: replaces top label with a specified new label; this passes a packet along an LSP.
  • A rule metric that the switch uses to select a rule when multiple rules match an MPLS packet.

Packets that do not match any MPLS rules are dropped.

MPLSoGRE Filtered Mirroring

In MPLS over Generic Routing Encapsulation (MPLSoGRE) filtered mirroring, IPv4 over MPLS over GRE (IPv4oMPLSoGRE) and IPv6 over MPLS over GRE (IPv6oMPLSoGRE) packets that enter a GRE tunnel endpoint on which MPLS lookup is performed, are selected for mirroring based on the destination IP address field in the inner IPv4 or IPv6 header.

Note: These packets are not selected for mirroring if they are forwarded based on either the L2 or outer L3 header destination address.

the image below shows the header format of the packets that are selected for mirroring.

Figure 1. Header Format of Packets

When mirroring to a GRE tunnel, the payload of the outgoing GRE packet contains the payload of the incoming source packet starting from the MPLS header. L2 and outer L3 headers are stripped from the mirror copy. When the MPLS lookup fails, the packet is still eligible for mirroring based on the selection criteria defined in the ACL.

MPLS Configuration

MPLS routing is enabled through the mpls ip command.

  • This command enables MPLS routing.

switch(config)#mpls ip
switch(config)#show running-config mpls ip
!

end
switch(config)#

MPLS rules are created by thempls static command. MPLS static rules identify a set of MPLS packets by a common top label and defines the method of handling these packets.

These commands create an MPLS rule that matches packets with a top label value of 3400 and causes the removal of the top label from the header stack. The nexthop destination of the IPv4 payload is IP address 10.14.4.4 through Ethernet interface 3/3/3. This rule has a metric value of 100.

switch(config)#mpls static top-label 3400 ethernet 3/3/3 10.14.4.4 pop 
payload-type ipv4
switch(config)#show running-config

!
mpls static top-label 3400 Ethernet3/3/3 10.14.4.4 pop payload-type ipv4
!

end
switch(config)#

These commands create a backup rule that forwards the packet through Ethernet interface 4/3. This rule’s metric value of 150 assigns it backup status prior to the first rule.

switch(config)#mpls static top-label 3400 ethernet 4/3 10.14.4.4 pop payload-type 
ipv4 metric 150
switch(config)#show running-config

!
mpls static top-label 3400 Ethernet4/3 10.14.4.4 pop payload-type ipv4 metric 150
mpls static top-label 3400 Ethernet3/3/3 10.14.4.4 pop payload-type ipv4
!

end
switch(config)#

These commands create an MPLS rule that forwards the packet to the nexthop address through any interface.

switch(config)#mpls static top-label 4400 10.15.46.45 pop payload-type ipv4
switch(config)#show running-config

!
mpls static top-label 3400 Ethernet4/3 10.14.4.4 pop payload-type ipv4 metric 150
mpls static top-label 3400 Ethernet3/3/3 10.14.4.4 pop payload-type ipv4
mpls static top-label 4400 10.15.46.45 pop payload-type ipv4
!

end
switch(config)#

This command configures a static tunnel for the tunnel endpoint 64.0.0.1 and pushes a label 11111 to it.

switch(config)#mpls static STATIC 64.0.0.1/32 54.0.0.1 Port-Channel7 label-stack 11111

The switch’s MPLS static rule configuration for specified routes and rules is displayed by show mpls route.

This command displays the MPLS rule configuration.

switch>show mpls config route
In-LabelOut-LabelMetricPayloadNextHop
3400pop100 ipv4 10.14.4.4,Et3/3/3
3400pop150 ipv4 10.14.4.4,Et4/3
switch>

Statistics about the configuration and implementation of MPLS rules are displayed by theshow mpls route summary command.

This command displays a summary of MPLS rule implementation.

switch>show mpls route summary
Number of Labels: 1 (1 unprogrammed)
Number of adjacencies in hardware: 0
Number of backup adjacencies: 2
switch>

Egress IPv4/IPv6 over MPLS ACLs

IPv4/IPv6 over MPLS packets are now eligible for ACLs at the egress stage by default, applicable only to IPv4/IPv6 over MPLS packets that are MPLS label popped (such as if the label is at the bottom of stack). The user can override this behavior if required, thereby disabling egress ACLs for certain MPLS labels by configuration. No special configuration is required to enable egress ACLs on IPv4/IPv6 over MPLS packets.

  • This command disables egress ACLs for MPLS top-label 12000 on the egress interface 120.1.1.1 nexthop address.
    switch(config)#no mpls static top-label 12000 120.1.1.1 pop payload-type ipv6
    switch(config)# 
  • This command enables egress ACLs for MPLS top-label 12000 on the egress interface 120.1.1.1 nexthop address.
    switch(config)#mpls static top-label 12000 120.1.1.1 pop payload-type ipv6 
    switch(config)#

Configuring MPLSoGRE Filtered Mirroring

The filtered mirroring of terminated MPLSoGRE packets is configured by creating an IPv4 access-list, and then attaching the IPv4 access-list to a monitor session source where a tunnel decap group has been configured. This IPv4 access-list has rules that match to either inner IPv4 or IPv6 destination addresses.

Enabling the TC-Counters TCAM Profile

The following limitations are applicable to MPLSoGRE filtered mirroring in tc-counters TCAM profile:

  • Security ACLs are not enforced on IPv4oMPLSoGRE and IPv6oMPLSoGRE terminated packets.
  • The rules of a mirroring-ACL are set to match either inner IPv4 or inner IPv6 header fields, but not both.

The ACLs containing rules to match both inner IPv4 and inner IPv6 header fields are not applicable to a single source interface in multiple mirroring sessions. In other words, all ACLs applied to a shared source interface must contain either inner IPv4 rules or inner IPv6 rules.

The commands below switch to the tc-counters TCAM profile in the running configuration.

switch(config)#hardware tcam
switch(config-hw-tcam)#system profile tc-counters
switch(config-hw-tcam)#exit
Defining Two IPv4 Access-Lists

The ip access-list command places the switch in ACL configuration mode, which is a group change mode that modifies an IPv4 access control list. The command specifies the name of the IPv4 ACL that

subsequent commands modify and creates an ACL if it references a nonexistent list. All changes in a group change mode edit session are pending till the end of the session.

The permit (Role) command configures one access-list to match the inner IPv4 address, and the other access-list to match the inner IPv6 address.

switch(config)#ip access-list dIPv4
switch(config)#10 permit ip any any inner ip any host 5.5.5.5
switch(config)#exit

switch(config)#ip access-list dIPv6
switch(config)#10 permit ip any any inner ipv6 any host 55::55
switch(config)#exit
Attaching Access-Lists

The monitor session source and monitor session destination commands allow to attach two access-lists to two different monitor session sources.

switch(config)#monitor session sess1 source et1 rx ip access-group dIPv4
switch(config)#monitor session sess1 destination tunnel mode gre source 1.1.1.1 
destination 2.2.2.2
switch(config)#monitor session sess2 source et2 rx ip access-group dIPv6
switch(config)#monitor session sess2 destination tunnel mode gre source 3.3.3.3 
destination 4.4.4.4
switch(config)#show monitor session

Session sess1
------------------------

Source Ports:

Rx Only: Et1(IP ACL: dIPv4)

Destination Ports:

statussourcedest TTL DSCPprotoVRFfwd-drop
Gre1 :active1.1.1.1 2.2.2.2128 0 0x88be defaultno


Session sess2
------------------------

Source Ports:

Rx Only: Et2(IP ACL: dIPv6), Et5(IP ACL: dIPv6)

Destination Ports:

status sourcedest TTL DSCPprotoVRFfwd-drop
Gre2 :active 3.3.3.3 4.4.4.4128 0 0x88be defaultno

switch(config)#

BGP/MPLS L3 VPN

Border Gateway Protocol/ Multiprotocol Label Switching (BGP/MPLS) L3 Virtual rivate Network (VPN) allows a Service Provider (SP) or an Enterprise to provide the service of interconnecting geographically dispersed customer sites. This type of service can be provided to multiple customers over the common network backbone infrastructure of the Service Provider, while:

  • Maintaining privacy of each customer
  • Allowing for overlapping IP addresses among customers
  • Having constrained route distribution – such as, only those routers in the Service Provider’s network that need the customer routes, have them.

Achieve the above through the extensions to BGP as defined in RFC 4364 for IPv4 and RFC 4659 for IPv6, and the use of VPN Routing and Forwarding Tables (VRFs), Route Distinguishers (RDs), and Route Targets (RTs).

BGP/MPLS L3 VPN is available when configuring BGP in the multi-agent routing protocol model.

Platform Compatibility

MPLS tunnel support for traceroute and PMTU discovery is available on the following platforms:

 

7280CR

7280QR

7280SR2K

7280TRA

7508

7500R2M

7280CR2

7280QRA

7280SR2L

7500E

7508N

7500RA

7280CR2A

7280SE

7280SRA

7500R

7512N

7500RM

7280CR2K

7280SR

7280SRAM

7500R2

7516N

 

7280CR2M

7280SR2

7280SRM

7504

7500R2A

 

7280CRA

7280SR2A

7280TR

7504N

7500R2AK

 

Operation

A Virtual Private Network, or VPN, is a set of geographically dispersed sites attached to the Service Provider’s (SP) backbone, with IP interconnectivity amongst the sites. Using this scenario, the customer can obtain “VPN service” from the SP. The SP will provide a VPN service to multiple customers, using this common backbone network infrastructure. The sample VPN topology diagram below illustrates three sites where a customer is being interconnected over the SP backbone network.

At each site, the Customer Edge router (CE) attaches to the Provider’s Edge router (PE). The CE can attach to more than one PE, and in these cases the CE is said to be “multi-homed”. The routers in the SP core network, those which do not attach to any CE, are referred to as “P” routers. The “P” routers do not need to know about the customer routes.

Figure 2. MPOLS Enabled Core Schematic

The CE attaches to PE in a VRF. The routes learned from the CE are programmed in the corresponding VRF and the PE then distributes the routes to other PEs as “VPN routes” using MP-BGP. This is done by using two new BGP address families, VPN-IPv4 (AFI=1, SAFI=128) and VPN-IPv6 (AFI=2, SAFI=128).

On the PEs, corresponding to the VPN, VRFs configure with the RD and one or more import and export RTs. The RD attaches to the customer route to create a VPN route. By picking a unique RD for each VRF and attaching it to the customer route, the VPN route is unique. This allows for customers with overlapping IP addresses to be managed by the Service Provider. This unique VPN route is advertised to other PEs along with the configured export RT and the VPN label. The PE router allocates a VPN label per VRF and address family. The PE router programs its Label FIB (LFIB) with this label information. When the PE router receives an incoming MPLS packet with the VPN label as the topmost label, it pops the label and does an IP lookup in the associated VRF. The PE router also maintains a mapping of import RTs to the corresponding VRFs. This mapping is used later when deciding into which VRFs a received VPN route should be imported into.

The PE learns customer routes from the CE through the PE-CE routing protocol, which could be Static routing, EBGP, OSPF, or ISIS. The PE will install those customer routes in the associated VRF, with the CE as the nexthop. The customer routes in the VRF are exported into the BGP VPN table as VPN routes, along with the VPN label and the configured export RTs as BGP path attributes. These VPN routes are then advertised to other PEs which have been activated for the VPN address-families (VPN-IPv4/VPN-IPv6). The PE then sets itself as the nexthop while advertising the VPN routes. The PE which receives those VPN routes strips out the RD and import them as IPv4 or IPv6 routes into the VRFs. The list of VRFs into which the route is imported is determined based on the mapping of import RTs to VRFs. These routes will be programmed into the FIB along with the VPN label and the remote PE as the nexthop. Once these routes are installed in the VRF, the CE connected to that VRF will learn those routes (based on the PE-CE routing protocol) and make it available it in the customer network that it is attached to. This way the geographically dispersed customer sites learn of each other’s networks and IP reachability is established between the them.

Forwarding

In the Service Provider’s core network there should be MPLS LSPs between the PEs. That is, the connection to the VPN next-hop should be over an MPLS tunnel. The MPLS LSPs in the core could be setup using RSVP-TE or LDP in conjunction with OSPF/ISIS or ISIS-SR.

When the PE receives an IP packet from the CE destined to the remote site, it does an IP lookup in the VRF to which the CE is connected. This lookup provides the VPN label to be used and the nexthop, which would be the remote-PE. The VPN label is imposed on the IP packet and the resulting MPLS packet is then tunneled through the MPLS LSP to the remote PE. As result of penultimate hop popping, the MPLS packet arrives at the remote PE with the VPN label as the topmost label. The label lookup results in the VPN label being popped and an IP lookup will be done in the associated VRF. Note that the PE would have programmed this label action when it allocated the label to start with. That IP lookup will result in the IP packet being forwarded out to the CE.

Configuration

Configuring BGP/MPLS L3 VPN involves enabling the SP core for MPLS and then configuring the PEs with the required BGP configuration.

It is assumed that the SP core network is enabled for MPLS. This involves configuring an IGP (OSPF/ISIS) followed by a label distribution protocol such as LDP, RSVP-TE or ISIS-SR. Typically, loopback interfaces are configured on all the PE and the P routers and the IGPs exchange reachability to those loopback interfaces. And then the MPLS Label Distribution Protocol will set up MPLS LSPs/tunnels between all those loopbacks.

Enabling MPLS and LDP on the PE involves the following steps:

  1. Configure terminal.
    switch#configure terminal
  2. Enter the Loopback0 interface config mode.
    switch(config)#interface Loopback0
  3. Enter destination IP address.
    switch(config)#ip address 11.0.0.1/32
  4. Enable MPLS routing.
    switch(config)#mpls ip
  5. Configure MPLS LDP.
    switch(config)#mpls ldp
  6. Configure the router ID interface.
    switch(config-mpls-ldp)#router-id interface Loopback0
  7. Configure for no shutdown.
    switch(config-mpls-ldp)#no shutdown
    Example:
    switch#configure terminal 
    switch(config)#interface Loopback0
    switch(config-if)#ip address 11.0.0.1/32
    switch(config)#mpls ip
    switch(config)#mpls ldp
    switch(config-mpls-ldp)#router-id interface Loopback0
    switch(config-mpls-ldp)#no shutdown

Enabling BGP to Exchange the Routing Tables with the Peer

  • Enabling the send-community extended knob on the neighbor. This essentially enables BGP to exchange the RTs with the peer.

    • Activating the peer (the remote PE) under the address-family VPN-IPv4 and address-family VPN-IPv6 modes enables BGP to negotiate the MPLS L3 VPN address families.
    • Specify the address for the VPN next-hop using the command, neighbor default encapsulation mpls next-hop-self source-interface Loopback0.

In the preceding configuration example, the system uses the address 11.0.0.1 from interface Loopback0 as the nexthop in the VPN route advertisements.

Configuring the VRF Information

First, the VRF must be configured in the global mode and IPv4 and IPv6 routing must be enabled in the VRF. After that, under the router bgp mode, we need to configure the VRF and provide the information related to RD and import and export RTs.

  1. Configure terminal.
    switch#configure terminal
  2. Enable IP routing.
    switch(config)#ip routing
  3. Enable IP routing for the VRF.
    switch(config)#ip routing vrf vrf1
  4. Enable IPv6 routing for the VRF.
    switch(config)#ipv6 unicast-routing vrf vrf1
switch#configure terminal
switch(config)#ip routing
switch(config)#ip routing vrf vrf1
switch(config)#ipv6 unicast-routing vrf vrf1

The VRF configuration under router BGP mode is shown below.

switch(config-router-bgp-vrf-vrf1)#show active
router bgp 300
vrf vrf1 
rd 11.0.0.1:0
route-target import vpn-ipv6 300:0
route-target import vpn-ipv4 300:0
route-target import vpn-ipv4 300:0
route-target import vpn-ipv4 300:0 
route-target export vpn-ipv6 300:0
route-target export vpn-ipv4 300:0
redistribute connected
redistribute static
switch(config-router-bgp-vrf-vrf1)#

Configuring the Route Distinguisher

The Route Distinguisher (RD) is structured such that it can be easily configured and managed. It is configured by specifying two fields separated by a colon, as in administrative-subfield: assigned-number-subfield.

The administrative subfield could contain either an IP address, as shown in the example (the PEs loopback address), or the AS number. The assigned-number-subfield can be any number which is determined by the SP. The primary requirement of the RD is that it must be unique per VRF. It is possible to have overlapping address space between VRFs, the intent of the RD is to ensure that a VPN route can be uniquely identified as it is received by a remote PE. However, the identification of which VRF(s) the received VPN route should be imported into is handled by the import RTs configured on the remote PE.

Configuring Route Targets

Next is the import and export Route Target configuration. The RTs are structured similar to the RDs. They too are made up of administrative-subfield: assigned-number-subfield. In the example shown, the AS number has been used as the administrative subfield. And the value 0 has been used for the assigned number subfield. It is the RT that plays an important role in identifying the VPN.

  • Received VPN routes with the import RT as path attributes will be imported into the VRF will have RTs has extended-community BGP path attributes. They will be imported into VRFs which import RT configuration for RTs in the received VPN route.

  • And while advertising the routes from the VRF as VPN routes, the export RT will be attached to the route as an extended-community BGP attribute.
    1. In the example, the connected and static routes in the VRF are redistributed into BGP. And these routes will be exported as VPN routes.
    2. It is also possible to have a BGP session with the CE. In that case, routes received over that session are exported as VPN routes. And imported routes are advertised to the CE.

Configuring Import / Export Route-maps

The routes that are imported into a VRF can be further controlled by applying an import route-map. And the routes that are exported from the VRF can be controlled by applying an export route-map.

Complete the following steps:

  1. Configure terminal.
    switch#configure terminal
  2. Configure BGP. In this example, BGP is configured AS 4274781899.
    switch(config)#router bgp 4274781899
  3. Configure the VRF under router bgp mode.
    switch(config-router-bgp)#vrf vrf1
  4. Select the BGP route distinguisher. In this example, 36351:268450419 is selected.
    switch(config-router-bgp-vrf-vrf1)#rd 36351:268450419
  5. Configure the import route-target VPN-IPv4, unicast address family. In this example, 36351:1001 is selected.
    switch(config-router-bgp-vrf-vrf1)#route-target import vpn-ipv4 36351:1001
  6. Configure another import route-target for VPN-IPv4 unicast address family. In this example, 36351:268450419 is selected.
    switch(config-router-bgp-vrf-vrf1)#route-target import vpn-ipv4 36351:268450419
  7. Configure the export route-target for VPN-IPv4 unicast address family. In this example, 36351:268450419 is selected.
    switch(config-router-bgp-vrf-vrf1)#route-target export vpn-ipv4 36351:268450419
  8. Configure the import route-map. In this example, the import router-map name is BGP-IMPORT-VRF-SERVICES.
    switch(config-router-bgp-vrf-vrf1)#route-target import vpn-ipv4 route-map BGP-IMPORT-VRF-SERVICES
  9. Configure the export route-map. In this example, the export route-map name is BGP-EXPORT-VRF-VRF1.
    switch(config-router-bgp-vrf-vrf1)#route-target export vpn-ipv4 route-map BGP-EXPORT-VRF-VRF1
  10. Optionally, redistribute connected routes in the VRF into BGP, with the associated route-map BGP-ANNOUNCE-CONNECTED.
    switch(config-router-bgp-vrf-vrf1)#redistribute connected route-map BGP-ANNOUNCE-CONNECTED
  11. Optionally, redistribute static routes in the vrf into BGP, with associated route-map BGP-ANNOUNCE-STATIC.
    switch(config-router-bgp-vrf-vrf1)#redistribute static route-map BGP-ANNOUNCE-STATIC
  12. The import and export route-maps should be separately configured. The configuration snippet below shows the configuration of the same route-map BGP-IMPORT-VRF-SERVICES.
    switch(config-router-bgp-vrf-vrf1)#route-map BGP-IMPORT-VRF-SERVICES permit 10
    switch(config-route-map-BGP-IMPORT-VRF-SERVICES)#match extcommunity SERVICES
    switch(config-route-map-BGP-IMPORT-VRF-SERVICES)#match ip address prefix-list SERVICES
Example:
switch#configure terminal
switch(config)#router bgp 4274781899
switch(config-router-bgp)#vrf vrf1
switch(config-router-bgp-vrf-vrf1)#rd 36351:268450419
switch(config-router-bgp-vrf-vrf1)#route-target import vpn-ipv4 36351:1001
switch(config-router-bgp-vrf-vrf1)#route-target import vpn-ipv4 36351:268450419
switch(config-router-bgp-vrf-vrf1)#route-target export vpn-ipv4 36351:268450419
switch(config-router-bgp-vrf-vrf1)#route-target import vpn-ipv4 route-map BGP-IMPORT-VRF-SERVICES 
switch(config-router-bgp-vrf-vrf1)#route-target export vpn-ipv4 route-map BGP-EXPORT-VRF-VRF1
switch(config-router-bgp-vrf-vrf1)#redistribute connected route-map BGP-ANNOUNCE-CONNECTED
switch(config-router-bgp-vrf-vrf1)#redistribute static route-map BGP-ANNOUNCE-STATIC
switch(config-router-bgp-vrf-vrf1)#route-map BGP-IMPORT-VRF-SERVICES permit 10 
switch(config-route-map-BGP-IMPORT-VRF-SERVICES)#match extcommunity SERVICES 
switch(config-route-map-BGP-IMPORT-VRF-SERVICES)#match ip address prefix-list SERVICES

VPN Next-hop

By default, the system uses the source address of the BGP session as the nexthop in the VPN advertisements. This source address is determined by the system while establishing the TCP session between the PEs. If the SP want to use a different address as the VPN next-hop, then an interface with that address must be specified under the BGP address-family VPN-IPv4 or address-family VPN-IPv6 configuration modes. For example,

switch(config-router-bgp)#address-family vpn-ipv4
switch(config-router-bgp-af)#neighbor 10.0.0.2 activate
switch(config-router-bgp-af)#neighbor default encapsulation mpls next-hop-self 
source-interface Loopback0


switch(config-router-bgp)#address-family vpn-ipv6
switch(config-router-bgp-af)#neighbor 10.0.0.2 activate
switch(config-router-bgp-af)#neighbor default encapsulation mpls next-hop-self 
source-interface Loopback0

In the previous example, the interface Loopback 0 has been specified. The system picks the VPN next-hop address from the interface based on the following rules:

  • For VPN-IPv4, the IPv4 address from the interface is picked.

  • For VPN-IPv6,
    • For an IPv4 peer,
      • Pick the IPv4 address from the interface.
      • If the interface does not have a IPv4 address, pick the IPv6 address.
    • For an IPv6 peer,
      • Pick the IPv6 address from the interface.
      • If the interface does not have an IPv6 address, pick the IPv4 address.

For VPN-IPv6, when an IPv4 address is picked as the next-hop, it is encoded as a IPv4-mapped IPv6 address in the VPN route advertisement. This is as per RFC 4659.

Show commands

Use the show bgp instance vrf vrf1 command to show the BGP instance status for a specific VRF to verify the route-targets and import/export route-maps being used. The command also displays the locally allocated MPLS label that the system has allocated for IPv4 and IPv6.

switch#show bgp instance vrf vrf1
BGP instance information for VRF vrf1
BGP Local AS: 4274781899, Router ID: 169.254.156.10
Total peers: 0
 Static peers:0
 Dynamic peers: 0
 Disabled peers:0
 Established peers: 0
Four Octet ASN mode enabled
Graceful restart helper mode disabled
Graceful restart mode disabled
Graceful restart timer timeout: 00:05:00
End of rib timer timeout: 00:05:00
Attributes of the reflected routes are not preserved
UCMP mode: disabled
Peer mac resolution timeout: 00:00:00
BGP IPv4 Listen Port Status: listening on port 179
BGP IPv6 Listen Port Status: listening on port 179
BGP Convergence information:
 BGP has converged: yes, Time taken to converge: 00:00:31
 Outstanding EORs:0, Outstanding Keepalives: 0
 Convergence timeout: 00:05:00
BGP Convergence timer is inactive
BGP Convergence based update synchronization is disabled
BGP Convergence slow-peer timeout: 00:01:30
Address-family IPv4 Unicast:
 Redistributed routes into BGP:
 Static
 Connected
 Route Distinguisher: 36351:268450419
Route targets to import:
 VPN-IPv4:
 36351:1001
 36351:268450419
 Route targets to export:
 VPN-IPv4:
 36351:268450419
 Route maps to apply on import:
 VPN-IPv4: BGP-IMPORT-VRF-SERVICES
 Route maps to apply on export:
 VPN-IPv4: BGP-EXPORT-VRF-DI-0056
 Local IP lookup MPLS VRF label: 135275
 Additional-paths installation is disabled
 Extended next-hop capability is disabled
Address-family IPv6 Unicast:
Redistributed routes into BGP:
Static
Connected
Route Distinguisher: 36351:268450419
Route targets to import:
VPN-IPv6:
36351:1001
Route targets to export:
VPN-IPv6:
36351:268450419
Local IP lookup MPLS VRF label: 135896
Additional-paths installation is disabled

Use the show bgp neighbors command to verify that the VPN address families have negotiated with the neighbor.

switch#show bgp neighbors
BGP neighbor is 10.0.0.2, remote AS 300, internal link
BGP version 4, remote router ID 0.0.1.1, VRF default
Last read 00:00:15, last write 00:00:31
Hold time is 180, keepalive interval is 60 seconds
Configured hold time is 180, keepalive interval is 60 seconds
Hold timer is active, time left: 00:02:02
Keepalive timer is active, time left: 00:00:16
Connect timer is inactive
Idle-restart timer is inactive
BGP state is Established, up for 00:44:18
Number of transitions to established: 1
Last state was OpenConfirm
Last event was HoldTime
Neighbor Capabilities:
Multiprotocol IPv4 Unicast: advertised and received and negotiated
Multiprotocol VPN-IPv4: advertised and received and negotiated
Multiprotocol VPN-IPv6: advertised and received and negotiated
Four Octet ASN: advertised and received and negotiated
Route Refresh: advertised and received and negotiated
Send End-of-RIB messages: advertised and received and negotiated
Additional-paths recv capability:
IPv4 Unicast: advertised
VPN-IPv4: advertised
VPN-IPv6: advertised
Additional-paths send capability:
IPv4 Unicast: received
VPN-IPv4: received
VPN-IPv6: received
Restart timer is inactive
End of rib timer is inactive
IPv4 Unicast End-of-RIB received: Yes
VPN-IPv4 End-of-RIB received: Yes
VPN-IPv6 End-of-RIB received: Yes
Message Statistics:
 SentRcvd
Opens:1 1
Notifications:0 0
Updates:6 6
Keepalives:5354
Route-Refresh:0 0
Total messages:6061
Prefix Statistics:
 SentRcvd
IPv4 Unicast: 1 1
IPv6 Unicast: 0 0
Configured maximum total number of routes is 12000
Inbound updates dropped by reason:
AS path loop detection: 0
Malformed MPBGP routes: 0
Originator ID matches local router ID: 0
Nexthop matches local IP address: 0
Local AS is 300, local router ID 0.0.0.1
Local TCP address is 10.0.0.1, local port is 179
Remote TCP address is 10.0.0.2, remote port is 47400

Use the show bgp vpn-ipv4 summary command to show the status of VPN-IPv4 peers. While the examples below are with respect to VPN-IPv4, the same set of commands are applicable to VPN-IPv6.

switch#show bgp vpn-ipv4 summary
BGP summary information for VRF default
Router identifier 0.0.0.1, local AS number 300
Neighbor Status Codes: m - Under maintenance
NeighborV ASMsgRcvd MsgSent InQ OutQ Up/Down StatePfxRcd PfxAcc
10.0.0.24 300 3379600 01d23h Estab11

Use the show bgp vpn-ipv4 command to show how the VPN-IPv4 routes sent and received.

switch#show bgp vpn-ipv4
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
Route status codes: s - suppressed, * - valid, > - active, # - not installed, E - 
ECMP head, e - ECMP
S - Stale, c - Contributing to ECMP, b - backup
% - Pending BGP convergence
Origin codes: i - IGP, e - EGP, ? - incomplete
AS Path Attributes:Or-ID - Originator ID,C-LST - Cluster List,LL Nexthop-Link 
Local Nexthop
 Network Next Hop MetricLocPref Weight Path
 * > RD: 11.0.0.1:0 IPv4 prefix 20.0.0.0/24
 -- - 0 i
 * > RD: 11.0.1.1:0 IPv4 prefix 20.0.1.0/24
 11.0.1.1-100 0 i

Each entry in the output represent a VPN path in the VPN table. For each VPN path, the RD and actual prefix along with the nexthop information is shown. Paths in the VPN table are either received from other VPN-IPv4 peers (other PEs) or exported from local VRFs.

In the above output, 20.0.0.0/24 is a local route that has been exported. Notice that it has been prepended with the RD 11.0.0.1:0 to make it a VPN-IPv4 route. And the prefix of 20.0.1.0/24 has been received from another PE. It has the RD of 11.0.1.1:0 with a nexthop of 11.0.1.1. Looking at each of those prefixes in detail:

20.0.0.0/24 is a local route from one of the VRFs that has been exported. Notice that along with the prefix, the RD, the export RT and the MPLS label information is displayed. In this case, the MPLS label is a locally allocated label.

switch#show bgp vpn-ipv4 20.0.1.0/24
BGP routing table information for VRF default
Router identifier 0.0.0.1, local AS number 300
BGP routing table entry for IPv4 prefix 20.0.1.0/24, Route Distinguisher: 
11.0.1.1:0
 Paths: 1 available
Local
11.0.1.1 from 10.0.0.2 (0.0.1.1)
Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
Extended Community: Route-Target-AS:300:0
MPLS label: 100123

20.0.1.0/24 is a prefix that has been received from the VPN-IPv4 peer, 10.0.0.2. The next-hop in this case is 11.0.1.1. This VPN route is imported into a VRF based on the import RT configuration matching the RT received in the VPN route (300:0).

Note: Route-Distinguishers for the non-default VRFs must be configured under the router bgp mode. Route-Distinguisher configured under the VRF definition mode are ignored.

The route is installed in the VRF only when the VPN next-hop is reachable through an MPLS tunnel. The presence of such an MPLS tunnel can be verified using the show tunnel fib command. The output below shows that there is an MPLS tunnel setup by LDP to the VPN nexthop 11.0.1.1.

switch#show tunnel fib
Type 'LDP', index 1, endpoint 11.0.1.1/32, forwarding None
 via 10.0.0.2, 'Ethernet6'
label stack 3

Use the show ip bgp vrf vrf1 command to show the BGP table for the VRF which contains the imported VPN-IPv4 route.

switch#show ip bgp vrf vrf1
BGP routing table information for VRF vrf1
Router identifier 11.0.0.1, local AS number 300
Route status codes:s-suppressed,*-valid,>-active,#-not installed, E-ECMP head,e-ECMP 
 S - Stale, c - Contributing to ECMP, b - backup, L - labeled-unicast
 % - Pending BGP convergence
Origin codes: i-IGP, e-EGP, ?-incomplete
AS Path Attributes: Or-ID-Originator ID, C-LST-Cluster List, LL Nexthop-Link Local Nexthop

 Network Next Hop MetricLocPref Weight Path
 * > 20.0.0.0/24 -- - 0i
 * > 20.0.1.0/24 11.0.1.1 - 100 0i

Each entry in the table represents a path either locally redistributed/received into the VRF (from a BGP peer) or imported from the VPN table.

Use the show ip bgp 20.0.1.0/24 vrf vrf1 command for a more detailed view of the imported IP prefix 20.0.1.0/24:

switch#show ip bgp 20.0.1.0/24 vrf vrf1
BGP routing table information for VRF vrf1
Router identifier 11.0.0.1, local AS number 300
BGP routing table entry for 20.0.1.0/24
 Paths: 1 available
Local
11.0.1.1 from 10.0.0.2 (0.0.1.1), imported VPN-IPv4 route, RD 11.0.1.1:0
Origin IGP, metric -, localpref 100, weight 0, valid, internal, best
Extended Community: Route-Target-AS:300:0
Remote MPLS label: 100123

Use the show ip route vrf vrf1 command to view the prefix installed in route table of the VRF:

switch#show ip route vrf vrf1
VRF: vrf1
Codes: C - connected, S - static, K - kernel,
 O - OSPF, IA - OSPF inter area, E1 - OSPF external type 1,
 E2 - OSPF external type 2, N1 - OSPF NSSA external type 1,
 N2 - OSPF NSSA external type2, B I - iBGP, B E - eBGP,
 R - RIP, I L1 - IS-IS level 1, I L2 - IS-IS level 2,
 O3 - OSPFv3, A B - BGP Aggregate, A O - OSPF Summary,
 NG - Nexthop Group Static Route, V - VXLAN Control Service,
 DH - DHCP client installed default route, M - Martian,
 DP - Dynamic Policy Route
Gateway of last resort is not set
 C 20.0.0.0/24 is directly connected, Ethernet5
 B I 20.0.1.0/24 [200/0] via 11.0.1.1/32,LDP tunnel index 1,label 100123
via 10.0.0.2,Ethernet3,label imp-null(3)

The output displays both the VPN label, as well as the underlay tunnel (LDP) information.

Syslog Messages

While transmitting an update, if there is no valid next-hop that could be sent, then the %BGP-3-VPN-DROP_TXUPDATE Syslog is generated. In the case of MPLS L3 VPN, it can occur in the following scenarios:

  • When BGP is attempting to advertise a received VPN route to an eBGP and next-hop-unchanged is not configured for that peer. The resolution is to configure next-hop-unchanged for thateBGP peer.
  • When next-hop-self is configured on the Route-Reflector and the RR is trying to reflect the received.

Limitations

  • While configuring a BGP Route-Reflector for the VPN-IPv4/VPN-IPv6 address families, the route-reflector must have transport MPLS LSPs to reach the PE nexthop addresses. Even though the route-reflector may not be in the data path and does not use the transport LSPs to forward traffic, the LSPs are required in order for the BGP nexthops to be considered as reachable valid candidates in the bestpath computation.
  • When configuring eBGP peers, which receive routes over an eBGP session and re-advertise the same to a different eBGP peer, next-hop-unchanged knob must be configured, so that the original nexthop is retained.
  • With iBGP route-reflector topology, next-hop-self knob must not be configured.
  • Even with directly connected PEs, the VPN nexthops should be the loopback on the directly connected PEs with an MPLS tunnel between them.
    • For a VPN route to be installed in the VRF, the VPN nexthop must resolve over a MPLS tunnel.
  • With OSPF as the PE-CE protocol, RFC 4576, setting of the DN bit in the LSA, is not supported.
  • Internal BGP (iBGP) as the PE-CE protocol, RFC 6368, is not supported.

MPLS commands

mpls ip

The mpls ip command enables MPLS routing. Multiprotocol Label Switching (MPLS) is a networking process that avoids complex lookups in a routing table by replacing complete network addresses with short path labels for directing data packets to network nodes. MPLS data paths are serviced through a tunnel encapsulation data structure that adds four-byte label headers to packets.

The no mpls ip and default mpls ip commands disable MPLS routing by removing the mpls ip command from running-config. When MPLS routing is disabled, routed MPLS packets are dropped and all MPLS routes and adjacencies are removed. MPLS routing is disabled by default.

Command mode

Global Configuration

Command Syntax

mpls ip

no mpls ip

default mpls ip

Examples:

  • This command enables MPLS routing. Previous commands enabled IP routing and configured MPLS static routes.
    switch(config)#mpls ip
    switch(config)#show running-config
    
    ! Command: show running-config
    
    !
    ip routing
    !
    mpls ip
    !
    mpls static top-label 3400 10.14.4.4 pop payload-type ipv4
    mpls static top-label 4400 10.15.46.45 pop payload-type ipv4
    !
    
    !
    end
    switch(config)#
    
  • This command disables MPLS routing.
    switch(config)#no mpls ip
    switch(config)#show running-config
    
    
    ! Command: show running-config
     <-------OUTPUT OMITTED FROM EXAMPLE-------->
    !
    ip routing
    !
    mpls static top-label 3400 10.14.4.4 pop payload-type ipv4
    mpls static top-label 4400 10.15.46.45 pop payload-type ipv4
    !
    
    !
    end
    switch(config)#
    

mpls static

The mpls static command creates an MPLS rule that specifies the method of handling of inbound MPLS traffic. Multiprotocol Label Switching (MPLS) is a networking process that replaces complete network addresses with short path labels for directing data packets to network nodes.

Static rules specify these parameters:

  • MPLS filter: The top-label parameter specifies the 20-bit value that the MPLS packet’s top header label must match to be handled by the rule.
  • Nexthop location: Specifies the destination nexthop address (IPv4 or IPv6) and the interface through which the switch forwards the packet.
  • MPLS action: Specifies the MPLS label stack management action performed on the packet:

    • pop-payload: removes the top label from stack; this terminates an LSP (label-switched path).
    • swap-label: replaces top label with a specified new label; this passes a packet along an LSP.
  • Rule priority: Specifies the rule to be used when an MPLS packet matches multiple rules.

The no mpls static and default mpls static commands delete the specified MPLS rule from running-config.

  • commands that include only a top label tag remove all MPLS rules with the matching top label.
  • commands with no PRIORITY parameter remove all matching routes of every metric value.

Command mode

Global Configuration

Command Syntax

mpls static top-label top_tag [DEST_INTF] NEXTHOP_ADDR ACTION [PRIORITY]

no mpls static top-label top_tag

no mpls static top-label top_tag[DEST_INTF] NEXTHOP_ADDR ACTION [PRIORITY]

default mpls static top-label top_tag

default mpls static top-label top_tag[DEST_INTF] NEXTHOP_ADDR ACTION [PRIORITY]

Parameters

  • top_tag Top header’s label field contents. Value ranges from 0 to 1048575 (20 bits).
  • DEST_INTFSpecifies interface through which NEXTHOP_ADDR is accessed. Options include:

    • <no parameter> Any interface.
    • ethernet e_num Ethernet interface specified by e_num.
    • loopback l_num Loopback interface specified by l_num.
    • management m_num Management interface specified by m_num.
    • port-channel p_num Port-channel interface specified by p_num.
    • vlan v_num VLAN interface specified by v_num.
    • vxlan vx_num VXLAN interface specified by vx_num.
  • NEXTHOP_ADDR Nexthop address for MPLS for filtered MPLS packets. Options include:

    • ipv4_addr IPv4 address.
    • ipv6_addr IPv6 address.
  • ACTION MPLS header stack management action performed on packet. Options include:

    • pop payload-type ipv4 Removes top layer from stack. Payload is handled as IPv4 packet.
    • pop payload-type ipv6 Removes top layer from stack. Payload is handled as IPv6 packet.
    • swap-label <0 to 1048575> Replaces header label with specified label value (20 bits).
  • PRIORITY Specifies rule priority when multiple rules match a packet. Options include:

    • <no parameter> Assigns a metric value of 100 to the rule.
    • metric <1 to 255> Lower values denote higher priority. Value ranges from 1 to 255.

The mpls static command does not support push label actions.

Examples:

  • These commands create an MPLS rule that matches packets with a top label value of 3400 and causes the removal of the top label from the header stack. The nexthop destination of the IPv4 payload is IP address 10.14.4.4 through Ethernet interface 3/3/3. This rule has a metric value of 100.
    switch(config)#mpls static top-label 3400 ethernet 3/3/3 10.14.4.4 pop 
    payload-type ipv4
    switch(config)#show running-config
    
    !
    mpls static top-label 3400 Ethernet3/3/3 10.14.4.4 pop payload-type ipv4
    !
    
    end
    switch(config)#
    
  • These commands create a backup rule that forwards the packet through Ethernet interface 4/3. This rule’s metric value of 150 assigns it backup status prior to the first rule.
    switch(config)#mpls static top-label 3400 ethernet 4/3 10.14.4.4 pop payload-type 
    ipv4 metric 150
    switch(config)#show running-config
    
    !
    mpls static top-label 3400 Ethernet4/3 10.14.4.4 pop payload-type ipv4 metric 150
    mpls static top-label 3400 Ethernet3/3/3 10.14.4.4 pop payload-type ipv4
    !
    
    <-------OUTPUT OMITTED FROM EXAMPLE-------->
    end
    switch(config)#
    
  • These commands create an MPLS rule that forwards the packet to the nexthop address through any interface.
    switch(config)#mpls static top-label 4400 10.15.46.45 pop payload-type ipv4
    switch(config)#show running-config
    
     <-------OUTPUT OMITTED FROM EXAMPLE-------->
    
    !
    mpls static top-label 3400 Ethernet4/3 10.14.4.4 pop payload-type ipv4 metric 150
    mpls static top-label 3400 Ethernet3/3/3 10.14.4.4 pop payload-type ipv4
    mpls static top-label 4400 10.15.46.45 pop payload-type ipv4
    !
    
    end
    switch(config)#
    

show mpls route summary

The show mpls route summary command displays statistics about the configuration and implementation of MPLS rules.

Command mode

EXEC

Command Syntax

show mpls route summary

Example:

This command displays a summary of MPLS rule implementation.
switch>show mpls route summary
Number of Labels: 1 (1 unprogrammed)
Number of adjacencies in hardware: 0
Number of backup adjacencies: 2
switch>

show mpls route

The show mpls config route command displays the switch’s MPLS static rule configuration for the specified routes and rules.

Command mode

EXEC

Command Syntax

show mpls [INFO_LEVEL] route [header_label]

Parameters
  • INFO_LEVEL Specifies the filters that are used to select the routes to display. Options include:
    • <no parameter> Displays routes published by the forwarding agent.
    • config Displays all configured routes.
    • lfib Displays routes stored to the Label Forwarding Information Base (LFIB).
  • header_label Filters routes by MPLS top header label. Options include:
    • <no parameter> Displays routes for all header values.
    • <0 to 1048575> Specifies header for which command displays information.

Example:

This command displays the MPLS rule configuration.
switch>show mpls config route
In-LabelOut-LabelMetricPayloadNextHop
3400pop100 ipv4 10.14.4.4,Et3/3/3
3400pop150 ipv4 10.14.4.4,Et4/3
switch>