# Multipoint LDP (mLDP) – part I – a review of MDT groups #

INTRO: Understanding Multipoint LDP (mLDP) it’s quite more easy if it is linked to a real, though simulated, example and if the technology is compared to other ones that could give the same service. I decided then to divide this long post into two parts, the first one is a review of MDT technology in the context of Multicast VPN Service, I’ve already wrote an introductory post about MDT (Default and Data Groups) that you can read at this link, here I want to give some further details about the configuration used in Cisco IOS to implement MDT, especially for the use of the BGP MDT Address Family, looking at many Cisco docs didn’t clear my doubts, so I decided to do some test by myself. In the second part, I will look specifically to mLDP starting from what I review in the first part in terms of PIM based P-Tunnels built in the Service Provider Core. To benefit from reading these two posts you need a basic understanding of Multicast-Routing, PIM, Bootstrap Router, BGP, LDP, MPLS, MPLS Labeled Switch Paths (LSPs) and MPLS/L3-VPN.

I used this IOS for P and PE routers c7200-adventerprisek9-mz.122-33.SRE15 and a generic 15.x for CEs, C-Rcv, C-Source (you just need to support basic unicast and multicast ip routing on CEs and ip routing on C-Rcv and C-Source)

Part 1 – A REVIEW OF MDT GROUPS

Some time ago, I was dealing with a multicast VPN deployment of a customer, and I needed to review all sort of multicast vpn options are available today. When I started to review involved technology, I was used to the “legacy” Multicast VPN deployment that uses VRFs and MDT groups, that is, we have PIM deployed in the core of the network and the Service Provider is not using MPLS at all to switch multicast traffic inside its network (see this link for a post introducing MDTs), though it was using L3 MPLS-VPNs to forward unicast traffic of their customers. I started with a brief review of the most important RFCs related to multicast VPN and reading RFC 6513 “Multicast in MPLS/BGP IP VPNS” I came at a section where this RFC says that to move multicast traffic from one ingress PE to other egress PEs, P-tunnels must be used – a P-tunnel is a transport mechanism inside the network of the Service Provider that instantiates a Provider Multicast Service Interface (PMSI) – quoting RFC6513 “A PMSI is a conceptual “overlay” on the  P-network with the following property: a PE in a given MVPN can give  a packet to the PMSI, and the packet will be delivered to some or all of the other PEs in the MVPN, such that any PE receiving the packet will be able to determine the MVPN to which the packet belongs.” I like very much the abstraction made by the RFC authors in defining a Multicast VPN (MVPN) that based on that can be simply drawn in this way:

 

 

 

 

 

 

 

From RFC 6513 I can also know that, among the different technologies that we can use to instantiate PMSTI and to create P-Tunnels there are:

1] PIM – an example of using PIM to create P-Tunnels is MVPNs using Multicast Data Tree (MDTs), in this case we have PIM inside the Service Provider Network (on PE and P routers PIM builds the Tree needed to encapsulate C-multicast traffic (Customer-mutlicast-traffic) inside Provider Multicast Groups and data plane is not using MPLS at all, though is configured for unicast L3 transport (see this link for a basic example).

2] Multipoint LDP (mLDP) –  in this case we use Point-to-Multipoint (P2MP) Label Swicthed Paths (LSPs) or Multipoint-to-Multipoint (MP2MP) LSPs, in this case we don’t need to run PIM inside the Providers’ Network and switching of C-multicast-traffic is done by using MPLS labels.

3] RSVP-TE – in this case we use RSVP Traffic Engineering P2MP LSPs

4] A mesh of Unicast P-TunnelsThis is called also Ingress Replication

Before approaching mLDP details, I want to show you how multicast traffic from a VPN customer can be transported inside a Service Provider using a legacy mode – a mode that Cisco and probably other vendors (I’ve not verified) calls MVPN Profile 0 – that consists of using VRFs, PIM as a signaling protocol inside the core and mGRE Tunnels working as P-Tunnel to transport the encapsulated multicast traffic of the customer (call it C-traffic), reviewing this will help in compare the difference when mLDP is used as P-Tunnel instead of GRE Tunnel. In another post I described the idea behind MDT default and data groups, here I want to give some more details about what MDT is, especially I would try to clarify what the BGP MDT address family is used for and when it is necessary to have an active BGP session under this AF. Below you can find the topology I will use for my test, (don’t consider switches as part of the test, I used them only to deploy router configurations using Ansible via my working station, I was thinking to speed up the configuration but I’m not an expert Ansible user, so I got the opposite result, anyway, this is another story 🙂 )

C-traffic is composed by a source (172.16.6.6) connected to CE6 transmitting over C-multicast group 226.0.0.6 so (S,G) multicast entry will be (172.16.6.6,226.0.0.6), then customer has a Rendezvous Point C-RP that it uses to build PIM Sparse Mode Tree among its sites, then we have a Provider-RP that hosts multicast entries of the MDT groups used to tunnel C-traffic inside the core. Before configuring any customer traffic let’s build the core network step by step so it can support multicast traffic from the vrf customer.

