MPLS LDP advertise lable

mpls ldp advertise-label 


This command is enable by default. The MPLS router will advertise every network it learnt or connected network to its neighbor. In order to stop this advertisement, we use  "no mpls ldp advertise-label " However, this command will disable every advertisement in the network.

If we want to specifically advertise label for specific network to specific destination, we can use the command as followings.
      mpls ldp advertise-lable for <dest prefix>  to <ldp peer>

Example

As shown in the figure, R1, R2 and R3 are in the MPLS network. In this scenario, we specify what prefix and what destination we want to have label advertised for the MPLS network. R1 will advertise label for 1.1.1.1/32 only but not 10.10.10.10/32. Here is the configuration example on R1

( we omitted the IGP configuration )

Before configuration

R2#sh mpls forwarding-table

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

16     Pop tag     30.30.30.30/32    570        Fa0/1      192.168.2.2

17     Pop tag     3.3.3.3/32        0          Fa0/1      192.168.2.2

18     Pop tag     10.10.10.10/32    0          Fa0/0      192.168.1.1

19     Pop tag     1.1.1.1/32        0          Fa0/0      192.168.1.1

Configuration command

no mpls ldp advertise-labels

mpls ldp advertise-labels for 2 to 1

access-list 1 permit 192.168.1.2

access-list 2 permit 1.1.1.1

Result / Verification

R2#sh mpls forwarding-table

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

16     Pop tag     30.30.30.30/32    570        Fa0/1      192.168.2.2

17     Pop tag     3.3.3.3/32        0          Fa0/1      192.168.2.2

18     Untagged    10.10.10.10/32    0          Fa0/0      192.168.1.1

19     Pop tag     1.1.1.1/32        0          Fa0/0      192.168.1.1

We can see now that the 10.10.10.10/32 label is not advertised to R2 from R1

EIGRP PE-CE

Sample Configuration of the EIGRP VRF
R1  -  R2


PE (R1)
int f0/0
ip vrf forwarding VPNA
ip address 192.168.1.1 255.255.255.0

router eigrp 1
address-family ipv6 unicast vrf VPNA
  network 192.168.1.0 0.0.0.255
  autonomous-system 1
  no auto-summary


CE (R2)
int f0/0
ip address 192.168.1.2 255.255.255.0

router eigrp 1
  network 192.168.1.0 0.0.0.255
  no auto-summary

MPLS advertise lable

When enable mpls in an interface, the router tags all prefixes it has learnt from the routing table and advertises out via ldp message to its neighbors. This behavior is enabled by default. However, we can tune this behavior by specifying prefixes in an access-list and configure the router to advertise them only.

Configuration Example

In normal condition which mpls ldp advertise-lables enable by default. Prefixed learnt by R1 are all tagged.

R1#sh mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Pop tag     2.2.2.2/32        0          Fa0/0      192.168.1.2
17     Pop tag     4.4.4.4/32        0          Fa0/0      192.168.1.2
R1#

Configuration
Configure Access-list to allow specific prefix being ldp advertised by the router.

R2
mpls ldp advertise-labels for 1

access-list 1 permit 2.2.2.0 0.0.0.255 

R1

mpls ldp advertise-labels for 1

access-list 1 permit 1.1.1.0 0.0.0.255 

R2#show mpls forwarding-table

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

16     Pop tag     1.1.1.1/32        0          Fa0/0      192.168.1.1

17     Untagged    3.3.3.3/32        0          Fa0/0      192.168.1.1

R1#sh mpls forwarding-table

Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop

tag    tag or VC   or Tunnel Id      switched   interface

16     Pop tag     2.2.2.2/32        0          Fa0/0      192.168.1.2

17     Untagged    4.4.4.4/32        0          Fa0/0      192.168.1.2

Now, after the configuration, the prefix 4.4.4.4 and 3.3.3.3 are not tagged anymore. They will be forwarded by the IP lookup as in the normal network.

OTV vs VPLS

I found an interesting article from cisco website which compares the OTV and VPLS technologies, So I would like to share here. 

Click here for the full link from Cisco

How OTV and VPLS Meet the Challenges of LAN Extensions

Table 1 summarizes the different ways that OTV and VPLS meet the challenges of LAN extensions.

