Hi Samrjit,   Mapping Server or normal router prefix to SID mappings should propagate through out the ISIS domain across multiple levels. In case of multiple mapping servers highest preference value (0-255) is preferred. Mapping server can be placed anywhere in the IGP SR domain.    check if you have the domain-wide keyword           segment-routing prefix-sid-map advertise-local [domain-wide]   I have pasted reference text from relevent IETF drafts. Can you test this in your lab?   https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-15#page-11 3.2.3.  Interoperability of Multiple SRMSes and Prefix-SID advertisements In the case of SR/LDP interoperability through the use of a SRMS, mappings are advertised by one or more SRMS. SRMS function is implemented in the link-state protocol (such as IS- IS and OSPF). Link-state protocols allow propagation of updates across area boundaries and therefore SRMS advertisements are propagated through the usual inter-area advertisement procedures in link-state protocols. Multiple SRMSs can be provisioned in a network for redundancy. Moreover, a preference mechanism may also be used among SRMSs so to deploy a primary/secondary SRMS scheme allowing controlled modification or migration of SIDs. The content of SRMS advertisement (i.e.: mappings) are a matter of local policy determined by the operator. When multiple SRMSs are active, it is necessary that the information (mappings) advertised by the different SRMSs is aligned and consistent. The following mechanism is applied to determine the preference of SRMS advertisements: If a node acts as an SRMS, it MAY advertise a preference to be associated with all SRMS SID advertisements sent by that node. The means of advertising the preference is defined in the protocol specific drafts e.g.,[I-D.ietf-isis-segment-routing-extensions] , [I-D.ietf-ospf-segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The preference value is an unsigned 8 bit integer with the following properties: 0 - Reserved value indicating advertisements from that node MUST NOT be used. 1 - 255 Preference value (255 is most preferred) Advertisement of a preference value is optional. Nodes which do not advertise a preference value are assigned a preference value of 128. ==================== https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/?include_text=1 2.1.2.  Prefix-SID Propagation    The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV    gets propagated across level boundaries.    The level-1-2 router that propagates the Prefix-SID sub-TLV between    levels MUST set the R-flag.    If the Prefix-SID contains a global index (L and V flags unset) and    it is propagated as such (with L and V flags unset), the value of the    index MUST be preserved when propagated between levels.    The level-1-2 router that propagates the Prefix-SID sub-TLV between    levels MAY change the setting of the L and V flags in case a local    label value is encoded in the Prefix-SID instead of the received    value. 2.4.  SID/Label Binding TLV    The SID/Label Binding TLV MAY be originated by any router in an IS-IS    domain.    <SNIP>       S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across       the entire routing domain.  If the S flag is not set, the SID/       Label Binding TLV MUST NOT be leaked between levels.  This bit       MUST NOT be altered during the TLV leaking.       D-Flag: when the SID/Label Binding TLV is leaked from level-2 to       level-1, the D bit MUST be set.  Otherwise, this bit MUST be       clear.  SID/Label Binding TLVs with the D bit set MUST NOT be       leaked from level-1 to level-2.  This is to prevent TLV looping       across levels.       A-Flag: Attached flag.  The originator of the SID/Label Binding       TLV MAY set the A bit in order to signal that the prefixes and       SIDs advertised in the SID/Label Binding TLV are directly       connected to their originators.  The mechanisms through which the       originator of the SID/Label Binding TLV can figure out if a prefix       is attached or not are outside the scope of this document (e.g.:       through explicit configuration).  If the Binding TLV is leaked to       other areas/levels the A-flag MUST be cleared. 2.4.4.  Mapping Server Prefix-SID    The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1    and contains the SID/index/label value associated with the prefix and    range.  The Prefix-SID SubTLV MUST be present in the SID/Label    Binding TLV unless the M-flag is set in the Flags field of the parent    TLV.    A node receiving an SRMS entry for a prefix MUST check the existence    of such prefix in its link-state database prior to consider and use    the associated SID.   ... View more

Hi, Could you add a back door link between the csrv CPEs? There use to be some data plane forwarding throttling with default license. If you don’t see ping loss over the back door link between the CPEs then that will rule out the CPE issues. In that case more troubleshooting will be needed to find out the router where the packet is dropped. You can find this info from the interface counters easily. ... View more

Hi,   In addition to what Santosh suggested, Following alternate also should help.   RP/0/RSP1/CPU0:ASR9006-L(config)#service cli interactive disable RP/0/RSP1/CPU0:ASR9006-L(config)#commit   RP/0/RSP1/CPU0:ASR9006-L#show running-config | file test_config Fri Aug 31 02:34:52.401 EDT Building configuration... ............. [OK] RP/0/RSP1/CPU0:ASR9006-L# RP/0/RSP1/CPU0:ASR9006-L#show running-config | file test_config  Fri Aug 31 02:38:25.297 EDT Building configuration... ............ [OK] RP/0/RSP1/CPU0:ASR9006-L#   Regards, Ashish ... View more