To have a fully working Multicast VPN scenario many protocols are involved, so you need to cook them very well, ingredients are: PIM, MDT, GRE Tunnels, Multipoint GRE Tunnels (mGRE), BGP, LDP, to be precise PIM, MDT and GRE Tunnels (P2P and multipoint) build the multicast vpn solution, but you need BGP and LDP at some point to support them; though is not strictly necessary to have LDP in the core of the network (because you will not use label switching to move multicast vrf traffic (C-traffic)) it’s necessary to transport L3 VPN unicast info to support RPF check (against RP of the customer (C-RP) and against multicast source of the customer (C-Source)) inside the vrf, in other words you need valid unicast route toward the RP and toward the source inside the vrf), then as first step I will configure LDP inside the core network on P and PE routers, let’s see how, nothing special it’s a basic LDP distribution of labels.

FIRST STEP – CONFIGURE LDP INSIDE THE CORE

I used OSPF as IGP, all core links and Loopbacks have IP belonging to subnets of 10.0.0.0/8 address space, for the router working as RP inside the core (Provider-RP) I used max-metric router lsa under ospf process, to be sure to put out this router of the data path for unicast traffic, this router will act as BGP Route Reflector (RR) too, in this way (without faults in the network) by default it will be a pure control plane router (data traffic of vrf customers will not pass through it). I also constrained the mpls label space of each router of the core to different label space, so it will be easy to understand which is the router that imposes some labels in case I need to check it; that said, config of IGP/MPLS-LDP are:

mpls label range X000 X999 ==> [where X is 1,2,3,4 for P1,P2,P3,Provider-RP respectively and 10,20,30,40,50,60 for PE1,PE2,PE3,PE4,PE5,PE6 respectively]

mpls ldp router-id Loopback0

mpls ip ==> on all links between P, PE and Provider-RP routers

router ospf 1
router-id “Loopback0 ip address”
log-adjacency-changes
passive-interface Loopback0
network 10.0.0.0 0.255.255.255 area 0

NOTE: If you are tempted to configure mpls ldp autoconfig here, be aware that for what happens at step 2 (PIM creates GRE Tunnels that inherit ip address from the loopback interfaces) the autoconfig ospf command enables mpls also on the Tunnels created by PIM, so Tunnel starts to send Hello Packet encapsulated in its source/destination, encapsulated in UDP and sent as register packet to the RP, these packets are totally not useful so it’s better to control where you enable mpls.

Let’s check some LDP LSPs built between the loopback of some PEs:

Ok, we have LSPs between PEs Loopbacks, let’ move to the second step.

SECOND STEP – CONFIGURE PIM INSIDE THE CORE AND DEFINE WHO IS THE RP INSIDE THE CORE FOR THE MULTICAST GROUP USED TO TUNNEL MULTICAST C-TRAFFIC

Here I have some elements to define, as said Provider-RP will be the router acting as Rendezvous Point (RP) inside the core P-Network, having an RP inside the core means that I will use PIM SPARSE MODE to control how (*,G) and (S,G) tree are built inside the service provider core. I choose G = 239.1.1.1, this multicast group will tunnel the multicast traffic directed to multicast group used inside the vrf, for the customer I will use G = 226.0.0.6. I have to choose also how to distribute the RP identity inside the core network, the method I will use is the Bootsrap Router. Steps to configure all these things are:

  1. Enable multicast routing on all P and PE routers.
  2. Disable AutoRP on all P and PE routers ==> this is not necessary, but helps in keeping multicast routing table (mrib) of the router clean, if you leave autorp enabled routers will automatically join groups (*, 224.0.1.40) and you will see this entry in mrib, then I decided to remove autorp from the game, just for clarity.
  3. Enable PIM sparse-mode on all links connecting P and PE routers.
  4. Configure Provider-RP router to act as an RP and as Bootstrap Router (the router distributing RP info about who the RP is, in this case Provider-RP itself)

Resulting configuration for this steps will be:

Globally on all P, PE and Provider-RP routers

ip multicast-routing
no ip pim autorp

For every link connecting P, PE and Provider-RP routers:

ip pim sparse-mode

For each Lo0 on P, PE and Provider-RP routers:

int Lo0
ip pim sparse-mode
!
ip pim register-source Lo0

Only on Provider’RP:

ip pim rp-candidate Lo0
ip pim bsr-candidate Lo0

Let’s verify PIM operations before PEs are configured for MDT looking at the following picture:

I see that every PIM routers in the network knows who is the RP (10.0.0.204) knowing it via BSR, and that this RP is valid for the whole multicast space, also I can see that GRE Tunnels are built on every PIM router, these tunnel cannot be found in the configuration of the routers but are present as software structures that are part of the normal working of PIM; on all PIM routers of the core, except for Provider-RP, I have one tunnel Tunnel0 that has the Loopback0 as source and the Loopback0 of the RP as destination, the tunnel transports PIM traffic over IP and is used to encapsulate PIM Register message toward the elected RP (Provider-RP) when potential multicast source will become active for one of the multicast groups mapped to the RP itself; these potential sources will be all the PEs configured with an MDT group inside the configured vrf. Note that this GRE Tunnels are not the tunnels used to transport multicast traffic of the customer, these tunnels a.k.a P-Tunnels in RFC 6513 terms, will be instantiated by the configuration of MDT inside the vrf, and by the configuration of address-family ipv4 mdt under bgp process of each PEs.

