# IOS-XR and ARM

**URL:** <https://forum.networklessons.com/t/ios-xr-and-arm/58828>\
**Category:** MPLS\
**Created:** [July 25, 2026, 8:10am UTC](https://forum.networklessons.com/t/ios-xr-and-arm/58828 "2026-07-25T08:10:39Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![davidilles](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/davidilles/32/9686_2.png) [@davidilles](https://forum.networklessons.com/u/davidilles)\
**Post date:** [July 25, 2026, 8:10am UTC](https://forum.networklessons.com/t/ios-xr-and-arm/58828/1 "2026-07-25T08:10:39Z")

</div>

Hello, everyone.

I’ve ran into an interesting issue while studying MPLS on XR and I would like your input on it.

IOS-XR documentation for LDP states the following when it comes to determining the LDP router ID:

> **[MPLS Label Distribution Protocol Commands on Cisco IOS XR Software](https://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-7/mpls/command/reference/gr37ldp.html)**
>
> MPLS Label Distribution Protocol Commands on Cisco IOS XR Software

![obrázok]()

I have the following loopbacks configured:

![obrázok]()

When I enable MPLS LDP, it picks 1.1.1.1 as the RID

![obrázok]()

I was quite suprised by this because I thought the RID selection process would fall to Step 3 since I haven’t configured any RIDs.

However, this process called ARM always picks one loopback (always the first one for some reason) as the global RID and that’s used instead (that is, if you don’t configure an RID manually).

![obrázok]()

This is apparently some IP address repository manager. It always picks the global RID upon booting XR.

Is it not possible to make it to the third step of the LDP RID selection process, then? Does ARM also always pick the first loopback it can find?

I did not manage to find much documentation regarding this, did anyone here experience this kind of problem before?

Thank you!  
David

---

<div class="post-metadata">

**Author:** ![lagapidis](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/lagapidis/32/4949_2.png) [@lagapidis](https://forum.networklessons.com/u/lagapidis)\
**Post date:** [July 30, 2026, 5:18am UTC](https://forum.networklessons.com/t/ios-xr-and-arm/58828/2 "2026-07-30T05:18:58Z")

</div>

Hello David

What you’ve observed is expected behavior. LDP’s router-ID selection follows a [documented](https://www.cisco.com/c/en/us/td/docs/ios_xr_sw/iosxr_r3-7/mpls/command/reference/gr37ldp.html#wp1532532) 3-step priority:

1. Configured LDP router-ID: if you explicitly set router-id A.B.C.D under `mpls ldp`
2. Global router ID from ARM: the system-wide router-ID published by IP ARM (Address Repository Manager)
3. Calculated fallback: the primary IPv4 address of the highest-numbered loopback

In practice, ARM’s global router-ID (Step 2) is populated automatically as soon as the router boots with any loopback interface present, so Step 3 is rarely reached. This is why you see 1.1.1.1 used instead of the documented Step 3 algorithm.

ARM’s automatic global-router-ID selection chooses the primary IPv4 address of the lowest-numbered (first available) Loopback interface. This is typically Loopback0, not the highest numbered or the highest IPv4 address. You can verify this directly [using this command](https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/ip-addresses/command/reference/b-ip-addresses-cr-asr9000/b-ipaddr-cr-asr9k_chapter_01000.html?bookSearch=true#wp2651402300):

`show arm router-ids`

The output of this command shows exactly which interface ARM picked. In your case, it found Loopback0 (1.1.1.1) first and stopped looking.

Now, can you bypass ARM and force step 3? Unfortunately, no, there is no documented CLI command to disable ARM’s global-router-ID computation system-wide just to force LDP to Step 3. ARM is a router-wide system function, not an LDP-specific toggle.

The best practice (and Cisco’s recommendation) is to short-circuit the entire selection chain by explicitly configuring the router ID as described in Step 1. This eliminates ambiguity, prevents session flaps from auto-selected defaults changing, and guarantees deterministic, stable behavior. This is the standard approach. It’s not a workaround, but the recommended design. Make sense?

I hope this has been helpful!

Laz

---

<div class="post-metadata">

**Author:** ![davidilles](https://cdn-forum.networklessons.com/user_avatar/forum.networklessons.com/davidilles/32/9686_2.png) [@davidilles](https://forum.networklessons.com/u/davidilles)\
**Post date:** [July 30, 2026, 7:25am UTC](https://forum.networklessons.com/t/ios-xr-and-arm/58828/3 "2026-07-30T07:25:12Z")

</div>

Hello Laz,

That makes perfect sense, thank you. It’s similar to how the BGP RID selection process works, which also picks the lowest-numbered loopback.

XR and RIDs are always a bit confusing topic since everything XE does regarding them, XR does differently.

Thank you again!  
David
