NG-MVPN Inter-AS Model C Using Non-Segmented mLDP Tunnels
This chapter provides information about NG-MVPN Inter-AS Model C Using Non-Segmented mLDP Tunnels.
Topics in this chapter include:
Applicability
The information and configuration in this chapter are based on SR OS Release 23.10.R2.
No specific configuration is required to support non-segmented multicast Label Distribution Protocol (mLDP) for inter-AS model C. However, recursive-opaque mLDP Forwarding Equivalence Class (FEC) functionality must be supported.
The configuration of multicast in a VPRN is described in the NG-MVPN Configuration with MPLS chapter.
Overview
Multicast in an inter-AS model C network can be implemented using Rosen, where the set of Multicast Distribution Trees (MDTs) are signaled using Protocol Independent Multicast Source-Specific Mode (PIM-SSM).
It is also possible to create MDTs between PEs in different Autonomous Systems (ASs) for Next-Generation MVPN (NG-MVPN) using non-segmented dynamic multicast LDP (mLDP) trees, where the root and leaf PEs are in different ASs. This chapter describes the configuration of MVPN services between PEs in different ASs using NG-MVPN techniques.
NG-MVPN Inter-AS Model C shows an example of a network comprising routers in two neighboring ASs, modeled as an inter-AS model C network; see the Inter-AS VPRN Model C chapter.
A VPRN instance exists in PE-1 and PE-5, with a single source and receiver connected. RR-3 is an off the data path Route Reflector (RR) for the vpn-ipv4 and mvpn-ipv4 address families, and ASBR-4 is RR for the label-ipv4 address family in AS 64496. PE-1 is client to both RRs. The situation in AS 64497 is similar.
The multicast source located at address 172.16.5.2 in AS 64497 generates multicast traffic with multicast group address 239.255.0.1, and the receiver at address 172.16.1.2 in AS 64496 becomes a member of the multicast group using IGMPv3 signaling. No multicast protocols are configured on the ASBRs.
In an MVPN, a transport tunnel is signaled that carries multicast traffic from source PE to any receiver PE that has multicast routers attached, or hosts that want to become multicast group members. In this case, an mLDP tunnel is signaled between source PE and destination PEs to carry multicast traffic across the multi-AS provider network.
An mLDP Provider Multicast Service Interface (PMSI), also known as the provider tunnel, is established between PEs that declare membership to the MVPN, by generating and advertising an MVPN type 1 intra-AD (Auto-Discovery) BGP route. This route contains a PMSI Tunnel Attribute (PTA) that provides the tunnel type, the root node, and the LSP ID. Upon receipt of the intra-AD route, the receiving PE checks the route validity so that it can be imported into the VPRN instance. If the route is valid, the receiving router signals a point-to-multipoint (P2MP) LDP label mapping message toward the root address contained within the PTA of the intra-AD route. At the root, MPLS-encapsulated multicast traffic is forwarded to the downstream router by pushing on a label received from the downstream router.
Inter-AS model C unicast requires the RRs in peer ASs to establish a multi-hop EBGP session over which vpn-ipv4 routes can then be exchanged. If RRs are not used, PEs in the peer ASs can exchange the vpn-ipv4 and mvpn-ipv4 routes over a multi-hop eBGP session. Therefore, model C also requires the PE system addresses to be advertised across the AS boundary first.
The path for inter-AS unicast traffic is resolved using vpn-ipv4 routes learnt via the multi-hop eBGP session between RR-3 and RR-7 and label-ipv4 routes learnt via ASBR-4 and ASBR-8. In a unicast environment, traffic from PE-1 to PE-5 takes the following path:
The tunnel from PE-1 to ASBR-4 comprises of three MPLS labels: the MPLS transport label to reach ASBR-4, followed by the MPLS label to reach PE-5 (bgp label-ipv4 learnt from ASBR-4), followed by the label associated with the vpn-ipv4 route.
ASBR-4 pops the outer-most MPLS transport label and forwards to ASBR-8.
ASBR-8 swaps the outer MPLS label (bgp label-ipv4) with the MPLS transport label to reach PE-5.
PE-5 pops the outer MPLS label and uses the VPRN label to forward traffic to the appropriate VPRN.
Unlike unicast, multicast requires a non-segmented provider tunnel for traffic to be routed from the root PE toward the receiver routers. This means that the tunnel must traverse multiple ASs without decapsulating and encapsulating labels at the AS boundaries, and therefore, must be non-segmented.
If the provider tunnel uses mLDP, the receivers initiate the signaling by sending an LDP label mapping message along the control path toward the root. This follows the path of the intra-AD route that advertises the root of the ingress PMSI (I-PMSI). An mLDP label mapping message consists of an allocated label L, with FEC element <X,Y>, where X identifies the root node and Y is the opaque value, so the P2MP label mapping can be denoted as <X,Y,L>.
The FEC element contains the root address of the LSP plus a variable-length opaque value. The opaque value contains information meaningful to the root and leaf routers, but not to intermediate routers; for example, a P2MP LSP ID or a nested opaque value.
The root address is the system address of PE-5 (the router that advertised the intra-AD route) which is reachable via ASBR-4.
However, in an mLDP environment, each router must take part in the signaling of the P2MP LSP, but not every router has an MVPN route, so any mLDP label mapping message received by P-2 to the root address of PE-5 is dropped. A solution to this is described in RFC 6512, Using Multipoint LDP When the Backbone Has No Route to the Root, as follows.
PE-1 signals an mLDP LSP as if the root is at ASBR-4. P-2 has a route to ASBR-4 because it participates in the IGP through the same IGP instance. The actual root address located in PE-5 is encapsulated in the mLDP label mapping message originated by PE-1 as an inner root address. This is a recursive FEC type 7; the root (PE-5) is encapsulated within a FEC element as an opaque value.
ASBR-4 receives the intra-AD MVPN route advertised by PE-5 with BGP next-hop ASBR-8.
mLDP Message Opaque Value Types in MVPN inter-AS Model C shows the opaque value types used in MVPN inter-AS model C.
Opaque Type |
Opaque Name |
Use |
FEC Element Representation |
---|---|---|---|
1 |
Generic |
VPRN local AS |
Root, Opaque<P2MP ID> |
7 |
Recursive FEC |
Inter-AS model C mLDP |
<ASBR, Opaque <Root, P2MP ID>> |
Configuration
Inter-AS MVPN Protocol Requirements shows the required protocol configuration and peering.
AS 64496
AS 64496 Protocols shows the protocol requirements for AS 64496.
Router Interface and IS-IS Configuration
The first step is to configure the router interfaces and IS-IS as the Interior Gateway Protocol (IGP) in AS 64496.
The router interfaces for PE-1 are configured as follows:
# on PE-1
configure {
router "Base" {
interface "int-PE-1-P-2" {
port 1/1/c1/1
ipv4 {
primary {
address 192.168.12.1
prefix-length 30
}
}
}
interface "int-PE-1-RR-3" {
port 1/1/c2/1
ipv4 {
primary {
address 192.168.13.1
prefix-length 30
}
}
}
interface "system" {
ipv4 {
primary {
address 192.0.2.1
prefix-length 32
}
}
}
}
}
Each interface is configured to run IS-IS as the IGP, as follows. Each router is configured as a level 2 router.
# on PE-1
configure {
router "Base" {
isis 0 {
admin-state enable
advertise-passive-only true
level-capability 2
area-address [49.0001]
interface "int-PE-1-P-2" {
interface-type point-to-point
}
interface "int-PE-1-RR-3" {
interface-type point-to-point
}
interface "system" {
passive true
}
level 2 {
wide-metrics-only true
}
}
}
}
The configuration for all other nodes in the AS is the same, other than the IP addresses. The IP addresses can be derived from Figure 1.
LDP Configuration
LDP is used as the MPLS protocol and must be enabled on each router interface, except for the VPN RR and the interfaces to the RR, as follows:
# on PE-1
configure {
router "Base" {
ldp {
interface-parameters {
interface "int-PE-1-P-2" {
ipv4 {
admin-state enable
fec-type-capability {
p2mp-ipv4 true
}
}
}
}
}
}
}
This configuration must be repeated on each of the other routers in the AS. Because LDP is used as the provider tunnel interface for multicast traffic, the previously indicated interfaces must also support P2MP LDP tunnels. Therefore, the FEC type capability for IPv4 P2MP tunnels must be enabled. The default value is enable, but is included in the preceding output for clarity.
BGP Configuration
RR-3 Configuration
RR-3 is the route reflector for the vpn-ipv4 and mvpn-ipv4 address families within AS 64496, and peers with PE-1, but not with ASBR-4 and P-2. The cluster ID is set to ensure that RR-3 is an RR. For supporting inter-AS VPRN model C, RR-3 also peers with RR-7 in AS 64497 for the same address families, through a multi-hop eBGP session.
# on RR-3
configure {
router "Base" {
autonomous-system 64496
bgp {
loop-detect discard-route
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
rapid-update {
vpn-ipv4 true
mvpn-ipv4 true
}
group "EBGP-vpn-mvpn" {
local-address 192.0.2.3
}
group "IBGP-vpn-mvpn" {
cluster {
cluster-id 192.0.2.3
}
}
neighbor "192.0.2.1" {
group "IBGP-vpn-mvpn"
peer-as 64496
family {
vpn-ipv4 true
mvpn-ipv4 true
}
}
neighbor "192.0.2.7" {
group "EBGP-vpn-mvpn"
multihop 10
peer-as 64497
family {
vpn-ipv4 true
mvpn-ipv4 true
}
}
}
}
}
ASBR-4 Configuration
Although ASBR-4 is the AS border router for AS 64496 (so that it peers with ASBR-8 in AS 64497), ASBR-4 is also configured as RR for the label-ipv4 address family within AS 64496, and peers with PE-1, as follows:
# on ASBR-4
configure {
router "Base" {
autonomous-system 64496
bgp {
loop-detect discard-route
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
rapid-update {
vpn-ipv4 true
mvpn-ipv4 true
}
rib-management {
label-ipv4 {
route-table-import {
policy-name "pol-imp-PE-and-RR-pfxs"
}
}
}
group "EBGP-label" { }
group "IBGP-label" {
cluster {
cluster-id 192.0.2.4
}
}
neighbor "192.0.2.1" {
group "IBGP-label"
peer-as 64496
family {
label-ipv4 true
}
}
neighbor "192.168.48.2" {
advertise-inactive true
group "EBGP-label"
peer-as 64497
family {
label-ipv4 true
}
export {
policy ["pol-exp-PE-and-RR-pfxs"]
}
}
}
}
}
The policies ensure that the system addresses of the PEs and the RRs are exchanged between AS 64496 and AS 64497. In this example, ASBR-4 generates the labeled routes but pops the label associated with RR-3; see the Pop-Label for /32 Label-IPv4 BGP routes chapter in the Unicast Routing Protocols volume of the 7450 ESS, 7750 SR, and 7950 XRS MD-CLI Advanced Configuration Guide - Part I.
# on ASBR-4
configure {
policy-options {
prefix-list "PE-pfxs" {
prefix 192.0.2.1/32 type exact { }
prefix 192.0.2.4/32 type exact { }
}
prefix-list "RR-pfxs" {
prefix 192.0.2.3/32 type exact { }
}
policy-statement "pol-exp-PE-and-RR-pfxs" {
entry 10 {
from {
prefix-list ["PE-pfxs" "RR-pfxs"]
}
action {
action-type accept
}
}
}
policy-statement "pol-imp-PE-and-RR-pfxs" {
entry 20 {
from {
prefix-list ["RR-pfxs"]
}
action {
action-type accept
advertise-label pop
}
}
entry 30 {
from {
prefix-list ["PE-pfxs"]
}
action {
action-type accept
}
}
}
}
}
PE-1 configuration
PE-1 is a BGP client of RR-3 and ASBR-4, as follows:
# on PE-1
configure {
router "Base" {
autonomous-system 64496
bgp {
loop-detect discard-route
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
rapid-update {
vpn-ipv4 true
mvpn-ipv4 true
}
group "IBGP-label" { }
group "IBGP-vpn-mvpn" { }
neighbor "192.0.2.3" {
group "IBGP-vpn-mvpn"
peer-as 64496
family {
vpn-ipv4 true
mvpn-ipv4 true
}
}
neighbor "192.0.2.4" {
group "IBGP-label"
peer-as 64496
family {
label-ipv4 true
}
}
}
}
}
P-2 does not have any BGP configuration; it participates in the MPLS data plane for switching unicast and multicast customer traffic, and does not have any services defined.
AS 64497
AS 64497 Protocols shows the protocol requirements for AS 64497.
Router Interface and OSPF Configuration
The first step is to configure router interfaces and OSPF on each router shown in AS 64497 Protocols. All router interfaces are members of a single backbone area: area 0.0.0.0.
The following router interfaces are configured on PE-5:
# on PE-5
configure {
router "Base" {
interface "int-PE-5-P-6" {
port 1/1/c2/1
ipv4 {
primary {
address 192.168.56.1
prefix-length 30
}
}
}
interface "int-PE-5-RR-7" {
port 1/1/c1/1
ipv4 {
primary {
address 192.168.57.1
prefix-length 30
}
}
}
interface "system" {
ipv4 {
primary {
address 192.0.2.5
prefix-length 32
}
}
}
}
}
On PE-5, OSPF is configured as follows:
# on PE-5
configure {
router "Base" {
ospf 0 {
admin-state enable
area 0.0.0.0 {
interface "int-PE-5-P-6" {
interface-type point-to-point
}
interface "int-PE-5-RR-7" {
interface-type point-to-point
}
interface "system" { }
}
}
}
}
LDP Configuration
LDP is used as the MPLS protocol and must be enabled on each router interface, except on the RR and the interfaces toward the RR, as follows:
# on PE-5
configure {
router "Base" {
ldp {
interface-parameters {
interface "int-PE-5-P-6" {
ipv4 {
admin-state enable
fec-type-capability {
p2mp-ipv4 true
}
}
}
}
}
}
}
This configuration must be repeated on each of the other routers in the AS, and the FEC type capability for IPv4 P2MP tunnels must again be enabled. The default value is enable, but is included in the preceding output for clarity.
BGP Configuration
The BGP configuration for AS 64497 is mirrored from AS 64496, so the configuration is similar, meaning that RR-7 is RR for the vpn-ipv4 and mvpn-ipv4 address families, and ASBR-8 is RR for the label-ipv4 address family, with PE-5 being the client. P-6 is not a BGP client for RR-7 and ASBR-8.
Inter-AS Configuration
Inter-AS Protocols shows the protocols required between ASBR-4 and ASBR-8. The interface addresses are used for the LDP transport and the BGP speaker peer addresses.
LDP Peering
LDP is configured as the MPLS protocol between ASBR-4 and ASBR-8. On ASBR-4, the interface toward ASBR-8 has LDP enabled, as follows. The interface address should be used as the LDP transport address because the system address of ASBR-8 is not known to ASBR-4.
# on ASBR-4
configure {
router "Base" {
ldp {
interface-parameters {
interface "int-ASBR-4-ASBR-8" {
admin-state enable
ipv4 {
admin-state enable
transport-address interface
fec-type-capability {
p2mp-ipv4 true
}
}
}
}
targeted-session { }
}
}
}
The P2MP FEC type capability for P2MP LDP is shown. This is the default value.
For completeness, the LDP configuration on ASBR-8 for the interface toward ASBR-4 is as follows:
# on ASBR-8
configure {
router "Base" {
ldp {
interface-parameters {
interface "int-ASBR-8-ASBR-4" {
admin-state enable
ipv4 {
admin-state enable
transport-address interface
fec-type-capability {
p2mp-ipv4 true
}
}
}
}
targeted-session { }
}
}
}
The LDP session is successfully established at ASBR-4, as follows:
[/]
A:admin@ASBR-4# show router ldp session 192.0.2.8
==============================================================================
LDP IPv4 Sessions
==============================================================================
Peer LDP Id Adj Type State Msg Sent Msg Recv Up Time
------------------------------------------------------------------------------
192.0.2.8:0 Link Established 141 143 0d 00:05:53
------------------------------------------------------------------------------
No. of IPv4 Sessions: 1
==============================================================================
===============================================================================
LDP IPv6 Sessions
===============================================================================
Peer LDP Id
Adj Type State Msg Sent Msg Recv Up Time
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
For completeness, the LDP session from ASBR-8 toward ASBR-4 is shown in the following output:
[/]
A:admin@ASBR-8# show router ldp session 192.0.2.4
==============================================================================
LDP IPv4 Sessions
==============================================================================
Peer LDP Id Adj Type State Msg Sent Msg Recv Up Time
------------------------------------------------------------------------------
192.0.2.4:0 Link Established 146 146 0d 00:06:01
------------------------------------------------------------------------------
No. of IPv4 Sessions: 1
==============================================================================
===============================================================================
LDP IPv6 Sessions
===============================================================================
Peer LDP Id
Adj Type State Msg Sent Msg Recv Up Time
-------------------------------------------------------------------------------
No Matching Entries Found
===============================================================================
When a label mapping message is received for an LDP FEC prefix, the next-hop for a FEC prefix is resolved in the routing table. The FEC is installed in the Label Information Base (LIB) if the next-hop matches a /32 route table entry.
The local interface configuration results in a route being installed with a subnet mask matching the interface configuration. In this case, the ASBR-to-ASBR route is 192.168.48.0/30.
For LDP to resolve the LDP FEC egress next-hop on ASBR-4, a /32 route matching the egress next-hop address is required in the FIB. For that purpose, on ASBR-4, a static route is configured for the /32 address located on ASBR-8, as follows:
# on ASBR-4
configure {
router "Base" {
static-routes {
route 192.168.48.2/32 route-type unicast {
next-hop "192.168.48.2" {
admin-state enable
}
}
}
}
}
Similarly, a static route on ASBR-8 is configured for the /32 address located on ASBR-4, as follows:
# on ASBR-8
configure {
router "Base" {
static-routes {
route 192.168.48.1/32 route-type unicast {
next-hop "192.168.48.1" {
admin-state enable
}
}
}
}
}
The following output shows that the static route is installed in the ASBR-4 Routing Information Base (RIB):
[/]
A:admin@ASBR-4# show router route-table protocol static
===============================================================================
Route Table (Router: Base)
===============================================================================
Dest Prefix[Flags] Type Proto Age Pref
Next Hop[Interface Name] Metric
-------------------------------------------------------------------------------
192.168.48.2/32 Remote Static 00h00m00s 5
192.168.48.2 1
-------------------------------------------------------------------------------
No. of Routes: 1
Flags: n = Number of times nexthop is repeated
B = BGP backup route available
L = LFA nexthop available
S = Sticky ECMP requested
===============================================================================
eBGP Peering - ASBR-4 to ASBR-8
The following shows the eBGP peering configuration for ASBR-4. The peer address is the interface address of ASBR-8.
# on ASBR-4
configure {
router "Base" {
autonomous-system 64496
bgp {
group "EBGP-label" { }
neighbor "192.168.48.2" {
advertise-inactive true
group "EBGP-label"
peer-as 64497
family {
label-ipv4 true
}
export {
policy ["pol-exp-PE-and-RR-pfxs"]
}
}
}
}
}
Similarly, the BGP configuration for ASBR-8 peering toward ASBR-4 is as follows:
# on ASBR-8
configure {
router "Base" {
autonomous-system 64497
bgp {
group "EBGP-label" { }
neighbor "192.168.48.1" {
advertise-inactive true
group "EBGP-label"
peer-as 64496
family {
label-ipv4 true
}
export {
policy ["pol-exp-PE-and-RR-pfxs"]
}
}
}
}
}
The BGP peering session between ASBR-4 and ASBR-8 is verified as follows. In this example, only label-ipv4 routes are exchanged.
[/]
A:admin@ASBR-4# show router bgp summary group "EBGP-label"
===============================================================================
BGP Router ID:192.0.2.4 AS:64496 Local AS:64496
===============================================================================
BGP Admin State : Up BGP Oper State : Up
Total Peers : 1
Total IPv4 Remote Rts : 0 Total IPv4 Rem. Active Rts : 0
Total IPv6 Remote Rts : 0 Total IPv6 Rem. Active Rts : 0
Total IPv4 Backup Rts : 0 Total IPv6 Backup Rts : 0
Total LblIpv4 Rem Rts : 3 Total LblIpv4 Rem. Act Rts : 3
Total LblIpv6 Rem Rts : 0 Total LblIpv6 Rem. Act Rts : 0
Total LblIpv4 Bkp Rts : 0 Total LblIpv6 Bkp Rts : 0
Total VPN-IPv4 Rem. Rts : 0 Total VPN-IPv4 Rem. Act. Rts: 0
Total VPN-IPv6 Rem. Rts : 0 Total VPN-IPv6 Rem. Act. Rts: 0
Total VPN-IPv4 Bkup Rts : 0 Total VPN-IPv6 Bkup Rts : 0
Total MVPN-IPv4 Rem Rts : 0 Total MVPN-IPv4 Rem Act Rts : 0
Total MVPN-IPv6 Rem Rts : 0 Total MVPN-IPv6 Rem Act Rts : 0
Total MDT-SAFI Rem Rts : 0 Total MDT-SAFI Rem Act Rts : 0
Total McIPv4 Remote Rts : 0 Total McIPv4 Rem. Active Rts: 0
Total McIPv6 Remote Rts : 0 Total McIPv6 Rem. Active Rts: 0
Total McVpnIPv4 Rem Rts : 0 Total McVpnIPv4 Rem Act Rts : 0
Total McVpnIPv6 Rem Rts : 0 Total McVpnIPv6 Rem Act Rts : 0
Total EVPN Rem Rts : 0 Total EVPN Rem Act Rts : 0
Total L2-VPN Rem. Rts : 0 Total L2VPN Rem. Act. Rts : 0
Total MSPW Rem Rts : 0 Total MSPW Rem Act Rts : 0
Total RouteTgt Rem Rts : 0 Total RouteTgt Rem Act Rts : 0
Total FlowIpv4 Rem Rts : 0 Total FlowIpv4 Rem Act Rts : 0
Total FlowIpv6 Rem Rts : 0 Total FlowIpv6 Rem Act Rts : 0
Total FlowVpnv4 Rem Rts : 0 Total FlowVpnv4 Rem Act Rts : 0
Total FlowVpnv6 Rem Rts : 0 Total FlowVpnv6 Rem Act Rts : 0
Total Link State Rem Rts: 0 Total Link State Rem Act Rts: 0
Total SrPlcyIpv4 Rem Rts: 0 Total SrPlcyIpv4 Rem Act Rts: 0
Total SrPlcyIpv6 Rem Rts: 0 Total SrPlcyIpv6 Rem Act Rts: 0
===============================================================================
BGP Summary
===============================================================================
Legend : D - Dynamic Neighbor
===============================================================================
Neighbor
Description
AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
-------------------------------------------------------------------------------
192.168.48.2
64497 18 0 00h05m42s 3/3/3 (Lbl-IPv4)
18 0
-------------------------------------------------------------------------------
eBGP Peering - RR-3 to RR-7
The following shows the configuration required for establishing an eBGP multi-hop peering session from RR-3 to RR-7. The peer address is the system address of RR-7.
# on RR-3
configure {
router "Base" {
static-routes {
route 192.0.2.7/32 route-type unicast {
indirect 192.0.2.4 {
admin-state enable
tunnel-next-hop {
resolution none
}
}
}
}
autonomous-system 64496
bgp {
loop-detect discard-route
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
rapid-update {
vpn-ipv4 true
mvpn-ipv4 true
}
group "EBGP-vpn-mvpn" {
local-address 192.0.2.3
}
---snip---
neighbor "192.0.2.7" {
group "EBGP-vpn-mvpn"
multihop 10
peer-as 64497
family {
vpn-ipv4 true
mvpn-ipv4 true
}
}
}
}
}
Similarly, the BGP configuration for RR-7 multi-hop peering with RR-3 is as follows:
# on RR-7
configure {
router "Base" {
static-routes {
route 192.0.2.3/32 route-type unicast {
indirect 192.0.2.8 {
admin-state enable
tunnel-next-hop {
resolution none
}
}
}
}
autonomous-system 64497
bgp {
loop-detect discard-route
rapid-withdrawal true
split-horizon true
ebgp-default-reject-policy {
import false
export false
}
rapid-update {
vpn-ipv4 true
mvpn-ipv4 true
}
group "EBGP-vpn-mvpn" {
local-address 192.0.2.7
}
neighbor "192.0.2.3" {
group "EBGP-vpn-mvpn"
multihop 10
peer-as 64496
family {
vpn-ipv4 true
mvpn-ipv4 true
}
}
---snip---
}
}
}
This peering session is verified as follows. Only vpn-ipv4 and mvpn-ipv4 routes are exchanged.
[/]
A:admin@RR-3# show router bgp summary group "EBGP-vpn-mvpn"
===============================================================================
BGP Router ID:192.0.2.3 AS:64496 Local AS:64496
===============================================================================
BGP Admin State : Up BGP Oper State : Up
Total Peers : 1
Total IPv4 Remote Rts : 0 Total IPv4 Rem. Active Rts : 0
Total IPv6 Remote Rts : 0 Total IPv6 Rem. Active Rts : 0
Total IPv4 Backup Rts : 0 Total IPv6 Backup Rts : 0
Total LblIpv4 Rem Rts : 0 Total LblIpv4 Rem. Act Rts : 0
Total LblIpv6 Rem Rts : 0 Total LblIpv6 Rem. Act Rts : 0
Total LblIpv4 Bkp Rts : 0 Total LblIpv6 Bkp Rts : 0
Total VPN-IPv4 Rem. Rts : 1 Total VPN-IPv4 Rem. Act. Rts: 0
Total VPN-IPv6 Rem. Rts : 0 Total VPN-IPv6 Rem. Act. Rts: 0
Total VPN-IPv4 Bkup Rts : 0 Total VPN-IPv6 Bkup Rts : 0
Total MVPN-IPv4 Rem Rts : 1 Total MVPN-IPv4 Rem Act Rts : 0
Total MVPN-IPv6 Rem Rts : 0 Total MVPN-IPv6 Rem Act Rts : 0
Total MDT-SAFI Rem Rts : 0 Total MDT-SAFI Rem Act Rts : 0
Total McIPv4 Remote Rts : 0 Total McIPv4 Rem. Active Rts: 0
Total McIPv6 Remote Rts : 0 Total McIPv6 Rem. Active Rts: 0
Total McVpnIPv4 Rem Rts : 0 Total McVpnIPv4 Rem Act Rts : 0
Total McVpnIPv6 Rem Rts : 0 Total McVpnIPv6 Rem Act Rts : 0
Total EVPN Rem Rts : 0 Total EVPN Rem Act Rts : 0
Total L2-VPN Rem. Rts : 0 Total L2VPN Rem. Act. Rts : 0
Total MSPW Rem Rts : 0 Total MSPW Rem Act Rts : 0
Total RouteTgt Rem Rts : 0 Total RouteTgt Rem Act Rts : 0
Total FlowIpv4 Rem Rts : 0 Total FlowIpv4 Rem Act Rts : 0
Total FlowIpv6 Rem Rts : 0 Total FlowIpv6 Rem Act Rts : 0
Total FlowVpnv4 Rem Rts : 0 Total FlowVpnv4 Rem Act Rts : 0
Total FlowVpnv6 Rem Rts : 0 Total FlowVpnv6 Rem Act Rts : 0
Total Link State Rem Rts: 0 Total Link State Rem Act Rts: 0
Total SrPlcyIpv4 Rem Rts: 0 Total SrPlcyIpv4 Rem Act Rts: 0
Total SrPlcyIpv6 Rem Rts: 0 Total SrPlcyIpv6 Rem Act Rts: 0
===============================================================================
BGP Summary
===============================================================================
Legend : D - Dynamic Neighbor
===============================================================================
Neighbor
Description
AS PktRcvd InQ Up/Down State|Rcv/Act/Sent (Addr Family)
PktSent OutQ
-------------------------------------------------------------------------------
192.0.2.7
64497 77 0 00h35m53s 1/0/1 (VpnIPv4)
78 0 1/0/2 (MvpnIPv4)
-------------------------------------------------------------------------------
VPRN Configuration
The VPRN service configuration for PE-1 and PE-5 is as follows:
# on PE-1
configure {
service {
vprn "VPRN 1" {
admin-state enable
service-id 1
customer "1"
igmp {
interface "int-PE-1-VPRN-1-H-1" {
version 3 # default
ssm-translate {
group-range start 239.255.0.0 end 239.255.255.255 {
source 172.16.5.2 { }
}
}
static {
group 239.255.0.1 {
starg
}
}
}
}
pim { }
mvpn {
c-mcast-signaling bgp
mdt-type receiver-only
auto-discovery {
type bgp
}
intersite-shared {
admin-state disable
}
vrf-target {
unicast true
}
provider-tunnel {
inclusive {
mldp {
admin-state enable
}
}
}
}
bgp-ipvpn {
mpls {
admin-state enable
route-distinguisher "64496:1"
vrf-target {
import-community "target:64497:1"
export-community "target:64496:1"
}
auto-bind-tunnel {
resolution filter
resolution-filter {
ldp true
}
}
}
}
interface "int-PE-1-VPRN-1-H-1" {
ipv4 {
primary {
address 172.16.1.1
prefix-length 30
}
}
sap 1/1/c3/1 { }
}
}
}
}
# on PE-5
configure {
service {
vprn "VPRN 1" {
admin-state enable
service-id 1
customer "1"
igmp {
interface "int-PE-5-VPRN-1-S-5" {
version 3 # default
}
}
pim {
interface "int-PE-5-VPRN-1-S-5" { }
}
mvpn {
c-mcast-signaling bgp
mdt-type sender-only
auto-discovery {
type bgp
}
intersite-shared {
admin-state disable
}
vrf-target {
unicast true
}
provider-tunnel {
inclusive {
mldp {
admin-state enable
}
}
}
}
bgp-ipvpn {
mpls {
admin-state enable
route-distinguisher "64497:1"
vrf-target {
import-community "target:64496:1"
export-community "target:64497:1"
}
auto-bind-tunnel {
resolution filter
resolution-filter {
ldp true
}
}
}
}
interface "int-PE-5-VPRN-1-S-5" {
ipv4 {
primary {
address 172.16.5.1
prefix-length 30
}
}
sap 1/1/c3/1 { }
}
}
}
}
Route Policy for MVPN Routes
The use of non-segmented LDP provider tunnels requires that intra-AD routes must be advertised across the AS boundary between PEs. Each intra-AD route generated by a PE that is a member of an MVPN contains the well-known community "No-Export", which prevents a BGP speaker from advertising the route across an AS boundary to another external BGP speaker.
In inter-AS model C, the RRs must support the MVPN address family. If the RR receives an intra-AD route containing the No-Export community, this route is not advertised to any external peer. A route policy is required to remove the No-Export community before the route can be advertised across the AS boundary to a BGP speaker that has negotiated the MVPN address family capability.
In the following example, a RemNoExport policy is defined, which removes the No-Export community, using the community remove action as a default action:
# on PE-1 and PE-5
configure {
policy-options {
community "NoExport" {
member "no-export" { }
}
policy-statement "RemNoExport" {
default-action {
action-type accept
community {
remove ["NoExport"]
}
}
}
}
}
This policy is applied as an export policy, so that the No-Export community is removed from all intra-AD routes advertised as updates to internal peers. The vpn-apply-export command must be included to ensure that the export policy is applied to routes belonging to VPN address families; in this case, mvpn-ipv4 routes.
# on PE-5
configure {
router "Base" {
bgp {
group "IBGP-vpn-mvpn" { }
neighbor "192.0.2.7" {
group "IBGP-vpn-mvpn"
vpn-apply-export true
peer-as 64497
family {
vpn-ipv4 true
mvpn-ipv4 true
}
export {
policy ["RemNoExport"]
}
}
}
}
}
This policy should also be configured and applied on PE-1, so that intra-AD routes can be exported from MVPN PEs in AS 64496 to AS 64497.
Verification
BGP MVPN Intra-AD Route Propagation
BGP MVPN Intra-AD Route Advertisement shows the propagation of the BGP MVPN intra-AD route from PE-5 to PE-1 across the AS boundary. The original route has the No-Export community removed on PE-5, because the export route policy is applied. RR-3 receives the route via RR-7 and reflects it to PE-1. The BGP next-hop attribute is changed by RR-7 to its system address: 192.0.2.7. RR-3 reflects the intra-AD route to PE-1, also changing the BGP next-hop attribute to its system address: 192.0.2.3.
PE-1 receives the route, and imports the route into VPRN 1 because the route target extended community matches the community configured in the MVPN context of the VPRN. PE-1 now uses the PTA contained within the intra-AD route to instantiate the provider tunnel.
The following output shows details of the MVPN intra-AD route received by PE-1, generated by PE-5:
[/]
A:admin@PE-1# show router bgp routes mvpn-ipv4 type intra-ad originator-ip 192.0.2.5 hunt
===============================================================================
BGP Router ID:192.0.2.1 AS:64496 Local AS:64496
===============================================================================
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. : 64497:1
Originator IP : 192.0.2.5
Nexthop : 192.0.2.3
Path Id : None
From : 192.0.2.3
Res. Nexthop : 0.0.0.0
Local Pref. : 100 Interface Name : NotAvailable
Aggregator AS : None Aggregator : None
Atomic Aggr. : Not Atomic MED : None
AIGP Metric : None IGP Cost : n/a
Connector : None
Community : target:64497:1
Cluster : No Cluster Members
Originator Id : None Peer Router Id : 192.0.2.3
Origin : IGP
Flags : Used Valid Best
Route Source : Internal
AS-Path : 64497
Route Tag : 0
Neighbor-AS : 64497
DB Orig Val : N/A Final Orig Val : N/A
Source Class : 0 Dest Class : 0
Add Paths Send : Default
Last Modified : 00h10m39s
VPRN Imported : 1
-------------------------------------------------------------------------------
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.5 LSP-ID : 8193
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
RIB Out Entries
-------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Routes : 1
===============================================================================
P2MP LDP LSP Signaling
The PTA lists the tunnel type as an LDP P2MP LSP. A P2MP label mapping message is originated on PE-1, with LSP ID 8193, with inner-root PE-5 and outer-root ASBR-4.
The intra-AD MVPN route is used to determine the path of the label mapping message from PE-1 toward PE-5. This is similar to the unicast routing case, where a vpn-ipv4 labeled route is used to determine the path to the source.
The BGP next-hop of the intra-AD route is the system address of ASBR-4, so this can be used as the root address of the mLDP LSP, and the actual root can be contained inside the label mapping message as an inner root. The inner root becomes an opaque value that is known to the originator and receiver of the label mapping message. PE-1 thus generates a recursive-opaque type=7 FEC: <ASBR-4, <PE-5, P2MP-id>>.
P2MP LDP Label Mapping shows the path taken by the label mapping message from PE-1 to PE-5.
P-2 does not have a BGP-LBL route to reach PE-5, but has an IGP route to reach the outer root ASBR-4. The label mapping message is forwarded from PE-1 to ASBR-4 via P-2. At each hop, a label is allocated and a label binding entry is created. In the following sections, the debug outputs are achieved using the following debug command:
debug
router "Base"
ldp
peer <peer-ip-address>
packet
label detail
exit
exit
exit
exit
exit
where <peer-ip-address> is the system address of the LDP peer.
LDP Hop PE-1 to P-2
The following output shows a debug of the P2MP label mapping message sent from PE-1 to P-2 upon receipt of the BGP MVPN intra-AD route:
7 2024/02/22 11:55:11.121 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Send Label Mapping packet (msgId 279) to 192.0.2.2:0
Protocol version = 1
Label 524284 advertised for the following FECs
P2MP: root = 192.0.2.4, T: 7, L: 17 (InnerRoot: 192.0.2.5 T: 1, L: 4, TunnelId: 8193)
"
The advertised label is 524284: the ingress label on PE-1. The P2MP root address is the next hop for the BGP-LBL route to reach PE-5 (192.0.2.5), namely ASBR-4 (192.0.2.4). T: 7 signifies that the FEC type is 7, GRT-recursive FEC, and L: 17 is the length of the opaque value. The opaque value contains the inner root 192.0.2.5 and a second opaque value: a type 1 (T: 1) generic FEC of length L = 4 bytes, containing the tunnel ID 8193.
The format of the type 7 opaque value aligns with the representation in Table 1:
<ASBR-4, Opaque type 7 <PE-5, Opaque type 1 <Tunnel-ID>>>.
The LDP binding table of PE-1 is shown in the following output:
[/]
A:admin@PE-1# show router ldp bindings active p2mp ipv4 opaque-type grt-recursive
===============================================================================
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 GRT Recursive with Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id
InnerRootAddr Interface
RootAddr Op
IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193
192.0.2.5 73728
192.0.2.4 Pop
524284 --
-- --
-------------------------------------------------------------------------------
No. of GRT Recursive with Generic IPv4 P2MP Active Bindings: 1
===============================================================================
The preceding output shows the GRT-recursive FEC binding with both the root address of ASBR-4 and the inner root address of PE-5.
LDP Hop P-2 to ASBR-4
At P-2, the label mapping messages received from PE-1 and advertised toward ASBR-4 are shown in the following output:
1 2024/02/22 11:55:10.965 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Recv Label Mapping packet (msgId 279) from 192.0.2.1:0
Protocol version = 1
Label 524284 advertised for the following FECs
P2MP: root = 192.0.2.4, T: 7, L: 17 (InnerRoot: 192.0.2.5 T: 1, L: 4, TunnelId: 8193)
"
2 2024/02/22 11:55:10.965 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Send Label Mapping packet (msgId 273) to 192.0.2.4:0
Protocol version = 1
Label 524284 advertised for the following FECs
P2MP: root = 192.0.2.4, T: 7, L: 17 (InnerRoot: 192.0.2.5 T: 1, L: 4, TunnelId: 8193)
"
The received message matches the advertised label from PE-1, and the label mapping message toward ASBR-4 (192.0.2.4) is again a GRT-recursive FEC type.
The following output shows the LDP label mapping for the GRT-recursive FEC on P-2:
[/]
A:admin@P-2# show router ldp bindings active p2mp ipv4 opaque-type grt-recursive
===============================================================================
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 GRT Recursive with Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id
InnerRootAddr Interface
RootAddr Op
IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193
192.0.2.5 Unknw
192.0.2.4 Swap
524284 524284
192.168.12.1 1/1/c2/1
-------------------------------------------------------------------------------
No. of GRT Recursive with Generic IPv4 P2MP Active Bindings: 1
===============================================================================
LDP Hop ASBR-4 to ASBR-8
ASBR-4 is the root of the mLDP tree in AS 64496. Upon receipt of an mLDP label mapping message containing this FEC element, ASBR-4 recognizes that it is the root and that the opaque value is a GRT-recursive opaque value. ASBR-4 parses the GRT-recursive opaque value and extracts the root value: PE-5.
ASBR-4 checks RTM for a route to reach the inner-root (PE-5), which is a BGP-LBL route with next-hop ASBR-8.
ASBR-4 creates an mLDP mapping message containing a GRT-recursive FEC whose opaque value has the inner root address of PE-5, and a root address of ASBR-8.
The following output shows the label mapping messages at ASBR-4:
1 2024/02/22 11:55:11.094 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Recv Label Mapping packet (msgId 273) from 192.0.2.2:0
Protocol version = 1
Label 524284 advertised for the following FECs
P2MP: root = 192.0.2.4, T: 7, L: 17 (InnerRoot: 192.0.2.5 T: 1, L: 4, TunnelId: 8193)
"
2 2024/02/22 11:55:11.094 UTC MINOR: DEBUG #2001 Base LDP
"LDP: Binding
Sending Label mapping label 524277 for P2MP: root = 192.168.48.2, T: 7, L: 17
(InnerRoot: 192.0.2.5 T: 1, L: 4, TunnelId: 8193)
to peer 192.0.2.8:0."
3 2024/02/22 11:55:11.094 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Send Label Mapping packet (msgId 245) to 192.0.2.8:0
Protocol version = 1
Label 524277 advertised for the following FECs
P2MP: root = 192.168.48.2, T: 7, L: 17 (InnerRoot: 192.0.2.5 T: 1, L: 4, TunnelId: 8193)
"
The label mapping message uses a format of the opaque type listed in mLDP Message Opaque Value Types in MVPN inter-AS Model C, where the new root is now ASBR-8, and the inner root address remains the PE-5 system address:
<ASBR-8, Opaque type 7 <PE-5, Opaque type 1 <Tunnel-ID>>>
At ASBR-4, the root changes from ASBR-4 to ASBR-8. ASBR-4 essentially becomes a leaf node with root at ASBR-8.
The following output shows the label binding output at ASBR-4:
[/]
A:admin@ASBR-4# show router ldp bindings active p2mp ipv4 opaque-type grt-recursive
===============================================================================
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 GRT Recursive with Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id
InnerRootAddr Interface
RootAddr Op
IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193
192.0.2.5 Unknw
192.0.2.4 (LF) Push
-- 524284
192.168.24.1 1/1/c2/1
8193
192.0.2.5 Unknw
192.168.48.2 (UF) Swap
524277 Stitched
-- --
-------------------------------------------------------------------------------
No. of GRT Recursive with Generic IPv4 P2MP Active Bindings: 2
===============================================================================
The label binding message received from the downstream router P-2 is known as the Lower FEC (LF). The label binding message forwarded to ASBR-8 has allocated a label and is stored as the Upper FEC (UF).
To create a non-segmented mLDP LSP, a label swap action must occur at ASBR-4, where the leaf of the P2MP LSP that has a root at ASBR-8 must be stitched to the P2MP LSP that has a root at ASBR-4 and leaf on PE-1. To achieve this, the UF label is swapped with the LF label. This stitching action is shown in the EgrLbl field of the UF entry.
LDP Hop ASBR-8 to P-6
ASBR-8 receives the label mapping message from ASBR-4. This contains a label mapping plus the opaque value with a GRT-recursive FEC type 7. The root address is a local address, so the recursive FEC is parsed and the root address of PE-5 is extracted.
1 2024/02/22 11:55:10.887 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Recv Label Mapping packet (msgId 245) from 192.0.2.4:0
Protocol version = 1
Label 524277 advertised for the following FECs
P2MP: root = 192.168.48.2, T: 7, L: 17 (InnerRoot: 192.0.2.5 T: 1, L: 4, TunnelId: 8193)
"
ASBR-8 has an IGP route to the PE-5 address (192.0.2.5) in the forwarding table.
Therefore, ASBR-8 constructs an mLDP label mapping message with FEC element containing the address of PE-5 as the root address. This is shown in the following output, where the opaque type is type 1. The opaque value is the tunnel ID contained in the original intra-AD MVPN route, which was contained int the lower FEC received from ASBR-4.
2 2024/02/22 11:55:10.887 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Send Label Mapping packet (msgId 260) to 192.0.2.6:0
Protocol version = 1
Label 524277 advertised for the following FECs
P2MP: root = 192.0.2.5, T: 1, L: 4, TunnelId: 8193
"
This aligns with the representation for generic FEC type 1 from Table 1:
<PE-5 Opaque type 1 <Tunnel-ID>>.
The following output taken from ASBR-8 shows the stitching of the recursive label mapping received from ASBR-4 to the generic IPv4 label mapping sent to P-6. The LF label received from ASBR-4 (524277) is stitched to the UF label (524277) via the common root address of 192.0.2.5.
[/]
A:admin@ASBR-8# show router ldp bindings active p2mp ipv4
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.8)
(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.5 (UF) Swap
524277 Stitched
-- --
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 1
===============================================================================
---snip---
===============================================================================
LDP GRT Recursive with Generic IPv4 P2MP Bindings (Active)
===============================================================================
P2MP-Id
InnerRootAddr Interface
RootAddr Op
IngLbl EgrLbl
EgrNH EgrIf/LspId
-------------------------------------------------------------------------------
8193
192.0.2.5 Unknw
192.168.48.2 (LF) Push
-- 524277
192.168.48.1 1/1/c3/1
-------------------------------------------------------------------------------
No. of GRT Recursive with Generic IPv4 P2MP Active Bindings: 1
===============================================================================
LDP Hop P-6 to PE-5
At P-6, the label mapping messages received from ASBR-8 and advertised toward PE-5 are shown in the following output:
1 2024/02/22 11:55:10.399 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Recv Label Mapping packet (msgId 260) from 192.0.2.8:0
Protocol version = 1
Label 524277 advertised for the following FECs
P2MP: root = 192.0.2.5, T: 1, L: 4, TunnelId: 8193
"
2 2024/02/22 11:55:10.399 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Send Label Mapping packet (msgId 266) to 192.0.2.5:0
Protocol version = 1
Label 524284 advertised for the following FECs
P2MP: root = 192.0.2.5, T: 1, L: 4, TunnelId: 8193
"
The following output on P-6 shows the LDP label mapping for this FEC:
[/]
A:admin@P-6# show router ldp bindings active p2mp ipv4 opaque-type generic
===============================================================================
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.5 Swap
524284 524277
192.168.68.2 1/1/c2/1
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 1
===============================================================================
PE-5
Finally, the following debug output on PE-5 shows the receipt of the mLDP label mapping message sent by P-6, which contains the system address of PE-5 as the root address:
6 2024/02/22 11:55:10.392 UTC MINOR: DEBUG #2001 Base LDP
"LDP: LDP
Recv Label Mapping packet (msgId 266) from 192.0.2.6:0
Protocol version = 1
Label 524284 advertised for the following FECs
P2MP: root = 192.0.2.5, T: 1, L: 4, TunnelId: 8193
"
The label binding output on PE-5 shows that the operation is a push operation. This is expected because PE-5 is the root node of the P2MP LSP.
[/]
A:admin@PE-5# show router ldp bindings active p2mp ipv4 opaque-type generic
===============================================================================
LDP Bindings (IPv4 LSR ID 192.0.2.5)
(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.5 Push
-- 524284
192.168.56.2 1/1/c2/1
-------------------------------------------------------------------------------
No. of Generic IPv4 P2MP Active Bindings: 1
===============================================================================
PIM status
Traffic is forwarded into multicast group 239.255.0.1 from the source using address 172.16.5.2.
An IGMPv3 group membership report is generated by the receiver and is shown on PE-1:
[/]
A:admin@PE-1# show router "1" igmp group
===============================================================================
IGMP Interface Groups
===============================================================================
(*,239.255.0.1) UpTime: 0d 00:14:40
Fwd List : int-PE-1-VPRN-1-H-1
-------------------------------------------------------------------------------
Entries : 1
===============================================================================
IGMP Host Groups
===============================================================================
No Matching Entries
===============================================================================
IGMP SAP Groups
===============================================================================
No Matching Entries
===============================================================================
IGMP SLA Profile Instance Groups
===============================================================================
No Matching Entries
===============================================================================
The status of the PIM group for VPRN 1 for multicast group 239.255.0.1 is shown in the following output:
[/]
A:admin@PE-1# show router "1" pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address : 239.255.0.1
Source Address : 172.16.5.2
RP Address : 0
Advt Router : 192.0.2.5
Flags : Type : (S,G)
Mode : sparse
MRIB Next Hop : 192.0.2.5
MRIB Src Flags : remote
Keepalive Timer : Not Running
Up Time : 0d 00:14:40 Resolved By : rtable-u
Up JP State : Joined Up JP Expiry : 0d 00:00:56
Up JP Rpt : Not Joined StarG Up JP Rpt Override : 0d 00:00:00
Register State : No Info
Reg From Anycast RP: No
Rpf Neighbor : 192.0.2.5
Incoming Intf : mpls-if-73728
Outgoing Intf List : int-PE-1-VPRN-1-H-1
Curr Fwding Rate : 78.560 kbps
Forwarded Packets : 7830 Discarded Packets : 0
Forwarded Octets : 7689060 RPF Mismatches : 0
Spt threshold : 0 kbps ECMP opt threshold : 7
Admin bandwidth : 1 kbps
-------------------------------------------------------------------------------
Groups : 1
===============================================================================
The incoming interface is an MPLS interface: mpls-if-73728. This is a PIM tunnel interface, as shown in the following output:
[/]
A:admin@PE-1# show router "1" pim tunnel-interface
===============================================================================
PIM Interfaces ipv4
===============================================================================
Interface Originator Address Adm Opr Transport Type
-------------------------------------------------------------------------------
mpls-if-73728 192.0.2.5 Up Up Rx-IPMSI
mpls-virt-if-1005857 192.0.2.1 Up Up Tx-IPMSI
-------------------------------------------------------------------------------
Interfaces : 2
===============================================================================
The originator address is 192.0.2.5, which is the root address of the mLDP tunnel on PE-5 — the non-segmented mLDP tunnel.
For completeness, the PIM status of the multicast group 239.255.0.1 on PE-5 is as follows:
[/]
A:admin@PE-5# show router "1" pim group detail
===============================================================================
PIM Source Group ipv4
===============================================================================
Group Address : 239.255.0.1
Source Address : 172.16.5.2
RP Address : 0
Advt Router : 192.0.2.5
Flags : Type : (S,G)
Mode : sparse
MRIB Next Hop : 172.16.5.2
MRIB Src Flags : direct
Keepalive Timer : Not Running
Up Time : 0d 00:13:15 Resolved By : rtable-u
Up JP State : Joined Up JP Expiry : 0d 00:00:00
Up JP Rpt : Not Joined StarG Up JP Rpt Override : 0d 00:00:00
Register State : No Info
Reg From Anycast RP: No
Rpf Neighbor : 172.16.5.2
Incoming Intf : int-PE-5-VPRN-1-S-5
Outgoing Intf List : mpls-if-73728
Curr Fwding Rate : 78.560 kbps
Forwarded Packets : 7951 Discarded Packets : 0
Forwarded Octets : 7807882 RPF Mismatches : 0
Spt threshold : 0 kbps ECMP opt threshold : 7
Admin bandwidth : 1 kbps
-------------------------------------------------------------------------------
Groups : 1
===============================================================================
Conclusion
Inter-AS model C multicast within a VPRN can be achieved using non-segmented mLDP trees. This chapter provides the configuration for inter-AS model C MVPN. The example also shows the associated commands, debug, and outputs, which can be used for verifying and troubleshooting.