On Provider-RP router I have two of these GRE Tunnel, Tu0 is still used to encapsulate PIM Register message from source that could be directly connected to router Provider-RP (in this scenario of Multicast VPN, no source will be directly connected to this router, so this Tunnel will never be used. Tunnel1 will act as the tunnel termination point for all Tunnel0 coming from each PEs and it will be used to decapsulate PIM Register Message sent by each PEs when working as active source on the MDT group 239.1.1.1, note that both Tu0 and Tu1 has Lo0 of Provider-RP itself as ip source and ip destination.

Let’s move to step 3.

THIRD STEP – CONFIGURE PEs WITH MINIMAL VRFs CONFIGURATION NEEDED TO ACTIVATE THEM AS SOURCE OF MDT GROUPS.

At step two, I prepared core network to handle multicast traffic that could arise from PEs, now it’s time to prepare PEs to send multicast traffic of the customer over this prepared PIM core, I will show you that when doing this PEs will act as sender and receiver over the default MDT group (I selected 239.1.1.1) and that multicast entries of the type (*, 239.1.1.1) and (“Lopoback0-IP”, 239.1.1.1) will be created in all routers (P, PE and Provider-RP). Sequence of steps is:

Create a minimal VRF (I name it C-ONE) configuration on one PE, I start from PE3 and check what happens:

With minimal here I mean this:

ip vrf C-ONE
rd 1:3
mdt default 239.1.1.1

enable multicast routing for the vrf and disable autorp for it:

PE3(config)#no ip pim vrf C-ONE autorp
PE3(config)#ip multicast-routing vrf C-ONE

enable link toward CE3 for the created vrf

interface FastEthernet2/1
ip vrf forwarding C-ONE
ip address 172.16.3.1 255.255.255.252

enable bgp process on PE3, I will use Provider-RP router as BGP route-reflector too, so define this neighbor under the BGP process:

PE3#show run | s r b
router bgp 100
bgp router-id 10.0.0.103
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.0.0.204 remote-as 100
neighbor 10.0.0.204 update-source Loopback0
!

with this configuration nothing happens, now activate the neighbor under the address-family ipv4 mdt adding this commands under bgp process

PE3(config)#router bgp 100
PE3(config-router)#address-family ipv4 mdt
PE3(config-router-af)#neighbor 10.0.0.204 activate

As soon as you enter the command a new Tunnel1 is created on PE3:

PE3#
*Nov 3 12:08:39.107: PIM(*): PIM subblock added to Tunnel1
*Nov 3 12:08:40.035: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up

This is how appears new Tunnel 1

PE3#show int Tu1 | i \.103|GRE
Interface is unnumbered. Using address of Loopback0 (10.0.0.103)
Tunnel source 10.0.0.103 (Loopback0)
Tunnel protocol/transport multi-GRE/IP => note the multipoint nature of the GRE Tunnel

This Tunnel is what plays the role of Provider Multicast Service Interface (PMSI) in RFC6513 terms, and it will be the interface that will tunnel multicast traffic of the customer under vrf C-ONE. The interesting thing is that you need to configure a minimum of these things to instantiate this PMSI: multicast-routing for the vrf, mdt group and the ipv4 mdt address family must contain a command that activate a potential neighbor, the other important thing to note is that I have configured no BGP at all on other routers so I really have no active BGP sessions on PE3, but the configuration reported above is enough to instantiate the PMSI, let’s verify that I have no active bgp sessions:

PE3#show ip bgp vpnv4 all summary

PE3#show ip bgp vpnv4 vrf C-ONE summary

PE3#show ip bgp ipv4 mdt all summary | b Neig
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.0.0.204 4 100 0 0 1 0 0 never (NoNeg) ==> the peer cannot negotiate this capability because it is not configured yet.

Now, let’s see which changes are made in PIM core network when this new Tunnel1 is activated. What happens is that PE3 starts to work simultaneously as multicast sender and as multicast receiver on the group 239.1.1.1, this can be viewed looking at some shows and to some packet captured on the link.

Following outputs tells me that PE3 sends to itself an IGMPv2 membership report, in other words it acts as a receiver for the group 239.1.1.1

PE3#show ip igmp membership 239.1.1.1 | i \*|Reporter
Reporter:
Channel/Group Reporter Uptime Exp. Flags Interface
*,239.1.1.1 0.0.0.0 03:22:56 stop 2VA Lo0

Upon receiving this igmp join, PE3, working as a first hop PIM router connected to a receiver sends a PIM (*,239.1.1.1) Join toward the RP (10.0.0.204) through P2, P2 forwards it up to the RP, during this process each involved router creates (*, 239.1.1.1) entry in its mrib. 

Looking at below captured packets I see also that PE3 sends a PIM Register-Source message toward the RP encapsulated in its Tunnel0 (source 10.0.0.103, destination 10.0.0.104) and that Provider-RP reply sending a PIM Register-Stop unicasted to PE3, since a receiver (PE3 itself) is already known to Provider-RP it also sends a PIM (S,G) Join toward the source (10.0.0.103 PE3) doing that al routers in the path between RP and the source will create also (10.0.0.103, 239.1.1.1) entries in their mribs.

The final state of the multicast entries at this step is this one:

At this point of the discussion is not important to analyze all the forwarding entries and OIL interfaces of the mribs, for now put in your memory that instantiating the PMSI, that is creating the mGRE Tunnel interface, creates multicast entries for the MDT group defined under the vrf and that on this interface the PE sends as a multicast source PIM Hello Packet originated from Lo0 10.0.0.103 and directed to all PIM Router 224.0.0.13, PE works as receiver too.

Let’s move on configuring the same minimal configuration on all other PEs, let’s start from PE1:

PE1#show run vrf | b ip vrf
ip vrf C-ONE
rd 1:1
mdt default 239.1.1.1
!
interface FastEthernet2/1
ip vrf forwarding C-ONE
ip address 172.16.1.1 255.255.255.252
!
PE1(config)#router bgp 100
PE1(config-router)#bgp router-id 10.0.0.101
PE1(config-router)#no bgp default ipv4-unicast
PE1(config-router)#neighbor 10.0.0.204 remote-as 100
PE1(config-router)#neighbor 10.0.0.204 update-source Lo0
PE1(config-router)#address-family ipv4 mdt
PE1(config-router-af)#neighbor 10.0.0.204 activate
*Nov 6 10:21:33.147: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up
*Nov 6 10:21:35.059: %PIM-5-DRCHG: VRF C-ONE: DR change from neighbor 0.0.0.0 to 10.0.0.101 on interface Tunnel1

As it can be seen by lokking at the log messages, as soon as I configure a neighbor under address family mdt a new Tunnel1 is created, let’s verify the type of tunnel:

PE1#show int Tu1 | i \.101|GRE
Interface is unnumbered. Using address of Loopback0 (10.0.0.101)
Tunnel source 10.0.0.101 (Loopback0)
Tunnel protocol/transport multi-GRE/IP

As expected we have a multi-GRE Tunnel, more interesting at this point is that on Tunnel1 inside vrf C-ONE PE3 and PE1 become PIM neighbors:

PE1#show ip pim vrf C-ONE neighbor | b Interface
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.0.0.103 Tunnel1 00:00:28/00:01:16 v2 1 / DR S P G

PE3#show ip pim vrf C-ONE neighbor | b Interface
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
10.0.0.101 Tunnel1 00:01:42/00:01:30 v2 1 / S P G

PE1#show int Tu0 | i PIM|GRE
Tunnel protocol/transport PIM/IPv4 ==> this is used to encapsulate PIM Register message toward Provider-RP

PE1#show int Tu1 | i PIM|GRE
Tunnel protocol/transport multi-GRE/IP ==> this is used to tunnel multicast traffic originating from the vrf.

Now, how the two PEs succeed in becoming PIM neighbors? Here it’s worth looking at the fact that we needed a bgp command to create the mGRE tunnel interface, but this is only how Cisco decide to implement the software structure of this service, in other words you need to configure a neighbor under address-family mdt and activate it, but no BGP neighbors are active at all so far, so is not BGP that transports PIM info between PEs, is only the PIM core that let PEs to discover each other through the Provider-RP that works as RP for the MDT group, this is true for normal PIM Sparse-Mode. Which is, then, the mechanism? When we create the mGRE Tunnel interface, these interfaces are enabled for PIM and as any other PIM enabled interface starts to send hello packets to the multicast address 224.0.0.13 (All PIM Routers):

PE3#show ip pim vrf C-ONE interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
10.0.0.103 Tunnel1 v2/S 1 30 1 10.0.0.103

PE1#show ip pim vrf C-ONE interface
Address Interface Ver/ Nbr Query DR DR
Mode Count Intvl Prior
10.0.0.101 Tunnel1 v2/S 1 30 1 10.0.0.103

I captured some of these packet on the cable, let’s see how they are transported in the PIM core:

When this packet is received by Provider-RP, it is first decapsulated on Tunnel1 interface:

Provider-RP#show int Tu1 | i up|Decap
Tunnel1 is up, line protocol is up
Description: Pim Register Tunnel (Decap) for RP 10.0.0.204

Note that same name Tunnel interfaces on different routers can have different functions, on Provider-RP Tunnel1 is the one receiving PIM Register message while I have no mGRE tunnel on it.

After being decapsulated, it’s delivered to the PIM process, since Provider-RP has already an outgoing interface active on the shared tree for the group 239.1.1.1, this first multicast packet addressed to 239.1.1.1 is sent down the shared tree to the receiver, who is the receiver? We’ve already seen that PE3 acts as a source and as a receiver for the multicast MDT group so the packet arrives by means of normal PIM forwarding to PE3, PE3 decapsulates it and receive the original PIM Hello from PE1, PE1 and PE3 becomes PIM neighbor on mGRE interface. After sending a Register Stop Message to PE1, PE1 stops to encapsulate multicast traffic to the RP and sends “normal” hello tunneled on mGRE Tunnel1 interface, here is the packet:

Now, leaving out all the PIM details about how the process continues, we can summarize in this way, when PE1 and PE3 starts to see each other as PIM neighbor and exchanging hello packets, they will be source and receiver reciprocally, then at some time they will leave the shared tree and will join the Source Tree where both PEs send (as source) and receive (as receiver) PIM hello packets, at the end of the game we can see these entries in the mribs of the three routers:

The picture shows how the forwarding of multicast packets on the MDT group 239.1.1.1 after some time switch on the Source Tree, the Rendezvous Point Provider-RP has its interfaces pruned on the Source Trees because it cannot be on the shortest path tree toward the source because I have configured max-metric router lsa under its ospf process to be sure of obtaining this, the figure shows also that counters are frozen on RP-Tree while moving on the Source Tree for both PEs.

Now to complete the game I have to configure remaining PEs, with the minimal configuration needed to enable the PIM core to tunnel multicast traffic (the one I’ve just written above), the configuration is the same seen for PE1 and PE3, after these configurations will be active, all PEs work as sender and receiver on the MDT group 239.1.1.1 and the PIM core is ready for tunnel multicast traffic for the VRFs. I complete these configurations on all PEs and then I summarize what I’ve done so far using the following figure:

The picture should show how after PIM in the core converges, PIM Source Trees are built, I have a source tree for each PE (source), Tunnel1 is the PMSI interface that will tunnel multicast traffic of the customer coming from the vrf into PIM in the core (Note that here the Tunnel-Id on all six PEs are all 1s, but the created Tunnel could have different IDs based on what Tunnels are already active on each routers), colored arrows show how the tunneled traffic flow over the PIM core. Now, are these minimal configurations and the consequent PIM states created in the core enough to effectively tunnel multicast traffic from the vrf connected to the customer? The answer is NO! Before moving on and see the reason behind that, let’s consider for a moment why Cisco associated the instantiation of the PMSI mGRE interface (Tunnel1 in my example) to the presence of the MDT address family under the BGP process. In other words, one might ask why do I need to configure BGP, if BGP is not really used to create the PIM state in the core that transport the tunneled multicast traffic? Answer to this question comes out if we consider “normal PIM Sparse-Mode” and “PIM SSM (Source Specific Multicast)”, in all the discussion I made so far I used a Rendezvous Point (RP) in the core and a generic private sparse-mode group, in my example 239.1.1.1, what happens if I use an SSM group as MDT group? SSM does not use an RP so PEs cannot discover each other meeting themselves on the RP as explained before, so how can they discover themselves without using an RP? We need another mechanism to inform a PE that other remote PEs are present and have instantiated a PMSI mGRE Tunnel interface over which they can communicate, this mechanism is the mdt address-family under the BGP process, using this address-family BGP uses an MDT SAFI that transport between BGP Peer these informations coded in a new Network Layer Reachability Information (NLRI):

RD:IPv4-address (12 octets) ==> RD is the route distinguisher configured under the vrf, and IPv4 address is the Loopback of the PE
Group Address (4 octets) ==> group address is the multicast group

Let’s make an example, I add a second vrf named C-TWO, this vrf will use an MDT default group of 239.232.1.1 working in Source Specific Multicast Mode (SSM)note that default assigned multicast range for SSM is 232/8, but I can define any group (in this case from a private space) to work in SSM Mode – In my test network I know that there is a Rendezvous Point (Provider-RP Router) that works as RP for the all multicast space, for SSM mode I don’t need an RP then to be sure Provider-RP is not some way elected as an RP for my SSM group of test, I can add these lines of configuration to it:

Provider-RP#show run | s access
access-list 1 deny 239.232.1.1 ==> deny the group I want to use as SSM group
access-list 1 permit 239.1.0.0 0.0.255.255 ==> I left 239.1.1.1 and some other space [239.1.0.0 – 239.1.255.255] to use as other MDT groups, to be mapped to Provider-RP’s Lo0
access-list 1 permit 224.0.0.0 0.255.255.255 ==> I left the well-known multicast address space

Provider-RP#show run | s candidate
ip pim bsr-candidate Loopback0 0
ip pim rp-candidate Loopback0 group-list 1 ==> this calls ACL1 and limits the advertisement of Lo0 10.0.0.204 as RP for only the permitted groups in the ACL

After this configuration I have:

Provider-RP#show ip pim rp mapping 239.1.1.1
Auto-RP is not enabled
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
This system is the Bootstrap Router (v2)
Group(s) 239.1.0.0/16
RP 10.0.0.204 (?), v2
Info source: 10.0.0.204 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:06:30, expires: 00:01:55

Then I still have an RP for the MDT default group of vrf C-ONE, and

Provider-RP#show ip pim rp mapping 239.232.1.1
Auto-RP is not enabled
PIM Group-to-RP Mappings
This system is a candidate RP (v2)
This system is the Bootstrap Router (v2)

This tells me that I have no RP for the group 239.232.1.1, then on all P and PEs routers I add these commands to tell them that group 239.232.1.1 will work as an SSM group

#access-list 2 permit 239.232.1.1
#ip pim ssm range 2

Now, let’s start on PE3 and activate new vrf C-TWO following these steps:

1] Define the vrf with only an RD
ip vrf C-TWO
rd 2:3

