# Profile 7

Load **basic.startup.config.with.cpim.cfg**

```
#IOS-XE
config replace flash:basic.startup.config.global.table.cfg
Y

#IOS-XR
configure
load bootflash:basic.startup.config.global.table.cfg
commit replace
y
```

The PE-CE links are now placed in the global table. All VRF config has been removed.

PIM adjacencies are not setup in the core. Use mLDP to transport multicast traffic in the core without the use of P-PIM.

## Answer <a href="#b158b2d7-cd66-4a03-bf20-ceb482096920" id="b158b2d7-cd66-4a03-bf20-ceb482096920"></a>

```
#PE1, PE2
ip multicast-routing distributed
ip multicast mpls mldp
ip pim mpls source lo0
!
int Gi3
 ip pim sparse-mode 

#P1, P2
mpls ldp mldp add ipv4

#PE3
mpls ldp mldp add ipv4
!
multicast-routing
 address-family ipv4
  mdt source Loopback0
  mdt mldp in-band-signaling ipv4
!
route-policy USE_MLDP_INBAND
  set core-tree mldp-inband
end-policy
!
router pim
 address-family ipv4
  rpf topology route-policy USE_MLDP_INBAND

#CE1, CE2, CE3, PE1, PE2
ip pim ssm default
```

## Explanation <a href="#id-262c71ec-87fc-4118-8ac1-d64f44631361" id="id-262c71ec-87fc-4118-8ac1-d64f44631361"></a>

Profile 7 is just profile 6 (mLDP with in-band signaling) but in the global table instead of in a VRF. The configuration is the same, except you do not reference a VRF on the PEs.

```
#IOS-XE
ip multicast mpls mldp
ip pim mpls source lo0

#IOS-XR
mpls ldp mldp add ipv4
!
multicast-routing
 address-family ipv4
  mdt source Loopback0
  mdt mldp in-band-signaling ipv4
!
route-policy USE_MLDP_INBAND
  set core-tree mldp-inband
end-policy
!
router pim
 address-family ipv4
  rpf topology route-policy USE_MLDP_INBAND
```

Remember that using mLDP with in-band signaling requires that SSM is used. This is because there is no default MDT, so RP information cannot be propagated to all participating PEs via BSR. For this reason, ASM (\*, G) entries are not translated into a P2MP tree. Instead, only (S, G) PIM joins are translated into an mLDP opaque value.

Let’s verify by joining a group on one of the hosts.

```
#CE3
int Gi3
 ip igmp ver 3

#C3
int gi0/1
 ip igmp ver 3
 ip igmp join-group 232.3.3.3 so 10.1.1.10
```

As expected, a PIM Join makes its way to PE3. The IIF is the auto-generated Imdtdefault interface. The RPF neighbor is found by doing a route lookup on the source. The BGP nexthop is used to determine the RPF neighbor in the core. Note that this requires the rpf topology fixup that uses mLDP instead of the default PIM for the RPF check on IOS-XR.

<div align="left"><figure><img src="/files/XYxPYX2ObKnXl8vm5GM4" alt=""><figcaption></figcaption></figure></div>

PE3 creates a mLDP P2MP FEC rooted at 1.1.1.1. The opaque ID value simply contains the (S, G) and the IPv4 address-family. This is not VPNv4 as we saw in profile 6, so an RD is not required.

<div align="left"><figure><img src="/files/lJbkZlslhjYKRlfi5aDX" alt=""><figcaption></figcaption></figure></div>

The tree is built hop by hop to the root, PE1.

<div align="left"><figure><img src="/files/fS4v9enhJVMHDVHebqAj" alt=""><figcaption></figcaption></figure></div>

PE1 extracts the customer (S, G) from the opaque value and converts this to a PIM Join, which is sent to CE1.

<div align="left"><figure><img src="/files/Go5eOtaPu4wpSER89pWe" alt=""><figcaption></figcaption></figure></div>

If we ping this group from C1, we see that C3 reponds:

<div align="left"><figure><img src="/files/dAttsGQYk8S5KX3JQzqV" alt=""><figcaption></figcaption></figure></div>

## Summary <a href="#id-57a10345-8969-49dd-80d6-7e475053e12c" id="id-57a10345-8969-49dd-80d6-7e475053e12c"></a>

Profile 7 is said to be used for a service provider’s IPTV “walled garden” deployment. “Walled garden” is another term for closed platform, meaning the IPTV exists only within the service provider’s AS and for its own customers. The service provider runs multicast in the global table, but does not want to run simple IP multicast in the core. Instead, mLDP is used, and in-band signaling is used within mLDP to signal SSM state. The advantage to using mLDP over PIM in the provider core is that you can use FRR mechanisms to protect against link failures. Additionally, if the provider is already running LDP anyways, it is simply to enable mLDP instead of turning on an additional protocol (PIM) in the core.

In-band mLDP profile 7 is useful for a service provider’s own IPTV deployment, because the amount of mLDP trees is predictable. The amount of IPTV channels is fixed. There is a tree per (S, G) flow, but the SP is in control of this. Profile 6 for mVPNs is not very popular (using in-band signaling for mVPNs for VRFs), because you cannot predict how much mLDP state will be created from your customers. (Each customer (S, G) flow creates an mLDP tree). Instead, profile 6 would be used if you are running the IPTV in a VRF, not usually to provide a multicast VPN service to customers.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://ccie-sp.gitbook.io/ccie-spv5.1-labs/labs/mvpn/profile-7.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.