300-510 SPRI — Cisco Service Provider Advanced Routing Implementation Specialist

Full question text, answer options, and explanations for this practice set — a spoiler-free alternative is the interactive quiz above for scored, shuffled practice.

1. . On an IOS XR router, a network operator configures IS-IS and assigns the NET address 49.0001.0100.1001.0001.00. What does the '00' at the end of the NET address represent?

   • A. The area ID for IS-IS Level 1
   • B. The pseudonode ID, indicating this is a router (not a pseudonode) — always 00 on end systems(correct)
   • C. The IS-IS system ID in compact form
   • D. The circuit ID identifying which interface is the DIS

   Explanation: In the NSAP/NET address format, the trailing selector byte (NSEL) is always 00 for IS-IS network entities, indicating this is an end system (router) rather than a pseudonode. The pseudonode ID byte preceding it distinguishes router LSPs (00) from pseudonode LSPs (01–FF). The system ID is the 6-byte field before the pseudonode ID. The area ID in this NET is 49.0001.

2. . A service provider engineer needs to configure an IS-IS interface on IOS XR as a point-to-point link rather than using DIS election. Which IOS XR interface-level IS-IS command achieves this?

   • A. isis network point-to-point(correct)
   • B. isis type point-to-point
   • C. isis circuit-type level-1
   • D. isis metric-style point-to-point

   Explanation: The IOS XR command to force IS-IS to treat an interface as point-to-point (suppressing DIS election and pseudonode generation) is 'isis network point-to-point' configured under the interface within the IS-IS router context. This is the correct IOS XR syntax and mirrors the IOS 'isis network point-to-point' command. The 'isis circuit-type' command controls Level-1, Level-2, or Level-1-2 participation, not the network type. There is no 'isis type' or 'isis metric-style point-to-point' command in IOS XR IS-IS.

3. . An IOS XR router runs IS-IS Level-1-2. A Level-1 area router cannot reach destinations in another Level-1 area and has only a default route pointing to the L1/L2 router. The network operator wants specific Level-1 prefixes from Area 49.0002 to appear in the Level-1 LSP database of Area 49.0001 without making all routers L1/L2. Which IS-IS feature should be configured on the L1/L2 router?

   • A. IS-IS route leaking using the 'propagate level-2 into level-1' route policy(correct)
   • B. IS-IS redistribution using 'redistribute isis level-2 into level-1'
   • C. Configuring the L1/L2 router as an IS-IS route reflector for Level-1 routes
   • D. Enabling IS-IS overload bit clearing on the L1/L2 boundary router

   Explanation: IS-IS route leaking (also called route redistribution between IS-IS levels) allows an L1/L2 router to copy selected Level-2 prefixes into its Level-1 LSP, making those prefixes reachable by purely Level-1 routers without a default route. On IOS XR this is configured as 'propagate level-2 into level-1' with a route policy to filter which prefixes are leaked. IS-IS does not use a route reflector model — that is a BGP concept. The overload bit affects SPF path selection, not prefix visibility across levels. 'redistribute isis' would cause looping issues and is not the correct IOS XR mechanism for inter-level leaking.

4. . A BGP engineer on IOS XR needs to apply the same update-source, remote-as, and password configuration to 20 iBGP peers without repeating the configuration for each neighbor. Which IOS XR BGP feature should be used?

   • A. BGP peer-template with 'neighbor X.X.X.X use peer-template NAME'
   • B. BGP neighbor group with 'neighbor-group NAME' and 'use neighbor-group NAME' under each peer(correct)
   • C. BGP peer-policy combined with a peer-session applied to each neighbor
   • D. BGP dynamic neighbors with 'bgp listen range' to auto-accept peers in the subnet

   Explanation: IOS XR BGP uses neighbor-groups (not peer-templates, which are the IOS equivalent) to share common configuration across multiple iBGP peers. You define 'neighbor-group IBGP-PEERS' with the shared attributes (remote-as, update-source, password) and then reference it under each neighbor with 'use neighbor-group IBGP-PEERS'. Peer-templates with 'use peer-template' are the IOS (not IOS XR) syntax. BGP dynamic neighbors with 'bgp listen range' auto-creates neighbor entries but does not deduplicate manual configuration. Peer-policy/peer-session is the IOS construct split from templates, not native IOS XR.

