# SR OAM DPM

Load **top2.sdn.transport.init.cfg** in topology1.

```
#XR1-11
configure
load top2.sdn.transport.init.cfg
commit replace
y

#IOS-XE
config replace bootflash:top2.sdn.transport.init.cfg
```

<figure><img src="/files/PeFuYh8RCWFLqpnRrHNp" alt=""><figcaption></figcaption></figure>

SR-MPLS using ISIS is already configured.

Configure data plane monitoring on XR3 so that all adjacency SIDs and prefix SIDs are tested every 1 minute for correct ingress and egress forwarding. Limit the testing to 20 pps.

Note that this lab requires XRv9000 to fully work properly (at least for XR3).

## Answer <a href="#id-4f22ffe5-31c3-4133-8aec-80bbf5470bfa" id="id-4f22ffe5-31c3-4133-8aec-80bbf5470bfa"></a>

```
#All XR routers
mpls oam

#XR3
mpls oam
 dpm
  pps 20
  interval 1
```

## Explanation <a href="#c373fda8-041f-41e4-9b30-7d04002b832c" id="c373fda8-041f-41e4-9b30-7d04002b832c"></a>

MPLS OAM DPM for SR is a fairly simple mechanism used to detect forwarding issues. DPM stands for data plane monitoring. First the process will perform an Adj-SID check for every Adj-SID of its directly connected neighbors. The router simply sends an LSP Ping with the top label as the Adj-SID for the neighbor’s adjacency with itself.

For example, on the XR3-XR2 link, XR3 sends an LSP ping to XR2 with the top label as XR2’s Adj-SID for that link. This causes XR2 to simply loop the packet back to XR3.

TI-LFA is not enabled, so XR3 only tests the single non-FRR Adj-SID. On XR2, we see that this is 24005:

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

XR3 sends an LSP ping with label 24005:

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

XR2 replies to XR3 with a successful result:

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

We can see the results of the adjacency SID tests using the following command on XR3:

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

Next, XR3 validates every prefix SID in its RIB. It verifies both the ingress and egress forwarding path in a clever way. It sets the TTL to 2 and sends the LSP Ping “backwards” to an upstream client with the client’s Adj-SID for itself. This causes the LSP Ping to be received inbound to XR3. Then XR3 forwards it egress to a downstream router, and verifies that it gets a successful reply.

For example, XR3 sends an LSP Ping to XR4 with top label as XR4’s Adj-SID with XR3, and then a subsequent label for the prefix SID for 10.0.0.1/32.

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

XR4 pops the top label and loops this back to XR3:

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

Now XR3 forwards this to XR1 on vlan 101 after popping the top label:

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

XR1 sends a successful reply:

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

This process is iterated for every upstream/downstream combination for every prefix SID. We can see the results using the following show command:

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

To see the details of the upstream/downstream combinations, we can specify a particular prefix:

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

DPM is ECMP aware, so in te case that multiple ECMP paths exist, all will be tested. For example, 10.0.0.11/32 is ECMP with two downstream nexthops:

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


---

# 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/sr/sr-oam-dpm.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.