In this post we will take a look at Profile 13, leveraging BGP as the customer multicast signaling mechanism. Since this is a follow on from Profiles 9 and 1, we're taking advantage of the MLDP encapsulated multicast traffic, BGP AD for PE discovery and now BGP as the customer multicast signaling.
Like Profile 11, XRv 6.0 doesn't seem to work in Profile 13 either. So we will check R1, R3 and R7.
R1, R3 and R7
vrf definition MVPN
address-family ipv4
mdt overlay use-bgp
XR1
router pim
vrf CORE
address-family ipv4
mdt c-multicast-routing bgp
R1#sh bgp ipv4 mvpn all | b Network
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf MVPN)
*> [1][100:100][192.0.2.1]/12
0.0.0.0 32768 ?
*>i [1][100:100][192.0.2.3]/12
192.0.2.3 0 100 0 ?
*>i [1][100:100][192.0.2.7]/12
192.0.2.7 0 100 0 ?
*>i [1][100:100][192.0.2.21]/12
192.0.2.21 100 0 i
*> [3][100:100][192.0.2.15][232.15.15.15][192.0.2.1]/22
0.0.0.0 32768 ?
*>i [3][100:100][192.0.2.16][232.16.16.16][192.0.2.21]/22
192.0.2.21 100 0 i
*>i [6][100:100][1.50693][192.0.2.15/32][227.1.2.3/32]/22
192.0.2.7 0 100 0 ?
*>i [7][100:100][1.50693][192.0.2.15/32][232.15.15.15/32]/22
192.0.2.3 0 100 0 ?
R3#sh bgp ipv4 mvpn all | b Network
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf MVPN)
*>i [1][100:100][192.0.2.1]/12
192.0.2.1 0 100 0 ?
*> [1][100:100][192.0.2.3]/12
0.0.0.0 32768 ?
*>i [1][100:100][192.0.2.7]/12
192.0.2.7 0 100 0 ?
*>i [1][100:100][192.0.2.21]/12
192.0.2.21 100 0 i
*>i [3][100:100][192.0.2.15][232.15.15.15][192.0.2.1]/22
192.0.2.1 0 100 0 ?
*>i [3][100:100][192.0.2.16][232.16.16.16][192.0.2.21]/22
192.0.2.21 100 0 i
*> [6][100:100][1.50693][192.0.2.15/32][227.1.2.3/32]/22
0.0.0.0 32768 ?
*> [7][100:100][1.50693][192.0.2.15/32][232.15.15.15/32]/22
0.0.0.0 32768 ?
R7#sh bgp ipv4 mvpn all | b Network
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 100:100 (default for vrf MVPN)
*>i [1][100:100][192.0.2.1]/12
192.0.2.1 0 100 0 ?
*>i [1][100:100][192.0.2.3]/12
192.0.2.3 0 100 0 ?
*> [1][100:100][192.0.2.7]/12
0.0.0.0 32768 ?
*>i [1][100:100][192.0.2.21]/12
192.0.2.21 100 0 i
*>i [3][100:100][192.0.2.15][232.15.15.15][192.0.2.1]/22
192.0.2.1 0 100 0 ?
*>i [3][100:100][192.0.2.16][232.16.16.16][192.0.2.21]/22
192.0.2.21 100 0 i
*> [6][100:100][1.50693][192.0.2.15/32][227.1.2.3/32]/22
0.0.0.0 32768 ?
*> [7][100:100][1.50693][192.0.2.16/32][232.16.16.16/32]/22
0.0.0.0 32768 ?
As we saw in Profile 11, we see route type 6 for Shared Tree Joins and Type 7 for Source tree joins. We also see type 3 for S-PMSI joins for the Data MDT traffic, mapped to the 232.0.0.0/8 ranges.
R3#show mpls mldp database | in MP2MP|P2MP|Label|FEC Root
LSM ID : 16 Type: P2MP Uptime : 01:37:17
FEC Root : 192.0.2.1
Out Label (U) : None Interface : GigabitEthernet1.23*
Local Label (D): 3023 Next Hop : 100.64.23.2
LSM ID : 1 (RNR LSM ID: 2) Type: MP2MP Uptime : 1d09h
FEC Root : 192.0.2.22
Out Label (U) : 2009 Interface : GigabitEthernet1.23*
Local Label (D): 3020 Next Hop : 100.64.23.2
R3#sh mpls forwarding-table labels 3020 - 3023
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
3020 [T] No Label [mdt 100:100 0][V] \
9028 aggregate/MVPN
3023 [T] No Label [mdt 100:100 1][V] \
976 aggregate/MVPN
R7#show mpls mldp database | in MP2MP|P2MP|Label|FEC Root
LSM ID : 10 Type: P2MP Uptime : 01:53:41
FEC Root : 192.0.2.21
Out Label (U) : None Interface : GigabitEthernet1.127*
Local Label (D): 7024 Next Hop : 100.64.127.12
LSM ID : 1 (RNR LSM ID: 2) Type: MP2MP Uptime : 1d09h
FEC Root : 192.0.2.22
Out Label (U) : 92018 Interface : GigabitEthernet1.127*
Local Label (D): 7020 Next Hop : 100.64.127.12
R7#show mpls forwarding-table labels 7019 - 7024
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
7019 No Label 100.64.214.0/24[V] \
0 aggregate/MVPN
7020 [T] No Label [mdt 100:100 0][V] \
8174 aggregate/MVPN
7024 [T] No Label [mdt 100:100 1][V] \
0 aggregate/MVPN
Now that we have verified the signaling, we'll verify the data plane now. From R15 to the ASM group first and then the SSM groups.
R15#ping 227.1.2.3 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 227.1.2.3, timeout is 2 seconds:
Reply to request 0 from 100.64.214.18, 40 ms
Reply to request 0 from 192.0.2.18, 42 ms
Reply to request 0 from 192.0.2.17, 40 ms
Reply to request 0 from 100.64.211.17, 40 ms
Reply to request 1 from 100.64.211.17, 8 ms
Reply to request 1 from 192.0.2.18, 13 ms
Reply to request 1 from 192.0.2.18, 11 ms
Reply to request 1 from 100.64.214.18, 11 ms
Reply to request 1 from 192.0.2.17, 8 ms
Reply to request 1 from 192.0.2.17, 8 ms
R3#show mpls mldp database | in MP2MP|P2MP|Label|FEC Root
LSM ID : 16 Type: P2MP Uptime : 01:41:53
FEC Root : 192.0.2.1
Out Label (U) : None Interface : GigabitEthernet1.23*
Local Label (D): 3023 Next Hop : 100.64.23.2
LSM ID : 1A Type: P2MP Uptime : 00:00:41
FEC Root : 192.0.2.1
Out Label (U) : None Interface : GigabitEthernet1.23*
Local Label (D): 3025 Next Hop : 100.64.23.2
LSM ID : 1 (RNR LSM ID: 2) Type: MP2MP Uptime : 1d09h
FEC Root : 192.0.2.22
Out Label (U) : 2009 Interface : GigabitEthernet1.23*
Local Label (D): 3020 Next Hop : 100.64.23.2
A new P2MP MDT is created and label allocated.
R3#sh mpls forwarding-table labels 3020 - 3025
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
3020 [T] No Label [mdt 100:100 0][V] \
9394 aggregate/MVPN
3023 [T] No Label [mdt 100:100 1][V] \
976 aggregate/MVPN
However when we check the LFIB for incremented flows, we don't see it. I'm not sure why this happens. But if you look at label 3020 packet count, it did increment, so one could deduce that label 3020 is used for ASM traffic.
R7#show mpls mldp database | in MP2MP|P2MP|Label|FEC Root
LSM ID : 10 Type: P2MP Uptime : 01:57:28
FEC Root : 192.0.2.21
Out Label (U) : None Interface : GigabitEthernet1.127*
Local Label (D): 7024 Next Hop : 100.64.127.12
LSM ID : 14 Type: P2MP Uptime : 00:00:28
FEC Root : 192.0.2.1
Out Label (U) : None Interface : GigabitEthernet1.67*
Local Label (D): 7023 Next Hop : 100.64.67.6
LSM ID : 1 (RNR LSM ID: 2) Type: MP2MP Uptime : 1d09h
FEC Root : 192.0.2.22
Out Label (U) : 92018 Interface : GigabitEthernet1.127*
Local Label (D): 7020 Next Hop : 100.64.127.12
Same happens with R7, a new P2MP MDT is created with label 7023.
R7#show mpls forwarding-table labels 7019 - 7024
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
7019 No Label 100.64.214.0/24[V] \
0 aggregate/MVPN
7020 [T] No Label [mdt 100:100 0][V] \
8540 aggregate/MVPN
7024 [T] No Label [mdt 100:100 1][V] \
0 aggregate/MVPN
Checking the LFIB, we see that label 7020 incremented. Indicating that label 7020 is forwarding ASM traffic.
R15#ping 232.15.15.15 source lo0 repeat 2
Type escape sequence to abort.
Sending 2, 100-byte ICMP Echos to 232.15.15.15, timeout is 2 seconds:
Packet sent with a source address of 192.0.2.15
Reply to request 0 from 192.0.2.17, 7 ms
Reply to request 0 from 192.0.2.17, 9 ms
Reply to request 1 from 192.0.2.17, 9 ms
Reply to request 1 from 192.0.2.17, 11 ms
Pinging the SSM group of 232.15.15.15 now to test the SSM Data MDT.
R3#sh mpls forwarding-table labels 3020 - 3025
Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or Tunnel Id Switched interface
3020 [T] No Label [mdt 100:100 0][V] \
9394 aggregate/MVPN
3023 [T] No Label [mdt 100:100 1][V] \
1464 aggregate/MVPN
We can quickly check the LFIB and verify that label 3023 is the SSM label.
Thanks for stopping by!
Rob Riker, CCIE #50693
No comments:
Post a Comment