MLDP-Based MVPN
Available Languages
Table Of Contents
Prerequisites for MLDP-Based MVPN
Information About MLDP-Based MVPN
Initial Deployment of an MLDP-Based MVPN
How to Configure MLDP-Based MVPN
Configuring Initial MLDP Settings
Configuring an MLDP-Based MVPN
Verifying the Configuration of an MLDP-Based MVPN
Configuration Examples for MLDP-Based MVPN
Example: Initial Deployment of an MLDP-Based MVPN
Example: Migration from a PIM with mGRE-Based MVPN to an MLDP-Based MPVN
Feature Information for MLDP-Based MVPN
MLDP-Based MVPN
First Published: December 3, 2010Last Updated: December 3, 2010The MLDP-based MVPN feature provides extensions to Label Distribution Protocol (LDP) for the setup of point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) label switched paths (LSPs) for transport in the Multicast Virtual Private Network (MVPN) core network.
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for MLDP-Based MVPN" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
Prerequisites for MLDP-Based MVPN
•
•
•
•
Prerequisites for MLDP-Based MVPN
•
•
•
Information About MLDP-Based MVPN
•
Overview of MLDP-Based MVPN
MVPN allows a service provider to configure and support multicast traffic in an MPLS VPN environment. This feature supports routing and forwarding of multicast packets for each individual VPN routing and forwarding (VRF) instance, and it also provides a mechanism to transport VPN multicast packets across the service provider backbone.
A VPN is network connectivity across a shared infrastructure, such as an Internet service provider (ISP). Its function is to provide the same policies and performance as a private network, at a reduced cost of ownership, thus creating many opportunities for cost savings through operations and infrastructure.
An MVPN allows an enterprise to transparently interconnect its private network across the network backbone of a service provider. The use of an MVPN to interconnect an enterprise network in this way does not change the way that the enterprise network is administered, nor does it change general enterprise connectivity.
As shown in Figure 1, in an MLDP-based MVPN, a static default multicast distribution tree (MDT) is established for each multicast domain. The default MDT defines the path used by provider edge (PE) routers to send multicast data and control messages to every other PE router in the multicast domain. A default MDT is created in the core network using a single MP2MP LSP. The default MDT behaves like a virtual LAN.
Figure 1 MLDP with the Default MDT Scenario
As shown in Figure 2, an MLDP-based MVPN also supports the dynamic creation of data MDTs for high-bandwidth transmission. For high-rate data sources, a data MDT is created using P2MP LSPs to off-load traffic from the default MDT to avoid unnecessary waste of bandwidth to PEs that did not join the stream. The creation of the data MDT is signaled dynamically using MDT Join TLV messages. Data MDTs are a feature unique to Cisco IOS software. Data MDTs are intended for high-bandwidth sources such as full-motion video inside the VPN to ensure optimal traffic forwarding in the MPLS VPN core. The threshold at which the data MDT is created can be configured on a per-router or a per-VRF basis. When the multicast transmission exceeds the defined threshold, the sending PE router creates the data MDT and sends a User Datagram Protocol (UDP) message, which contains information about the data MDT to all routers on the default MDT.
Figure 2 MLDP with the Data MDT Scenario
Data MDTs are created only for (S, G) multicast route entries within the VRF multicast routing table. They are not created for (*, G) entries regardless of the value of the individual source data rate.
The only transport mechanism previously available was Protocol Independent Multicast (PIM) with Multipoint Generic Routing Encapsulation (mGRE) over an IP core network. The introduction of Multicast Label Distribution Protocol (MLDP) provides transport by using MLDP with label encapsulation over an MPLS core network.
MLDP creates the MDTs as follows:
•
–
•
–
All other operations of MVPN remain the same regardless of the tunneling mechanism:
•
•
The only other difference when using MLDP is that the MDT group address used in the mGRE solution is replaced with a VPN ID.
Benefits of MLDP-Based MVPN
•
•
•
Initial Deployment of an MLDP-Based MVPN
Initial deployment of an MLDP-based MVPN involves the configuration of a default MDT and one or more data MDTs.
A static default MDT is established for each multicast domain. The default MDT defines the path used by PE routers to send multicast data and control messages to every other PE router in the multicast domain. A default MDT is created in the core network using a single MP2MP LSP.
An MLDP-based MVPN also supports the dynamic creation of data MDTs for high-bandwidth transmission.
Default MDT Creation
Figure 3 shows the default MDT scenario. The Opaque value used to signal a default MDT consists of two parameters: the VPN ID and the MDT number for the VPN in the format (vpn-id, 0) where vpn-id is a manually configured 7-byte number that uniquely identifies this VPN. The default MDT is set to zero.
In this scenario, each of the three PE routers belong to the VRF called VRF and they have the same VPN ID. Each PE router with the same VPN ID will join the same MP2MP tree. The PE routers have created a primary MP2MP tree rooted at P-Central (Root 1) and a backup MP2MP tree rooted at PE-North (Root 2). There are two sources at PE-West and interested receivers at both PE-North and PE-East. PE-West will choose one of the MP2MP trees to transmit the customer VPN traffic, but all PE routers can receive traffic on either of the MP2MP trees.
Figure 3 Default MDT Scenario
LSP Downstream Default MDT Creation
Figure 4 and Figure 5 show the downstream tree creation for each of the roots. Each PE router configured with VPN ID 100:2 creates the same Forwarding Equivalence Class (FEC) Type Length Value (TLV), but with a different root and downstream labels per MP2MP tree. The FEC type will be MP2MP Down, which prompts the receiving Label Switched Route (LSR) to respond with an upstream label mapping message to create the upstream path.
Figure 4 Default MDT Downstream—Root 1
Figure 5 Default MDT Downstream—Root 2
LSP Upstream Default MDT Creation
Figure 6 and Figure 7 show the upstream LSP creation for the default MDTs. For each downstream label received, a corresponding upstream label is sent. In Figure 6, P-Central sends out three upstream labels (111, 109, and 105) to each downstream directly connected neighbor (downstream is away from the root). The process for PE-North is the same except that it only sends a single upstream label (313) as there is only one directly connected downstream neighbor.
Figure 6 Default MDT Upstream—Root 1
Figure 7 Default MDT Upstream—Root 2
PIM Overlay Signaling of VPN Multicast State
The signaling of the multicast state within a VPN is via PIM. It is called overlay signaling because the PIM session runs over the multipoint LSP and maps the VPN multicast flow to the LSP. In an MVPN, the operation of PIM is independent of the underlying tunnel technology. In the MVPN solution, a PIM adjacency is created between PE routers, and the multicast states within a VRF are populated over the PIM sessions. When using MLDP, the PIM session runs over an LSP-VIF interface. Figure 8 shows PIM signaling running over the default MDT MP2MP LSP. Access to the MP2MP LSP is via the LSP-VIF, which can see all the leaf PE routers at the end of branches, much like a LAN interface. In the figure, PE-East sends a downstream label mapping message to the root, P-Central, which in turn sends an upstream label mapping message to PE-West. These messages result in the creation of the LSP between the two leaf PE routers. A PIM session can then be activated over the top of the LSP allowing the (S, G) states and control messages to be signaled between PE-West and PE-East. In this case, PE-East receives a Join TLV message for (10.5.200.3, 238.1.200.2) within VRF, which it inserts into the mroute table. The Join TLV message is then sent via the PIM session to PE-West (BGP next-hop of 10.5.200.3), which populates its VRF mroute table. This procedure is identical to the procedure using an mGRE tunnel.
Figure 8 PIM Signaling over LSP
Data MDT Creation
In an MVPN, traffic that exceeds a certain threshold can move off the default MDT onto a data MDT. This section discusses how a data MDT is created using MLDP.
Data MDT Scenario
Figure 9 shows the data MDT scenario. The Opaque value used to signal a data MDT consists of two parameters: the VPN ID and the MDT number in the format (vpn-id, MDT# > 0) where vpn-id is a manually configured 7-byte number that uniquely identifies this VPN. The second parameter is the unique data MDT number for this VPN, which is a number greater than zero.
In the scenario, two receivers at PE-North and PE-East are interested in two sources at PE-West. If the source 10.5.200.3 exceeds the threshold on the default MDT, PE-West will issue an MDT Join TLV message over the default MDT MP2MP LSP advising all PE routers that a new data MDT is being created.
Because PE-East has an interested receiver in VRF, it will build a multipoint LSP using P2MP back to PE-West, which will be the root of the tree. PE-North does not have a receiver for 10.5.200.3, therefore it will just cache the Join TLV message.
Figure 9 Data MDT Scenario
How to Configure MLDP-Based MVPN
This section contains the following tasks:
•
•
•
Configuring Initial MLDP Settings
Perform this task to configure the initial MLDP settings.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configuring an MLDP-Based MVPN
Perform this task to configure an MLDP-based MVPN.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
DETAILED STEPS
Verifying the Configuration of an MLDP-Based MVPN
Perform this task in privileged EXEC mode to verify the configuration of an MLDP-based MVPN.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Step 1
Enter the show mpls mldp database command to display information in the MLDP database. It shows the FEC, the Opaque value of the FEC decoded, and the replication clients associated with it:
Router# show mpls mldp database* Indicates MLDP recursive forwarding is enabledLSM ID : D3000001 (RNR LSM ID: 8A000002) Type: MP2MP Uptime : 00:04:54FEC Root : 172.30.20.1Opaque decoded : [mdt 100:2 0]Opaque length : 11 bytesOpaque value : 07 000B 0000010000000100000000RNR active LSP : (this entry)Upstream client(s) :172.30.20.1:0 [Active]Expires : Never Path Set ID : 99000001Out Label (U) : 32 Interface : Ethernet1/0*Local Label (D): 30 Next Hop : 10.0.1.7Replication client(s):MDT (VRF VRF)Uptime : 00:04:54 Path Set ID : 5000002Interface : Lspvif0Step 2
Enter the show ip pim neighbor command to display PIM adjacencies information:
Router# show ip pim vrf VRF neighbor192.168.10.18 Serial6/0 04:53:19/00:01:18 v2 1 / G172.30.20.3 Lspvif0 04:52:32/00:01:28 v2 1 / B S P G172.30.20.2 Lspvif0 04:52:32/00:01:17 v2 1 / B S P GStep 3
Enter the show ip mroute command to display the contents of the multicast routing (mroute) table:
Router# show ip mroute vrf VRF 238.1.200.2 10.5.200.3(10.5.200.3, 238.1.200.2), 04:54:18/00:02:40, flags: sTIncoming interface: Lspvif0, RPF nbr 172.30.20.2Outgoing interface list:Serial6/0, Forward/Sparse-Dense, 04:54:18/00:02:40Step 4
Enter the show mpls forwarding-table command to display the contents of the MPLS Label Forwarding Information Base (LFIB):
Router# show mpls forwarding-table | inc 1F000001105 307 mLDP:1F000001 38468 Se5/0 point2point208 mLDP:1F000001 38468 Se4/0 point2point109 307 mLDP:1F000001 34738 Se5/0 point2point408 mLDP:1F000001 34738 Se6/0 point2point111 408 mLDP:1F000001 282 Se6/0 point2point208 mLDP:1F000001 282 Se4/0 point2pointStep 5
Enter the show adjacency command to display adjacency information for the specified LSP-VIF interface:
Router# show adjacency lspvif0105 307 mLDP:1F000001 38468 Se5/0 point2point208 mLDP:1F000001 38468 Se4/0 point2point109 307 mLDP:1F000001 34738 Se5/0 point2point408 mLDP:1F000001 34738 Se6/0 point2point111 408 mLDP:1F000001 282 Se6/0 point2point208 mLDP:1F000001 282 Se4/0 point2pointConfiguration Examples for MLDP-Based MVPN
This section provides the following configuration examples:
•
•
Example: Initial Deployment of an MLDP-Based MVPN
Initial deployment of an MLDP-based MVPN involves the configuration of a default MDT and one or more data MDTs.
Default MDT Configuration
The following example shows how to configure the default MDT for an MLDP-based MVPN. This configuration is based on the sample topology illustrated in Figure 10.
Figure 10 Default MDT Example
This configuration is consistent for every PE router participating in the same VPN ID. The vpn id 100:2 command replaces the MDT group address used with the mGRE transport method. To provide redundancy, two default MDT trees are statically configured, rooted at P-Central and PE-North. The selection as to which MP2MP tree the default MDT will use at a particular PE router is determined by Interior Gateway Protocol (IGP) metrics. An MP2MP LSP is implicit for the default MDT.
ip pim mpls source Loopback0ip multicast-routingip multicast-routing vrf VRF!ip vrf VRFrd 100:2vpn id 100:2route-target export 200:2route-target import 200:2mdt default mpls mldp 172.30.20.1 (P-Central)mdt default mpls mldp 172.30.20.3 (PE-North)PIM Adjacencies
PIM operates over the LSP-VIF as if it were a regular tunnel interface. That means PIM hellos are exchanged over the LSP-VIF to establish PIM adjacencies over the default MDT. The sample output in this section displays the three PIM adjacencies in VRF of PE-East. The first is the adjacency to the receiver network over serial interface 6/0, and the next two are the adjacencies to PE-West and PE-North over the MP2MP LSP via LSP-VIF interface 0.
PE-East# show ip pim vrf VRF neighbor192.168.10.18 Serial6/0 04:53:19/00:01:18 v2 1 / G172.30.20.3 Lspvif0 04:52:32/00:01:28 v2 1 / B S P G172.30.20.2 Lspvif0 04:52:32/00:01:17 v2 1 / B S P GThe output from the show ip mroute command also shows the (S, G) entry for VRF. The stream 238.1.200.2 has the Reverse Path Forwarding (RPF) interface of LSP-VIF interface 0 and the neighbor 172.30.20.2, which is PE-West.
PE-East# show ip mroute vrf VRF 238.1.200.2 10.5.200.3(10.5.200.3, 238.1.200.2), 04:54:18/00:02:40, flags: sTIncoming interface: Lspvif0, RPF nbr 172.30.20.2Outgoing interface list:Serial6/0, Forward/Sparse-Dense, 04:54:18/00:02:40MLDP Database Entry—PE-East
The sample output in this section displays the database entries for the MP2MP trees supporting the default MDT at PE-East. The database is searched by Opaque value MDT 100:2, which results in information for two MP2MP trees (one for each root) being returned. Both trees have different system IDs (2E000001, F2000005) and use the same Opaque value ([mdt 100:2 0]), but with different roots. The last 0 in the Opaque value indicates this tree is a default MDT. Entry 79000004 shows it is the primary MP2MP tree, therefore PE-East will transmit all source multicast traffic on this LSP, and B2000006 will be the backup root. Note that interface LSP-VIF interface 0 represents both MP2MP LSPs. The Local Label (D) is the downstream label allocated by PE-East for this tree. In other words, traffic from the root will be received with either label 408 (Primary Tree) or 407 (Backup Tree). The Out Label (U) is the label that PE-East will use to send traffic into the tree; upstream towards the root, either 105 for the Primary Tree or 108 for the Backup Tree. Both these labels were received from P-Central.
PE-East# show mpls mldp database opaque_type mdt 100:2* Indicates MLDP recursive forwarding is enabledLSM ID : 79000004 (RNR LSM ID: 8A000002) Type: MP2MP Uptime : 00:04:54FEC Root : 172.30.20.1Opaque decoded : [mdt 100:2 0]Opaque length : 11 bytesOpaque value : 07 000B 0000010000000100000000RNR active LSP : (this entry)Upstream client(s) :172.30.20.1:0 [Active]Expires : Never Path Set ID : 99000001Out Label (U) : 32 Interface : Ethernet1/0*Local Label (D): 30 Next Hop : 10.0.1.7Replication client(s):MDT (VRF VRF)Uptime : 00:04:54 Path Set ID : 5000002Interface : Lspvif0LSM ID : 79000005 (RNR LSM ID: 8A000003) Type: MP2MP Uptime : 00:04:54FEC Root : 172.30.20.3Opaque decoded : [mdt 100:2 0]Opaque length : 11 bytesOpaque value : 07 000B 0000010000000100000001RNR active LSP : (this entry)Upstream client(s) :172.30.20.1:0 [Active]Expires : Never Path Set ID : 99000002Out Label (U) : 32 Interface : Ethernet1/0*Local Label (D): 30 Next Hop : 10.0.1.7Replication client(s):MDT (VRF VRF)Uptime : 00:04:54 Path Set ID : 5000003Interface : Lspvif0Label Forwarding Entry—P-Central (Root 1)
The sample output shown in this section displays the VRF (MDT 100:2) MLDP database entry 1F000001 for the primary MP2MP LSP, which is P-Central. Because the local router P-Central is the root, there is no upstream peer ID, therefore no labels are allocated locally. However there are three replication clients, representing each of the three PE routers: PE-North, PE-West, and PE-East. These replication clients are the downstream nodes of the MP2MP LSP. These clients receive multipoint replicated traffic.
In the replication entry looking from the perspective of the root, there are two types of labels:
•
•
From the labels received and sent in the replication entries, the Label Forwarding Information Base (LFIB) is created. The LFIB has one entry per upstream path and one entry per downstream path. In this case because P-Central is the root, there are only upstream entries in the LFIB that have been merged with the corresponding downstream labels. For example, label 105 is the label P-Central sent to PE-East to send source traffic upstream. Traffic received from PE-East will then be replicated using the downstream labels 307 to PE-West and 208 to PE-North.
P-Central# show mpls mldp database opaque_type mdt 100:2LSM ID : 79000006 (RNR LSM ID: 1F000001) Type: MP2MP Uptime : 00:04:54FEC Root : 172.30.20.1Opaque decoded : [mdt 100:2 0]Opaque length : 11 bytesOpaque value : 07 000B 0000010000000100000000RNR active LSP : (this entry)Upstream client(s) : NoneReplication client(s):172.3.20.2:0Uptime : 01:46:43 Path Set ID : AC000008Out label (D) : 208 Interface : Serial4/0Local label (U): 109 Next Hop : 172.30.10.2172.3.20.3:0Uptime : 01:42:43 Path Set ID : E00000COut label (D) : 307 Interface : Serial5/0Local label (U): 111 Next Hop : 172.30.10.6172.3.20.4:0Uptime : 01:40:43 Path Set ID : 3D000010Out label (D) : 408 Interface : Serial6/0Local label (U): 105 Next Hop : 172.30.10.10P-Central# show mpls forwarding-table | inc 1F000001105 307 mLDP:1F000001 38468 Se5/0 point2point208 mLDP:1F000001 38468 Se4/0 point2point109 307 mLDP:1F000001 34738 Se5/0 point2point408 mLDP:1F000001 34738 Se6/0 point2point111 408 mLDP:1F000001 282 Se6/0 point2point208 mLDP:1F000001 282 Se4/0 point2pointThe sample output shown in this section displays the entry on P-Central for the MP2MP LSP rooted at PE-North (backup root). In this tree P-Central is a branch of the tree, not a root, therefore there are some minor differences to note:
•
•
•
–
–
Central_P# show mpls mldp database opaque_type mdt 100:2LSM ID : E6000004Uptime : 00:42:03Tree type : MP2MPFEC Root : 172.30.20.3Opaque length : 14 bytesOpaque value : 07000B00 01000000 00020000 00009COpaque decoded : [mdt 100:2 0]Upstream peer ID : 172.30.20.3:0, Label local (D): 104 remote (U): 313 activePath Set ID : 48000003Replication client(s):172.30.20.2:0 uptime: 00:42:03 Path Set ID: CF000004remote label (D): 207 local label (U): 115nhop: 172.30.10.2 intrf: Serial4/0172.30.20.4:0 uptime: 00:41:44 Path Set ID: 5800000Eremote label (D): 407 local label (U): 108nhop: 172.30.10.10 intrf: Serial6/0Central_P# show mpls forwarding-table | inc E6000004104 207 mLDP:E6000004 251228 Se4/0 point2point407 mLDP:E6000004 251334 Se6/0 point2point108 207 mLDP:E6000004 0 Se4/0 point2point313 mLDP:E6000004 0 Se5/0 point2point115 313 mLDP:E6000004 0 Se5/0 point2point407 mLDP:E6000004 0 Se6/0 point2pointData MDT Configuration
The following example shows how to configure the data MDT for an MLDP-based MVPN. This configuration is based on the sample topology illustrated in Figure 11.
Figure 11 Data MDT Example
The sample output in this section displays the data MDT configuration for all the PE routers. The mdt data commands are the only additional commands necessary. The first mdt data command allows a maximum of 60 data MDTs to be created, and the second mdt data command sets the threshold. If the number of data MDTs exceeds 60, then the data MDTs will be reused in the same way as they are for the mGRE tunnel method (the one with the lowest reference count).
ip pim vrf VRF mpls source Loopback0!ip vrf VRFrd 100:2vpn id 100:2route-target export 200:2route-target import 200:2mdt default mpls mldp 172.30.20.1 (P-Central)mdt default mpls mldp 172.30.20.3 (PE-North)mdt data mpls mldp 60mdt data threshold 1VRF mroute Table—PE-West
The sample output in this section displays the VRF mroute table on PE-West before the high-bandwidth source exceeds the threshold. At this point there are two streams, representing each of the two VPN sources at PE-West, on a single MP2MP LSP (System ID D8000000). The LSP represents the default MDT accessed via LSP-VIF interface 0.
PE-West# show ip mroute vrf VRF verbose...(10.5.200.2, 238.1.200.1), 00:00:25/00:03:29, flags: sTIncoming interface: Serial6/0, RPF nbr 192.168.10.6Outgoing interface list:Lspvif0, LSM MDT: D8000000 (default),Forward/Sparse-Dense,...(10.5.200.3, 238.1.200.2), 00:11:14/00:02:48, flags: sTIncoming interface: Serial6/0, RPF nbr 192.168.10.6Outgoing interface list:Lspvif0, LSM MDT: D8000000 (default),Forward/Sparse-Dense,...The sample output in this section displays the output after the source transmission exceeds the threshold. PE-West sends an MDT Join TLV message to signal the creation of a data MDT. In this case, the data MDT number is 1, therefore PE-East will send a label mapping message back to PE-West with a FEC TLV containing root=PE-West, Opaque value=(mdt vpn-id 1). The System ID is now changed to 4E000003 signaling a different LSP; however, the LSP-VIF is still LSP-VIF interface 0. The (S, G) entry also has the "y" flag set indicating this stream has switched to a data MDT.
PE-West# show ip mroute vrf VRF 10.5.200.3 238.1.200.2 verbose...(10.5.200.3, 238.1.200.2), 00:00:08/00:03:27, flags: sTyIncoming interface: Serial6/0, RPF nbr 192.168.10.6MDT TX nr: 1 LSM-ID 4E000003Outgoing interface list:Lspvif0, LSM MDT: 4E000003 (data) Forward/Sparse-Dense,LSP-VIF Adjacencies—PE-West
For the interface LSP-VIF, each virtual circuit represents a unique multipoint LSP forwarding instance. The correct adjacency is selected when sending the multicast packet. The sample output in this section displays the application of that concept on PE-West. There is a single LSP-VIF interface 0 interface, but it has three adjacencies as follows:
•
•
•
PE-West# show adjacency lspvif 0Protocol Interface AddressIP Lspvif0 4E000003(5)IP Lspvif0 58000000(4)IP Lspvif0 D8000000(3)MLDP Database Entries
The sample output in this section displays the MLDP entry for the data MDT (4E000003) on the ingress router PE-West. The following points about this entry should be noted:
•
•
•
•
•
•
PE-West# show mpls mldp database id 4E000003LSM ID : 4E000003 (RNR LSM ID: 8A000002) Type: P2MP Uptime : 00:04:54FEC Root : 172.30.20.2Opaque decoded : [mdt 100:2 1]Opaque length : 11 bytesOpaque value : 07 000B 0000010000000100000000RNR active LSP : (this entry)Upstream client(s) : NoneReplication client(s):MDT (VRF VRF)Uptime : 00:04:54 Path Set ID : 5000002Interface : Lspvif0172.30.20.1:0Uptime : 01:41:43 Path Set ID : D9000007Out label (D) : 27 Interface : Serial4/0Local label (U): 112 Next Hop : 172.30.10.1The sample output in this section displays the database entry for the data MDT on PE-East, the egress router. Also shown is the MDT Join TLV message that was sent from PE-West over the default MDT. The MDT Join TLV message contains all the necessary information to allow PE-East to create a label mapping message P2MP LSP back to the root of PE-West. Label 414 will be used by P-Central to send traffic to PE-East.
*Feb 19 04:43:24.039: PIM(1): MDT join TLV received for (10.5.200.3,238.1.200.2)
*Feb 19 04:43:24.039: MLDP: LDP root 172.30.20.2 added
*Feb 19 04:43:24.039: MLDP: [mdt 100:2 1] label mapping msg sent to 172.30.20.1:0PE-East# show mpls mldp database opaque_type mdt 100:2 1LSM ID : 4E000003 (RNR LSM ID: 8A000002) Type: P2MP Uptime : 00:04:54FEC Root : 172.30.20.2Opaque decoded : [mdt 100:2 1]Opaque length : 11 bytesOpaque value : 07 000B 0000010000000100000000RNR active LSP : (this entry)Upstream client(s) : NoneReplication client(s):MDT (VRF VRF)Uptime : 00:04:54 Path Set ID : 5000002Interface : Lspvif0LFIB Entry for the Data MDT
The sample output in this section displays the LFIB entry for the data MDT as it passes through P-Central and PE-East. The Tunnel ID used for the LSP is the Opaque value [mdt 100:2 1].
P-Central# show mpls for label 112Local Outgoing Prefix Bytes Label Outgoing Next HopLabel Label or Tunnel Id Switched interface111 414 [mdt 100:2 1] 2993584 Se6/0 point2pointPE-East# show mpls for label 400Local Outgoing Prefix Bytes Label Outgoing Next HopLabel Label or Tunnel Id Switched interface414 [T] No Label [mdt 100:2 1][V] 3297312 aggregate/greenExample: Migration from a PIM with mGRE-Based MVPN to an MLDP-Based MPVN
The following example shows an MLDP-based MVPN configuration that has been migrated from a PIM with mGRE based MVPN. The differences in the CLI from the PIM with mGRE-based MVPN are highlighted via comments below. In this example, MLDP derives the FEC from the import route target configured in the VRF.
ip vrf VRFrd 50:1111vpn id 50:10 ! MLDP-based MVPN configurationroute-target export 100:100route-target import 100:100mdt preference mldp pimmdt default mpls mldp 1.1.1.1 ! MLDP-based MVPN configurationmdt default mpls mldp 2.2.2.2 ! MLDP-based MVPN configurationmdt data mpls mldp 255 ! MLDP-based MVPN configurationmdt data threshold 40 list 1 ! MLDP-based MVPN configuration!ip multicast-routingip multicast-routing vrf VRF!interface Loopback0ip address 205.1.0.1 255.255.255.0ip router isisip pim sparse-dense-mode!interface Ethernet1/0ip vrf forwarding greenip address 220.0.2.1 255.255.255.0ip pim sparse-dense-mode!interface Ethernet2/0ip address 200.0.0.1 255.255.255.0ip pim sparse-dense-modeip router isismpls ip ! MLDP-based MVPN configuration!router isisnet 49.0000.0000.0000.00Additional References
Related Documents
Cisco IOS commands
Overview of the IP multicast technology area
"IP Multicast Technology Overview" module
Concepts, tasks, and examples for configuring an IP multicast network using PIM
IP multicast commands: complete command syntax, command mode, defaults, command history, usage guidelines, and examples
Standards
No new or modified standards are supported , and support for existing standards has not been modified.
—
MIBs
No new or modified MIBs are supported.
To locate and download MIBs for selected platforms, Cisco software releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
No new or modified RFCs are supported , and support for existing standards has not been modified.
—
Technical Assistance
Feature Information for MLDP-Based MVPN
Table 1 lists the release history for this feature.
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
.Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2010 Cisco Systems, Inc. All rights reserved.
FeedbackContact Cisco
- Open a Support Case
- (Requires a Cisco Service Contract)