5. . On an IOS XR BGP route reflector, a client sends a BGP UPDATE with community 65000:200. The operator wants the RR to set local-preference to 200 for all routes carrying this community before reflecting them to other clients. Which configuration sequence correctly implements this in IOS XR?

   • A. Define a community-set matching 65000:200, reference it in a route-policy that sets local-preference 200, apply the policy as 'route-policy POLICY in' under the RR client neighbor(correct)
   • B. Define an ip community-list matching 65000:200, reference it in a route-map that sets local-preference 200, apply the route-map as 'neighbor X route-map RMAP in'
   • C. Define a prefix-set matching the client's prefixes, apply a route-policy that sets local-preference 200 outbound toward all other clients
   • D. Configure 'bgp default local-preference 200' globally on the RR to apply to all client routes carrying any community

   Explanation: IOS XR BGP uses Routing Policy Language (RPL) rather than route-maps. The correct approach is: (1) define a community-set ('community-set COMM_200 / 65000:200 / end-set'), (2) write a route-policy that matches it and sets local-preference ('if community matches-any COMM_200 then set local-preference 200 endif'), and (3) apply it inbound ('route-policy POLICY in') under the neighbor configuration. Option B uses IOS/IOS-XE syntax (ip community-list, route-map, neighbor route-map) which does not apply to IOS XR. Option C uses a prefix-set which matches destination prefixes, not communities. Option D globally overrides local-preference for all routes regardless of community.

6. . A service provider configures a BGP route reflector cluster for redundancy with two RRs sharing cluster-id 10.0.0.1. A client receives the same prefix reflected by both RRs. Which BGP attribute prevents the client from creating a routing loop by re-advertising the reflected prefix back to the cluster?

   • A. ORIGINATOR_ID — set to the originating client's BGP router-id; discarded if the router sees its own ORIGINATOR_ID
   • B. CLUSTER_LIST — contains the cluster-id of each RR that reflected the route; a router discards UPDATEs containing its own cluster-id(correct)
   • C. LOCAL_PREF — the RR sets a higher local-preference so clients prefer the reflected path over any loop path
   • D. ATOMIC_AGGREGATE — set by the RR to signal that the prefix has been summarized and should not be re-advertised

   Explanation: The CLUSTER_LIST attribute is the primary loop-prevention mechanism in BGP route reflection. Each RR prepends its cluster-id to CLUSTER_LIST when reflecting a route. When a router receives an UPDATE, it checks whether its own cluster-id appears in CLUSTER_LIST; if it does, the route is discarded, preventing loops. ORIGINATOR_ID carries the BGP router-id of the originating client and prevents a client from accepting its own reflected route back, but it does not prevent inter-cluster loops the way CLUSTER_LIST does. LOCAL_PREF and ATOMIC_AGGREGATE serve entirely different purposes and do not prevent RR loops.

7. . A service provider uses BGP confederations. The confederation identifier is AS 65000. The confederation is divided into member ASes 65001, 65002, and 65003. Router R1 is in member AS 65001 and peers with R2 in member AS 65002. When R1 advertises a route to R2, which BGP attributes does R1 modify compared to advertising the same route to an external eBGP peer outside the confederation?

   • A. R1 prepends the confederation identifier 65000 to AS_PATH; NEXT_HOP is preserved as R1's address
   • B. R1 prepends member AS 65001 to AS_PATH using a confederation segment (AS_CONFED_SEQUENCE); NEXT_HOP and MED are preserved as in iBGP(correct)
   • C. R1 prepends member AS 65001 to AS_PATH as a normal AS_SEQUENCE segment; NEXT_HOP is changed to R1's address as in normal eBGP
   • D. R1 does not modify AS_PATH; LOCAL_PREF is reset to 100; NEXT_HOP is changed to R1's confederation-facing interface

   Explanation: Within a BGP confederation, inter-member AS peering uses eBGP sessions but behaves partially like iBGP. The sending router prepends its member AS number using a special AS_CONFED_SEQUENCE segment (type 3) — not a regular AS_SEQUENCE (type 2). AS_CONFED_SEQUENCE segments are stripped when the route leaves the confederation, so external peers never see internal member AS numbers. NEXT_HOP, LOCAL_PREF, and MED are all preserved across confederation member boundaries (unlike normal eBGP where LOCAL_PREF is stripped and NEXT_HOP changes). This is a key distinction — confederation eBGP carries iBGP-like attribute semantics for LOCAL_PREF and NEXT_HOP.