2] associate an interface that will go to a CE of this vrf to C-TWO (not shown in topology diagram)
int fa1/0
ip vrf forwarding C-TWO
ip address 172.16.3.9 255.255.255.252

3] enable multicast routing for the vrf and disable autorp
ip multicast-routing vrf C-TWO
no ip pim vrf C-TWO autorp

4] return under vrf configuration and configure the MDT group 239.232.1.1, remember that I defined this group as working in SSM mode and that I’ve already this configuration running for bgp process,

PE3#show run | s r b
router bgp 100
bgp router-id 10.0.0.103
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.0.0.204 remote-as 100
neighbor 10.0.0.204 update-source Loopback0
!
address-family ipv4 mdt
neighbor 10.0.0.204 activate

but at the moment no BGP session is active between PEs or between PEs and a Route Reflector:

PE3(config)#ip vrf C-TWO
PE3(config-vrf)#mdt default 239.232.1.1
*Nov 8 2017 10:40:33.183 ITALY: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up
Nov 8 2017 10:40:35.147 ITALY: %PIM-5-DRCHG: VRF C-TWO: DR change from neighbor 0.0.0.0 to 10.0.0.103 on interface Tunnel2

As soon as I put the mdt group under the vrf a new Tunnel2 is created this is the Provider Multicast Service Interface (PMSI) mGRE Tunnel for vrf C-TWO:

