CCIE SPv4 MPLS Multicast VPN - Profile 14 Partitioned MDT - MLDP P2MP - BGP-AD - BGP C-mast Signaling

In this post we will take a look at Profile 14, this is follow on from Profile 5 which used PIM as the customer multicast signaling mechanism. This profile leverages BGP as the customer multicast signaling mechanism. This profile is supported on IOS and XR, with IOS there is a new command I want to briefly touch on, mdt strict-rpf interface, which is a command required when using partitioned MDTs. The documentation states the command is required, which isn't true, it is optional. It is more a way to prevent problems like duplicate multicast streams. If not enabled, traffic will still be delivered, but sub-optimal multicast flows may result.

The logic is that an RPF check is executed, which is checking to make sure the source traffic is coming in on the interface the router would used to forward back to the source, reverse path forwarding. If the interface is a multi-access interface, more than one destination reachable out that interface, the local router may not be the correct RPF neighbor on that interface. If R15 was dually connected to R1 and R4, and both routers were receiving multicast traffic from R15, R15 could send twice the multicast flows, one to R1 and one to R4.

The remote PE, like R7 for instance could receive a multicast flow from R1 and R4. If PIM is used as the overlay signaling protocol, this is not likely but not impossible to happen, as asserts would be triggered and one of the flows would be stopped. Since we are using BGP as the C-Mcast signaling, this is guaranteed not happen, asserts that is, so IOS ingress PEs need to have a way to prevent duplicate multicast flows. This capability doesn't apply to our design since each CE is singly attached to a PE and not dually attached.

Feel free to review this Cisco guide on this, I have offered my interpretation of the issue.

https://www.cisco.com/c/en/us/support/docs/ip/multicast/118677-technote-mvpn-00.html

R1, R3, R7
vrf definition MVPN
 address-family ipv4
  mdt preference mldp 
  mdt auto-discovery mldp
  mdt strict-rpf interface
  mdt partitioned mldp p2mp
  mdt overlay use-bgp
!
mpls mldp logging notifications

XR1, XR5 and XR6
router pim
 vrf CORE
  address-family ipv4
   rpf topology route-policy RPL_MLDP_PART_P2MP

   mdt c-multicast-routing bgp
!
mpls ldp
 mldp

  logging notifications

Since we are dealing with on demand flows from SSM joined groups, ASM groups are also supported but not tested. We will join a couple new SSM groups, we have enabled MLDP logging on all the routers as well. Not much has changed in the BGP or MPLS verification's so I will skip those and focus on new group signaling with the associated log messages and then verify the reachability.

R18 will join a new SSM group, 232.18.18.18 with a source of R16s PE facing interface.

R18
  int l00
  ip igmp join-group 232.18.18.18 source 100.64.204.16

We configure R18 to join a new SSM group.


R7
%MLDP-5-ADD_BRANCH: [gid 7 (0x00000007)] Root: 192.0.2.21, Add P2MP branch MDT remote label

R7 is the last hop router, it needs to add a new label mapping message and new P2MP MDT with a root of XR1, which is the PE that connects to the customer source.

XR1
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x0002A [global-id 7] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label 
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x0002A [global-id 7] P2MP 192.0.2.21, Add LDP 192.0.2.22:0 branch remote label 92026

XR1 also generated a log message, with 2 different labels for the new MDT, one "no_label" for the multicast label and label 92026 to reach the next hop of XR2.

R16#sh ip mroute ssm

(100.64.204.16, 232.18.18.18), 00:10:06/00:03:28, flags: sPT
  Incoming interface: GigabitEthernet1.204, RPF nbr 0.0.0.0
  Outgoing interface list: Null

We check R16 and see an (S, G) entry proving that the signaling worked.

R7#sh ip multicast vrf MVPN mpls vif 

Interface   Next-hop             Application     Ref-Count   Table / VRF name   Flags
 Lspvif0     0.0.0.0              MDT               N/A       1    (vrf MVPN) 0x1
 Lspvif2     192.0.2.1            MDT               N/A       1    (vrf MVPN) 0x1
 Lspvif1     192.0.2.21           MDT               N/A       1    (vrf MVPN) 0x1

We check the local VIF database and see that LSPVIF1 points to XR1.

R7#sh ip rpf vrf MVPN 100.64.204.16
RPF information for ? (100.64.204.16)
  RPF interface: Lspvif0
  Strict-RPF interface: Lspvif1
  RPF neighbor: ? (192.0.2.21)
  RPF route/mask: 100.64.204.0/24
  RPF type: unicast (bgp 50693)
  Doing distance-preferred lookups across tables
  BGP originator: 192.0.2.21
  RPF topology: ipv4 multicast base, originated from ipv4 unicast base

We check R7's output for the RPF connection, this is where we verify the "strict RPF interface" command which points to LSPVIF1 which is the overlay tunnel we'll use to reach the source of the traffic.

R7#sh ip pim vrf MVPN 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,
      L - DR Load-balancing Capable
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Prio/Mode
100.64.214.18     GigabitEthernet1.214     2d10h/00:01:37    v2    1 / DR S P G
192.0.2.21        Lspvif1                  04:37:57/00:01:42 v2    1 / DR G

Technically there shouldn't be any PIM adjacencies on R7 except to the CE device, but we have one towards XR1, which ties to LSPVIF1 which is our RPF interface. I can't find a way to disable PIM on XR to resolve this so I just ignore it knowing it's not necessary.

R7#sh mpls forwarding-table labels 7026 - 7029
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
7026  [T]  No Label   [gid 7 (0x00000007)][V]   \
                                       1220          aggregate/MVPN 
7027  [T]  No Label   [gid 3 (0x00000003)][V]   \
                                       0             aggregate/MVPN 
7028  [T]  No Label   [gid 1 (0x00000001)][V]   \
                                       0             aggregate/MVPN 
7029  [T]  No Label   [gid 4 (0x00000004)][V]   \
                                       0             aggregate/MVPN 

We check the MPLS forwarding table for "MVPN" and see 4 labels, which we then filter down to just those labels.

R16#ping 232.18.18.18 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 232.18.18.18, timeout is 2 seconds:

Reply to request 0 from 192.0.2.18, 30 ms
Reply to request 1 from 192.0.2.18, 8 ms
Reply to request 2 from 192.0.2.18, 8 ms
Reply to request 3 from 192.0.2.18, 9 ms
Reply to request 4 from 192.0.2.18, 8 ms
Reply to request 5 from 192.0.2.18, 8 ms
Reply to request 6 from 192.0.2.18, 13 ms
Reply to request 7 from 192.0.2.18, 8 ms
Reply to request 8 from 192.0.2.18, 10 ms
Reply to request 9 from 192.0.2.18, 7 ms

On the source, R16, we ping to the SSM group 232.18.18.18 and get replies back.

R7#sh mpls forwarding-table labels 7026 - 7029
Local      Outgoing   Prefix           Bytes Label   Outgoing   Next Hop    
Label      Label      or Tunnel Id     Switched      interface              
7026  [T]  No Label   [gid 7 (0x00000007)][V]   \
                                       1830          aggregate/MVPN 
7027  [T]  No Label   [gid 3 (0x00000003)][V]   \
                                       0             aggregate/MVPN 
7028  [T]  No Label   [gid 1 (0x00000001)][V]   \
                                       0             aggregate/MVPN 
7029  [T]  No Label   [gid 4 (0x00000004)][V]   \
                                       0             aggregate/MVPN 

Checking the LFIB on R7 we see label 7026 has incremented bytes label switched.

Thanks for stopping by!

Rob Riker, CCIE #50693