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

Both IP FRR (LFA) and RSVP-TE FRR have same purpose i.e. to Fast ReRoute the traffic to a back up path in case of primary link/node/path failures. If you use RSVP TE you donot need LFA. IP FRR doesn't use RSVP to presignal a back up tunnel. It simply uses your IGP (OSPF /  ISIS). By default IGP calculates the best path to a particular destination and installs the route in the RIB and FIB. When IP FRR (LFA) is enabled on the IGP, along with a primary path it also calculates a back up path and install it as back up path in RIB and FIB but the back up path is not used for traffic forwarding till we have a failure. Because we have the back up path pre-caluclated and installed in RIB and FIB(it takes the longest time) switchingover to back up path in case of a failure is very quick. IP FRR can achieve the same protection times like RSVP-TE FRR (50ms) with out much overhead of creating back up tunnels and RSVP signalling etc.   You can have a look at this for more details    https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/configuration/xe-3s/iri-xe-3s-book/iri-ip-lfa-frr.html    https://learningnetwork.cisco.com/thread/117782   regards Ashish ... View more

You can go through the following detailed technote for more details https://community.cisco.com/t5/service-providers-documents/asr9000-xr-using-satellite-technote/ta-p/3136039   ... View more

Hi,   Thare known SSH related issues. It would be helpful if you could raise a TAC case for analysing the crash. You can attach to the TAC case the crashinfo file (in bootflash:) and corefiles generated in harddisk:/core/   regards Ashish ... View more

Hi Muhammad,   It is possible to tunnel the MPLS frames over IP only infrastructure. Please see if the following helps https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/mp_l3_vpns/configuration/xe-16/mp-l3-vpns-xe-16-book/mpls-vpn-l3vpn-over-gre.html   regards Ashish ... View more

The "remove private-as" configuration is done on the provider side (centurylink) public peering. This explains why you don't see the private AS prepended at the other branch received prefixes. Take a look at the following for more details. https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13756-32.html   regards Ashish ... View more

Hi Hawk, Is your branch site having a private AS (64512 – 65535), and are you prepending the same? Centurylink may be removing the same using "remove private-as".   regards Ashish ... View more

Hi Ibrahim,   Assuming you have IOS/XE you can use the following guide to enable LFA for OSPFv2. https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_ospf/configuration/xe-3s/iro-xe-3s-book/iro-lfa-frr.html   The basic configuration for LFA FRR is as simple as activating it under OSPF through " fast-reroute   per-prefix   enable   prefix-priority   priority-level "   For remote LFA also the RLFA node computation is dynamic and no pre provisioning/configuration is required.   regards Ashish ... View more

Hi, Yes. What this means is, any traffic that comes with top label of 8065 will be load balanced across the two links. If you are using L3VPN/L2VPN and 10.112.64.129/32 is the destination PE, the actual destination IP may be different. In this case the load balance hashing algorithim uses the bottom label in the stack to choose the link between the two. regards Ashish ... View more

Hi Ashhad, The drop count is for total number of packets dropped due to exceeding BW. Simple way to increase the BW is by trial error. Otherwise if they have any reports of rate of voice traffic sent then that can be used to change your policy-map. regards Ashish ... View more

Hi Marek, "segment-routing mpls sr-prefer" changes the default label imposition behavior from LDP to SR. It comes in picture in scenarios where you have both LDP label and SR label. So if you have SR prefix SIDs allocated (normally explicitly configured) for GRT network prefixes, then the above command will make the traffic SR MPLS switched. Answer to your second question is same. you can control SID allocation (assign or not) for GRT network either on the originating router or on the mapping servers (if the GRT network is in the LDP domain). regards Ashish ... View more