PE3#show ip int br | i Tu
Tunnel0 10.0.0.103 YES unset up up ==> used to encapsulate PIM register message to Provider-RP for sparse-mode group in the core
Tunnel1 10.0.0.103 YES unset up up ==> mGRE tunnel for vrf C-ONE using mdt 239.1.1.1 sparse-mode group
Tunnel2 10.0.0.103 YES unset up up ==> mGRE tunnel for vrf C-TWO using mdt 239.232.1.1 working in SSM mode

PE3#show int Tu2 | i \.103|GRE
Interface is unnumbered. Using address of Loopback0 (10.0.0.103)
Tunnel source 10.0.0.103 (Loopback0)
Tunnel protocol/transport multi-GRE/IP

I can say that the minimal configuration that can instantiate a PMSI interface also in the case I use an SSM group for mdt is the same that I used for non SSM mode, so which is the real difference? To see the difference let’s do the same configuration on another PE, for example PE1, adding the new vrf C-TWO configured for the same SSM group 239.232.1.1

Following the same steps used for PE3:

PE1(config)#ip vrf C-TWO
PE1(config-vrf)#mdt default 239.232.1.1

*Nov  8 11:04:56.815: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel2, changed state to up

*Nov  8 11:04:58.775: %PIM-5-DRCHG: VRF C-TWO: DR change from neighbor 0.0.0.0 to 10.0.0.101 on interface Tunnel2