8. . An IOS XR router redistributes OSPF routes into IS-IS and IS-IS routes into OSPF. The operator discovers a routing loop: an IS-IS route redistributed into OSPF is then redistributed back into IS-IS with a lower administrative distance than the original. Which mechanism on IOS XR prevents this mutual redistribution loop?

   • A. Setting a route tag on IS-IS redistributed routes and filtering that tag in the OSPF-to-IS-IS redistribution route policy(correct)
   • B. Enabling IS-IS passive-interface on all redistributed interfaces to prevent LSP flooding of external routes
   • C. Using the 'distance' command to raise OSPF external administrative distance above IS-IS so IS-IS routes always win
   • D. Configuring 'redistribute maximum-prefix' in both OSPF and IS-IS to limit the number of redistributed routes

   Explanation: The correct and standard technique for preventing mutual redistribution loops between two IGPs is tag-based filtering. When redistributing IS-IS into OSPF, you set a route tag (e.g., tag 100) on the redistributed routes. In the OSPF-to-IS-IS redistribution policy, you add a 'deny' clause for routes carrying tag 100, preventing OSPF routes that originated from IS-IS from being redistributed back. On IOS XR, this is implemented in RPL route-policies using 'set tag' and 'if tag eq 100 then drop endif'. Raising OSPF external administrative distance (option C) helps with path selection but does not prevent the redistributed route from appearing in the IS-IS database at all. 'redistribute maximum-prefix' limits count, not origin. Passive-interface stops adjacencies, not redistribution.

9. . A service provider needs to authenticate IS-IS adjacencies on IOS XR using a key-chain. Choose 2 configuration steps that are required to enable IS-IS key-chain authentication on an interface in IOS XR.

   • A. Define a key-chain globally with 'key chain CHAIN-NAME' and configure key IDs with key-string and cryptographic-algorithm (e.g., hmac-md5 or hmac-sha-256)(correct)
   • B. Under the IS-IS router and interface stanza, configure 'hello authentication keychain CHAIN-NAME' to authenticate IS-IS Hello PDUs(correct)
   • C. Configure 'isis authentication mode md5' directly on the interface without referencing a key-chain for IOS XR compatibility
   • D. Apply 'ip authentication key-chain eigrp CHAIN-NAME' under the IS-IS interface to enable cross-protocol key reuse
   • E. Configure 'lsp authentication keychain CHAIN-NAME' under the IS-IS router instance to authenticate LSPs in addition to Hello PDUs

   Explanation: IOS XR IS-IS key-chain authentication requires two steps: (1) defining the key-chain globally under 'key chain NAME' with key IDs, key strings, and a hash algorithm such as hmac-md5 or hmac-sha-256, and (2) referencing that key-chain under the IS-IS interface (or router instance) with 'hello authentication keychain CHAIN-NAME'. Option E describes LSP authentication which is valid but the question asks specifically about adjacency (Hello PDU) authentication; 'lsp authentication keychain' secures LSPs not adjacencies. Option C uses IOS (not IOS XR) syntax — IOS XR does not use 'isis authentication mode md5' directly on interfaces without a key-chain reference. Option D is EIGRP syntax and is completely irrelevant to IS-IS.

10. . An IOS XR operator runs 'show mpls ldp neighbor' and sees the session state as 'GR' for one peer. What does this indicate?

    • A. The LDP session is established and the peer has Graceful Restart capability negotiated(correct)
    • B. The LDP session has failed and is in a grace period waiting for the peer to re-establish
    • C. The LDP neighbor is using a non-default hello interval (GR = Greater-than-default Rate)
    • D. The LDP session is using MD5 authentication and the peer has authenticated successfully

    Explanation: In IOS XR, the 'GR' flag in 'show mpls ldp neighbor' output indicates that LDP Graceful Restart has been negotiated with that peer. This means both routers have agreed that if the LDP control plane restarts, the peer will retain MPLS forwarding state for a configured hold-down period (the 'reconnect timeout') rather than immediately withdrawing all label bindings. This prevents traffic black-holing during process restarts or RP switchovers. A failed session in grace period would typically show as 'Down' or 'Connecting', not 'GR'. MD5 authentication status is shown separately.

