Last updated: May 2026
350-501 SPCOR — Cisco Service Provider Core Specialist
Test your knowledge with official exam-style questions
Questions and options are shuffled each attempt
▶Cisco Service Provider Core Specialist — Practice Set 1: All Questions & Explanations
Full question text, answer options, and explanations for this practice set — a spoiler-free alternative is the interactive quiz above for scored, shuffled practice.
. A network engineer examines a service provider topology. Traffic from a customer DSL modem flows to a DSLAM, then to a regional aggregation router, then across the MPLS backbone, and finally to an internet peering router that connects to other autonomous systems. Which SP network tier does the regional aggregation router represent?
- A. Access tier — directly connected to customer premises equipment
- B. Aggregation tier — collects traffic from multiple access nodes and concentrates it toward the core(correct)
- C. Core tier — provides high-speed switching across the SP backbone
- D. Peering tier — exchanges traffic with other autonomous systems
Explanation: In a standard SP network hierarchy, the access tier directly connects to customer equipment (DSLAMs, ONTs, CPE). The aggregation tier sits above the access tier and collects traffic from multiple access devices, providing traffic concentration and often subscriber management functions. The core tier provides high-speed backbone switching, and the peering tier handles inter-AS connectivity at IXPs. The regional aggregation router in this scenario sits between the DSLAM (access) and the MPLS backbone (core), making it an aggregation-tier device.
. An engineer reviews an IOS XR system and notices that after a 'process restart bgp' command, IS-IS adjacencies remained stable and MPLS forwarding continued without interruption. Which IOS XR design principle explains this behavior?
- A. IOS XR loads all routing protocols in a single process context — restarting BGP triggers a graceful reload of all protocols simultaneously, which maintains forwarding
- B. IOS XR's microkernel architecture isolates routing protocol processes in separate memory spaces; restarting BGP affects only the BGP process and does not touch IS-IS, the FIB, or the forwarding hardware(correct)
- C. IOS XR uses MPLS FRR to protect against all control-plane restarts, rerouting traffic automatically whenever any process is restarted
- D. IOS XR replicates all BGP state to the IS-IS process as a backup; if BGP restarts, IS-IS temporarily handles BGP responsibilities to maintain forwarding
Explanation: IOS XR is built on a microkernel architecture (based on QNX) where each routing protocol, management plane application, and forwarding component runs as an independent user-space process in its own protected memory space. A BGP process restart is contained entirely within the BGP process — it cannot write to or corrupt the memory of IS-IS, MPLS, or the forwarding plane processes. The forwarding hardware continues to use its installed FIB entries uninterrupted. This process isolation is a foundational high-availability design principle of IOS XR.
. A service provider is deploying PE routers at the edge of their MPLS network and P routers in the core. The PE routers need to support BNG subscriber management, L2VPN services, and MPLS L3VPN with complex QoS hierarchies. The P routers need maximum port density and throughput at minimum cost per bit. Which Cisco platform assignment is most appropriate?
- A. Deploy ASR 9000 as PE routers for their rich service feature set; deploy NCS 5500 as P routers for their high-density, low-cost-per-bit merchant-silicon design(correct)
- B. Deploy NCS 5500 as PE routers since merchant silicon provides better QoS support; deploy ASR 9000 as P routers for their modular chassis design
- C. Deploy ASR 9000 as both PE and P routers — consistency simplifies operations and the ASR 9000 is the only platform that supports all required features
- D. Deploy NCS 5500 as both PE and P routers — the Jericho2 ASIC supports all L3VPN, BNG, and L2VPN features needed at the PE
Explanation: The Cisco ASR 9000 is a services-oriented modular platform with custom Cisco QuantumFlow Processor (QFP) ASICs designed specifically for rich feature support including BNG subscriber management, hierarchical QoS, L2VPN (VPLS, EVPN), and MPLS L3VPN at the PE edge. The NCS 5500 uses Broadcom Jericho2 merchant silicon which delivers industry-leading port density and throughput at low cost-per-bit — ideal for core P routers performing simple MPLS label switching at very high rates. This heterogeneous deployment is a common and recommended SP design pattern.
. A service provider examines a router that shows the following output. What does this indicate about the router's HA configuration? RP/0/RSP0/CPU0:PE1# show redundancy Active node: 0/RSP0/CPU0 Standby node: 0/RSP1/CPU0 Standby node state: Ready NSR: Enabled
- A. The router has dual Route Processors installed; the standby RP is synchronized and NSR is active, meaning routing protocol state is replicated — a switchover will not reset BGP or IS-IS sessions(correct)
- B. The router is in a failover state — the active RP has failed and the standby RP has taken over; NSR enabled means it is attempting to recover BGP sessions
- C. NSR Enabled means the router will reboot if the standby RP fails to synchronize within 60 seconds
- D. The standby RP state 'Ready' means it has not yet completed synchronization and cannot take over immediately; NSR is pre-provisioned but not yet active
Explanation: The 'show redundancy' output shows a healthy dual-RP setup: the active RP is in slot 0/RSP0 and the standby RP is in 0/RSP1 with state 'Ready', meaning it is fully synchronized and can take over immediately. 'NSR: Enabled' means Non-Stop Routing is active — routing protocol state (BGP TCP sessions, IS-IS adjacency state, etc.) is continuously replicated from the active RP to the standby RP. If the active RP fails, the standby RP takes over all routing sessions transparently without any BGP session resets or IS-IS adjacency drops.
. A service provider's carrier Ethernet team is deploying an E-LINE service for a financial institution connecting two sites. The customer requires transparent Ethernet transport with preserved 802.1Q VLAN tags (customer VLANs must pass through unchanged). Which MEF service attribute enables this?
- A. CE-VLAN ID preservation — the SP transports the customer's 802.1Q frames unchanged, preserving the VLAN tag from UNI to UNI across the E-LINE service(correct)
- B. The SP must translate the customer VLAN tag to an SP VLAN tag using Q-in-Q (802.1ad) — original tags are always removed and remapped
- C. E-LINE services only support untagged Ethernet frames; customers must remove 802.1Q tags at the CPE before handoff to the SP UNI
- D. VLAN tag preservation requires the E-TREE service type; E-LINE services always operate as port-based services without VLAN awareness
Explanation: MEF E-LINE services can be provisioned as either port-based (all traffic from the UNI port is transported, including any VLAN tags) or VLAN-based (specific 802.1Q VLAN IDs are mapped to an EVC). CE-VLAN ID preservation is a MEF service attribute that specifies whether the customer's original 802.1Q VLAN tags are delivered transparently to the remote UNI — for financial customers requiring transparent LAN extension, preserving CE-VLAN tags is typically required. Q-in-Q (802.1ad) adds an outer SP VLAN tag while preserving the inner customer tag; untagged-only operation is not a standard E-LINE requirement.
. An engineer runs 'show isis adjacency' on an IOS XR router and sees the following output. What does the 'UP' state and 'L2' level indicate? System Id Interface SNPA State Hold Changed NSF IPv4/IPv6 P-ROUTER-2 Gi0/0/0/1 *PtoP* Up 26 00:04:32 Capable Up/None
- A. The adjacency is Up and operating at IS-IS Level 2 (backbone level), which routes between different IS-IS areas; NSF Capable means the neighbor supports Graceful Restart(correct)
- B. The adjacency is Up at IS-IS Level 2, meaning it only routes Level 2 inter-area traffic; the 'NSF Capable' flag means this is a backup adjacency used only during failures
- C. L2 indicates the adjacency is on a Layer 2 Ethernet segment; IS-IS is running in bridging mode on this interface
- D. The Hold timer of 26 seconds indicates the adjacency will expire in 26 seconds; the 'Up' state will transition to 'Init' when the timer reaches zero
Explanation: In IS-IS, Level 1 (L1) routing is intra-area (routing within a single IS-IS area), and Level 2 (L2) routing is inter-area (routing between different IS-IS areas — the backbone). An L2 adjacency means both routers are L2 or L1/L2 routers and are exchanging Level 2 LSPs. The 'Up' state confirms the adjacency is active. 'NSF Capable' in the output indicates that the IS-IS neighbor has advertised Graceful Restart (NSF) capability in its IIH hello PDUs. The Hold timer shows the remaining time before the adjacency would expire if no hellos are received — it is constantly refreshed by incoming IIH packets.
. An IOS XR engineer needs to verify that BFD sessions are active for all BGP neighbors. The engineer runs 'show bfd session'. Which fields in the output confirm the BFD session is actively monitoring the BGP peer?
- A. The 'State' field showing 'Up' and the 'H/W' field showing 'Yes' confirm the BFD session is active and hardware-offloaded to the line card for sub-second detection(correct)
- B. The 'State' field showing 'Init' means the BFD session is in the process of establishing — this is the expected steady-state for active monitoring
- C. BFD sessions for BGP are only visible in 'show bgp neighbors <ip> detail'; the 'show bfd session' command only shows BFD sessions for IGP protocols
- D. The 'Echo' field showing 'Yes' in the BFD output indicates that BFD is using echo mode, which provides the most reliable failure detection for BGP peers
Explanation: In IOS XR 'show bfd session' output, the key indicators of a healthy active BFD session are: 'State: Up' (session is actively exchanging BFD control packets and the path is verified), and 'H/W: Yes' (the BFD session has been offloaded to line card hardware, enabling microsecond-level packet processing without RP involvement). When BFD detects a failure, it immediately notifies the client protocol (BGP in this case), which triggers fast convergence. 'State: Init' indicates the session is still being established (not a steady state). BFD sessions for all client protocols (BGP, IS-IS, OSPF, RSVP) are visible in 'show bfd session'.
. An engineer reviews the following IOS XR BGP configuration on a PE router. What is the role of the 'update-source Loopback0' statement? router bgp 65000 bgp router-id 10.0.0.1 neighbor 10.0.0.2 remote-as 65000 update-source Loopback0 address-family vpnv4 unicast
- A. update-source Loopback0 forces BGP to source its TCP session from the Loopback0 IP address, ensuring session stability since loopbacks do not go down when physical interfaces fail(correct)
- B. update-source Loopback0 sets the BGP next-hop for all VPNv4 routes to the Loopback0 address, which is required for MPLS L3VPN next-hop resolution
- C. update-source Loopback0 is required for iBGP sessions and has no effect on eBGP — it configures the source of BGP KEEPALIVE messages only
- D. update-source Loopback0 binds the BGP session to a specific VRF routing table associated with Loopback0
Explanation: The 'update-source' command specifies the source IP address that IOS XR BGP uses for the TCP session establishing the BGP peering. Using Loopback0 (or any loopback interface) as the source is a best practice for iBGP sessions in SP networks because loopback interfaces never go down as long as the router is operational — they are not affected by physical link failures. If the BGP session were sourced from a physical interface IP address, any failure of that interface would reset the BGP session even if alternative paths exist via other interfaces. The neighbor's BGP configuration must reference the loopback IP, and the loopback must be reachable via the IGP (IS-IS or OSPF).
. An engineer interprets the following IOS XR 'show bgp vpnv4 unicast all summary' output. PE-1 has neighbor 10.0.0.5 showing 'Idle' state. What is the most likely cause and first troubleshooting step? Neighbor Spk AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down St/PfxRcd 10.0.0.5 0 65000 0 0 0 0 0 00:00:15 Idle
- A. Idle state with 0 messages received/sent and a very short Up/Down time (15 seconds) indicates the session has never established; the first step is to verify IGP reachability to 10.0.0.5 with 'show route 10.0.0.5' and verify the neighbor is configured with the correct 'update-source' loopback(correct)
- B. Idle state means the BGP hold timer expired; the engineer should increase the BGP hold timer with 'timers bgp 60 180' to prevent future session drops
- C. Idle is the normal steady state for a VPNv4 address family neighbor — the neighbor will become Active when the first VPN route is available to advertise
- D. Idle state indicates a BGP policy is blocking the session — the engineer should check for an inbound route-policy on this neighbor that is dropping all prefixes
Explanation: In BGP, 'Idle' with 0 messages sent/received and a very recent Up/Down timestamp (15 seconds) indicates the session has not been able to complete the TCP handshake — the BGP session never reached Active or OpenSent state. The most common causes are: (1) the loopback IP used as the BGP source is not reachable via the IGP from the remote end, (2) incorrect 'update-source' configuration — the local router is sourcing the session from a different address than the remote router expects, or (3) a firewall/ACL blocking TCP port 179. 'show route 10.0.0.5' verifies IGP reachability to the intended neighbor loopback. Idle is never a normal steady state for an expected BGP session.
. An IOS XR router is configured with IS-IS metric-style wide and segment routing MPLS. The engineer wants to verify that prefix SIDs are being advertised in the IS-IS LSP for the router's loopback. Which IOS XR command displays the IS-IS link state database entry for the local router including SR prefix-SID advertisements?
- A. show isis database detail(correct)
- B. show segment-routing mpls mapping-server
- C. show mpls label table detail
- D. show isis route 10.0.0.1/32 detail
Explanation: The 'show isis database detail' command displays the full content of the IS-IS Link State Database, including all TLVs and sub-TLVs from all routers in the IS-IS domain. For SR-enabled routers, the LSP will contain SR-specific TLVs including the SR Capabilities sub-TLV (advertising the SRGB range), and for each prefix (such as the loopback), a Prefix-SID sub-TLV in TLV 135/235 containing the SID index value. This is the primary command to verify that a router is correctly advertising its SR capabilities and prefix SIDs to the rest of the IS-IS domain. The detail output shows all TLV types including SR-specific extensions.
. An IOS XR engineer is configuring QoS on an MPLS core interface to prioritize voice traffic (MPLS EXP 5) and assign it to a strict priority queue. The interface is GigabitEthernet0/0/0/2. Which IOS XR QoS configuration correctly implements this?
- A. class-map match-any EXP5 match mpls experimental topmost 5 policy-map CORE-QOS class EXP5 priority level 1 service-policy CORE-QOS interface GigabitEthernet0/0/0/2 service-policy output CORE-QOS
- B. class-map match-any EXP5 match mpls experimental topmost 5 policy-map CORE-QOS class EXP5 priority level 1 interface GigabitEthernet0/0/0/2 service-policy output CORE-QOS(correct)
- C. qos-group 5 dscp ef interface GigabitEthernet0/0/0/2 service-policy output CORE-QOS
- D. interface GigabitEthernet0/0/0/2 ip access-group VOICE-ACL in priority-queue out
Explanation: In IOS XR, MPLS EXP-based QoS requires: (1) a class-map using 'match mpls experimental topmost <value>' to match the EXP bits in the topmost MPLS label — 'topmost' specifies the outermost label in the stack; (2) a policy-map with the class assigned to 'priority level 1' (strict priority/LLQ); (3) the policy-map applied to the interface output direction using 'service-policy output'. Option A has a 'service-policy' statement inside the policy-map which is invalid (that's a nested policy-map, not an interface application). Options C and D use incorrect syntax for MPLS EXP matching.
. An engineer configures PIM-SM on an IOS XR router. The RP address is 10.255.255.1 and must be statically configured. The interface toward the RP is GigabitEthernet0/0/0/0. Which IOS XR command correctly configures the static RP?
- A. ip pim rp-address 10.255.255.1
- B. router pim address-family ipv4 rp-address 10.255.255.1(correct)
- C. multicast-routing address-family ipv4 interface GigabitEthernet0/0/0/0 rp-address 10.255.255.1
- D. router pim rp-static 10.255.255.1 bidir
Explanation: In IOS XR, PIM-SM configuration is done within the 'router pim' configuration hierarchy. The RP address is configured under the address-family context: 'router pim' → 'address-family ipv4' → 'rp-address <RP-IP>'. The optional 'group-list' parameter can restrict which multicast groups use this RP. Option A uses IOS (classic) syntax ('ip pim'). Option C incorrectly places the RP address under the 'multicast-routing' interface configuration — this section configures multicast forwarding on interfaces, not the RP address. Option D uses invalid 'rp-static' syntax that is not standard IOS XR.
. An engineer is troubleshooting BGP route policy application on IOS XR. The engineer needs to check which routes from eBGP peer 198.51.100.5 are being accepted after the inbound route-policy is applied. Which command directly shows the routes received from a specific neighbor after policy processing?
- A. show bgp neighbors 198.51.100.5 received-routes — displays all routes received from the neighbor before inbound policy is applied (Adj-RIB-In pre-policy)
- B. show bgp neighbors 198.51.100.5 routes — displays only the routes from this neighbor that passed the inbound policy and were accepted into the BGP table (Adj-RIB-In post-policy)(correct)
- C. show bgp ipv4 unicast — displays all BGP routes in the global table; routes from 198.51.100.5 can be filtered by the neighbor field
- D. show route protocol bgp — displays all routes from BGP in the RIB but does not show neighbor-specific information
Explanation: In IOS XR (consistent with IOS behavior), BGP provides two views of received routes per neighbor: 'show bgp neighbors <IP> received-routes' shows the Adj-RIB-In (pre-policy) — all routes received from the neighbor BEFORE any inbound route-policy is applied (requires 'soft-reconfiguration inbound' or 'route-policy-changed' to be stored). 'show bgp neighbors <IP> routes' shows the routes that actually passed the inbound policy and were accepted into the BGP table — the Adj-RIB-In post-policy view. To debug which routes a policy is accepting or rejecting, comparing the two outputs reveals which prefixes the policy filtered.
. An IOS XR router shows the following BFD session output for an IS-IS neighbor. The state is 'Down'. The IS-IS adjacency is still 'Up'. What does this indicate? RP/0/RSP0/CPU0:PE1# show bfd session IPv4: Neighbor State Detect Mult Desired TX Interval Required RX Interval 10.1.1.2 Down 3 300ms 300ms
- A. A BFD session in 'Down' state with IS-IS still 'Up' indicates IS-IS is ignoring the BFD failure — this is normal because IS-IS uses its own hold timer independently of BFD
- B. The BFD session is 'Down' but the IS-IS adjacency may not yet have timed out — depending on IS-IS hello timer configuration, the adjacency will go down soon; BFD failure should trigger immediate IS-IS adjacency teardown if BFD is correctly registered to IS-IS(correct)
- C. BFD Down state means the BFD process is administratively disabled; IS-IS continues normally and BFD is not affecting the IS-IS session
- D. This is expected behavior — BFD and IS-IS adjacencies operate completely independently and a BFD Down state never affects IS-IS adjacency state
Explanation: When BFD is enabled under the IS-IS interface configuration ('bfd minimum-interval <ms> multiplier <n>'), IOS XR registers IS-IS as a client of the BFD session. If BFD detects the neighbor as down (the BFD session state transitions to 'Down'), BFD immediately notifies IS-IS, which should cause IS-IS to tear down the adjacency immediately — much faster than waiting for the IS-IS hold timer to expire. If BFD shows 'Down' but IS-IS is still 'Up', it may indicate a timing window (IS-IS notification is pending), a misconfiguration where BFD is not registered to IS-IS on this interface, or an IOS XR software issue. The correct behavior is IS-IS adjacency teardown within milliseconds of BFD declaring the session down.
. An engineer runs 'show mpls ldp neighbor' on an IOS XR router. The output shows a neighbor with state 'Operational'. What does this indicate?
- A. The LDP session is fully established and label bindings are being exchanged between the local router and the neighbor(correct)
- B. 'Operational' means the neighbor has been discovered via UDP hello but the TCP session has not yet been established
- C. 'Operational' means the LDP session is configured but administratively shut down
- D. 'Operational' means the LDP session is in the graceful restart recovery window after an RP switchover
Explanation: In IOS XR, LDP neighbor states progress from discovery (UDP hello received) to TCP session establishment to label binding exchange. The 'Operational' state in 'show mpls ldp neighbor' output indicates the LDP session has fully established — the TCP connection is up, the LDP initialization exchange is complete, and label bindings are actively being advertised and received. This is the steady-state for a functioning LDP peer relationship. Partial states (such as 'TCP connecting' or 'Init') indicate the session is still being established.
. An engineer verifies MPLS L3VPN forwarding and runs 'show mpls forwarding' on a PE router. For the remote PE's loopback prefix 10.0.0.2/32, the output shows label operation 'Swap 16002' on outgoing interface GigabitEthernet0/0/0/0. What does the 'Swap 16002' operation indicate?
- A. The router pops the current top label and pushes label 16002 — this is used at the PHP (penultimate hop) router before the packet reaches the label's owner
- B. The router replaces the incoming MPLS label with label 16002 and forwards the packet out GigabitEthernet0/0/0/0 — this is a standard label swap operation at a transit LSR(correct)
- C. The router pushes label 16002 onto the label stack in addition to the existing label — this operation is used when adding an SR segment to a label stack
- D. Label 16002 is the VPN label (inner label) for the customer VRF — the swap operation indicates this is the egress PE performing VRF lookup
Explanation: In MPLS, the three fundamental label operations are Push (add a label to the stack), Pop (remove the top label), and Swap (replace the top label with a new value). A 'Swap 16002' operation at a transit LSR (P router or PE forwarding toward a remote PE) means: receive the packet with the current top label, replace that label value with 16002, and forward out the specified interface. Label 16002 is a Segment Routing label derived from the SRGB base plus the prefix-SID index of the remote PE's loopback (e.g., SRGB base 16000 + index 2 = 16002). The packet continues through the MPLS network with the swapped label until it reaches the label owner.
. An engineer runs 'show segment-routing traffic-eng policy detail' on an IOS XR router and sees the following: Policy: SR-TE-POLICY-1 Color: 100 End-point: 10.0.0.5 Status: Up Admin: up Operational: up Candidate-paths: Preference: 200 (explicit) Active Explicit: segment-list SL-PRIMARY 10.0.0.2 [16002] 16003 16005 Preference: 100 (dynamic) Weight: 0 Metric Type: TE What does the candidate-path with Preference 200 indicate?
- A. The active candidate path uses an explicitly configured segment list 'SL-PRIMARY' with a label stack [16002, 16003, 16005] — higher preference value wins, so this explicit path is preferred over the dynamic path with preference 100(correct)
- B. Preference 200 means this path has a lower priority — SR-TE uses ascending preference so preference 100 is preferred over preference 200
- C. The explicit segment list represents three separate MPLS tunnels that are load-balanced across — the preference value determines the load-balancing weight
- D. The label stack [16002, 16003, 16005] contains only adjacency SIDs — prefix SIDs cannot be used in an SR-TE explicit path segment list
Explanation: In IOS XR SR-TE policy, candidate-paths can be explicit (operator-defined segment lists) or dynamic (PCE or local computation). When multiple candidate-paths exist for the same policy, the one with the HIGHEST preference value is selected as the active path — higher preference wins (this is the opposite of OSPF/IS-IS metric where lower is better). The segment list [16002, 16003, 16005] is an ordered stack of SR labels (prefix-SIDs or adjacency-SIDs) that define the explicit path through the network. The packet enters the network with this label stack imposed and follows the explicit path through nodes 10.0.0.2 → next → next → 10.0.0.5. The dynamic path (preference 100) is a backup activated only if the explicit path becomes unavailable.
. An IOS XR PE router is configured with MPLS LDP. The engineer verifies the LDP configuration with 'show mpls ldp parameters' and notices the LDP router-id is set to 10.0.0.1 (Loopback0). Why is it important to configure the LDP router-id explicitly as the loopback address?
- A. Without explicit configuration, IOS XR selects the highest IP address from any interface as the LDP router-id — if a physical interface is used, LDP session resets will occur whenever that interface bounces(correct)
- B. The LDP router-id must match the BGP router-id exactly; using a loopback ensures both IDs are the same value
- C. LDP requires the router-id to be in the same subnet as the iBGP peer addresses; a loopback in the /32 range satisfies this requirement
- D. The LDP router-id is only used for LDP discovery and has no effect on session stability; explicit configuration is purely cosmetic
Explanation: IOS XR LDP selects a router-id automatically if not explicitly configured — it chooses the highest numerical IP address from any interface that is up. If a physical interface is selected and that interface goes down (link failure, maintenance), the LDP router-id changes or becomes unavailable, causing all LDP sessions to reset and all label bindings to be withdrawn and re-established. Explicitly configuring the LDP router-id to a loopback address ('mpls ldp router-id Loopback0 force' in IOS XR) ensures stability because loopback interfaces are always up as long as the router is running. This is a critical best practice in SP deployments.
. An engineer runs 'show mpls ldp bindings 10.1.1.0 24 detail' on an IOS XR PE router and sees the prefix has a local binding with label 24001 and a remote binding from neighbor 10.0.0.2 with label 16001. The entry is marked 'Used' for the remote binding. What does 'Used' indicate for the remote binding?
- A. 'Used' on the remote binding means it was selected for installation in the LFIB as the active forwarding label for reaching 10.1.1.0/24 via neighbor 10.0.0.2(correct)
- B. 'Used' means the label binding was learned from the neighbor but has been marked as a duplicate and is not being used for forwarding
- C. 'Used' means the binding is administratively configured and overrides any dynamically learned LDP bindings for the same prefix
- D. 'Used' on a remote binding indicates that the label has been advertised to all downstream LDP neighbors as the local binding for this prefix
Explanation: In IOS XR 'show mpls ldp bindings' output, the LIB (Label Information Base) stores all label bindings received from all LDP neighbors (remote bindings) and locally assigned bindings (local bindings). For remote bindings, the 'Used' flag indicates that this particular binding has been selected as the best/active binding and has been installed in the LFIB (Label Forwarding Information Base) — it is the label that will be used in the MPLS label swap operation when forwarding traffic toward prefix 10.1.1.0/24 via the next-hop neighbor. Bindings from other neighbors for the same prefix will be in the LIB but not marked 'Used' if they lost the best-path selection.
. An IOS XR PE router is configured with an L2VPN xconnect group for a pseudowire to a remote PE at 10.0.0.8. The engineer runs 'show l2vpn xconnect' and sees the pseudowire state is 'UP UP'. What does the 'UP UP' status represent?
- A. The first 'UP' indicates the attachment circuit (customer-facing interface) is operationally up; the second 'UP' indicates the pseudowire to the remote PE is operationally up(correct)
- B. Both 'UP' values indicate that both PE routers at either end of the pseudowire have confirmed the xconnect is active — one 'UP' per PE endpoint
- C. 'UP UP' means the pseudowire has two active paths for redundancy — both primary and backup pseudowires are operational
- D. 'UP UP' means the pseudowire is in active state on both the control plane and the data plane — the first 'UP' is control plane and the second is data plane confirmation
Explanation: In IOS XR 'show l2vpn xconnect' output, the two-field status (e.g., 'UP UP') reports the state of the two components that make up a point-to-point xconnect: the first field is the state of the AC (Attachment Circuit) — the customer-facing interface (e.g., an Ethernet subinterface or port); the second field is the state of the PW (Pseudowire) — the MPLS-encapsulated tunnel to the remote PE. Both must be 'UP' for end-to-end L2VPN service to work. Common failure states include 'DN DN' (both down), 'UP DN' (AC is up but pseudowire is down, often due to MPLS connectivity issue), or 'DN UP' (pseudowire is up but the customer interface is down).
. An engineer needs to verify that a VPLS instance on IOS XR is learning customer MAC addresses correctly on both local attachment circuits and remote pseudowires. Which IOS XR command displays the MAC address table for a specific VPLS bridge domain?
- A. show l2vpn bridge-domain bd-name VPLS-CUSTOMER mac detail(correct)
- B. show arp vrf VPLS-CUSTOMER
- C. show mac-address-table vlan 100
- D. show l2vpn forwarding mac address
Explanation: In IOS XR, VPLS MAC address tables are maintained within L2VPN bridge domains. The command 'show l2vpn bridge-domain bd-name <NAME> mac detail' displays the MAC address table for the specified bridge domain, including: learned MAC addresses, the interface or pseudowire through which each MAC was learned, aging timers, and static vs. dynamic entries. The 'detail' keyword shows additional information including the MPLS label used to reach remote MAC addresses via pseudowires. 'show mac-address-table vlan' is IOS/NX-OS syntax. 'show arp' shows Layer 3 ARP entries, not Layer 2 MAC forwarding tables.
. A service provider configures a VPLS service on IOS XR using LDP signaling. Two PE routers (PE1 and PE2) are configured in the same VPLS instance. An engineer on PE1 runs 'show l2vpn bridge-domain detail' and sees the pseudowire to PE2 is in 'Standby' state despite both PE routers being reachable. What is the most likely cause?
- A. The pseudowire is in Standby because PE2 has a higher router-id and won the VPLS designated forwarder election — PE1's pseudowire is the backup
- B. The VC ID (Virtual Circuit ID) configured on PE1 for this pseudowire does not match the VC ID configured on PE2's end of the same pseudowire — LDP negotiation fails and the pseudowire remains in Standby
- C. Standby state in VPLS indicates the pseudowire is administratively shut down with the 'shutdown' command under the xconnect group
- D. The pseudowire is in Standby because the MTU configured on PE1's pseudowire does not match PE2's configured MTU — LDP label mapping is refused and the pseudowire does not come up(correct)
Explanation: In MPLS pseudowire and VPLS signaling via LDP (RFC 4447), LDP Label Mapping messages include interface parameters TLVs that must match on both endpoints for the pseudowire to transition to 'Up' state. One critical parameter is MTU — both PEs must agree on the MTU of the pseudowire. If PE1 signals MTU 1500 and PE2 signals MTU 9000 (or any mismatch), LDP will refuse the label mapping and the pseudowire remains in 'Standby' (signaled but not operationally active). Other parameters that can cause this include encapsulation type and VLAN ID. The VC ID mismatch would prevent LDP signaling from matching the pseudowire at all (the pseudowire wouldn't be found). The 'show l2vpn xconnect detail' command shows the specific mismatch reason.
. A BNG engineer on IOS XR configures subscriber access for PPPoE sessions. The subscribers need to be authenticated via RADIUS and have their IP addresses assigned from a local IP pool. Which IOS XR configuration component defines the local IP address pool for PPPoE subscriber assignment?
- A. ip local pool PPPoE-POOL 100.64.0.1 100.64.1.254 — defines a local address pool in the global configuration
- B. address-pool PPPoE-POOL address range 100.64.0.1 100.64.1.254 — configured under 'pool vrf default ipv4' in IOS XR(correct)
- C. dhcp pool PPPoE-POOL network 100.64.0.0 255.255.254.0 default-router 100.64.0.1 — PPPoE uses DHCP pools for address assignment
- D. ipv4 address pool PPPoE-POOL 100.64.0.1/23 — configured under the BNG interface policy-map
Explanation: In IOS XR BNG, local IPv4 address pools for subscriber assignment are configured under the 'pool vrf <vrf-name> ipv4 <pool-name>' configuration hierarchy: 'pool vrf default ipv4 PPPoE-POOL' → 'address range 100.64.0.1 100.64.1.254'. This creates a named pool in the context of a specific VRF. The pool name is then referenced in the subscriber service profile or directly in the RADIUS response via the Framed-Pool attribute. Option A uses IOS (classic) syntax. Option C uses DHCP pool syntax which is separate from PPPoE IP address assignment. Option D uses invalid syntax.
. An IOS XR engineer wants to retrieve the running configuration of a router using NETCONF. Which NETCONF RPC operation and datastore target are used to retrieve the running configuration?
- A. <get-config> RPC with <source><running/></source> — retrieves the active running configuration from the running datastore(correct)
- B. <get> RPC with <filter type='subtree'> — retrieves both running configuration and operational state
- C. <get-config> RPC with <source><candidate/></source> — the candidate datastore always mirrors the running configuration
- D. <copy-config> RPC with <target><startup/></target> — copies the running configuration to the startup datastore for retrieval
Explanation: NETCONF (RFC 6241) defines the 'get-config' RPC for retrieving configuration data from a specific datastore. The running datastore contains the active configuration currently being used by the device. The correct RPC is: <rpc><get-config><source><running/></source></get-config></rpc>. The 'get' RPC (without '-config') retrieves operational state data as well as configuration from the device's operational state tree — it does not target a specific configuration datastore. The candidate datastore is an optional writeable workspace for staging configuration changes before committing them to running — it does not automatically mirror running.
. A service provider deploys model-driven telemetry on IOS XR routers and streams BGP session state data to a time-series database. The engineer needs to verify on the router that the telemetry subscription is active and data is being sent. Which IOS XR command shows the telemetry subscription status and counters?
- A. show telemetry model-driven subscription(correct)
- B. show snmp mib ifTable
- C. show netconf-yang operational
- D. show grpc trace
Explanation: In IOS XR, 'show telemetry model-driven subscription' displays the status of all configured model-driven telemetry subscriptions. The output shows: subscription name and ID, associated sensor-groups and destination-groups, operational state (Active/Inactive), collection intervals, and critically — counters showing the number of collection cycles completed and data messages sent to the destination collector. This command is the primary operational tool for verifying that telemetry streaming is working correctly. 'show telemetry model-driven destination' shows the connection status to the collector. 'show grpc trace' shows gRPC transport-level debugging but not subscription-level telemetry status.