I see that PE1 creates new Tunnel2 interface

PE1#show int Tu2 | i \.101|GRE
Interface is unnumbered. Using address of Loopback0 (10.0.0.101)
Tunnel source 10.0.0.101 (Loopback0)
Tunnel protocol/transport multi-GRE/IP

From a software structure point of view then, there is no difference between working with a sparse-mode group or an SSM mode, the real difference is that I have no RP where PE1 and PE3 can meet exchanging their hello packets, then it’s time to activate the BGP sessions in the core for the mdt address-family. I can choose to fully mesh PEs, instead I will use Provider-RP as a BGP route-reflector, why this router? Because it’s already active in the network and it’s a pure Control-Plane router, then let’s use it. Let’s verify that after some time we have no PIM neighborship between PE3 and PE1 on Tunnel2 interface:

PE3#show ip pim vrf C-ONE neighbor | b Address
Address Prio/Mode
10.0.0.101 Tunnel1 00:55:31/00:01:18 v2 1 / S P G
10.0.0.106 Tunnel1 01:11:25/00:01:20 v2 1 / DR S P G
10.0.0.105 Tunnel1 01:11:31/00:01:16 v2 1 / S P G
10.0.0.104 Tunnel1 01:12:18/00:01:25 v2 1 / S P G
10.0.0.102 Tunnel1 01:14:22/00:01:20 v2 1 / S P G

PE3#show ip pim vrf C-TWO neighbor | b Address
Address Prio/Mode

As first step I configure BGP on Provider-RP activating only PE3:

Provider-RP(config)#router bgp 100
Provider-RP(config-router)#bgp router-id 10.0.0.204
Provider-RP(config-router)#no bgp default ipv4-unicast
Provider-RP(config-router)#neighbor PE peer-group
Provider-RP(config-router)#neighbor PE remote-as 100
Provider-RP(config-router)#neighbor PE update-source Lo0
Provider-RP(config-router)#neighbor 10.0.0.103 peer-group PE
Provider-RP(config-router)#address-family ipv4 mdt
Provider-RP(config-router-af)#neighbor PE route-reflector-client
Provider-RP(config-router-af)#neighbor 10.0.0.103 activate

BGP session goes up ==> *Nov 8 10:22:52.134: %BGP-5-ADJCHANGE: neighbor 10.0.0.103 Up

Let’s check some BGP shows, looking at the picture below, to see what this new BGP adjacency between Provider-RP and PE3 adds to my MVPN game:

I see that when there is only a BGP active session between PE3 and Provider-RP (Route-Reflector), PE3 sends NLRI under AFI/SAFI = 1/66 for both MDT groups, but only for the group working as an SSM group the BGP attribute is passed to PIM. When a second PE (PE1 in the picture) is activated as a BGP peer of the Router Reflector under AF MDT, RR reflects these new NLRIs between PE3 and PE1 and they can now see each other as PIM neighbors on the new instantiated Tunnel2 mGRE interface.

