The new way refers to the setting up of Multipoint LSP in the MPLS VPN environment to carry multicast traffic in the VPN. Here, all CE routers belong to a single customer at different branches. There is no multicast receiver behind CE3 router. The MPLS core is PIM-free. Only PE routers will run PIM with the CE routers
This Internet Draft introduces the Label Distribution Protocol (LDP) extensions for point-to-multipoint (P2MP) and multipoint-to-multipoint (MP2MP) Label Switched Paths (LSPs) in MPLS networks. These extensions are also called mLDP or Multipoint LDP. Of the various applications for multipoint LSPs, one is support for multicast in MPLS VPN. Previously, this was achieved through mVPN.
LDP RFC introduced the mechanism to setup point-to-point LSP (P2P) in the MPLS network where there is a single source and single destination. However, a P2MP LSP allows traffic from a single ingress router (root node) to be delivered to multiple egress routers (leaf nodes). A MP2MP LSP allows traffic from multiple ingress routers to multiple egress routers. At any point, a single copy of packet is sent to any LSP without any multicast routing protocol in the network.
PE routers configuration
The Loopback 0 interface of PE1 router is configured to be used as the Root Node IP address. The Opaque value for the multipoint LSP is constructed based on the VPN ID value of 1:1. The mdt default mpls mldp command creates the MP2MP LSP known to all PE routers for that particular VRF. This LSP is used to forward all customer multicast traffic by default
PE1 router:
Setting up a P2MP LSP with LDP Traditionally, LDP-signaled LSPs are initiated by the egress router. The egress (receiving) router initiates the label propagation and is propagated throughout the MPLS network. All LSRs maintain a forwarding state towards the egress router following the shortest IGP path, and any LSR can act as an ingress LSR. This, essentially, sets up a multipoint-to-point (MP2P) LSP as multiple senders can send traffic to a single receiver.In contrast, a P2MP LSP has a single ingress (root) node and one or more egress (leaf) nodes. The transit nodes provide reachability to the root node. Leaf nodes initiate P2MP LSP setup. The leaf nodes should be aware of the ingress router. Also, the leaf nodes should be able to identify the correct P2MP LSP as several P2MP LSPs could be originated from the ingress router. A new Capability Parameter is introduced for P2MP capability which is exchanged using LDP Initialization message. A new P2MP FEC Element is defined which carries the IPv4 address of the root and an Opaque value (also called tree identifier and is manually configured VPN ID). This combination uniquely identifies a P2MP LSP within the MPLS network. Leaf node allocates a label and advertises its P2MP Label Mapping {Root IP Address, Opaque Value, Label} to the upstream LDP node on the shortest path to the root. The upstream node creates its own Label Mapping on receiving this from its downstream node. When the root node receives this P2MP Label Mapping from its downstream (transit) node, it checks the forwarding state for {Root IP Address, Opaque Value}. If not, it creates the forwarding state and pushes this "Label" onto all traffic that is forwarded over this P2MP LSP.In P2MP LSP, the rule for distribution is to advertise a label only towards the neighbor that lies on the IGP best path to the root. Thus the sender of the label determines the best path to the root.
ip vrf CUST1 rd 1:1 vpn id 1:1
route-target both 1:1
mdt default mpls mldp 1.1.1.1 ! interface Loopback 0 ip address 1.1.1.1 255.255.255.255 ip ospf 1 area 0 ! ip multicast-routing vrf CUST1 ! ip pim vrf CUST1 rp-address 12.1.1.1 ! interface fastethernet 1/1 ip vrf forwarding CUST1 ip address 192.168.1.1 255.255.255.0 ip pim sparse-mode ! router bgp 100 neighbor 3.3.3.3 remote-as 100 neighbor 3.3.3.3 update-source Loopback 0 neighbor 4.4.4.4 remote-as 100 neighbor 4.4.4.4 update-source Loopback 0 ! address-family vpnv4 neighbor 3.3.3.3 activate neighbor 4.4.4.4 activate exit-address-family ! address-family ipv4 vrf CUST1 redistribute connected exit-address-family ! PE2 and PE3 are config the same!!.
PE1 has no PIM adjacency with P router. However, it has PIM adjacency with PE2 and PE3 routers via Lspvif0 interface.
!--- The following output shows no PIM adjacencies within MPLS core
PE1# show ip pim neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
PE1#
!--- The following output shows PIM adjacencies with CE1 router, PE2 and PE3 routers
PE1# show ip pim vrf CUST1 neighbor
PIM Neighbor Table
Mode: B - Bidir Capable, DR - Designated Router, N - Default DR Priority,
P - Proxy Capable, S - State Refresh Capable, G - GenID Capable
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
192.168.1.2 FastEthernet1/1 00:01:03/00:01:40 v2 1 / DR S G
4.4.4.4 Lspvif0 00:26:24/00:01:25 v2 1 / DR S P G
3.3.3.3 Lspvif0 00:28:36/00:01:23 v2 1 / S P G
Now multicast traffic is sourced from CE1 router with CE2 being the multicast receiver. For PE1 router, the incoming interface is the interface connected to the CE1 router. The outgoing interface will be Lspvif0.PE1# show ip mroute vrf CUST1 239.10.10.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.10.10.1), 00:00:55/stopped, RP 12.1.1.1, flags: SP
Incoming interface: Lspvif0, RPF nbr 3.3.3.3
Outgoing interface list: Null
(192.168.1.2, 239.10.10.1), 00:00:55/00:02:04, flags: T
Incoming interface: FastEthernet1/1, RPF nbr 192.168.1.2
Outgoing interface list:
Lspvif0, Forward/Sparse, 00:00:50/00:02:39
http://blog.ine.com/2010/03/08/using-mpls-and-m-ldp-signaling-for-multicast-vpns/comment-page-1/#comment-108787
tested on "Cisco 7200 routers with 12.3(33)SRE"
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.10.10.1), 00:00:55/stopped, RP 12.1.1.1, flags: SP
Incoming interface: Lspvif0, RPF nbr 3.3.3.3
Outgoing interface list: Null
(192.168.1.2, 239.10.10.1), 00:00:55/00:02:04, flags: T
Incoming interface: FastEthernet1/1, RPF nbr 192.168.1.2
Outgoing interface list:
Lspvif0, Forward/Sparse, 00:00:50/00:02:39
http://blog.ine.com/2010/03/08/using-mpls-and-m-ldp-signaling-for-multicast-vpns/comment-page-1/#comment-108787
tested on "Cisco 7200 routers with 12.3(33)SRE"