11. . On an IOS XR router, the operator configures 'mpls ldp router-id Loopback0 force'. What is the effect of the 'force' keyword?

    • A. It forces LDP to use Loopback0's IP address as the router-id immediately, even if it requires tearing down and re-establishing existing LDP sessions(correct)
    • B. It forces all LDP label bindings to be advertised only via Loopback0 as the next-hop interface
    • C. It forces LDP to run only on Loopback0 and suppresses LDP hellos on all other interfaces
    • D. It forces LDP to prefer the Loopback0 address as the transport address for new sessions without affecting established sessions

    Explanation: Without the 'force' keyword, 'mpls ldp router-id Loopback0' takes effect only when LDP is next restarted or when a new session is established — existing sessions keep their current router-id. The 'force' keyword instructs LDP to immediately apply the new router-id change, which requires tearing down all active LDP sessions and re-establishing them using the new router-id. This is important in operational environments where the LDP router-id and the IGP router-id need to be consistent without waiting for a natural restart. The 'force' keyword does not restrict LDP to Loopback0 only — LDP still runs on all enabled interfaces.

12. . A network engineer needs to verify that an MPLS LSP end-to-end from router PE1 (10.0.0.1) to router PE2 (10.0.0.2) is forwarding correctly. The engineer wants to test label switching at each hop. Which IOS XR command initiates an LSP traceroute for this purpose?

    • A. traceroute mpls ipv4 10.0.0.2/32(correct)
    • B. traceroute mpls ldp ipv4 10.0.0.2/32 verbose
    • C. mpls traceroute ipv4 peer 10.0.0.2
    • D. trace mpls lsp 10.0.0.2 255.255.255.255

    Explanation: On IOS XR, the LSP traceroute command syntax is 'traceroute mpls ipv4 <prefix/length>' which uses MPLS echo request/reply packets with incrementing TTLs to reveal each LSP hop and the labels used at each transit router. This is the standard IOS XR MPLS OAM traceroute command (equivalent to 'mpls traceroute' on IOS). Option B has extra keywords ('ldp' and 'verbose') that are not part of the base IOS XR syntax for this operation — 'verbose' is valid but 'ldp' is not a required keyword in this context. Options C and D use non-existent IOS XR command syntax.

13. . An RSVP-TE tunnel is configured on IOS XR with 'path-option 1 explicit name PATH1' and 'path-option 2 dynamic'. The explicit path PATH1 traverses links R1-R2-R3-R4. MPLS FRR with link-protect is enabled on all links. The R2-R3 link fails. Within 50 ms, traffic is rerouted. After RSVP re-signaling, what is the expected long-term recovery behavior?

    • A. Traffic permanently uses the FRR bypass tunnel protecting the R2-R3 link until manually reset
    • B. RSVP attempts to re-signal the LSP along PATH1 (explicit); if it fails, it falls back to path-option 2 dynamic and the tunnel moves to the dynamic path(correct)
    • C. The tunnel is torn down because the explicit path is no longer available; a new tunnel must be manually configured
    • D. RSVP re-signals exclusively along PATH1 ignoring the failure, causing the tunnel to remain down until the R2-R3 link recovers

    Explanation: MPLS FRR provides sub-50ms local repair by switching to a pre-computed bypass tunnel. However, this is a local repair mechanism — the RSVP signaling for the protected LSP still needs to find a new end-to-end path. RSVP will attempt to re-signal along path-option 1 (PATH1 explicit). Since PATH1 traverses the failed R2-R3 link, re-signaling via PATH1 fails. RSVP then falls back to path-option 2 dynamic, which computes a new path avoiding the failed link using CSPF, and re-establishes the LSP along the new path. The FRR bypass is temporary — it handles the first 50ms while RSVP re-signaling completes the permanent reroute.