Now, what I learned from this long test? That BGP MDT address family is used for both “normal” Sparse-Mode Group that use an RP in the Core, and for SSM Groups, the primary functions in both cases is to instantiate the mGRE Tunnels, then in the case of an SSM Group an active BGP session in this MDT address-family is needed to let PEs discover each other and become PIM neighbors on the mGRE Tunnels of the SSM MDT Group, instead in the case of using an RP in the core, BGP MDT active sessions are not necessary.

Now it should be clear how BGP MDT address-family works in the big picture of a MVPN, let’s move on. Are the configurations made so far enough to tunnel multicast traffic of the customer? As wrote before the answer is no, first of all I need some multicast traffic from the customer, then based on which type of multicast traffic is used by the vrf customer I need to satisfy the RPF requirement of this multicast solution, what does this mean? Customers behind the VRFs could use all the different types of multicast that is available, for example they can use PIM Sparse-Mode with an RP provided by themselves or PIM Sparse-Mode with an RP provided by the Service Provider, or PIM SSM or they can use Bidirectional-PIM, all of these multicast solutions must pass the RPF check to work; generally speaking, multicast solutions that use an RP have to pass two types of RPF check at some point, one against the RP IP Address and one against the Source IP Address, clearly multicast solutions that don’t use an RP must pass only the RPF check against the Source IP Address; now RPF rule says that to pass its RPF check, when receiving multicast traffic on an interface from a source, the router must have a valid UNICAST route to the source pointing out from the same interface, then I need also unicast info that must be transported between PEs, to have this I must use MPLS L3 VPN (and then you must use MPBGP vpnv4 address family too, and normally the L3 VPN traffic will be label switched in the core between Loopbacks of the PEs, and then you need LDP), so all protocols puzzle are joining together for building the whole MVPN picture, move then to the fourth step.

4TH STEP – ADD C-MULTICAST TRAFFIC AND ACTIVATE MPLS L3/VPN TO SATISFY RPF CHECK FOR THIS TRAFFIC

In my test network, customer of vrf C-ONE will use a pure PIM Sparse-Mode multicast solution using group 226.0.0.6, they have receivers in site 3 and 2, a router working as Rendezvous Point (C-RP) in site 5, and a multicast source in site 6 (C-Source). Let’s add this multicast traffic.

1] On receivers ask to join the multicast group 226.0.0.6

C-Rcv-3(config)#int e0/0
C-Rcv-3(config-if)#ip igmp join-group 226.0.0.6

C-Rcv-2(config)#int e0/0
C-Rcv-2(config-if)#ip igmp join-group 226.0.0.6

2] Enable multicast-routing and PIM on routers CEs

3] On PEs activate pim sparse mode on the interfaces facing CE routers

After these steps are completed CEs will receive a join for group 226.0.0.6, they become PIM neighbors of their attached PE but they cannot know who is the RP for the group 226.0.0.6, then they build an mroute (*, 226.0.0.6) entry in their mrib, but they cannot send a (*,G) PIM Join to their PEs toward the RP, because, as said, CEs has no RP info, as a consequence no (*, 226.0.0.6) entry is for now created on PEs, the following figure summarize the interesting multicast states for the customer:

4] Activate Rendezvous Point of the customer
To distribute info about who is the RP inside vrf C-ONE I will use Bootstrap Router method, let’s configure it:

C-RP(config)#ip multicast-routing
C-RP(config)#int e0/0
C-RP(config-if)#ip pim sparse-mode
C-RP(config)#ip pim rp-candidate e0/0
C-RP(config)#ip pim bsr-candidate e0/0
*Nov 9 11:03:04.866: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up ==> Tunnel encap to itself for potential directly attached sources
*Nov 9 11:03:04.867: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel1, changed state to up ==> Tunnel decap for PIM Register Source message

NOTE: these tunnels have nothing to do with MDT, they play the same role of Tu0 and Tu1 of Provider-RP but only for C-multicast traffic behind the vrf C-ONE

5] Activate multicast routing and PIM on CE5 an enable PIM on PE5 interface facing CE5

After these operations multicast states are:

I see how the RP mapping information (who is the RP?) travel up to CE5 but is not installed in PE5, the debug ip pim bsr message tells me that PE5 has no unicast path to the IP address that claims to be the RP (172.16.5.6), in other words, PE5 is failing a RPF check against the RP IP Address, then some sort of unicast routing must be present to support the distribution of multicast messages (this is a general rule always true), so I choose to use BGP between CE and PE and advertise the network between CE5 and C-RP.

6] Activate BGP between CE5 and PE5 in address-family ipv4 vrf C-ONE:

CE5#show run | s r b
router bgp 65005
bgp log-neighbor-changes
network 172.16.5.4 mask 255.255.255.252
neighbor 172.16.5.1 remote-as 100

PE5#show run vrf C-ONE | b router
router bgp 100
address-family ipv4 vrf C-ONE
no synchronization
neighbor 172.16.5.2 remote-as 65005
neighbor 172.16.5.2 activate