Table 1. Comparison of OTV and VPLS

Preservation of Site Independence
OTV	VPLS
OTV conveys MAC address reachability information in a control protocol. The flooding of unknown unicast traffic can be suppressed from the overlay as these are not required to trigger MAC address learning. Flooding anomalies are contained within a single site.	VPLS relies on flooding to propagate MAC address reachability information. Therefore, flooding cannot be prevented.
The OTV control protocol can carry MAC address to IP mappings and use them to populate the Address Resolution Protocol (ARP) cache on the different edge devices. Edge devices will serve as ARP proxies and allow the suppression of ARP broadcasts across the overlay. ARP storms will not propagate across sites.	VPLS does not have a control protocol capable of associating information with particular MAC addresses at an appropriate scale. Controlling ARP traffic and other network events is not practical without the addition of a control protocol.1
OTV has built-in filtering capabilities to localize the most common link-local networking protocols (Spanning Tree Protocol, VLAN Trunking Protocol [VTP], Hot Standby Router Protocol [HSRP], etc.) and prevent them from traversing the overlay. This feature prevents protocol failures from propagating across sites. The localization of First-Hop Resiliency Protocols (HSRP, Virtual Router Redundancy Protocol [VRRP], etc.) both isolates failures and helps ensure optimal routing.	VPLS allows the suppression of Spanning Tree Protocol and VLAN distribution protocols such as VTP and Generic VLAN Registration Protocol (GVRP). VPLS does not provide integrated mechanisms to maintain First Hop Resiliency Protocols such as HSRP, VRRP, or Gateway Load-Balancing Protocol (GLBP) localized.
Transport Independence
OTV	VPLS
The overlay nature of OTV allows it to work over any transport as long as this transport can forward IP packets. Any optimizations performed for IP in the transport will benefit the OTV encapsulated traffic.	VPLS requires a label-switched transport to function. This approach is best when an MPLS transport is available. When an MPLS transport is not available, variants such as VPLS over Generic Routing Encapsulation (GRE) allow the deployment of a VPLS solution over a mesh of IP GRE tunnels.
Multihoming and End-to-End Loop Prevention
OTV	VPLS
As part of the OTV control protocol, automatic detection of multihoming is included. This feature enables the multihoming of sites without requiring additional configuration or protocols.	VPLS requires the addition of specific protocols to provide multihoming. Some examples of protocols that must be added to VPLS include Border Gateway Protocol (BGP) with multihoming extensions, Interchassis Communication Protocol (ICCP) and Multichassis Link Aggregation Control Protocol (MLACP), Cisco IOS®Software Embedded Event Manager (EEM), and Multiple Spanning Tree (MST).
	Cisco VPLS eliminates the need for these protocols by using device clustering solutions that allow multihoming that is transparent to the VPLS cloud. With the use of virtual switching system (VSS) technology, a pair of provider edge devices can appear as a single device for the purpose of providing dual-active multihoming of VPLS sites without the need for any additional protocols.
OTV provides per-VLAN single active edge device multihoming by default. When combined with virtual PortChannel (vPC), Cisco Layer 2 multipathing, or Transparent Interconnection of Lots of Links (TRILL) technology, OTV can offer all-active multihoming. Up to 16 active edge devices can be used per site in OTV, allowing continuity of Cisco Layer 2 multipathing and TRILL clouds as they are extended over OTV.	All multihoming schemes for VPLS focus on reducing the multiple provider-edge devices on a site to a single active device.
	Cisco VPLS benefits from the capability to consolidate two provider-edge devices into a single device using VSS to provide active-active dual homing.
Bandwidth Utilization: Replication, Load Balancing, and Path Diversity
OTV	VPLS
OTV uses native IP multicast to help ensure optimal replication of multicast, broadcast, and signaling traffic.	VPLS uses a full mesh of point-to-multipoint (P2MP) tunnels to prevent head-end replication of multicast traffic.
OTV headers are defined to allow the core to hash traffic based on five-tuples of Layer 2, 3, and 4 information and distribute traffic over multiple paths to avoid polarization of encapsulated traffic.2	The addition of FAT-pseudowire (FAT-PW) gives Cisco VPLS (and all MPLS services) an effective mechanism for distributing the load over multiple paths in the backbone based on Layer 2 through 4 information and thus avoiding tunnel polarization.
OTV allows effective load balancing of flows across the multiple edge devices available in an all-active multihomed deployment. Load balancing follows equal-cost multipath (ECMP) rules based on the information provided by the OTV control protocol. Hashing is performed based on Layer 2 through 4 information.	Since VPLS is intrinsically single homed for all active-path forwarding purposes, per-flow load balancing is not possible in VPLS.
	Cisco VPLS overcomes this limitation by using VSS to provide dual-active provider-edge multihoming.