14. . On an IOS XR penultimate hop router (PHP), a labeled packet for prefix 10.1.1.1/32 arrives. The PHP's LFIB shows label 3 (implicit null) bound to this prefix by the egress PE. What action does the PHP take?

    • A. The PHP forwards the packet with label 3 intact to the egress PE, which performs label lookup on label 3
    • B. The PHP pops the label and forwards the unlabeled IP packet directly to the egress PE, saving the egress PE one label lookup(correct)
    • C. The PHP drops the packet because label 3 is a reserved label reserved for OAM and cannot be forwarded
    • D. The PHP swaps label 3 with an explicit null label (label 0) before forwarding to the egress PE

    Explanation: Label 3 is the implicit null label in MPLS. When an egress LSR advertises label 3 (implicit null) to its LDP or RSVP-TE upstream neighbor, it signals that the upstream router (the penultimate hop) should pop the MPLS label before forwarding the packet. This is Penultimate Hop Popping (PHP) — the PHP removes the MPLS label stack and sends a plain IP packet to the egress PE, which then performs a regular IP forwarding lookup. This saves the egress PE from performing two operations (label pop + IP lookup) and instead only does one (IP lookup). Label 0 is explicit null (used to preserve EXP bits to the egress); PHP does not swap to explicit null unless the egress PE advertises label 0.

15. . An IOS XR network operator configures Segment Routing MPLS under IS-IS. Which configuration block correctly enables SR-MPLS for IS-IS on IOS XR?

    • A. Under 'router isis CORE', add 'address-family ipv4 unicast' and then 'segment-routing mpls'(correct)
    • B. Under 'mpls traffic-eng', add 'segment-routing' and 'router-id Loopback0'
    • C. Under 'segment-routing', add 'address-family ipv4' and 'router isis CORE activate'
    • D. Under 'router isis CORE', add 'segment-routing ldp' to enable SR as an LDP replacement

    Explanation: On IOS XR, SR-MPLS is enabled within the IGP (IS-IS) configuration. Under 'router isis PROCESS-NAME', enter 'address-family ipv4 unicast' and add 'segment-routing mpls'. This instructs IS-IS to advertise SR capability TLVs and use SR labels for IP prefix reachability. Option B configures MPLS TE which is a different feature (RSVP-TE based). Option C has incorrect syntax — there is no 'router isis activate' under the segment-routing stanza. Option D uses 'segment-routing ldp' which is not valid syntax; enabling SR-MPLS under IS-IS replaces LDP for prefix SIDs, but the configuration keyword is 'segment-routing mpls', not 'segment-routing ldp'.

16. . On an IOS XR router running SR-MPLS with IS-IS, an engineer configures a Prefix-SID for Loopback0 (10.0.0.1/32) using 'prefix-sid index 1'. The Segment Routing Global Block (SRGB) is configured as 16000-23999. What MPLS label will be allocated for this Prefix-SID?

    • A. Label 1, because the index is 1
    • B. Label 16001, because the SRGB starts at 16000 and index 1 means SRGB-start + 1(correct)
    • C. Label 16000, because index 1 means the first entry and the SRGB base is 16000
    • D. Label 23999, because index 1 is interpreted relative to the end of the SRGB

    Explanation: A Prefix-SID index is added to the SRGB base address to derive the MPLS label. With SRGB 16000–23999, the base (start) is 16000. A Prefix-SID with index 1 results in label 16000 + 1 = 16001. Index 0 would result in label 16000. This is the standard SR-MPLS label calculation: label = SRGB_start + SID_index. The absolute SID value in the label stack is SRGB-base + index, not the index value itself (which would be non-SRGB and invalid for SR forwarding). Operators must ensure no two nodes use the same index within the same SR domain.