After this PE5 has a valid route and install RP mapping:

PE5#show ip pim vrf C-ONE rp map
Auto-RP is not enabled
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 172.16.5.6 (?), v2
Info source: 172.16.5.6 (?), via bootstrap, priority 0, holdtime 150
Uptime: 00:01:48, expires: 00:01:41

Verify that this RP mapping via bsr message is sent by PE5 to PE3 and to PE2 via mGRE Tunnel, activate debug ip pim vrf C-ONE on both PE2 and PE3:

PE3#
*Nov 9 14:19:50.011: PIM-BSR(1): bootstrap (172.16.5.6) on non-RPF path Tunnel1 or from non-RPF neighbor 0.0.0.0 discarded

PE3#show ip rpf vrf C-ONE 172.16.5.6
failed, no route exists

PE2#
*Nov 9 14:22:52.406: PIM-BSR(1): bootstrap (172.16.5.6) on non-RPF path Tunnel1 or from non-RPF neighbor 0.0.0.0 discarded

PE2#show ip rpf vrf C-ONE 172.16.5.6
failed, no route exists

You see that both PEs discard the RP mapping bsr message coming from PE5 on mGRE Tunnel1, the reason is again an RPF check failure against the advertised RP IP address, this happens because PE3 and PE2 has no valid UNICAST route to the ip 172.16.5.6 inside vrf C-ONE, so the game should be clear now, you MUST enable L3 VPN Unicast routing exchange between PEs to support a Multicast VPN, you must distribute at least network IP reachability for the subnet where C-RP and (for a similar concept, RPF failure against C-Source) C-Source are connected, then the next step is:

7] activate MPBGP between PEs (here I use Provider-RP as BGP route-reflector) and distribute unicast network reachability for the subnet where C-RP, C-Source, C-Receivers are connected

I will complete now all the relevant configurations, then at the end of the post I will attach all the files so you can download them if you want, and I give some final shows about how Multicast traffic from customer of vrf C-ONE flows from one PEs to another over the PIM core, capturing some multicast packet in the data plane. NOTE: I will remove vrf C-TWO used before to demonstrate how BGP MDT address-family works.

Let’s visualize the final working configuration for my Multicast VPN scenario, the picture tries to summarize what each protocol is needed for:

Picture shows configurations for a CE, its connected PE and Provider-RP router that works both as an RP and a BGP route reflector, many protocols as already said (PIM, BGP, MPBGP, LDP,) works together to support a fullw working MVPN scenario.

Let’s try to visualize, looking at the following picture, how a converged PIM Sparse-Mode solution for customer behind vrf C-ONE builds its PIM Source Tree over the MDT default tree:

On the left side you can see the converged PIM states for MDT group 239.1.1.1 in the core, each PE acts as a source and as receiver on the MDT default group, colored arrows show you the way from a source PE toward remote receivers PEs, on the right side you can see the converged PIM states inside vrf C-ONE and how the traffic from source (172.16.6.6, 226.0.0.6) flows from the source to PE6, tunneled over MDT Tunnel1, and going down to the receivers after being decapsulated from Tunnel1. One side effect of using a default MDT is that when one PE transmits, all the PEs joined to the MDT default groups (that is all the PEs where the MDT group is configured) will receive the multicast traffic from the remote source, this happens also for the PEs that have no active receivers for the multicast group of the vrf. This behavior is not avoidable, because this is how MDT default group works, to confirm that multicast packets arrives to such PEs (in my example PE1, PE4 and PE5 too where RP of the customer is connected but no receivers are present) I captured the packets on the wires:

Just for curious people, I configured an icmp sla probe on C-SRC that continuously sends pings to group 226.0.0.6 from source 172.16.6.6. Here the result from a manual ping:

C-Source#ping 226.0.0.6 source 172.16.6.6
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 226.0.0.6, timeout is 2 seconds:
Packet sent with a source address of 172.16.6.6

Reply to request 0 from 172.16.3.6, 58 ms
Reply to request 0 from 172.16.2.6, 68 ms

The picture should clearly show that the transmission of multicast packets from the source to the receivers is pure mGRE/IP transport, no MPLS-LDP-Labels are used for this traffic, also it can be seen that useless multicast traffic is delivered over the PIM MDT core to the PEs where no receivers interested in that traffic are present. Unicast replies are Labeled switched instead as per standard L3 MPLS/VPN service. Having useless traffic on some PEs is a limitation due to how Default MDT works, you can run many optimizations to avoid this, for example using MDT Data Groups on a vrf (you can read about my basic test on MDT Data here), other optimizations can be about the PIM states that need to be maintained in the core, for example if using only SSM Groups as MDT Default, you can eliminate the use of Rendezvous Point in the core (but in this case you need to have active BGP MDT sessions that allow PEs to discover each other via MDT update), you can use also Bidirectional-PIM for Default MDT to minimize the PIM states in the core; now, these are all PIM design choices, the question that could come at this point is, I can label switch unicast packet for customers, it’s possible to label switch also the multicast traffic eliminating PIM from the core of the network? Now that I reviewed how PIM/MDT works from a control plane and data plane point of view, I can better understand how to use mLDP to reach this target, this is the subject of the second part of this post that you can read here.

Router-Config-PIM_MDT