Scalability and Topology Independence
OTV	VPLS
OTV is designed to scale to a relatively large density of edge devices (in the hundreds). This capability is a critical element in deciding where in the data center the functions should be deployed. A convenient place to deploy the required edge devices is the aggregation layer in the data center network. This placement simplifies network design and operations by taking the existing Layer 2 domains directly into an OTV overlay when required. Positioning the edge devices in the aggregation layer requires a solution capable of supporting a high number of edge devices, and OTV provides the required scalability. Placing the edge devices elsewhere in the network (at the WAN edge, for example) would require additional hardware to extend the Layer 2 domains from the aggregation layer to the edge devices, increasing the network complexity and operational burden.	VPLS is designed to include a few provider edge devices (40 to 60). If the number of provider edge devices is large, schemes like Hierarchical VPLS (H-VPLS) are required. Use of H-VPLS is equivalent to placing the provider edge devices at the data center edge and adding Ethernet over MPLS (EoMPLS) or IEEE QinQ to aggregate traffic to the provider edge devices. Clearly, there are many elements to be maintained in such a model, and this poses strict topological restrictions on the deployment of VPLS. The use of BGP signaling in VPLS enables greater scalability, does not require H-VPLS, and removes the topological constraints discussed.
VLAN and MAC Address Scalability
OTV	VPLS
OTV intrinsically carries traffic for multiple VLANs over a single overlay.	VPLS can carry a single VLAN per VPLS instance. To multiplex multiple VLANs on a single instance, VPLS uses IEEE QinQ.
OTV has built-in hierarchical identifiers that allow the scaling of the VLAN ID space beyond the 4K VLANs possible in a single 802.1Q domain.	To scale beyond 4K VLANs using a single VPLS instance, VPLS requires the assistance of external devices in the site to provide additional IEEE QinQ encapsulation that can be transported transparently in the single instance.
	Cisco VPLS is enhanced to support more than 4K per instance without the assistance of external devices and with a simplified configuration model.
For the first release of OTV, MAC addresses in the overlay are learned on all sites. However, VLANs can be scoped to the sites where they are relevant, which reduces the size of the tables based on the site. OTV also can provide conversational programming of the forwarding tables to save valuable hardware memory space.3	VPLS relies on flooding, and therefore all MAC addresses are learned at all sites. Since multiple VLANs must be hidden from VPLS with IEEE QinQ encapsulation, VLAN scoping is not really an option and all MAC addresses are learned everywhere.
	Cisco VPLS enables much more efficient handling of the IEEE 802.1Q headers, allowing VLAN pruning and benefiting MAC address scalability.
Complex Operations
OTV	VPLS
OTV provides a single protocol to address the different requirements posed by LAN extensions. OTV provides autodiscovery mechanisms that are built into the single protocol and allow point-to-cloud provisioning with zero impact on existing sites.	VPLS requires many protocols to address the different LAN extension challenges. BGP for autodiscovery; Label Distribution Protocol (LDP) for pseudowire establishment; BGP, ICCP, MLACP, and Cisco IOS EEM for multihoming; P2MP LDP for multicast distribution; BGP and Next-Hop Resolution Protocol (NHRP) for GRE tunnel establishment if VPLS is used over GRE; etc.
	Cisco VPLS simplifies much of this complexity by eliminating the need for some of these add-on protocols and concealing others behind an enterprise-class provisioning model.
OTV has been designed with automated processes and little need to use the command-line interface (CLI).	Due to the proliferation of protocols, the VPLS CLI can be rather busy.
	Cisco VPLS has many enhancements to consolidate CLI operations and simplify operations.