17. . A service provider engineer configures an SR-TE policy on IOS XR to steer traffic to endpoint 10.0.0.5 using color 100. The policy uses a candidate-path with an explicit segment-list. Which IOS XR configuration stanza is used to define this SR-TE policy?

    • A. Under 'mpls traffic-eng', add 'policy POLICY-NAME' with 'color 100 end-point ipv4 10.0.0.5' and 'candidate-path preference 100 explicit segment-list SEG-LIST'
    • B. Under 'segment-routing traffic-eng', add 'policy POLICY-NAME' with 'color 100 end-point ipv4 10.0.0.5' and 'candidate-path preference 100 explicit segment-list SEG-LIST'(correct)
    • C. Under 'router isis CORE', add 'segment-routing te-policy color 100 endpoint 10.0.0.5 segment-list SEG-LIST'
    • D. Under 'interface tunnel-te1', add 'destination 10.0.0.5' and 'segment-routing color 100 segment-list SEG-LIST'

    Explanation: SR-TE policies on IOS XR are configured under the 'segment-routing traffic-eng' configuration hierarchy, not under 'mpls traffic-eng' (which is for RSVP-TE). The policy block specifies the policy name, color, and IPv4 endpoint. Candidate paths with preference values select between multiple path options; 'explicit segment-list' references a named segment-list defining the ordered SID stack. The (color, endpoint) tuple is used by the headend to automatically steer traffic matching the corresponding BGP color extended community. IS-IS does not host SR-TE policy configuration. Tunnel-te interfaces are for RSVP-TE, not SR-TE.

18. . An IOS XR operator enables TI-LFA (Topology Independent Loop-Free Alternates) under IS-IS for SR-MPLS. After a link failure, the router installs a repair path with a label stack of [16005, 16008] where 16005 is the SID for an intermediate node P and 16008 is the SID for the post-convergence next-hop PE. What does this label stack indicate about the nature of the TI-LFA repair?

    • A. A link-protect repair where the backup path goes directly to the post-convergence next-hop via label 16008 only
    • B. A node-protect repair where traffic is tunneled through node P (SID 16005) to reach PE (SID 16008), bypassing the failed node entirely(correct)
    • C. A repair using a PCE-computed path where 16005 is the PCE's SID and 16008 is the final destination SID
    • D. A microloop avoidance path temporarily used during IGP convergence, not a permanent FRR path

    Explanation: In TI-LFA, when the repair requires going through an intermediate node P that is not the normal next-hop (to bypass a failed node), the repair path label stack contains the SID of the repair node P followed by the SID of the post-convergence destination. The headend pushes [16005 (P's Node-SID), 16008 (PE's Node-SID)] so the packet is first routed to P using SR forwarding, and from P it is routed to PE — the failed node is bypassed. A link-protect repair that only needs to avoid a link (not a node) would use a single label for the post-convergence next-hop because the alternate path exists within normal topology. Multi-label TI-LFA repair stacks are characteristic of node-protect repairs requiring a detour through a specific intermediate node.

19. . An IOS XR router participates in an SR domain and also has LDP running for backward compatibility with non-SR routers. The operator wants SR-MPLS Prefix-SIDs to take precedence over LDP-allocated labels for SR-capable prefixes. Which configuration ensures this on IOS XR?

    • A. Under 'router isis CORE', configure 'segment-routing mpls sr-prefer' to prioritize SR labels over LDP
    • B. Under 'mpls ldp', configure 'prefer-segment-routing' to instruct LDP to defer to SR label bindings for SR-capable prefixes(correct)
    • C. Disable LDP entirely with 'no mpls ldp' to force all traffic onto SR labels
    • D. Under 'segment-routing', configure 'mapping-server' to rewrite LDP labels to SR labels globally

    Explanation: When both LDP and SR-MPLS are running simultaneously, the 'prefer-segment-routing' command under 'mpls ldp' on IOS XR instructs the LFIB to install SR labels (Prefix-SIDs) in preference to LDP-allocated labels for the same prefixes. This enables a phased migration where some nodes are SR-capable and others still use LDP — the SR-capable nodes use SR forwarding among themselves while LDP still functions for non-SR nodes. Option A's 'sr-prefer' keyword under 'router isis' is not standard IOS XR syntax. Disabling LDP (option C) is disruptive and not required for SR preference. The SR mapping server is used to assign SIDs to non-SR-capable nodes, not to rewrite LDP labels.

