In the Profile 11 post, CustA’s PEs moved their multicast signalling into BGP and kept a GRE default MDT on the PIM-SSM group 232.0.10.1. Profile 13 keeps the BGP signalling and builds the default MDT with mLDP.
mLDP builds multicast trees from LDP label mappings. A point-to-multipoint (P2MP) tree carries traffic from its root to its leaves. On a multipoint-to-multipoint (MP2MP) tree, every member sends to and receives from all the others, and the tree is built toward one root.
On A-PE1, the group 232.0.10.1 is gone, and the default MDT is MDT number 0 on Lspvif0, an LSP virtual interface:
A-PE1#show ip mroute 232.0.10.1
Group 232.0.10.1 not found
A-PE1#show ip mroute | i 232.1.10
A-PE1#show ip pim vrf CustA mdt
* implies mdt is the default MDT, # is (*,*) Wildcard,
> is non-(*,*) Wildcard
MDT Group/Num Interface Source VRF
* 0 Lspvif0 Loopback0 CustATopology file: topology.clab.yml · Addressing: ipam.md · Stage configs, 2 nodes (A-PE1, A-PE2): stage_configs/lab03-s5b-spa-mvpn-p13/
The stage ends without a data MDT. The data MDT is a P2MP tree rooted at A-PE1, and A-PE2 could not join it. A-PE2’s path to A-PE1 is an RSVP-TE tunnel with next hop 0.0.0.0, so mLDP found no LDP neighbour to send its join to.
The Configuration
The change on A-PE1:
vrf definition CustA
vpn id 64501:10
address-family ipv4
no mdt auto-discovery pim
no mdt default 232.0.10.1
mdt auto-discovery mldp
mdt default mpls mldp 10.1.0.1
mdt default mpls mldp 10.1.0.3
exit-address-familyA-PE1.ios applies on top of the Profile 11 configuration in stage_configs/lab03-s5a-spa-mvpn-p11/: the BGP IPv4 MVPN address family on the PEs and A-RR, mdt overlay use-bgp and the customer RP. Profile 13 carries its auto-discovery and C-multicast routes in that address family, so it does not work without the Profile 11 configuration.
mdt auto-discovery mldp replaces mdt auto-discovery pim: BGP auto-discovery stays, with mLDP building the provider tunnel. The two mdt default mpls mldp lines make A-P1, 10.1.0.1, and A-P3, 10.1.0.3, the roots of two MP2MP trees. A-P1 is A-PE1’s neighbour on Gi2, and A-P3 is A-PE2’s neighbour on Gi2. A PE sends on one tree and receives only on the trees it has joined, so both PEs list both roots.
mLDP identifies a tree by its root and an opaque value. IOS-XE builds the opaque value from the VPN ID and an MDT number, so the VPN ID has to be the same on every PE of the multicast VPN, here A-PE1 and A-PE2. The VPN ID is separate from the route distinguisher, which is different on each PE. A-PE2 has the same VPN ID:
A-PE2#show run vrf CustA | i vpn id
vpn id 64501:10mLDP is on by default on IOS-XE, and it runs on the P routers with their existing LDP configuration. BGP sessions with both PEs in the IPv4 MVPN address family were not modified, since the RR router will not need any change:
! trimmed to the neighbour table
RP/0/RP0/CPU0:A-RR#show bgp ipv4 mvpn sum
Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd
10.1.0.5 0 64501 15378 14058 21 0 0 3d08h 1
10.1.0.6 0 64501 15392 14057 21 0 0 3d08h 2The MP2MP Trees
A-PE1’s Type 1 route names the tree in its PMSI Tunnel attribute:
BGP routing table entry for [1][10.1.0.5:10][10.1.0.5]/12, version 327
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
Advertised to update-groups:
1
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.1.0.5)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Community: no-export
Extended Community: RT:64501:10
PMSI Attribute: Flags: 0x0, Tunnel type: 7, length 24, label: exp-null, tunnel parameters: 0800 0104 0A01 0001 000E 0200 0B06 4501 0000 0010 0000 0000
rx pathid: 0, tx pathid: 0x0Tunnel type 7 is an mLDP MP2MP LSP, and the tunnel parameters are the tree’s FEC element. 08 is the type of the MP2MP downstream FEC element, 0A01 0001 is the root, 10.1.0.1, and the last four bytes are the MDT number, 0. IOS-XE reads the VPN ID 64501:10 as hexadecimal, so it shows up as 06 4501 0000 0010.
Both PEs join both trees. A-PE1’s mLDP database:
A-PE1#show mpls mldp database
* For interface indicates MLDP recursive forwarding is enabled
* For RPF-ID indicates wildcard value
> Indicates it is a Primary MLDP MDT Branch
LSM ID : 1 (RNR LSM ID: 2) Type: MP2MP Uptime : 00:05:22
FEC Root : 10.1.0.1
Opaque decoded : [mdt 64501:10 0]
Opaque length : 11 bytes
Opaque value : 02 000B 0645010000001000000000
RNR active LSP : (this entry)
Candidate RNR ID(s): 3
Upstream client(s) :
10.1.0.1:0 [Active]
Expires : Never Path Set ID : 1
Out Label (U) : 1124 Interface : GigabitEthernet2*
Local Label (D): 1521 Next Hop : 10.1.1.21
Replication client(s):
> MDT (VRF CustA)
Uptime : 00:05:22 Path Set ID : 2
Interface : Lspvif0 RPF-ID : *
LSM ID : 3 (RNR LSM ID: 2) Type: MP2MP Uptime : 00:05:22
FEC Root : 10.1.0.3
Opaque decoded : [mdt 64501:10 0]
Opaque length : 11 bytes
Opaque value : 02 000B 0645010000001000000000
RNR active LSP : 1 (root: 10.1.0.1)
Upstream client(s) :
10.1.0.1:0 [Active]
Expires : Never Path Set ID : 3
Out Label (U) : 1125 Interface : GigabitEthernet2*
Local Label (D): 1522 Next Hop : 10.1.1.21
Replication client(s):
> MDT (VRF CustA)
Uptime : 00:05:22 Path Set ID : 4
Interface : Lspvif0 RPF-ID : *A-PE1 reaches both roots through A-P1, 10.1.1.21 on Gi2. RNR active LSP is root node redundancy: a PE sends on the tree whose root has the lowest cost, and the other tree is a candidate. A-PE1 sends on LSM 1, the tree rooted at A-P1.
A-PE2 sends on the tree rooted at A-P3, its lower-cost root, metric 2 against 3:
! trimmed to the RNR lines
A-PE2#show mpls mldp database
LSM ID : 1 (RNR LSM ID: 2) Type: MP2MP Uptime : 04:35:02
FEC Root : 10.1.0.1
RNR active LSP : 3 (root: 10.1.0.3)
LSM ID : 3 (RNR LSM ID: 2) Type: MP2MP Uptime : 04:32:29
FEC Root : 10.1.0.3
RNR active LSP : (this entry)
Candidate RNR ID(s): 1A-PE2#show mpls mldp root
Root node : 10.1.0.1
Metric : 3
Distance : 110
Interface : GigabitEthernet3 (via unicast RT)
FEC count : 1
Path count : 2
Path(s) : 10.1.1.33 LDP nbr: 10.1.0.4:0 GigabitEthernet3
: 10.1.1.29 LDP nbr: 10.1.0.3:0 GigabitEthernet2
Root node : 10.1.0.3
Metric : 2
Distance : 110
Interface : GigabitEthernet2 (via unicast RT)
FEC count : 1
Path count : 1
Path(s) : 10.1.1.29 LDP nbr: 10.1.0.3:0 GigabitEthernet2With CustA-HQ sending to 239.10.10.10, A-P1 has switched 35360 bytes with label 1124, A-PE1’s upstream label for the tree rooted at A-P1, and none with 1125:
A-P1#show mpls forwarding-table | i mdt
1124 1307 [mdt 64501:10 0] 35360 Gi3 10.1.1.18
1125 1303 [mdt 64501:10 0] 0 Gi3 10.1.1.18
1126 1522 [mdt 64501:10 0] 0 Gi5 10.1.1.22
1127 1521 [mdt 64501:10 0] 0 Gi5 10.1.1.22Both trees run from A-PE1 through A-P1 and A-P3 to A-PE2:
Each PE’s label mapping travels toward the root along the unicast path, and each router on that path joins the tree. A-PE2 reaches both roots through A-P3, and A-P1 and A-P3 reach each other over their direct link, so the trees do not pass through A-P2 or A-P4. A-PE2 also has an equal-cost path to A-P1 through A-P4, and mLDP chose the path through A-P3. The mLDP databases on A-P2 and A-P4 are empty:
A-P2#show mpls mldp data
* For interface indicates MLDP recursive forwarding is enabled
* For RPF-ID indicates wildcard value
> Indicates it is a Primary MLDP MDT BranchA-P4#show mpls mldp data
* For interface indicates MLDP recursive forwarding is enabled
* For RPF-ID indicates wildcard value
> Indicates it is a Primary MLDP MDT Branch
A-P4#A-PE2 receives CustA-HQ’s flow on Lspvif0, with the sending PE, A-PE1, 10.1.0.5, as the RPF neighbour, and sends it to CustA-Br1 on Gi4:
(*, 239.10.10.10), 3d05h/00:03:15, RP 10.10.0.1, flags: Sg
Incoming interface: Lspvif0, RPF nbr 10.1.0.5
Outgoing interface list:
GigabitEthernet4, Forward/Sparse, 3d05h/00:03:15
(10.10.0.1, 239.10.10.10), 00:01:06/00:01:53, flags: TgQ
Incoming interface: Lspvif0, RPF nbr 10.1.0.5
Outgoing interface list:
GigabitEthernet4, Forward/Sparse, 00:01:06/00:03:22IOS-XE presents the multicast VPN’s mLDP trees to the VRF as one interface, Lspvif0. In Profile 11, Tunnel1 had that role for the GRE default MDT. In A-PE1’s mLDP database, both MP2MP trees list MDT (VRF CustA) on Lspvif0 as a replication client.
The Data MDT
Removing mdt default 232.0.10.1 also removed the data MDT line of Profile 11, mdt data 232.1.10.0 0.0.0.255 threshold 1. IOS-XE refuses it without a group default MDT:
A-PE2(config-vrf-af)#mdt data 232.1.10.0 0.0.0.255 threshold 1
% MDT default group must be configured firstThe mLDP form moves selected flows onto a P2MP tree rooted at the PE behind the source. The lines on A-PE1 and A-PE2:
ip access-list extended ACL_DATA_MDT_CUSTA
permit ip any host 239.10.10.20
vrf definition CustA
address-family ipv4
mdt data mpls mldp 10 list ACL_DATA_MDT_CUSTA immediate-switch
exit-address-familyThe ACL selects 239.10.10.20 only, so 239.10.10.10 stays on the default MDT. immediate-switch replaces threshold 1, so the switch to the data MDT does not depend on the flow’s rate. 10 is the maximum number of data MDTs for the VRF.
A data MDT carries a flow only to the PEs with receivers for it. Here, 239.10.10.20 should leave the MP2MP trees for a P2MP tree that runs from A-PE1 to A-PE2, the PE behind the receiver, CustA-Br1.
CustA-Br1 joined 239.10.10.20, and CustA-HQ sent to it. A-PE1 announced the data MDT in a Type 3 route:
BGP routing table entry for [3][10.1.0.5:10][10.10.0.1][239.10.10.20][10.1.0.5]/22, version 341
Paths: (1 available, best #1, table MVPNv4-BGP-Table, not advertised to EBGP peer)
Advertised to update-groups:
1
Refresh Epoch 1
Local
0.0.0.0 from 0.0.0.0 (10.1.0.5)
Origin incomplete, localpref 100, weight 32768, valid, sourced, local, best
Community: no-export
Extended Community: RT:64501:10
PMSI Attribute: Flags: 0x0, Tunnel type: 2, length 24, label: exp-null, tunnel parameters: 0600 0104 0A01 0005 000E 0200 0B06 4501 0000 0010 0000 0001
rx pathid: 0, tx pathid: 0x0Tunnel type 2 is an mLDP P2MP LSP. In the tunnel parameters, 06 is the type of the P2MP FEC element, the root is 0A01 0005, A-PE1’s own 10.1.0.5, and the MDT number is 1. A-PE1 is the root of the new tree:
A-PE1# show mpls mldp data opaque_type mdt 64501:10 1
LSM ID : 5 Type: P2MP Uptime : 00:00:45
FEC Root : 10.1.0.5 (we are the root)
Opaque decoded : [mdt 64501:10 1]
Opaque length : 11 bytes
Opaque value : 02 000B 0645010000001000000001
Upstream client(s) :
None
Expires : N/A Path Set ID : 7
Replication client(s):
> MDT (VRF CustA)
Uptime : 00:00:45 Path Set ID : None
Interface : Lspvif0 RPF-ID : *The Leaf Information Required flag is 0 in Flags: 0x0, so A-PE1 asks for no Leaf auto-discovery routes. With mLDP, A-PE2 joins the tree itself: it sends a label mapping toward 10.1.0.5, to the LDP neighbour that is its next hop toward that root. A-PE2’s root table has no such neighbour:
A-PE2#show mpls mldp root
Root node : 10.1.0.1
Metric : 3
Distance : 110
Interface : GigabitEthernet3 (via unicast RT)
FEC count : 1
Path count : 2
Path(s) : 10.1.1.33 LDP nbr: 10.1.0.4:0 GigabitEthernet3
: 10.1.1.29 LDP nbr: 10.1.0.3:0 GigabitEthernet2
Root node : 10.1.0.3
Metric : 2
Distance : 110
Interface : GigabitEthernet2 (via unicast RT)
FEC count : 1
Path count : 1
Path(s) : 10.1.1.29 LDP nbr: 10.1.0.3:0 GigabitEthernet2
Root node : 10.1.0.5
Metric : 0
Distance : 1
Interface : Tunnel20 (via unicast RT)
FEC count : 1
Path count : 1
Path(s) : 0.0.0.0 LDP nbr: NULL Tunnel20The path to 10.1.0.5 is Tunnel20, A-PE2’s RSVP-TE tunnel to A-PE1 from the inter-area TE post. Its autoroute destination installed a static route to 10.1.0.5 with no next-hop address:
A-PE2#show ip route 10.1.0.5
Routing entry for 10.1.0.5/32
Known via "static", distance 1, metric 0 (connected)
Routing Descriptor Blocks:
* directly connected, via Tunnel20
Route metric is 0, traffic share count is 1mLDP takes its path from the unicast routing table, via unicast RT in the root table. The static multicast route from the IP multicast core post points the RPF check for 10.1.0.5 to Gi2, and mLDP does not use it:
A-PE2#show ip rpf 10.1.0.5
RPF information for ? (10.1.0.5)
RPF interface: GigabitEthernet2
RPF neighbor: ? (10.1.1.29)
RPF route/mask: 10.1.0.5/32
RPF type: multicast (static)
Doing distance-preferred lookups across tables
RPF topology: ipv4 multicast baseWithout an LDP neighbour toward 10.1.0.5, A-PE2 sent no label mapping, so the tree has no branch to A-PE2. A-PE2 has the tree in its database with no upstream client:
A-PE2#show mpls mldp data opaque_type mdt 64501:10 1
LSM ID : 5 Type: P2MP Uptime : 00:03:36
FEC Root : 10.1.0.5
Opaque decoded : [mdt 64501:10 1]
Opaque length : 11 bytes
Opaque value : 02 000B 0645010000001000000001
Upstream client(s) :
None
Expires : N/A Path Set ID : 7
Replication client(s):
MDT (VRF CustA)
Uptime : 00:03:36 Path Set ID : None
Interface : Lspvif0 RPF-ID : *PIM on A-PE2 still sets Y, Joined MDT-data group, on the (S,G) entry:
(*, 239.10.10.20), 00:04:20/00:03:05, RP 10.10.0.1, flags: Sg
Incoming interface: Lspvif0, RPF nbr 10.1.0.5
Outgoing interface list:
GigabitEthernet4, Forward/Sparse, 00:04:20/00:03:05
(10.10.0.1, 239.10.10.20), 00:04:06/stopped, flags: TYgQ
Incoming interface: Lspvif0, RPF nbr 10.1.0.5, MDT: [1, 10.1.0.5]/never
Outgoing interface list:
GigabitEthernet4, Forward/Sparse, 00:04:06/00:03:05A-PE1 sends 239.10.10.20 on the data MDT, MDT-data number 1 in its send list:
A-PE1#show ip pim vrf CustA mdt send
MDT-data send list for VRF: CustA
(source, group) MDT-data group/num ref_count
(10.10.0.1, 239.10.10.20) 1 1CustA-HQ’s ping to 239.10.10.20 got replies only to requests 0 to 8:
CustA-HQ#ping 239.10.10.20 source lo0 repeat 10000
Type escape sequence to abort.
Sending 10000, 100-byte ICMP Echos to 239.10.10.20, timeout is 2 seconds:
Packet sent with a source address of 10.10.0.1
Reply to request 0 from 10.10.0.2, 7 ms
Reply to request 0 from 10.10.0.2, 7 ms
Reply to request 1 from 10.10.0.2, 4 ms
Reply to request 1 from 10.10.0.2, 4 ms
Reply to request 2 from 10.10.0.2, 4 ms
Reply to request 2 from 10.10.0.2, 5 ms
Reply to request 3 from 10.10.0.2, 3 ms
Reply to request 3 from 10.10.0.2, 3 ms
Reply to request 4 from 10.10.0.2, 3 ms
Reply to request 4 from 10.10.0.2, 3 ms
Reply to request 5 from 10.10.0.2, 4 ms
Reply to request 5 from 10.10.0.2, 5 ms
Reply to request 6 from 10.10.0.2, 4 ms
Reply to request 6 from 10.10.0.2, 4 ms
Reply to request 7 from 10.10.0.2, 4 ms
Reply to request 7 from 10.10.0.2, 4 ms
Reply to request 8 from 10.10.0.2, 5 ms
Reply to request 8 from 10.10.0.2, 5 ms.............................................................
...................
CustA-HQ#mpls mldp path traffic-eng lets mLDP use TE tunnels and expects LDP to run on them. The test commands on A-PE1, the same on A-PE2 with Tunnel20:
mpls mldp path traffic-eng
interface Tunnel10
mpls ipWith this configuration, A-PE2 had a targeted LDP session to 10.1.0.5 over Tunnel20:
A-PE2#show run | i mpls mldp
mpls mldp path traffic-eng
A-PE2#show run int Tunnel20 | i mpls|autoroute
mpls ip
tunnel mpls traffic-eng autoroute destination
A-PE2#show mpls interfaces
Tunnel20 Yes (ldp) No No No Yes
A-PE2#show mpls ldp discovery
Tunnel20 (ldp): Targeted -> 10.1.0.5
Targeted Hellos:
10.1.0.6 -> 10.1.0.5 (ldp): active/passive, xmit/recv
LDP Id: 10.1.0.5:0However, the root entry stayed the same:
Root node : 10.1.0.5
Interface : Tunnel20 (via unicast RT)
Path(s) : 0.0.0.0 LDP nbr: NULL Tunnel20mLDP still had no next-hop address to map to that LDP session.
The mdt data line and both test commands were removed from A-PE1 and A-PE2. The removal on A-PE1, the same on A-PE2 with Tunnel20:
no mpls mldp path traffic-eng
interface Tunnel10
no mpls ip
vrf definition CustA
address-family ipv4
no mdt data mpls mldp 10 list ACL_DATA_MDT_CUSTA immediate-switch
exit-address-familyA-PE1 after the change:
A-PE1#show run | i mpls mldp path|^mpls ip
A-PE1#show mpls interfaces
Interface IP Tunnel BGP Static Operational
GigabitEthernet2 Yes (ldp) Yes No No Yes
GigabitEthernet3 Yes (ldp) Yes No No Yes
Tunnel10 No No No No Yes
Tunnel11 No No No No YesThe ping to 239.10.10.20 then got replies to all 20 requests:
! trimmed to the first and last two requests
CustA-HQ#ping 239.10.10.20 source lo0 repeat 20
Type escape sequence to abort.
Sending 20, 100-byte ICMP Echos to 239.10.10.20, timeout is 2 seconds:
Packet sent with a source address of 10.10.0.1
Reply to request 0 from 10.10.0.2, 27 ms
Reply to request 0 from 10.10.0.2, 27 ms
Reply to request 1 from 10.10.0.2, 3 ms
Reply to request 1 from 10.10.0.2, 3 ms
Reply to request 18 from 10.10.0.2, 5 ms
Reply to request 18 from 10.10.0.2, 5 ms
Reply to request 19 from 10.10.0.2, 7 ms
Reply to request 19 from 10.10.0.2, 7 msThe flow to 239.10.10.20 with the data MDT and after its removal:
A-PE1’s final VRF configuration has no data MDT, and its mLDP database lists only the two MP2MP trees:
! trimmed to the VRF definition
A-PE1#show running-config vrf CustA
vrf definition CustA
rd 10.1.0.5:10
vpn id 64501:10
!
address-family ipv4
mdt auto-discovery mldp
mdt default mpls mldp 10.1.0.1
mdt default mpls mldp 10.1.0.3
mdt overlay use-bgp
route-target export 64501:10
route-target import 64501:10
exit-address-familyA-PE1#show mpls mldp database summary
LSM ID Type Root Decoded Opaque Value Client Cnt.
1 MP2MP 10.1.0.1 [mdt 64501:10 0] 1
3 MP2MP 10.1.0.3 [mdt 64501:10 0] 1What’s Next
The next post adds BGP labelled unicast on both providers.
Leave a Reply