Deployment of OTV does not affect the existing network, and therefore OTV can be transparently overlaid without losing site independence or altering the behavior of core or site protocols.	VPLS needs to be carefully designed into the network, which limits flexibility.

1IP-only LAN service (IPLS), because of its static nature, is not appropriate for the volume of hosts that must be handled per site in a LAN extension service. 2User Datagram Protocol (UDP) headers for OTV are not available at first customer shipment (FCS). 3Feature will be available after FCS.

MPLS Sample Configuration

MPLS network


<explanation will be added later on>

Configuration
Download
http://ge.tt/3DhIfuz

PE1


VRF configuration

ip vrf cust_1
 rd 1:1
 route-target export 1:100
 route-target import 1:100
!

EIGRP between PE1 and CE1


router eigrp 1
 auto-summary
 !
 address-family ipv4 vrf cust_1
  redistribute bgp 1 metric 10000 100 100 1 1500
  network 192.168.1.0
  auto-summary
  autonomous-system 1
 exit-address-family

MP-BGP (VPNv4-MPLS) configuration
!
router bgp 1
 bgp log-neighbor-changes
 neighbor 3.3.3.3 remote-as 1
 neighbor 3.3.3.3 update-source Loopback0
 !
 address-family ipv4
  neighbor 3.3.3.3 activate
  no auto-summary
  no synchronization
 exit-address-family
 !
 address-family vpnv4
  neighbor 3.3.3.3 activate
  neighbor 3.3.3.3 send-community extended
 exit-address-family
 !
 address-family ipv4 vrf cust_1
  redistribute eigrp 1
  neighbor 3.3.3.3 remote-as 1
  neighbor 3.3.3.3 activate
  no synchronization
 exit-address-family
!

Verification


Customer routing table


CE1#sh ip route
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/8 is variably subnetted, 2 subnets, 2 masks
C       1.1.1.0/24 is directly connected, Loopback0
D       1.0.0.0/8 is a summary, 00:28:44, Null0
D    4.0.0.0/8 [90/435200] via 192.168.1.2, 00:05:42, FastEthernet0/0
C    192.168.1.0/24 is directly connected, FastEthernet0/0
D    192.168.2.0/24 [90/307200] via 192.168.1.2, 00:05:42, FastEthernet0/0

CE2#sh ip route

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

D    1.0.0.0/8 [90/435200] via 192.168.2.1, 00:06:02, FastEthernet0/0

     4.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C       4.4.4.0/24 is directly connected, Loopback0

D       4.0.0.0/8 is a summary, 00:13:46, Null0

D    192.168.1.0/24 [90/307200] via 192.168.2.1, 00:06:02, FastEthernet0/0

C    192.168.2.0/24 is directly connected, FastEthernet0/0

CE2#

Provider edge routing table

Routing table

PE1#sh ip route

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

     3.0.0.0/32 is subnetted, 1 subnets

O       3.3.3.3 [110/11] via 10.1.1.2, 00:11:19, FastEthernet0/1

     10.0.0.0/24 is subnetted, 1 subnets

C       10.1.1.0 is directly connected, FastEthernet0/1

PE1#

VRF routing table

PE1#sh ip route vrf cust_1

Routing Table: cust_1

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

D    1.0.0.0/8 [90/409600] via 192.168.1.1, 00:12:52, FastEthernet0/0

B    4.0.0.0/8 [200/409600] via 3.3.3.3, 00:07:29

C    192.168.1.0/24 is directly connected, FastEthernet0/0

B    192.168.2.0/24 [200/0] via 3.3.3.3, 00:07:30

PE1#

MPLS tagging VPNv4


* Normally, there are 2 MPLS tags. However, in this scenario, there is an implicit null on the outer layer so it will pop out left only VPN tag.

PE1#sh ip cef vrf cust_1 192.168.2.0

192.168.2.0/24, version 12, epoch 0, cached adjacency 10.1.1.2

0 packets, 0 bytes

  tag information set

    local tag: VPN-route-head

    fast tag rewrite with Fa0/1, 10.1.1.2, tags imposed: {18}

  via 3.3.3.3, 0 dependencies, recursive

    next hop 10.1.1.2, FastEthernet0/1 via 3.3.3.3/32

    valid cached adjacency

    tag rewrite with Fa0/1, 10.1.1.2, tags imposed: {18}