20. . On an IOS XR router, a network operator configures PIM-SM and wants to statically define 10.10.10.1 as the Rendezvous Point for multicast group range 232.0.0.0/8. After entering 'router pim' and 'address-family ipv4', which command sets the static RP?

    • A. rp-address 10.10.10.1 232.0.0.0/8(correct)
    • B. static-rp 10.10.10.1 access-group 232
    • C. ip pim rp-address 10.10.10.1 prefix-list PIM-GROUPS
    • D. pim rp 10.10.10.1 group-range 232.0.0.0/8

    Explanation: On IOS XR, within the 'router pim' / 'address-family ipv4' configuration context, the command to configure a static Rendezvous Point is 'rp-address <RP-IP> <ACL-name or prefix>' — for example 'rp-address 10.10.10.1 232.0.0.0/8' to restrict the RP to the specified group range. IOS XR accepts a prefix (CIDR) or an access-list name. Option B ('static-rp') is not valid IOS XR syntax. Option C ('ip pim rp-address') is IOS/IOS-XE syntax and does not apply to IOS XR. Option D ('pim rp group-range') is not a valid IOS XR command.

21. . Two service provider networks each have their own PIM-SM domain and RPs. A multicast source in AS 65001 is sending to group 239.1.1.1. Receivers in AS 65002 need to receive the stream. MSDP is deployed between the two RPs. Which MSDP message type carries the source (S,G) information from AS 65001's RP to AS 65002's RP?

    • A. MSDP Source-Active (SA) message, sent by the originating RP containing (S,G,RP) tuples for active sources(correct)
    • B. MSDP Keepalive message, which includes (S,G) state as a piggyback to reduce control traffic
    • C. MSDP Notification message, sent when a new source registers and containing the source's multicast group range
    • D. PIM Register message forwarded by the RP to MSDP peers in other domains using IP tunneling

    Explanation: MSDP (Multicast Source Discovery Protocol) uses Source-Active (SA) messages to distribute source information between PIM-SM domains. When a multicast source registers with its local RP, that RP generates SA messages containing (Source IP, Group IP, RP IP) tuples and floods them to its MSDP peers (including the RP in AS 65002). The remote RP receiving the SA can then join the shortest-path tree to the source. MSDP Keepalive messages only maintain the TCP session between peers and carry no (S,G) information. MSDP does not have a 'Notification' message type. PIM Register messages are local to a PIM domain — they are not forwarded to MSDP peers.

22. . An IOS XR service provider core runs mLDP (Multicast LDP) for multicast traffic transport over an MPLS network. A Point-to-Multipoint (P2MP) mLDP LSP is built. What is the correct forwarding model for a P2MP mLDP LSP?

    • A. The root node initiates label distribution downstream toward all leaves; transit nodes replicate labeled packets to multiple downstream interfaces
    • B. Each leaf node sends an mLDP Label Mapping message upstream toward the root; the root originates labeled multicast packets that are replicated at branching transit nodes(correct)
    • C. The root node runs RSVP-TE PATH messages to signal the P2MP tree; mLDP merely assigns labels to the RSVP-TE established tunnels
    • D. All nodes in the P2MP tree send labeled packets to a central replication server which distributes copies to each leaf

    Explanation: mLDP uses a downstream-driven signaling model: leaf nodes initiate the P2MP tree by sending mLDP Label Mapping messages upstream hop-by-hop toward the root (identified by a FEC element). Each transit node aggregates upstream requests and builds the branching tree. When the root has data to send, it forwards labeled packets into the P2MP LSP; transit nodes with multiple downstream branches replicate the labeled packet to each downstream interface. This is the opposite of RSVP-TE which uses downstream-initiated but source-driven PATH messages. mLDP operates independently of RSVP-TE and does not use a central replication server.

