In this post we will take a look at the next MVPN Profile, Profile 7 which leverages the global table for forwarding. The configuration from Profile 6 can be used just remove the VRF configuration piece. I could have made a bunch of changes to the existing VPNv4 configuration, I chose to create a few new interfaces and keep them in the global table. There will be a lot of config snippets, which will help you understand the configuration. We'll take a look at the interface configs first, then the BGP configs then the multicast configs.
R1
interface GigabitEthernet1.2701
encapsulation dot1Q 2701
ip address 100.64.151.1 255.255.255.0
ip pim sparse-mode
ip igmp version 3
!
interface Loopback0
ip address 192.0.2.1 255.255.255.255
ip pim sparse-mode
R15
interface GigabitEthernet1.2701
encapsulation dot1Q 2701
ip address 100.64.151.15 255.255.255.0
ip pim sparse-mode
ip igmp version 3
R3
interface GigabitEthernet1.2711
encapsulation dot1Q 2711
ip address 100.64.173.3 255.255.255.0
ip pim sparse-mode
ip igmp version 3
!
interface Loopback0
ip address 192.0.2.3 255.255.255.255
ip pim sparse-mode
R17
interface GigabitEthernet1.2711
encapsulation dot1Q 2711
ip address 100.64.173.17 255.255.255.0
ip pim sparse-mode
ip igmp version 3
XR1
interface GigabitEthernet0/0/0/0.2704
ipv4 address 100.64.161.11 255.255.255.0
encapsulation dot1q 2704
!
router pim
address-family ipv4
interface GigabitEthernet0/0/0/0.2704
interface Loopback0
R16
interface GigabitEthernet1.2704
encapsulation dot1Q 2704
ip address 100.64.161.16 255.255.255.0
ip pim sparse-mode
ip igmp version 3
With the interface configuration complete, we can begin the BGP part.
R1
router bgp 1.50693
address-family ipv4
network 100.64.151.0 mask 255.255.255.0
neighbor 192.0.2.22 activate
R3
router bgp 1.50693
address-family ipv4
network 100.64.173.0 mask 255.255.255.0
neighbor 192.0.2.22 activate
XR1
router bgp 1.50693
address-family ipv4 unicast
network 100.64.161.0/24
neighbor 192.0.2.22
address-family ipv4 unicast
XR2
router bgp 1.50693
address-family ipv4 unicast
!
!
neighbor 192.0.2.1
address-family ipv4 unicast
route-reflector-client
!
!
neighbor 192.0.2.3
address-family ipv4 unicast
route-reflector-client
!
!
neighbor 192.0.2.21
address-family ipv4 unicast
route-reflector-client
Now we will take a look at the multicast configuration on IOS and XR.
R1 and R3
ip multicast mpls mldp
ip pim mpls source Loopback0
XR1
route-policy RPL_IN_BAND_GLOBAL
set core-tree mldp-inband
end-policy
!
router pim
address-family ipv4
rpf topology route-policy RPL_IN_BAND_GLOBAL
!
multicast-routing
address-family ipv4
mdt source Loopback0
interface all enable
mdt mldp in-band-signaling ipv4
With the configuration in place, and some testing done, I realized that configuring an IOS router behind and IOS PE as an SSM source didn't work, I didn't see any signaling happen. However I did set an IOS router behind an XR PE the SSM signaling did work.
R17
interface GigabitEthernet1.2711
ip igmp join-group 232.17.17.17 source 100.64.161.16
Next we configure R17 to join an SSM group with R16 as the source.
R3#sh mpls mldp database
* Indicates MLDP recursive forwarding is enabled
LSM ID : B Type: P2MP Uptime : 00:22:55
FEC Root : 192.0.2.21
Opaque decoded : [ipv4 100.64.161.16 232.17.17.17]
Opaque length : 8 bytes
Opaque value : 03 0008 6440A110E8111111
Upstream client(s) :
192.0.2.2:0 [Active]
Expires : Never Path Set ID : B
Out Label (U) : None Interface : GigabitEthernet1.23*
Local Label (D): 3024 Next Hop : 100.64.23.2
Replication client(s):
MRIBv4(0)
Uptime : 00:22:55 Path Set ID : None
Interface : Lspvif6
Checking R3, which is the last hop router, we see an MLDP binding with the root set as XR1 with a local label of 3024.
R3#sh mpls forwarding-table labels 3024
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
3024 [T] No Label [ipv4 100.64.161.16 232.17.17.17] \
244 aggregate
Checking the LFIB, we see local label 3024. I did a test ping to verify the data plane was working, which is why the bytes switched counter incremented.
R3
%MLDP-5-ADD_BRANCH: [ipv4 100.64.161.16 232.17.17.17] Root: 192.0.2.21, Add P2MP branch MRIBv4(0) remote label
R2
%MLDP-5-ADD_BRANCH: [ipv4 100.64.161.16 232.17.17.17] Root: 192.0.2.21, Add P2MP branch 192.0.2.3:0 remote label 3024
R5
%MLDP-5-ADD_BRANCH: [ipv4 100.64.161.16 232.17.17.17] Root: 192.0.2.21, Add P2MP branch 192.0.2.2:0 remote label 2019
XR2
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x0001A [ipv4 100.64.161.16 232.17.17.17] P2MP 192.0.2.21, Add LDP 192.0.2.5:0 branch remote label 5027
XR1
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00038 [ipv4 100.64.161.16 232.17.17.17] P2MP 192.0.2.21, Add LDP 192.0.2.22:0 branch remote label 92024
The above outputs show each hop on the IGP path back to the root which is XR1 and the label values that were allocated for this traffic.
R15
interface GigabitEthernet1.2701
ip igmp join-group 232.15.15.1 source 100.64.161.16
R1#show mpls mldp database
* Indicates MLDP recursive forwarding is enabled
LSM ID : 3A Type: P2MP Uptime : 00:06:25
FEC Root : 192.0.2.21
Opaque decoded : [ipv4 100.64.161.16 232.15.15.1]
Opaque length : 8 bytes
Opaque value : 03 0008 6440A110E80F0F01
Upstream client(s) :
192.0.2.4:0 [Active]
Expires : Never Path Set ID : 3F
Out Label (U) : None Interface : GigabitEthernet1.14*
Local Label (D): 1026 Next Hop : 100.64.14.4
Replication client(s):
MRIBv4(0)
Uptime : 00:06:25 Path Set ID : None
Interface : Lspvif5
R1#sh mpls forwarding-table labels 1026
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
1026 [T] No Label [ipv4 100.64.161.16 232.15.15.1] \
244 aggregate
R1
%MLDP-5-ADD_BRANCH: [ipv4 100.64.161.16 232.15.15.1] Root: 192.0.2.21, Add P2MP branch MRIBv4(0) remote label
R4
%MLDP-5-ADD_BRANCH: [ipv4 100.64.161.16 232.15.15.1] Root: 192.0.2.21, Add P2MP branch 192.0.2.1:0 remote label 1026
XR1
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00039 [ipv4 100.64.161.16 232.15.15.1] P2MP 192.0.2.21, Add Local branch remote label no_label
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00039 [ipv4 100.64.161.16 232.15.15.1] P2MP 192.0.2.21, Add LDP 192.0.2.4:0 branch remote label 4028
We do the same things on for R15 and R1 and all the routers on the IGP path to the root.
R16#ping 232.17.17.17 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 232.17.17.17, timeout is 2 seconds:
Reply to request 0 from 100.64.173.17, 25 ms
Reply to request 1 from 100.64.173.17, 14 ms
R3#sh mpls forwarding-table labels 3024
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
3024 [T] No Label [ipv4 100.64.161.16 232.17.17.17] \
488 aggregate
R16#ping 232.15.15.1 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 232.15.15.1, timeout is 2 seconds:
Reply to request 0 from 100.64.151.15, 8 ms
Reply to request 1 from 100.64.151.15, 6 ms
R1#sh mpls forwarding-table labels 1026
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
1026 [T] No Label [ipv4 100.64.161.16 232.15.15.1] \
366 aggregate
After pinging the SSM groups again, we see the packets switched counter incremented again.
Thanks for stopping by!
Rob Riker, CCIE #50693
Sunday, December 30, 2018
CCIE SPv4 MPLS Multicast VPN - Profile 7 Global MLDP In-band Signaling
Labels:
data,
global,
in band signaling,
l3vpn,
LDP,
MDT,
mLDP,
MPLS,
multicast,
multipoint LDP,
mVPN,
partitioned,
PIM,
Profile 7,
Service Provider,
sp
CCIE SPv4 MPLS Multicast VPN - Profile 6 VRF MLDP - In-band Signaling
In this post we will take a look at a different variation than our previous posts. We will leverage an in-band signaling variation versus the out-of-band signaling, overlay signaling with PIM and BGP. In band signaling treats multicast traffic just like unicast traffic and populates the LFIB with SSM Groups. This profile only supports SSM traffic, no discovery method exists to learn dynamic multicast sources.
R1, R3 and R7
ip multicast vrf MVPN mpls mldp
ip pim vrf MVPN mpls source Loopback0
XR1, XR5 and XR6
route-policy RPL_IN_BAND
set core-tree mldp-inband
end-policy
!
router pim
vrf CORE
address-family ipv4
rpf topology route-policy RPL_IN_BAND
!
multicast-routing
address-family ipv4
mdt source Loopback0
interface all enable
!
vrf CORE
address-family ipv4
mdt mldp in-band-signaling ipv4
The configuration is in place we can begin the verification.
R1#sh bgp ipv4 mvpn all
RP/0/0/CPU0:XR1#sh bgp ipv4 mvpn
Sun Dec 30 01:07:37.269 UTC
R1#sh ip pim vrf MVPN neighbor
PIM Neighbor Table
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
100.64.201.15 GigabitEthernet1.201 3d12h/00:01:22 v2 1 / DR S P G
RP/0/0/CPU0:XR1#sh pim vrf CORE neighbor
Sun Dec 30 01:07:53.778 UTC
Neighbor Address Interface Uptime Expires DR pri Flags
100.64.204.11* GigabitEthernet0/0/0/0.204 1w3d 00:01:24 1 B E
100.64.204.16 GigabitEthernet0/0/0/0.204 1w3d 00:01:29 1 (DR) P
192.0.2.21* GImdtCORE 01:36:41 now 1 (DR) E
192.0.2.21* ImdtCORE 01:36:41 now 1 (DR) E
We also see that only CE PIM neighbors are formed.
Since the signaling is in-band, whenever a customer router signals interest to receive traffic from an SSM group, this triggers a label mapping message back to the root, the PE connected to the source.
R20
interface Loopback0
ip igmp join-group 232.20.20.21 source 192.0.2.15
ip igmp join-group 232.20.20.20 source 192.0.2.16
XR5
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x0001B [vpnv4 100:100 192.0.2.16 232.20.20.20] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x0001C [vpnv4 100:100 192.0.2.15 232.20.20.21] P2MP 192.0.2.1, Add PIM MDT branch remote label no_label
R1
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.16 232.20.20.20 100:100] Root: 192.0.2.21, Add P2MP branch 192.0.2.25:0 remote label 24026
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.20.20.21 100:100] Root: 192.0.2.1, Add P2MP branch 192.0.2.25:0 remote label 24022
R4
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.16 232.20.20.20 100:100] Root: 192.0.2.21, Add P2MP branch 192.0.2.1:0 remote label 1031
XR1
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00035 [vpnv4 100:100 192.0.2.16 232.20.20.20] P2MP 192.0.2.21, Add LDP 192.0.2.4:0 branch remote label 4031
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00035 [vpnv4 100:100 192.0.2.16 232.20.20.20] P2MP 192.0.2.21, Add Local branch remote label no_label
We see that after R20 signal interest in a couple SSM groups, we see end to end signaling from XR5 to XR1.
R18
interface Loopback0
ip igmp join-group 232.18.18.2 source 192.0.2.15
R7
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.18.18.2 100:100] Root: 192.0.2.1, Add P2MP branch MRIBv4(1) remote label
R6
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.18.18.2 100:100] Root: 192.0.2.1, Add P2MP branch 192.0.2.7:0 remote label 7026
R5
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.18.18.2 100:100] Root: 192.0.2.1, Add P2MP branch 192.0.2.6:0 remote label 6023
R4
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.18.18.2 100:100] Root: 192.0.2.1, Add P2MP branch 192.0.2.5:0 remote label 5024
R1
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.18.18.2 100:100] Root: 192.0.2.1, Add P2MP branch 192.0.2.4:0 remote label 4026
The same thing applies for the R18 signaled group, end to end signaling.
R16#sh ip mroute
(192.0.2.16, 232.20.20.20), 00:17:03/00:02:41, flags: sT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet1.204, Forward/Sparse, 00:12:50/00:02:41
Checking R16, we see the (S, G) entry proving that end to end signaling was successful.
R16#ping 232.20.20.20 source lo0 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 232.20.20.20, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.16
Reply to request 0 from 192.0.2.20, 13 ms
Reply to request 0 from 192.0.2.20, 14 ms
Reply to request 1 from 192.0.2.20, 9 ms
Reply to request 1 from 192.0.2.20, 9 ms
From the source, we ping the group from the loopback and get replies back in.
R15#sh ip mroute
(192.0.2.15, 232.18.18.2), 00:00:04/00:03:25, flags: sT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet1.201, Forward/Sparse, 00:00:04/00:03:25
R1, R3 and R7
ip multicast vrf MVPN mpls mldp
ip pim vrf MVPN mpls source Loopback0
XR1, XR5 and XR6
route-policy RPL_IN_BAND
set core-tree mldp-inband
end-policy
!
router pim
vrf CORE
address-family ipv4
rpf topology route-policy RPL_IN_BAND
!
multicast-routing
address-family ipv4
mdt source Loopback0
interface all enable
!
vrf CORE
address-family ipv4
mdt mldp in-band-signaling ipv4
The configuration is in place we can begin the verification.
R1#sh bgp ipv4 mvpn all
RP/0/0/CPU0:XR1#sh bgp ipv4 mvpn
Sun Dec 30 01:07:37.269 UTC
We can see that no BGP MVPN neighbors or routes are learned, proving there is no customer routes signaled via BGP.
R1#sh ip pim vrf MVPN neighbor
PIM Neighbor Table
Neighbor Interface Uptime/Expires Ver DR
Address Prio/Mode
100.64.201.15 GigabitEthernet1.201 3d12h/00:01:22 v2 1 / DR S P G
RP/0/0/CPU0:XR1#sh pim vrf CORE neighbor
Sun Dec 30 01:07:53.778 UTC
Neighbor Address Interface Uptime Expires DR pri Flags
100.64.204.11* GigabitEthernet0/0/0/0.204 1w3d 00:01:24 1 B E
100.64.204.16 GigabitEthernet0/0/0/0.204 1w3d 00:01:29 1 (DR) P
192.0.2.21* GImdtCORE 01:36:41 now 1 (DR) E
192.0.2.21* ImdtCORE 01:36:41 now 1 (DR) E
We also see that only CE PIM neighbors are formed.
Since the signaling is in-band, whenever a customer router signals interest to receive traffic from an SSM group, this triggers a label mapping message back to the root, the PE connected to the source.
R20
interface Loopback0
ip igmp join-group 232.20.20.21 source 192.0.2.15
ip igmp join-group 232.20.20.20 source 192.0.2.16
XR5
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x0001B [vpnv4 100:100 192.0.2.16 232.20.20.20] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x0001C [vpnv4 100:100 192.0.2.15 232.20.20.21] P2MP 192.0.2.1, Add PIM MDT branch remote label no_label
R1
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.16 232.20.20.20 100:100] Root: 192.0.2.21, Add P2MP branch 192.0.2.25:0 remote label 24026
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.20.20.21 100:100] Root: 192.0.2.1, Add P2MP branch 192.0.2.25:0 remote label 24022
R4
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.16 232.20.20.20 100:100] Root: 192.0.2.21, Add P2MP branch 192.0.2.1:0 remote label 1031
XR1
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00035 [vpnv4 100:100 192.0.2.16 232.20.20.20] P2MP 192.0.2.21, Add LDP 192.0.2.4:0 branch remote label 4031
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00035 [vpnv4 100:100 192.0.2.16 232.20.20.20] P2MP 192.0.2.21, Add Local branch remote label no_label
We see that after R20 signal interest in a couple SSM groups, we see end to end signaling from XR5 to XR1.
R18
interface Loopback0
ip igmp join-group 232.18.18.2 source 192.0.2.15
R7
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.18.18.2 100:100] Root: 192.0.2.1, Add P2MP branch MRIBv4(1) remote label
R6
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.18.18.2 100:100] Root: 192.0.2.1, Add P2MP branch 192.0.2.7:0 remote label 7026
R5
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.18.18.2 100:100] Root: 192.0.2.1, Add P2MP branch 192.0.2.6:0 remote label 6023
R4
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.18.18.2 100:100] Root: 192.0.2.1, Add P2MP branch 192.0.2.5:0 remote label 5024
R1
%MLDP-5-ADD_BRANCH: [vpnv4 192.0.2.15 232.18.18.2 100:100] Root: 192.0.2.1, Add P2MP branch 192.0.2.4:0 remote label 4026
The same thing applies for the R18 signaled group, end to end signaling.
R16#sh ip mroute
(192.0.2.16, 232.20.20.20), 00:17:03/00:02:41, flags: sT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet1.204, Forward/Sparse, 00:12:50/00:02:41
Checking R16, we see the (S, G) entry proving that end to end signaling was successful.
R16#ping 232.20.20.20 source lo0 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 232.20.20.20, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.16
Reply to request 0 from 192.0.2.20, 13 ms
Reply to request 0 from 192.0.2.20, 14 ms
Reply to request 1 from 192.0.2.20, 9 ms
Reply to request 1 from 192.0.2.20, 9 ms
From the source, we ping the group from the loopback and get replies back in.
R15#sh ip mroute
(192.0.2.15, 232.18.18.2), 00:00:04/00:03:25, flags: sT
Incoming interface: Loopback0, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet1.201, Forward/Sparse, 00:00:04/00:03:25
On R15 we see the MRIB with the signaled group interest.
R15#ping 232.18.18.2 source lo0 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 232.18.18.2, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.15
Reply to request 0 from 192.0.2.18, 11 ms
Reply to request 0 from 192.0.2.18, 11 ms
Reply to request 1 from 192.0.2.18, 8 ms
Reply to request 1 from 192.0.2.18, 8 ms
Pings to the group address sourced from the loopback.
R7#sh mpls forwarding-table labels 7026
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
7026 [T] No Label [vpnv4 192.0.2.15 232.18.18.2 100:100][V] \
488 aggregate/MVPN
Unfortunately, there isn't a way to verify IOS XRv multicast forwarding, the ping replies is are ok, the upstream routers, like R1 for XR5 have an entry for the signaled 232.20.20.20 group.
R1#show mpls forwarding-table labels 1031
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
1031 24026 [vpnv4 192.0.2.16 232.20.20.20 100:100] \
2928 Gi1.15 100.64.15.15
R16#ping 232.20.20.20 source lo0 repeat 5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 232.20.20.20, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.16
Reply to request 0 from 192.0.2.20, 11 ms
Reply to request 0 from 192.0.2.20, 11 ms
Reply to request 1 from 192.0.2.20, 8 ms
Reply to request 1 from 192.0.2.20, 8 ms
Reply to request 2 from 192.0.2.20, 7 ms
Reply to request 2 from 192.0.2.20, 7 ms
Reply to request 3 from 192.0.2.20, 10 ms
Reply to request 3 from 192.0.2.20, 10 ms
Reply to request 4 from 192.0.2.20, 10 ms
Reply to request 4 from 192.0.2.20, 10 ms
R1#show mpls forwarding-table labels 1031
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
1031 24026 [vpnv4 192.0.2.16 232.20.20.20 100:100] \
4148 Gi1.15 100.64.15.15
We can see that the counter incremented, proving that traffic to the source was sent.
Thanks for stopping by!
Rob Riker, CCIE #50693
Labels:
data,
in band signaling,
l3vpn,
LDP,
MDT,
mLDP,
MPLS,
multicast,
multipoint LDP,
mVPN,
partitioned,
PIM,
Profile 6,
Service Provider,
sp,
VRF
Friday, December 28, 2018
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
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
Labels:
BGP,
BGP Auto Discovery,
data,
Default,
l3vpn,
LDP,
MDT,
mLDP,
MPLS,
multicast,
multipoint LDP,
mVPN,
partitioned,
PIM,
Profile 14,
Service Provider,
sp,
VRF
Wednesday, December 26, 2018
CCIE SPv4 MPLS Multicast VPN - Profile 5 Partitioned MDT - MLDP P2MP - BGP-AD - PIM C-mcast Signaling
In this post we'll take a look at the next MVPN profile, Profile 5. This profile is the first of Partitioned MDTs where we focus on just P2MP MDTs. MP2MP MDTs can still be formed, but this profile allows for only on demand multicast signaling when we're done. We still have the MPLS MLDP logging enabled, so when new SSM groups are signaled, there will be logging messages generated.
XR1, XR5 and XR6
route-policy RPL_MLDP_PART_P2MP
set core-tree mldp-partitioned-p2mp
end-policy
!
multicast-routing
vrf CORE
address-family ipv4
no mdt partitioned mldp ipv4 mp2mp
mdt partitioned mldp ipv4 p2mp
!
!
!
router pim
vrf CORE
address-family ipv4
rpf topology route-policy RPL_MLDP_PART_P2MP
no mdt c-multicast-routing
Now that the configuration is in place, let's verify the PE routers and then configure CEs to signal new group joins to trigger label mapping messages.
RP/0/0/CPU0:XR1#sh bgp ipv4 mvpn | b Network
Wed Dec 26 23:50:51.261 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf CORE)
*>i[1][192.0.2.3]/40 192.0.2.3 0 100 0 ?
*>i[1][192.0.2.7]/40 192.0.2.7 0 100 0 ?
*> [1][192.0.2.21]/40 0.0.0.0 0 i
*>i[1][192.0.2.25]/40 192.0.2.25 100 0 i
*>i[1][192.0.2.26]/40 192.0.2.26 100 0 i
*> [3][0][0.0.0.0][0][0.0.0.0][192.0.2.21]/120
0.0.0.0 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.25]/120
192.0.2.25 100 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.26]/120
192.0.2.26 100 0 i
*>i[3][0][0.0.0.0][32][224.0.0.13][192.0.2.25]/120
192.0.2.25 100 0 i
*> [3][32][192.0.2.16][32][232.1.1.1][192.0.2.21]/120
0.0.0.0 0 i
*> [3][32][192.0.2.16][32][232.16.16.16][192.0.2.21]/120
0.0.0.0 0 i
*> [3][32][192.0.2.16][32][232.19.19.19][192.0.2.21]/120
0.0.0.0 0 i
*> [3][32][192.0.2.16][32][232.20.20.20][192.0.2.21]/120
0.0.0.0 0 i
*>i[7][100:100][116229][32][192.0.2.16][32][232.16.16.16]/184
192.0.2.7 0 100 0 ?
RP/0/0/CPU0:XR1#sh pim vrf CORE neighbor
Wed Dec 26 23:50:38.932 UTC
PIM neighbors in VRF CORE
Flag: B - Bidir capable, P - Proxy capable, DR - Designated Router,
E - ECMP Redirect capable
* indicates the neighbor created for this router
Neighbor Address Interface Uptime Expires DR pri Flags
100.64.204.11* GigabitEthernet0/0/0/0.204 6d23h 00:01:32 1 B E
100.64.204.16 GigabitEthernet0/0/0/0.204 6d23h 00:01:31 1 (DR) P
192.0.2.21* LmdtCORE 07:19:31 00:01:39 1
192.0.2.25 LmdtCORE 06:43:10 00:01:20 1 (DR)
RP/0/0/CPU0:XR1#show mpls mldp database | in "P2MP|Label|FEC Root"
Wed Dec 26 23:50:23.663 UTC
LSM-ID: 0x0001C Type: P2MP Uptime: 00:35:40
FEC Root : 192.0.2.21 (we are the root)
Local Label : 91018 (internal)
LSM-ID: 0x0001E Type: P2MP Uptime: 00:35:23
FEC Root : 192.0.2.21 (we are the root)
Local Label : 91020 (internal)
LSM-ID: 0x0001D Type: P2MP Uptime: 00:35:24
FEC Root : 192.0.2.25
Local Label (D) : 91019
LSM-ID: 0x0000D Type: P2MP Uptime: 06:45:14
FEC Root : 192.0.2.21 (we are the root)
Local Label : 91015 (internal)
LSM-ID: 0x0000E Type: P2MP Uptime: 00:35:40
FEC Root : 192.0.2.25
Local Label (D) : 91016
LSM-ID: 0x0001F Type: P2MP Uptime: 00:35:09
FEC Root : 192.0.2.21 (we are the root)
Local Label : 91025 (internal)
LSM-ID: 0x00022 Type: P2MP Uptime: 00:28:47
FEC Root : 192.0.2.21 (we are the root)
Local Label : 91023 (internal)
RP/0/0/CPU0:XR1#show mpls forwarding labels 91014 91025
Wed Dec 26 23:52:11.826 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
91014 24022 MLDP: 0x80002 UNKNOWN intf 0xa12db890 192.0.2.26 0
91015 92014 MLDP: 0x0000d Gi0/0/0/0.112 100.64.112.120 0
91016 Unlabelled MLDP: 0x0000e
91018 92025 MLDP: 0x0001c Gi0/0/0/0.112 100.64.112.120 0
4023 MLDP: 0x0001c Gi0/0/0/0.114 100.64.114.4 0
91019 Unlabelled MLDP: 0x0001d
91020 4028 MLDP: 0x0001e Gi0/0/0/0.114 100.64.114.4 0
91023 4031 MLDP: 0x00022 Gi0/0/0/0.114 100.64.114.4 0
91025 4029 MLDP: 0x0001f Gi0/0/0/0.114 100.64.114.4 0
RP/0/0/CPU0:XR5# sh pim vrf CORE neighbor
Wed Dec 26 23:53:37.337 UTC
PIM neighbors in VRF CORE
Flag: B - Bidir capable, P - Proxy capable, DR - Designated Router,
E - ECMP Redirect capable
* indicates the neighbor created for this router
Neighbor Address Interface Uptime Expires DR pri Flags
100.64.206.15* GigabitEthernet0/0/0/0.206 07:04:03 00:01:38 1 B E
100.64.206.20 GigabitEthernet0/0/0/0.206 07:03:57 00:01:35 1 (DR) P
192.0.2.21 LmdtCORE 06:43:23 00:01:41 1
192.0.2.25* LmdtCORE 06:54:22 00:01:22 1 (DR)
RP/0/0/CPU0:XR5# sh bgp ipv4 mvpn | b Network
Wed Dec 26 23:53:37.517 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf CORE)
*>i[1][192.0.2.3]/40 192.0.2.3 0 100 0 ?
*>i[1][192.0.2.7]/40 192.0.2.7 0 100 0 ?
*>i[1][192.0.2.21]/40 192.0.2.21 100 0 i
*> [1][192.0.2.25]/40 0.0.0.0 0 i
*>i[1][192.0.2.26]/40 192.0.2.26 100 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.21]/120
192.0.2.21 100 0 i
*> [3][0][0.0.0.0][0][0.0.0.0][192.0.2.25]/120
0.0.0.0 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.26]/120
192.0.2.26 100 0 i
*> [3][0][0.0.0.0][32][224.0.0.13][192.0.2.25]/120
0.0.0.0 0 i
*>i[3][32][192.0.2.16][32][232.1.1.1][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.16.16.16][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.19.19.19][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.20.20.20][192.0.2.21]/120
192.0.2.21 100 0 i
RP/0/0/CPU0:XR5#show mpls mldp database | in "P2MP|Label|FEC Root"
Wed Dec 26 23:53:37.247 UTC
LSM-ID: 0x00010 Type: P2MP Uptime: 00:38:37
FEC Root : 192.0.2.21
Local Label (D) : 24026
LSM-ID: 0x00012 Type: P2MP Uptime: 00:38:37
FEC Root : 192.0.2.21
Local Label (D) : 24030
LSM-ID: 0x00011 Type: P2MP Uptime: 00:38:37
FEC Root : 192.0.2.25 (we are the root)
Local Label : 24029 (internal)
LSM-ID: 0x00003 Type: P2MP Uptime: 06:48:26
FEC Root : 192.0.2.25 (we are the root)
Local Label : 24027 (internal)
RP/0/0/CPU0:XR5# show mpls forwarding labels 24026 24030
Wed Dec 26 23:54:48.742 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24026 Unlabelled MLDP: 0x00010
24027 1024 MLDP: 0x00003 Gi0/0/0/0.15 100.64.15.1 0
24029 1030 MLDP: 0x00011 Gi0/0/0/0.15 100.64.15.1 0
24030 Unlabelled MLDP: 0x00012
RP/0/0/CPU0:XR6# sh bgp ipv4 mvpn | b Network
Wed Dec 26 23:55:52.536 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf CORE)
*>i[1][192.0.2.3]/40 192.0.2.3 0 100 0 ?
*>i[1][192.0.2.7]/40 192.0.2.7 0 100 0 ?
*>i[1][192.0.2.21]/40 192.0.2.21 100 0 i
*>i[1][192.0.2.25]/40 192.0.2.25 100 0 i
*> [1][192.0.2.26]/40 0.0.0.0 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.25]/120
192.0.2.25 100 0 i
*> [3][0][0.0.0.0][0][0.0.0.0][192.0.2.26]/120
0.0.0.0 0 i
*>i[3][0][0.0.0.0][32][224.0.0.13][192.0.2.25]/120
192.0.2.25 100 0 i
*>i[3][32][192.0.2.16][32][232.1.1.1][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.16.16.16][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.19.19.19][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.20.20.20][192.0.2.21]/120
192.0.2.21 100 0 i
RP/0/0/CPU0:XR6# sh pim vrf CORE neighbor
Wed Dec 26 23:55:52.296 UTC
PIM neighbors in VRF CORE
Flag: B - Bidir capable, P - Proxy capable, DR - Designated Router,
E - ECMP Redirect capable
* indicates the neighbor created for this router
Neighbor Address Interface Uptime Expires DR pri Flags
100.64.215.16* GigabitEthernet0/0/0/0.215 07:36:31 00:01:22 1 B E
100.64.215.19 GigabitEthernet0/0/0/0.215 07:30:25 00:01:35 1 (DR) P
192.0.2.21 LmdtCORE 06:45:38 00:01:26 1
192.0.2.25 LmdtCORE 06:49:37 00:01:38 1
192.0.2.26* LmdtCORE 07:22:30 00:01:33 1 (DR)
RP/0/0/CPU0:XR6# show mpls mldp database | in "P2MP|Label|FEC Root"
Wed Dec 26 23:55:52.146 UTC
LSM-ID: 0x00010 Type: P2MP Uptime: 00:40:38
FEC Root : 192.0.2.21
Local Label (D) : 24026
LSM-ID: 0x00011 Type: P2MP Uptime: 00:40:38
FEC Root : 192.0.2.25
Local Label (D) : 24029
LSM-ID: 0x00012 Type: P2MP Uptime: 00:40:38
FEC Root : 192.0.2.26 (we are the root)
Local Label : 24033 (internal)
LSM-ID: 0x00003 Type: P2MP Uptime: 00:40:38
FEC Root : 192.0.2.25
Local Label (D) : 24023
LSM-ID: 0x00013 Type: P2MP Uptime: 00:40:38
FEC Root : 192.0.2.21
Local Label (D) : 24034
LSM-ID: 0x00016 Type: P2MP Uptime: 00:34:16
FEC Root : 192.0.2.21
Local Label (D) : 24027
RP/0/0/CPU0:XR6# show mpls forwarding labels 24023 24034
Wed Dec 26 23:57:29.170 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24023 Unlabelled MLDP: 0x00003
24024 Pop 192.0.2.3/32 Gi0/0/0/0.63 100.64.63.3 52793
24025 Unlabelled 192.0.2.19/32[V] Gi0/0/0/0.215 100.64.215.19 1600
24026 Unlabelled MLDP: 0x00010
24027 Unlabelled MLDP: 0x00016
24029 Unlabelled MLDP: 0x00011
24033 Unlabelled MLDP: 0x00012
24034 Unlabelled MLDP: 0x00013
Now that we have verified the PE routers, we can configure new group joins on the CEs to see new labels for the new group joins.
R19
interface Loopback0
ip igmp join-group 232.1.1.2 source 192.0.2.16
XR6
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00017 [global-id 10] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label
XR1
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00023 [global-id 10] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00023 [global-id 10] P2MP 192.0.2.21, Add LDP 192.0.2.4:0 branch remote label 4024
R20
interface Loopback0
ip igmp join-group 232.1.1.20 source 192.0.2.16
XR5
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00015 [global-id 11] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label
XR1
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00024 [global-id 11] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00024 [global-id 11] P2MP 192.0.2.21, Add LDP 192.0.2.4:0 branch remote label 4025
R16#ping 232.1.1.2 source lo0 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 232.1.1.2, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.16
Reply to request 0 from 192.0.2.19, 16 ms
Reply to request 0 from 192.0.2.19, 17 ms
Reply to request 1 from 192.0.2.19, 11 ms
Reply to request 1 from 192.0.2.19, 13 ms
R16#ping 232.1.1.20 source lo0 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 232.1.1.20, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.16
Reply to request 0 from 192.0.2.20, 12 ms
Reply to request 0 from 192.0.2.20, 12 ms
Reply to request 1 from 192.0.2.20, 9 ms
Reply to request 1 from 192.0.2.20, 9 ms
After signaling the new groups, the new label bindings are triggered, then the groups are pinged from the source and ping replies are received.
Thanks for stopping by!
Rob Riker, CCIE #50693
XR1, XR5 and XR6
route-policy RPL_MLDP_PART_P2MP
set core-tree mldp-partitioned-p2mp
end-policy
!
multicast-routing
vrf CORE
address-family ipv4
no mdt partitioned mldp ipv4 mp2mp
mdt partitioned mldp ipv4 p2mp
!
!
!
router pim
vrf CORE
address-family ipv4
rpf topology route-policy RPL_MLDP_PART_P2MP
no mdt c-multicast-routing
Now that the configuration is in place, let's verify the PE routers and then configure CEs to signal new group joins to trigger label mapping messages.
RP/0/0/CPU0:XR1#sh bgp ipv4 mvpn | b Network
Wed Dec 26 23:50:51.261 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf CORE)
*>i[1][192.0.2.3]/40 192.0.2.3 0 100 0 ?
*>i[1][192.0.2.7]/40 192.0.2.7 0 100 0 ?
*> [1][192.0.2.21]/40 0.0.0.0 0 i
*>i[1][192.0.2.25]/40 192.0.2.25 100 0 i
*>i[1][192.0.2.26]/40 192.0.2.26 100 0 i
*> [3][0][0.0.0.0][0][0.0.0.0][192.0.2.21]/120
0.0.0.0 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.25]/120
192.0.2.25 100 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.26]/120
192.0.2.26 100 0 i
*>i[3][0][0.0.0.0][32][224.0.0.13][192.0.2.25]/120
192.0.2.25 100 0 i
*> [3][32][192.0.2.16][32][232.1.1.1][192.0.2.21]/120
0.0.0.0 0 i
*> [3][32][192.0.2.16][32][232.16.16.16][192.0.2.21]/120
0.0.0.0 0 i
*> [3][32][192.0.2.16][32][232.19.19.19][192.0.2.21]/120
0.0.0.0 0 i
*> [3][32][192.0.2.16][32][232.20.20.20][192.0.2.21]/120
0.0.0.0 0 i
*>i[7][100:100][116229][32][192.0.2.16][32][232.16.16.16]/184
192.0.2.7 0 100 0 ?
RP/0/0/CPU0:XR1#sh pim vrf CORE neighbor
Wed Dec 26 23:50:38.932 UTC
PIM neighbors in VRF CORE
Flag: B - Bidir capable, P - Proxy capable, DR - Designated Router,
E - ECMP Redirect capable
* indicates the neighbor created for this router
Neighbor Address Interface Uptime Expires DR pri Flags
100.64.204.11* GigabitEthernet0/0/0/0.204 6d23h 00:01:32 1 B E
100.64.204.16 GigabitEthernet0/0/0/0.204 6d23h 00:01:31 1 (DR) P
192.0.2.21* LmdtCORE 07:19:31 00:01:39 1
192.0.2.25 LmdtCORE 06:43:10 00:01:20 1 (DR)
RP/0/0/CPU0:XR1#show mpls mldp database | in "P2MP|Label|FEC Root"
Wed Dec 26 23:50:23.663 UTC
LSM-ID: 0x0001C Type: P2MP Uptime: 00:35:40
FEC Root : 192.0.2.21 (we are the root)
Local Label : 91018 (internal)
LSM-ID: 0x0001E Type: P2MP Uptime: 00:35:23
FEC Root : 192.0.2.21 (we are the root)
Local Label : 91020 (internal)
LSM-ID: 0x0001D Type: P2MP Uptime: 00:35:24
FEC Root : 192.0.2.25
Local Label (D) : 91019
LSM-ID: 0x0000D Type: P2MP Uptime: 06:45:14
FEC Root : 192.0.2.21 (we are the root)
Local Label : 91015 (internal)
LSM-ID: 0x0000E Type: P2MP Uptime: 00:35:40
FEC Root : 192.0.2.25
Local Label (D) : 91016
LSM-ID: 0x0001F Type: P2MP Uptime: 00:35:09
FEC Root : 192.0.2.21 (we are the root)
Local Label : 91025 (internal)
LSM-ID: 0x00022 Type: P2MP Uptime: 00:28:47
FEC Root : 192.0.2.21 (we are the root)
Local Label : 91023 (internal)
RP/0/0/CPU0:XR1#show mpls forwarding labels 91014 91025
Wed Dec 26 23:52:11.826 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
91014 24022 MLDP: 0x80002 UNKNOWN intf 0xa12db890 192.0.2.26 0
91015 92014 MLDP: 0x0000d Gi0/0/0/0.112 100.64.112.120 0
91016 Unlabelled MLDP: 0x0000e
91018 92025 MLDP: 0x0001c Gi0/0/0/0.112 100.64.112.120 0
4023 MLDP: 0x0001c Gi0/0/0/0.114 100.64.114.4 0
91019 Unlabelled MLDP: 0x0001d
91020 4028 MLDP: 0x0001e Gi0/0/0/0.114 100.64.114.4 0
91023 4031 MLDP: 0x00022 Gi0/0/0/0.114 100.64.114.4 0
91025 4029 MLDP: 0x0001f Gi0/0/0/0.114 100.64.114.4 0
RP/0/0/CPU0:XR5# sh pim vrf CORE neighbor
Wed Dec 26 23:53:37.337 UTC
PIM neighbors in VRF CORE
Flag: B - Bidir capable, P - Proxy capable, DR - Designated Router,
E - ECMP Redirect capable
* indicates the neighbor created for this router
Neighbor Address Interface Uptime Expires DR pri Flags
100.64.206.15* GigabitEthernet0/0/0/0.206 07:04:03 00:01:38 1 B E
100.64.206.20 GigabitEthernet0/0/0/0.206 07:03:57 00:01:35 1 (DR) P
192.0.2.21 LmdtCORE 06:43:23 00:01:41 1
192.0.2.25* LmdtCORE 06:54:22 00:01:22 1 (DR)
RP/0/0/CPU0:XR5# sh bgp ipv4 mvpn | b Network
Wed Dec 26 23:53:37.517 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf CORE)
*>i[1][192.0.2.3]/40 192.0.2.3 0 100 0 ?
*>i[1][192.0.2.7]/40 192.0.2.7 0 100 0 ?
*>i[1][192.0.2.21]/40 192.0.2.21 100 0 i
*> [1][192.0.2.25]/40 0.0.0.0 0 i
*>i[1][192.0.2.26]/40 192.0.2.26 100 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.21]/120
192.0.2.21 100 0 i
*> [3][0][0.0.0.0][0][0.0.0.0][192.0.2.25]/120
0.0.0.0 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.26]/120
192.0.2.26 100 0 i
*> [3][0][0.0.0.0][32][224.0.0.13][192.0.2.25]/120
0.0.0.0 0 i
*>i[3][32][192.0.2.16][32][232.1.1.1][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.16.16.16][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.19.19.19][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.20.20.20][192.0.2.21]/120
192.0.2.21 100 0 i
RP/0/0/CPU0:XR5#show mpls mldp database | in "P2MP|Label|FEC Root"
Wed Dec 26 23:53:37.247 UTC
LSM-ID: 0x00010 Type: P2MP Uptime: 00:38:37
FEC Root : 192.0.2.21
Local Label (D) : 24026
LSM-ID: 0x00012 Type: P2MP Uptime: 00:38:37
FEC Root : 192.0.2.21
Local Label (D) : 24030
LSM-ID: 0x00011 Type: P2MP Uptime: 00:38:37
FEC Root : 192.0.2.25 (we are the root)
Local Label : 24029 (internal)
LSM-ID: 0x00003 Type: P2MP Uptime: 06:48:26
FEC Root : 192.0.2.25 (we are the root)
Local Label : 24027 (internal)
RP/0/0/CPU0:XR5# show mpls forwarding labels 24026 24030
Wed Dec 26 23:54:48.742 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24026 Unlabelled MLDP: 0x00010
24027 1024 MLDP: 0x00003 Gi0/0/0/0.15 100.64.15.1 0
24029 1030 MLDP: 0x00011 Gi0/0/0/0.15 100.64.15.1 0
24030 Unlabelled MLDP: 0x00012
RP/0/0/CPU0:XR6# sh bgp ipv4 mvpn | b Network
Wed Dec 26 23:55:52.536 UTC
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf CORE)
*>i[1][192.0.2.3]/40 192.0.2.3 0 100 0 ?
*>i[1][192.0.2.7]/40 192.0.2.7 0 100 0 ?
*>i[1][192.0.2.21]/40 192.0.2.21 100 0 i
*>i[1][192.0.2.25]/40 192.0.2.25 100 0 i
*> [1][192.0.2.26]/40 0.0.0.0 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][0][0.0.0.0][0][0.0.0.0][192.0.2.25]/120
192.0.2.25 100 0 i
*> [3][0][0.0.0.0][0][0.0.0.0][192.0.2.26]/120
0.0.0.0 0 i
*>i[3][0][0.0.0.0][32][224.0.0.13][192.0.2.25]/120
192.0.2.25 100 0 i
*>i[3][32][192.0.2.16][32][232.1.1.1][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.16.16.16][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.19.19.19][192.0.2.21]/120
192.0.2.21 100 0 i
*>i[3][32][192.0.2.16][32][232.20.20.20][192.0.2.21]/120
192.0.2.21 100 0 i
RP/0/0/CPU0:XR6# sh pim vrf CORE neighbor
Wed Dec 26 23:55:52.296 UTC
PIM neighbors in VRF CORE
Flag: B - Bidir capable, P - Proxy capable, DR - Designated Router,
E - ECMP Redirect capable
* indicates the neighbor created for this router
Neighbor Address Interface Uptime Expires DR pri Flags
100.64.215.16* GigabitEthernet0/0/0/0.215 07:36:31 00:01:22 1 B E
100.64.215.19 GigabitEthernet0/0/0/0.215 07:30:25 00:01:35 1 (DR) P
192.0.2.21 LmdtCORE 06:45:38 00:01:26 1
192.0.2.25 LmdtCORE 06:49:37 00:01:38 1
192.0.2.26* LmdtCORE 07:22:30 00:01:33 1 (DR)
RP/0/0/CPU0:XR6# show mpls mldp database | in "P2MP|Label|FEC Root"
Wed Dec 26 23:55:52.146 UTC
LSM-ID: 0x00010 Type: P2MP Uptime: 00:40:38
FEC Root : 192.0.2.21
Local Label (D) : 24026
LSM-ID: 0x00011 Type: P2MP Uptime: 00:40:38
FEC Root : 192.0.2.25
Local Label (D) : 24029
LSM-ID: 0x00012 Type: P2MP Uptime: 00:40:38
FEC Root : 192.0.2.26 (we are the root)
Local Label : 24033 (internal)
LSM-ID: 0x00003 Type: P2MP Uptime: 00:40:38
FEC Root : 192.0.2.25
Local Label (D) : 24023
LSM-ID: 0x00013 Type: P2MP Uptime: 00:40:38
FEC Root : 192.0.2.21
Local Label (D) : 24034
LSM-ID: 0x00016 Type: P2MP Uptime: 00:34:16
FEC Root : 192.0.2.21
Local Label (D) : 24027
RP/0/0/CPU0:XR6# show mpls forwarding labels 24023 24034
Wed Dec 26 23:57:29.170 UTC
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
24023 Unlabelled MLDP: 0x00003
24024 Pop 192.0.2.3/32 Gi0/0/0/0.63 100.64.63.3 52793
24025 Unlabelled 192.0.2.19/32[V] Gi0/0/0/0.215 100.64.215.19 1600
24026 Unlabelled MLDP: 0x00010
24027 Unlabelled MLDP: 0x00016
24029 Unlabelled MLDP: 0x00011
24033 Unlabelled MLDP: 0x00012
24034 Unlabelled MLDP: 0x00013
Now that we have verified the PE routers, we can configure new group joins on the CEs to see new labels for the new group joins.
R19
interface Loopback0
ip igmp join-group 232.1.1.2 source 192.0.2.16
XR6
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00017 [global-id 10] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label
XR1
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00023 [global-id 10] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00023 [global-id 10] P2MP 192.0.2.21, Add LDP 192.0.2.4:0 branch remote label 4024
R20
interface Loopback0
ip igmp join-group 232.1.1.20 source 192.0.2.16
XR5
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00015 [global-id 11] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label
XR1
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00024 [global-id 11] P2MP 192.0.2.21, Add PIM MDT branch remote label no_label
mpls_ldp[1181]: %ROUTING-MLDP-5-BRANCH_ADD : 0x00024 [global-id 11] P2MP 192.0.2.21, Add LDP 192.0.2.4:0 branch remote label 4025
R16#ping 232.1.1.2 source lo0 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 232.1.1.2, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.16
Reply to request 0 from 192.0.2.19, 16 ms
Reply to request 0 from 192.0.2.19, 17 ms
Reply to request 1 from 192.0.2.19, 11 ms
Reply to request 1 from 192.0.2.19, 13 ms
R16#ping 232.1.1.20 source lo0 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 232.1.1.20, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.16
Reply to request 0 from 192.0.2.20, 12 ms
Reply to request 0 from 192.0.2.20, 12 ms
Reply to request 1 from 192.0.2.20, 9 ms
Reply to request 1 from 192.0.2.20, 9 ms
After signaling the new groups, the new label bindings are triggered, then the groups are pinged from the source and ping replies are received.
Thanks for stopping by!
Rob Riker, CCIE #50693
Labels:
BGP,
BGP Auto Discovery,
data,
Default,
l3vpn,
LDP,
MDT,
mLDP,
MPLS,
multicast,
multipoint LDP,
mVPN,
partitioned,
PIM,
Profile 5,
Service Provider,
sp,
VRF
Subscribe to:
Posts (Atom)