NG-MVPN Wildcard S-PMSI
This chapter provides information about next generation multicast virtual private networks (NG-MVPNs): use of wildcard selective PMSI.
Topics in this chapter include:
Applicability
The chapter was initially written based on SR OS Release 13.0.R4, but the CLI in the current edition is based on Release 15.0.R5.
MPLS provider tunnels can be set up using multicast label distribution protocol (mLDP) or point-to-multipoint (P2MP) resource reservation protocol with traffic engineering (RSVP-TE) label switched paths (LSPs). SR OS Release 12.0.R4 or later is required for route reflectors (RRs) peering with multicast virtual private network (MVPN) PEs.
Provider multicast service interfaces (PMSIs) are signaled using mLDP. PE MVPN auto-discovery uses BGP MVPN IPv4 network layer routing.
Knowledge of multi-protocol BGP (MP-BGP), RFC 4364, BGP/MPLS IP Virtual Private Networks (VPNs), RFC 6513, Multicast in MPLS/BGP IP VPNs/RFC 6514, BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs, and RFC 6625, Wildcards in Multicast VPN Auto-Discovery Routes, is assumed throughout this chapter.
Overview
Consider a service provider core network used to deliver multicast services to a number of receiver PEs using Next Generation MVPN techniques, as defined in RFC 6513/6514, where multicast traffic is forwarded between PEs across a mesh of provider tunnels.
The provider tunnel used is the default Inclusive PMSI (I-PMSI) that is instantiated between all source and receiver PEs. This results in a full mesh of provider tunnels between all PEs in the MVPN. In a large network, this can result in an inefficient use of bandwidth because multicast traffic is forwarded to all PEs regardless of whether the PE has an interested receiver. Some of the mesh scaling issues can be mitigated by using source-only/destination-only configuration on PEs. However, this technique requires additional configuration and is not fully optimal when mLDP is used in the core.
To address the preceding limitation, wildcard Selective PMSI (S-PMSI) has been developed, as per RFC 6625. In the standard customer signaling notation of (C-S,C-G), this becomes (C-*,C-*). Using methods defined in RFC 6625, it is possible to use a (C-*,C-*) S-PMSI as the default tunnel, where the receiver PE can join the S-PMSI by mapping the channel join to a wildcard channel group. Multiple channels can be transported by the wildcard (C-*,C-*) S-PMSI, where an S-PMSI auto-discovery route is advertised with an empty channel group and source address:
Bandwidth savings can be achieved by the delivery of multicast channels on S-PMSIs, because traffic is not forwarded to PEs that have no interested receivers.
Control plane savings can be achieved by eliminating the need for the full tunnel mesh between all PES. The wildcard S-PMSI is only signaled on PEs containing attached upstream multicast sources, for which the PE is resolved as an upstream multicast hop (UMH) within the MVPN.
Multicast VPN shows the concept of an MVPN.
In Multicast VPN, PE-1 has a directly connected multicast source (S-1). For clarity, consider this MVPN as a single multicast group. PE-1 is configured as a sender PE because it is the PE closest to the source. PE-2, PE-3, PE-4, and PE-5 are configured as receiver-only PEs because they have connected receiver hosts H-2, H-3, H-4, and H-5, respectively. Hosts H-2 to H-5 connected to receiver PEs can receive multicast channels from the source, S-1, connected to the source PE, PE-1, within the same virtual private routed network (VPRN).
Within the provider network, multicast traffic is delivered from the source PE to the receiver PE across a PMSI tunnel. This tunnel is, in this case, a P2MP LSP, with its root at PE-1 and with a leaf at each of the receiver PEs. Any traffic that is forwarded into the tunnel interface is replicated so that a single copy of a multicast stream is received at all PEs.
The PMSI tunnel is created after each PE has declared themselves as a member of the MVPN using BGP MVPN auto-discovery techniques.
There are two choices of PMSI:
An I-PMSI, which is created on each PE within the MVPN, with a root at each PE and a leaf at all other PEs that are members of the MVPN. The I-PMSI is the default tunnel for all multicast traffic carried between sender PE and receiver PEs. When at least one receiver PE has a host interested in becoming a member of a multicast group, traffic for that group is delivered to all PEs via the I-PMSI, regardless of whether they have an interested host. Receiver PEs with no such interested host then drop the traffic.
An S-PMSI, which is created to carry multicast traffic to the subset of receiver PEs that have connected hosts interested in receiving multicast traffic. This can be for a specific group, so that one S-PMSI carries traffic for one multicast group, denoted as (C-S,C-G) or (C-*,C-G). The S-PMSI can also be signaled to carry traffic for multiple multicast groups, denoted using a wildcard: (C-*,C-*) or (C-S,C-*). The wildcard S-PMSI can be signaled in place of the I-PMSI, so that all traffic can be carried on the S-PMSI by default. In this case, no I-PMSI is signaled.
In the case of an I-PMSI, the tunnel type is included in the BGP auto-discovery intra-AD route originated and advertised to all other PEs within the VPRN.
If a wildcard S-PMSI is to be used and no I-PMSI tunnel is to be signaled, then an intra-AD route update for I-PMSI is advertised with no tunnel type attribute included. In addition, the source PE will originate an additional S-PMSI auto-discovery route containing no source-encoding wildcard information.
S-PMSI Auto-Discovery BGP NLRI shows the S-PMSI MVPN BGP network layer reachability information (NLRI) advertisement.
Route Distinguisher (8 octets) |
Multicast Source Length (1 octet) |
Multicast Source (variable) |
Multicast Group Length (1 octet) |
Multicast Group (variable) |
Originating Router IP Address |
To signal the S-PMSI as wildcard (C-*,C-*) S-PMSI, the multicast source length and multicast group length fields are encoded with the value of zero (0), representing (C-*,C-*) wildcard.
The objectives are to:
Configure multicast in a VPRN on PE-1 to PE-5 using mLDP as the tunnel signaling method.
Connect multicast sources to the sender PE-1.
Create receiver hosts that can receive multicast traffic from the source, and to observe the effect on the provider network.
The following configuration tasks should be completed as a prerequisite:
Full mesh IS-IS or OSPF between each of the PE routers and the RR.
Link-layer LDP between all PEs.
mLDP used as the provider tunnel signaling protocol. This is enabled by default when link-layer LDP is enabled.
RSVP-TE is also supported as a provider tunnel signaling mechanism and could be used instead of mLDP.
Configuration
The example topology is shown in Schematic Topology, containing five PE routers. P-6 acts as an RR.
Global BGP Configuration
The first step is to configure an IBGP session between each of the PEs and the RR (PE-6) shown in Schematic Topology. The address families negotiated between the IBGP peers are vpn-ipv4 (unicast routing) and mvpn-ipv4 (multicast routing).
The configuration for PE1 is:
configure
router
bgp
group INTERNAL
family vpn-ipv4 mvpn-ipv4
type internal
neighbor 192.0.2.6
exit
exit
The configuration for the other PE nodes is exactly the same.
The configuration for the RR at P-6 is:
configure
router
bgp
cluster 0.0.0.1
group "RR_CLIENTS"
family vpn-ipv4 mvpn-ipv4
type internal
neighbor 192.0.2.1
exit
neighbor 192.0.2.2
exit
neighbor 192.0.2.3
exit
neighbor 192.0.2.4
exit
neighbor 192.0.2.5
exit
exit
On PE-1, verify that the BGP session with RR at P-6 is established with address families vpn-ipv4 and mvpn-ipv4 capabilities negotiated:
*A:PE-1# show router bgp summary
===============================================================================
BGP Router ID:192.0.2.1 AS:65545 Local AS:65545
===============================================================================
BGP Admin State : Up BGP Oper State : Up
Total Peer Groups : 1 Total Peers : 1
Total VPN Peer Groups : 0 Total VPN Peers : 0
Total BGP Paths : 17 Total Path Memory : 4488
---snip---
===============================================================================
BGP Summary
===============================================================================
Legend : D - Dynamic Neighbor
===============================================================================
Neighbor
Description
AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
-------------------------------------------------------------------------------
192.0.2.6
65545 3 0 00h00m19s 0/0/0 (VpnIPv4)
3 0 0/0/0 (MvpnIPv4)
-------------------------------------------------------------------------------
*A:PE-1#
The same command can be used on the other PEs to verify their BGP sessions to the RR.
Configuring VPRN on PEs
The following outputs show the VPRN configurations for each PE. The specific MVPN configuration is shown later.
The VPRN configuration for PE-1 is:
# on PE-1
configure
service
vprn 1 customer 1 create
route-distinguisher 65545:1
auto-bind-tunnel
resolution-filter
ldp
exit
resolution filter
exit
vrf-target target:65545:1
interface "int-PE-1-S-1" create
address 172.16.11.1/24
sap 1/1/3 create
exit
exit
interface "rp" create
address 10.0.0.1/32
loopback
exit
pim
apply-to all
rp
static
address 10.0.0.1
group-prefix 239.255.0.0/16
exit
exit
exit
no shutdown
exit
no shutdown
There is a single interface toward S-1 from which the multicast group is transmitted.
If the customer signaling uses PIM ASM, a customer Rendezvous Point (RP) is required.
A loopback interface called ‟rp” acts as the RP for all group prefixes in the 239.255.0.0/16 range. This will be the RP for all groups.
MVPN configuration enables BGP as both the auto-discovery mechanism and the customer multicast signaling protocol across the VPRN. The provider tunnel between PEs within the MVPN is signaled using mLDP.
PE-2 contains an attached receiver, therefore a single interface is configured to accommodate this, as follows. The RP is configured as a static RP:
# on PE-2
configure
service
vprn 1 customer 1 create
route-distinguisher 65545:1
auto-bind-tunnel
resolution-filter
ldp
exit
resolution filter
exit
vrf-target target:65545:1
interface "int-PE-2-H-2" create
address 172.16.22.1/24
sap 1/2/1 create
exit
exit
igmp
interface "int-PE-2-H-2”
no shutdown
exit
no shutdown
exit
pim
apply-to all
rp
static
address 10.0.0.1
group-prefix 239.255.0.0/16
exit
exit
exit
no shutdown
exit
no shutdown
PE-3 also has an attached receiver, as follows:
# on PE-3
configure
service
vprn 1 customer 1 create
route-distinguisher 65545:1
auto-bind-tunnel
resolution-filter
ldp
exit
resolution filter
exit
vrf-target target:65545:1
interface "int-PE-3-H-3" create
address 172.16.33.1/24
sap 1/2/1 create
exit
exit
igmp
interface "int-PE-3-H-3"
no shutdown
exit
no shutdown
exit
pim
apply-to all
rp
static
address 10.0.0.1
group-prefix 239.255.0.0/16
exit
exit
exit
no shutdown
exit
no shutdown
The configuration for PE-4 and PE-5 is similar.
MVPN Configuration for PEs
The provider-tunnel inclusive configuration specifies that a wildcard S-PMSI will be used instead of an I-PMSI as the default PMSI. The MVPN configuration for all PEs is:
# on all PE’s
configure
service
vprn 1
mvpn
auto-discovery default
c-mcast-signaling bgp
provider-tunnel
inclusive
mldp
no shutdown
exit
wildcard-spmsi
exit
exit
vrf-target unicast
exit
exit
The keyword wildcard-spmsi reduces the number of PMSIs signaled. If there are no group sources on the receiver PEs, there will be no S-PMSI signaled. This has an effect similar to configuring the receiver PEs as MDT-type receiver-only.
Provider Tunnel Signaling
Each PE originates BGP MVPN intra-AD routes to determine membership of an MVPN.
The provider tunnels constructed between the PEs within the VPRN are signaled on receipt of an intra-AD route update from other PEs. The intra-AD update message contains details of the originator, along with the VRF route-target extended community. If an I-PMSI is to be signaled, a PMSI tunnel attribute is included that determines the tunnel type, such as LDP P2MP LSP. PEs that receive this intra-AD update will import the route into the MVPN, then signal a P2MP LDP label map toward the originator, which is the root of the LDP P2MP LSP.
However, if a wildcard S-PMSI is to be used as the default PMSI, no PMSI tunnel attribute is included within the intra-AD update.
The following output shows a BGP update originated by PE-1, and received by PE-2:
*A:PE-2# show router bgp routes mvpn-ipv4 type intra-ad rd 65545:1 detail
originator-ip 192.0.2.1
===============================================================================
BGP Router ID:192.0.2.2 AS:65545 Local AS:65545
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Original Attributes
Route Type : Intra-Ad
Route Dist. : 65545:1
Originator IP : 192.0.2.1
Nexthop : 192.0.2.1
Path Id : None
From : 192.0.2.6
Res. Nexthop : 0.0.0.0
Local Pref. : 100 Interface Name : NotAvailable
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : 0
AIGP Metric : None
Connector : None
Community : no-export target:65545:1
Cluster : 0.0.0.1
Originator Id : 192.0.2.1 Peer Router Id : 192.0.2.6
Flags : Used Valid Best IGP
Route Source : Internal
AS-Path : No As-Path
Route Tag : 0
Neighbor-AS : N/A
Orig Validation: N/A
Source Class : 0 Dest Class : 0
Add Paths Send : Default
Last Modified : 00h00m25s
VPRN Imported : 1
Modified Attributes
Route Type : Intra-Ad
Route Dist. : 65545:1
---snip---
VPRN Imported : 1
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
*A:PE-2#
There is no PMSI tunnel attribute included, and the route is imported into the correct VPRN (VPRN 1).
The intra-AD originated by PE-2 is:
*A:PE-1# show router bgp routes mvpn-ipv4 type intra-ad rd 65545:1
originator-ip 192.0.2.2 hunt
===============================================================================
BGP Router ID:192.0.2.1 AS:65545 Local AS:65545
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
Route Type : Intra-Ad
Route Dist. : 65545:1
Originator IP : 192.0.2.2
Nexthop : 192.0.2.2
Path Id : None
From : 192.0.2.6
Res. Nexthop : 0.0.0.0
Local Pref. : 100 Interface Name : NotAvailable
Community : no-export target:65545:1
Cluster : 0.0.0.1
Originator Id : 192.0.2.2 Peer Router Id : 192.0.2.6
Flags : Used Valid Best IGP
Route Source : Internal
AS-Path : No As-Path
Route Tag : 0
Neighbor-AS : N/A
Orig Validation: N/A
Source Class : 0 Dest Class : 0
Add Paths Send : Default
Last Modified : 00h00m50s
VPRN Imported : 1
-------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
*A:PE-1#
This output also contains no PMSI tunnel attribute: PE-2 has no group source and there is no S-PMSI signaled. All other receiver PEs will originate a similar intra-AD route.
The following output shows all intra-AD routes originated by the PEs within the VPRN, as received by PE-1:
*A:PE-1# show router bgp routes mvpn-ipv4 type intra-ad rd 65545:1
===============================================================================
BGP Router ID:192.0.2.1 AS:65545 Local AS:65545
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType OriginatorIP LocalPref MED
RD SourceAS Path-Id Label
Nexthop SourceIP
As-Path GroupIP
-------------------------------------------------------------------------------
i Intra-Ad 192.0.2.1 100 0
65545:1 - None -
192.0.2.1 -
No As-Path -
u*>i Intra-Ad 192.0.2.2 100 0
65545:1 - None -
192.0.2.2 -
No As-Path -
u*>i Intra-Ad 192.0.2.3 100 0
65545:1 - None -
192.0.2.3 -
No As-Path -
u*>i Intra-Ad 192.0.2.4 100 0
65545:1 - None -
192.0.2.4 -
No As-Path -
u*>i Intra-Ad 192.0.2.5 100 0
65545:1 - None -
192.0.2.5 -
No As-Path -
-------------------------------------------------------------------------------
Routes : 5
===============================================================================
*A:PE-1#
Instead of an I-PMSI being signaled, an S-PMSI AD route update is advertised by PE-1 to all receiver PEs within the MVPN. The NLRI encoding has a zero length field for both source and group addresses, so is seen to represent multicast group (C-*,C-*). This is wildcard nomenclature for both source and group addresses.
The BGP route as advertised by PE-1:
*A:PE-1# show router bgp routes mvpn-ipv4 type spmsi-ad rd 65545:1 hunt
===============================================================================
BGP Router ID:192.0.2.1 AS:65545 Local AS:65545
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
-------------------------------------------------------------------------------
RIB In Entries
-------------------------------------------------------------------------------
---snip---
-------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
Route Type : Spmsi-Ad
Route Dist. : 65545:1
Originator IP : 192.0.2.1
Source IP : 0.0.0.0
Group IP : 0.0.0.0
Nexthop : 192.0.2.1
Path Id : None
To : 192.0.2.6
Res. Nexthop : n/a
Local Pref. : 100 Interface Name : NotAvailable
Aggregator AS : None Aggregator : None
---snip---
Community : no-export target:65545:1
Cluster : No Cluster Members
Originator Id : None Peer Router Id : 192.0.2.6
Origin : IGP
AS-Path : No As-Path
Route Tag : 0
Neighbor-AS : N/A
Orig Validation: N/A
Source Class : 0 Dest Class : 0
-------------------------------------------------------------------------------
PMSI Tunnel Attributes :
Tunnel-type : LDP P2MP LSP
Flags : Type: RNVE(0) BM: 0 U: 0 Leaf: not required
MPLS Label : 0
Root-Node : 192.0.2.1 LSP-ID : 8193
-------------------------------------------------------------------------------
Routes : 6
===============================================================================
*A:PE-1#
The source IP and group IP address fields are advertised as 0.0.0.0, and the tunnel type attribute is now included as an LDP P2MP LSP.
The following output shows the MVPN status at PE-1, with the I-PMSI tunnel name containing a wildcard S-PMSI denoted by (W):
*A:PE-1# show router 1 mvpn
===============================================================================
MVPN 1 configuration data
===============================================================================
signaling : Bgp auto-discovery : Default
UMH Selection : Highest-Ip SA withdrawn : Disabled
intersite-shared : Enabled Persist SA : Disabled
vrf-import : N/A
vrf-export : N/A
vrf-target : unicast
C-Mcast Import RT : target:192.0.2.1:2
ipmsi : ldp
i-pmsi P2MP AdmSt : Up
i-pmsi Tunnel Name : mpls-if-73728(W)
Mdt-type : sender-receiver
BSR signalling : none
Wildcard s-pmsi : Enabled
Multistream-SPMSI : Disabled
s-pmsi : none
data-delay-interval: 3 seconds
enable-asm-mdt : N/A
===============================================================================
*A:PE-1#
At this point, there is no interested host and no customer multicast flow (c-flow), so there is no S-PMSI LDP P2MP LSP signaled.
Data Transmission at Source PE
Multicast traffic for a particular group will be forwarded between the sender and receiver PE over a provider tunnel (PMSI). Because there is no default I-PMSI present, the receiver PE has to choose an S-PMSI to be used for forwarding, based on the NLRI contained within the S-PMSI AD routes.
The provider tunnel is signaled using a P2MP LDP label mapping message toward the root address signaled in the wildcard S-PMSI AD BGP update message. As previously shown, the update message is based on whether traffic is being forwarded on the shared or source-based shortest path tree.
When joining the shared tree, a c-multicast shared-join is sent toward the appropriate PE, which represents the UMH toward the RP. The UMH is chosen from the unicast route that represents the RP address. When joining the shortest path tree, a source-join c-multicast route is sent toward the UMH chosen from the unicast route that represents the actual source address. In both cases, the VPN-IPv4 unicast route advertises a VRF route import community that contains the system address as a next hop. Upon receipt of these updates, the UMH PE will forward traffic along the signaled wildcard S-PMSI.
Each S-PMSI is bound to one or more flows, as determined by the NLRI contained within the S-PMSI BGP update. The use of the wildcard within the BGP update to replace the c-source and c-group allows multiple flows to be bound to a single provider tunnel.
Traffic will only be forwarded upon reception of a BGP MVPN source-join or shared-join BGP route at the sender PE.
Data Reception at Receiver PE
When the sender PE has originated an S-PMSI AD route update, each receiver PE will install the route into its VRF. The S-PMSIs installed are used to select an appropriate upstream multicast router for a c-flow when an attached receiver is interested in receiving traffic from that c-flow.
The receiver PE will receive a flow based on the best match of the incoming (C-S,C-G) or (C-*,C-G) IGMP/MLD or PIM join.
If an IGMP/MLD group membership query or PIM join is received by the receiver PE over an attachment circuit for a group, the contained (C-S,C-G) or (C-*,C-G) must match the (C-S,C-G) contained within any installed S-PMSI AD route. In the case of the wildcard S-PMSI being the only installed NLRI, this will be a match; that is, incoming (C-*,C-G) or (C-S,C-G) will match the S-PMSI (C-*,C-*).
In this example, the c-group flow is 239.255.0.1.
Traffic Flow
A traffic stream representing a c-flow is enabled on PE-1: group address 239.255.0.1 with source address of 172.16.11.2. The RP for this group is found locally on PE-1. The outgoing interface list is empty:
*A:PE-1# show router 1 pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address : 239.255.0.1
Source Address : 172.16.11.2
RP Address : 10.0.0.1
Advt Router : 192.0.2.1
Flags : Type : (S,G)
Mode : sparse
MRIB Next Hop : 172.16.11.2
MRIB Src Flags : direct
Keepalive Timer Exp: 0d 00:03:22
Up Time : 0d 00:00:08 Resolved By : rtable-u
Up JP State : Not Joined Up JP Expiry : 0d 00:00:00
Up JP Rpt : Not Joined StarG Up JP Rpt Override : 0d 00:00:00
Register State : Pruned Register Stop Exp : 0d 00:00:46
Reg From Anycast RP: No
Rpf Neighbor : 172.16.11.2
Incoming Intf : int-PE-1-S-1
Outgoing Intf List :
Outgoing Sap List :
Outgoing Host List :
Curr Fwding Rate : 1018.6 kbps
Forwarded Packets : 653 Discarded Packets : 0
Forwarded Octets : 978194 RPF Mismatches : 0
Spt threshold : 0 kbps ECMP opt threshold : 7
Admin bandwidth : 1 kbps
-------------------------------------------------------------------------------
Groups : 1
===============================================================================
*A:PE-1#
A host connected to PE-2 sends a (C-*,C-G) IGMP v2 group membership query for group 239.255.0.1.
PE-2 sends a BGP MVPN shared-join route update toward PE-1, where the RP address of the group 10.0.0.1 is found.
The following debug output from PE-2 shows the shared-join BGP route update transmitted by PE-2:
1 2017/10/11 12:05:18.893 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.6
"Peer 1: 192.0.2.6: UPDATE
Peer 1: 192.0.2.6 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 76
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.2
Type: Shared-Join Len:22 RD: 65545:1 SrcAS: 65545 Src: 10.0.0.1
Grp: 239.255.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.1:2
"
Upon receipt of the shared-join, traffic flows on the shared tree toward the receiver PE. This will flow on the default wildcard S-PMSI, as shown in the outgoing interface list:
*A:PE-1# show router 1 pim group 239.255.0.1 type starg detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address : 239.255.0.1
Source Address : *
RP Address : 10.0.0.1
Advt Router : 192.0.2.1
Flags : Type : (*,G)
Mode : sparse
MRIB Next Hop :
MRIB Src Flags : self
Keepalive Timer : Not Running
Up Time : 0d 00:04:16 Resolved By : rtable-u
Up JP State : Joined Up JP Expiry : 0d 00:00:43
Up JP Rpt : Not Joined StarG Up JP Rpt Override : 0d 00:00:00
Rpf Neighbor :
Incoming Intf :
Outgoing Intf List : mpls-if-73728(W)
Curr Fwding Rate : 0.0 kbps
Forwarded Packets : 0 Discarded Packets : 0
Forwarded Octets : 0 RPF Mismatches : 0
Spt threshold : 0 kbps ECMP opt threshold : 7
Admin bandwidth : 1 kbps
-------------------------------------------------------------------------------
Groups : 1
===============================================================================
*A:PE-1#
When traffic is received on the shared tree by PE-2, the source address is learned, so a source-join BGP route update is sent toward the UMH PE, which contains the source address of 172.16.11.2. The UMH is chosen from the unicast route-table using a lookup for the best route matching the source address.
The following debug output from PE-2 shows the BGP source-join route update toward the source of group 239.255.0.1, as transmitted by PE-2:
3 2017/10/11 12:05:47.191 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.6
"Peer 1: 192.0.2.6: UPDATE
Peer 1: 192.0.2.6 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 76
Flag: 0x90 Type: 14 Len: 33 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.2
Type: Source-Join Len:22 RD: 65545:1 SrcAS: 65545 Src: 172.16.11.2
Grp: 239.255.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.1:2
"
The c-flow toward host H-2 flows along the shortest path tree, and on PE-1 the outgoing interface list is populated with the wildcard S-PMSI:
*A:PE-1# show router 1 pim group detail 239.255.0.1 source 172.16.11.2
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address : 239.255.0.1
Source Address : 172.16.11.2
RP Address : 10.0.0.1
Advt Router : 192.0.2.1
Flags : spt, rpt-prn-des Type : (S,G)
Mode : sparse
MRIB Next Hop : 172.16.11.2
MRIB Src Flags : direct
Keepalive Timer Exp: 0d 00:00:47
Up Time : 0d 00:16:49 Resolved By : rtable-u
Up JP State : Joined Up JP Expiry : 0d 00:00:00
Up JP Rpt : Pruned Up JP Rpt Override : 0d 00:00:00
Register State : Pruned Register Stop Exp : 0d 00:00:05
Reg From Anycast RP: No
Rpf Neighbor : 172.16.11.2
Incoming Intf : int-PE-1-S-1
Outgoing Intf List : mpls-if-73728(W)
Curr Fwding Rate : 1018.6 kbps
Forwarded Packets : 85773 Discarded Packets : 0
Forwarded Octets : 128487954 RPF Mismatches : 0
Spt threshold : 0 kbps ECMP opt threshold : 7
Admin bandwidth : 1 kbps
-------------------------------------------------------------------------------
Groups : 1
===============================================================================
*A:PE-1#
The outgoing interface is the MPLS interface mpls-if-73728. This maps to a P2MP LDP label binding from which the p2mp-id can be derived:
*A:PE-1# show router ldp bindings active p2mp ipv4 opaque-type generic
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.1)
(IPv6 LSR ID ::)
===============================================================================
Label Status:
U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
e - Label ELC
FEC Flags:
LF - Lower FEC, UF - Upper FEC, M - Community Mismatch, BA - ASBR Backup FEC
===============================================================================
LDP Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id Interface
RootAddr Op IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193 73728
192.0.2.1 Push -- 262137
192.168.16.2 1/1/1
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 1
===============================================================================
*A:PE-1#
After the source-join is received, the sender PE will advertise a source-active AD BGP route to all PEs within the MVPN, to announce the presence of a (C-S,C-G) group. The following debug output shows the source-active AD route received on PE-2:
5 2017/10/11 12:06:17.172 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.6
"Peer 1: 192.0.2.6: UPDATE
Peer 1: 192.0.2.6 - Received BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 86
Flag: 0x90 Type: 14 Len: 29 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.1
Type: Source-AD Len: 18 RD: 65545:1 Src: 172.16.11.2 Grp: 239.255.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0x80 Type: 9 Len: 4 Originator ID: 192.0.2.1
Flag: 0x80 Type: 10 Len: 4 Cluster ID:
0.0.0.1
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:65545:1
"
The PIM status of the group on receiver PE-2 shows that the incoming interface is the wildcard S-PMSI originated on PE-1, as denoted by the (W):
*A:PE-2# show router 1 pim group 239.255.0.1 source 172.16.11.2 detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address : 239.255.0.1
Source Address : 172.16.11.2
RP Address : 10.0.0.1
Advt Router : 192.0.2.1
Flags : spt Type : (S,G)
Mode : sparse
MRIB Next Hop : 192.0.2.1
MRIB Src Flags : remote
Keepalive Timer Exp: 0d 00:02:02
Up Time : 0d 00:08:58 Resolved By : rtable-u
Up JP State : Joined Up JP Expiry : 0d 00:00:02
Up JP Rpt : Not Pruned Up JP Rpt Override : 0d 00:00:00
Register State : No Info
Reg From Anycast RP: No
Rpf Neighbor : 192.0.2.1
Incoming Intf : mpls-if-73729(W)
Outgoing Intf List : int-PE-2-H-2
Curr Fwding Rate : 1018.6 kbps
Forwarded Packets : 45751 Discarded Packets : 0
Forwarded Octets : 68534998 RPF Mismatches : 0
Spt threshold : 0 kbps ECMP opt threshold : 7
Admin bandwidth : 1 kbps
-------------------------------------------------------------------------------
Groups : 1
===============================================================================
*A:PE-2#
The S-PMSI is an LDP P2MP LSP. The LDP label binding for P2MP LSP-Id 8193 at PE-2 shows that the label operation is a label pop:
*A:PE-2# show router ldp bindings active p2mp p2mp-id 8193 root 192.0.2.1
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.2)
(IPv6 LSR ID ::)
===============================================================================
Label Status:
U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
e - Label ELC
FEC Flags:
LF - Lower FEC, UF - Upper FEC, M - Community Mismatch, BA - ASBR Backup FEC
===============================================================================
LDP Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id Interface
RootAddr Op IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193 73729
192.0.2.1 Pop 262136 --
-- --
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 1
===============================================================================
*A:PE-2#
PE-3 has no host joined to c-flow group 239.255.0.1. However, it contains the PIM state for this group due to the presence of the source-active AD route within the VRF. This route was received when the host connected to PE-2 joined the c-flow group.
The following output shows the source-active AD route within PE-3 for group 239.255.0.1 from source 172.16.11.2:
*A:PE-3# show router bgp routes mvpn-ipv4 type source-ad rd 65545:1
===============================================================================
BGP Router ID:192.0.2.3 AS:65545 Local AS:65545
===============================================================================
Legend -
Status codes : u - used, s - suppressed, h - history, d - decayed, * - valid
l - leaked, x - stale, > - best, b - backup, p - purge
Origin codes : i - IGP, e - EGP, ? - incomplete
===============================================================================
BGP MVPN-IPv4 Routes
===============================================================================
Flag RouteType OriginatorIP LocalPref MED
RD SourceAS Path-Id Label
Nexthop SourceIP
As-Path GroupIP
-------------------------------------------------------------------------------
u*>i Source-Ad - 100 0
65545:1 - None -
192.0.2.1 172.16.11.2
No As-Path 239.255.0.1
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
*A:PE-3#
However, traffic is not received from the S-PMSI because there is no label binding for the LDP P2MP LSP. The following output shows that there is no label binding for the LSP Id 8193, which has its root on PE-1:
*A:PE-3# show router ldp bindings p2mp p2mp-id 8193 root 192.0.2.1
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.3)
(IPv6 LSR ID ::)
===============================================================================
Label Status:
U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
e - Label ELC
FEC Flags:
LF - Lower FEC, UF - Upper FEC, M - Community Mismatch, BA - ASBR Backup FEC
===============================================================================
LDP Generic IPv4 P2MP Bindings
===============================================================================
P2MP-Id
RootAddr Interface IngLbl EgrLbl
EgrNH EgrIf/LspId
Peer
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
*A:PE-3#
A static IGMPv2 (*,G) group is created on interface int-PE-3-H3 for group 239.255.0.1 toward PE-3. The following debug output shows the process.
4 2017/10/11 11:32:30.123 UTC MINOR: DEBUG #2001 vprn1 IGMP[vprn1 inst 2]
"IGMP[vprn1 inst 2]: igmpIfSGStaticAdd
Adding Static SG (0.0.0.0,239.255.0.1) to IGMP interface int-PE-3-H-3 [ifIndex 5]"
5 2017/10/11 11:32:30.123 UTC MINOR: DEBUG #2001 vprn1 IGMP[vprn1 inst 2]
"IGMP[vprn1 inst 2]: igmpIfGroupAdd
Adding 239.255.0.1 to IGMP interface int-PE-3-H-3 [ifIndex 5] database"
6 2017/10/11 11:32:30.123 UTC MINOR: DEBUG #2001 vprn1 IGMP[vprn1 inst 2]
"IGMP[vprn1 inst 2]: igmpProcessGroupRec
Process group rec CHG_TO_EXCL received on interface int-PE-3-H-3 [ifIndex 5]
for group 239.255.0.1 in mode INCLUDE. Num srcs 0"
7 2017/10/11 11:32:30.123 UTC MINOR: DEBUG #2001 vprn1 IGMP[vprn1 inst 2]
"IGMP[vprn1 inst 2]: igmpIfSrcAdd
Adding i/f source entry for interface int-PE-3-H-3 [ifIndex 5] (*,239.255.0.1)
to IGMP fwdList Database, redir if N/A"
A similar process takes place when receiver host H-3 sends an unsolicited IGMP v2 group membership query for this group. The first message would correspond to the IGMP query instead.
After the IGMP interface source entry has been added for interface int-PE-3-H-3, an mLDP P2MP label mapping message is sent from PE-3 toward the root node PE-1, as follows:
8 2017/10/11 11:32:30.123 UTC MINOR: DEBUG #2001 Base LDP
"LDP: Binding
Sending Label mapping label 262136 for P2MP: root = 192.0.2.1, T: 1, L: 4,
TunnelId: 8193 to peer 192.0.2.4:0."
9 2017/10/11 11:32:30.123 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Send Label Mapping packet (msgId 618) to 192.0.2.4:0
Protocol version = 1
Label 262136 advertised for the following FECs
P2MP: root = 192.0.2.1, T: 1, L: 4, TunnelId: 8193
"
BGP shared-join and source-join BGP route updates are sent via the RR toward the RP (source = 10.0.0.1) and the actual source (172.16.11.2), respectively:
10 2017/10/11 11:32:30.124 UTC MINOR: DEBUG #2001 Base Peer 1: 192.0.2.6
"Peer 1: 192.0.2.6: UPDATE
Peer 1: 192.0.2.6 - Send BGP UPDATE:
Withdrawn Length = 0
Total Path Attr Length = 100
Flag: 0x90 Type: 14 Len: 57 Multiprotocol Reachable NLRI:
Address Family MVPN_IPV4
NextHop len 4 NextHop 192.0.2.3
Type: Shared-Join Len:22 RD: 65545:1 SrcAS: 65545 Src: 10.0.0.1
Grp: 239.255.0.1
Type: Source-Join Len:22 RD: 65545:1 SrcAS: 65545 Src: 172.16.11.2
Grp: 239.255.0.1
Flag: 0x40 Type: 1 Len: 1 Origin: 0
Flag: 0x40 Type: 2 Len: 0 AS Path:
Flag: 0x80 Type: 4 Len: 4 MED: 0
Flag: 0x40 Type: 5 Len: 4 Local Preference: 100
Flag: 0xc0 Type: 8 Len: 4 Community:
no-export
Flag: 0xc0 Type: 16 Len: 8 Extended Community:
target:192.0.2.1:2
"
The PIM status for the c-group 239.255.0.1 on PE-3 is as follows:
*A:PE-3# show router 1 pim group
===============================================================================
Legend: A = Active S = Standby
===============================================================================
PIM Groups ipv4
===============================================================================
Group Address Type Spt Bit Inc Intf No.Oifs
Source Address RP State Inc Intf(S)
-------------------------------------------------------------------------------
239.255.0.1 (*,G) mpls-if-73729* 1
* 10.0.0.1
239.255.0.1 (S,G) spt mpls-if-73729* 1
172.16.11.2 10.0.0.1
-------------------------------------------------------------------------------
Groups : 2
===============================================================================
* indicates that the corresponding row element may have been truncated.
*A:PE-3#
Assume that a receiver on each of PE-4 and PE-5 needs to join group 239.255.0.1, as shown in S-PMSI P2MP LSP Schematic.
S-PMSI P2MP LSP Schematic shows the S-PMSI P2MP LSP. The next set of outputs shows the P2MP label mapping of the LDP LSP between PE-1 and the receiver PEs.
The root of the S-PMSI is on PE-1, as follows:
*A:PE-1# show router ldp bindings active p2mp p2mp-id 8193 root 192.0.2.1
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.1)
(IPv6 LSR ID ::)
===============================================================================
Label Status:
U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
e - Label ELC
FEC Flags:
LF - Lower FEC, UF - Upper FEC, M - Community Mismatch, BA - ASBR Backup FEC
===============================================================================
LDP Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id Interface
RootAddr Op IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193 73728
192.0.2.1 Push -- 262137
192.168.16.2 1/1/1
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 1
===============================================================================
*A:PE-1#
The egress label on PE-1 becomes the ingress label on P-6. P-6 has two leaves: one toward PE-4 and one toward PE-5, as follows:
*A:P-6# show router ldp bindings active p2mp p2mp-id 8193 root 192.0.2.1
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.6)
(IPv6 LSR ID ::)
===============================================================================
Label Status:
U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
e - Label ELC
FEC Flags:
LF - Lower FEC, UF - Upper FEC, M - Community Mismatch, BA - ASBR Backup FEC
===============================================================================
LDP Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id Interface
RootAddr Op IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193 Unknw
192.0.2.1 Swap 262137 262136
192.168.46.1 1/1/2
8193 Unknw
192.0.2.1 Swap 262137 262136
192.168.56.1 1/1/1
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 2
===============================================================================
*A:P-6#
On PE-5, the following output shows that the LSP terminates as a leaf, as the operation (Op) is shown as ‟pop”:
*A:PE-5# show router ldp bindings active p2mp p2mp-id 8193 root 192.0.2.1
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.5)
(IPv6 LSR ID ::)
===============================================================================
---snip---
===============================================================================
LDP Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id Interface
RootAddr Op IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193 73729
192.0.2.1 Pop 262136 --
-- --
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 1
===============================================================================
*A:PE-5#
On PE-4, the P2MP LSP has 3 entries: a pop operation to receiver H-4, and two label swaps toward PE-3 and PE-2:
*A:PE-4# show router ldp bindings active p2mp p2mp-id 8193 root 192.0.2.1
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.4)
(IPv6 LSR ID ::)
===============================================================================
Label Status:
U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
e - Label ELC
FEC Flags:
LF - Lower FEC, UF - Upper FEC, M - Community Mismatch, BA - ASBR Backup FEC
===============================================================================
LDP Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id Interface
RootAddr Op IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193 73729
192.0.2.1 Pop 262136 --
-- --
8193 73729
192.0.2.1 Swap 262136 262136
192.168.24.1 1/1/2
8193 73729
192.0.2.1 Swap 262136 262136
192.168.34.1 1/1/3
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 3
===============================================================================
*A:PE-4#
PE-2 and PE-3 are termination PEs for P2MP leaf. On PE-2, the pop operation is shown:
*A:PE-2# show router ldp bindings active p2mp p2mp-id 8193 root 192.0.2.1
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.2)
(IPv6 LSR ID ::)
===============================================================================
---snip---
P2MP-Id Interface
RootAddr Op IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193 73729
192.0.2.1 Pop 262136 --
-- --
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 1
===============================================================================
*A:PE-2#
On PE-3, the P2MP pop operation is shown:
*A:PE-3# show router ldp bindings active p2mp p2mp-id 8193 root 192.0.2.1
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.3)
(IPv6 LSR ID ::)
===============================================================================
Label Status:
U - Label In Use, N - Label Not In Use, W - Label Withdrawn
WP - Label Withdraw Pending, BU - Alternate For Fast Re-Route
e - Label ELC
FEC Flags:
LF - Lower FEC, UF - Upper FEC, M - Community Mismatch, BA - ASBR Backup FEC
===============================================================================
LDP Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id Interface
RootAddr Op IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193 73729
192.0.2.1 Pop 262136 --
-- --
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 1
===============================================================================
*A:PE-3#
Conclusion
MVPN wildcard Selective PMSI (S-PMSI), developed as per RFC 6625, provides an optimal solution for multicast routing in a VPRN. This protocol provides simple configuration, operation, and fast protection time in conjunction with MPLS and LDP fast-failover schemes. Wildcard S-PMSI can be used in a multicast network to avoid a large full mesh of an I-PMSI.