23. . A service provider deploys mVPN using BGP-based procedures (Profile 14 / Next-Generation mVPN) on IOS XR. Instead of using a dedicated P-tunnel, the operator uses SR-TE policies to carry multicast VPN traffic. Which BGP address family is used for mVPN route advertisement in Profile 14?

    • A. BGP IPv4 multicast address family (address-family ipv4 multicast) carrying VPN multicast routes
    • B. BGP L2VPN EVPN address family carrying mVPN routes as EVPN route type 6
    • C. BGP IPv4 VPN-Multicast (MDT SAFI) address family within the VPNv4 address family using MDT address family
    • D. BGP mVPN address family (address-family ipv4 mvpn) for advertising I-PMSI and S-PMSI A-D routes(correct)

    Explanation: Next-Generation BGP-based mVPN (Profile 14) uses the BGP mVPN address family ('address-family ipv4 mvpn' on IOS XR) to advertise Inclusive and Selective Provider Multicast Service Interface Auto-Discovery (I-PMSI A-D and S-PMSI A-D) routes, as well as Leaf A-D and Source Active A-D routes. These route types (1–5) carry provider tunnel information, including SR-TE policy identifiers when SR-TE is used as the underlay P-tunnel. The MDT SAFI (option C) is an older Cisco proprietary signaling mechanism predating the BGP mVPN standards. The 'ipv4 multicast' address family carries regular multicast routing information but not VPN-specific mVPN A-D routes. L2VPN EVPN route type 6 is for multicast in EVPN contexts, not mVPN.

24. . An IOS XR router needs to be configured as a PCEP client (PCC) to request SR-TE paths from an external stateful PCE. Choose 2 correct IOS XR configuration elements required to enable PCEP client functionality.

    • A. Under 'segment-routing traffic-eng', configure 'pce address ipv4 <PCE-IP>' to identify the PCE server(correct)
    • B. Under 'segment-routing traffic-eng', configure 'pcc' with 'source-address ipv4 <PCC-loopback>' to set the PCC source address for PCEP sessions(correct)
    • C. Under 'mpls traffic-eng', configure 'pce peer <PCE-IP>' to register the router as a PCEP client
    • D. Under 'router ospf', configure 'capability pcep' to advertise PCE capability in the IGP
    • E. Under 'mpls ldp', configure 'pcep enable' to share LDP labels with the PCE for path computation

    Explanation: On IOS XR, PCEP client (PCC) configuration is done entirely within 'segment-routing traffic-eng'. The two required elements are: (A) specifying the PCE using 'pce address ipv4 <PCE-IP>' which tells the router where to connect, and (B) the 'pcc' sub-block with 'source-address ipv4 <loopback-IP>' defining the local PCEP session source. The 'mpls traffic-eng pce peer' syntax (option C) is IOS-XE RSVP-TE based PCE configuration, not SR-TE PCEP configuration. OSPF does not have a 'capability pcep' command for PCEP — PCE discovery via IGP uses OSPF/IS-IS PCE capability TLVs but these are distinct from configuring the PCEP session. Option E conflates LDP with PCEP which are separate control-plane protocols.

25. . An IOS XR P router receives a labeled packet with label 16010 on interface GigabitEthernet0/0/0/0. The LFIB shows: label 16010 — swap to label 16010, next-hop 192.168.1.2, output interface GigabitEthernet0/0/0/1. The router performs the swap but the packet is dropped by the next router. An MPLS ping to 10.0.0.10/32 (the prefix behind label 16010) succeeds from PE1 but fails from P1. What is the most likely cause?

    • A. The MPLS TTL expired at P1 because the IP TTL was not propagated into the MPLS label and defaulted to 1
    • B. The next-hop router P2 does not have label 16010 in its LFIB — the SR Prefix-SID index maps to a different label in P2's SRGB(correct)
    • C. P1 is performing PHP incorrectly and popping the label before forwarding, sending an unlabeled packet to P2 which drops non-MPLS traffic
    • D. The MPLS ping reply is routed via the control plane path which differs from the data plane LFIB entry

    Explanation: In SR-MPLS, all nodes must have a consistent SRGB for global SIDs to be portable. If P2 has a different SRGB range (e.g., 17000–24999 instead of 16000–23999), then label 16010 does not fall in P2's SRGB and P2's LFIB has no entry for label 16010 — it drops the packet. The MPLS ping from PE1 succeeds because PE1 inserts the correct SID based on its own SRGB-to-SID mapping and the echo request may take a different path or the PE is the only router tested. Correct SR-MPLS deployment requires all nodes in the SR domain to use the same SRGB or at least have overlapping ranges that cover all allocated Prefix-SIDs. MPLS TTL defaults to 255, not 1. PHP would result in an IP packet being forwarded, not dropped at P2 (unless P2 has no IP route). MPLS ping uses the same MPLS data path.