Cisco SPRI 300-510 common mistakes
Cisco SPRI 300-510 · Understand the traps and how to avoid them.
When a redistribution question asks why an OSPF external route is missing or has the wrong metric, the candidate redistributes into OSPF and stops there, never checking that the seed metric is 20 by default and never checking the metric-type (E1 vs E2). They also forget that redistributing into OSPF does not automatically advertise the route unless a matching 'redistribute' statement exists on the ASBR and the route is in the RIB.
Most candidates memorize 'redistribute connected subnets' as a syntax drill and never internalize that OSPF defaults external routes to E2 with metric 20, that E1 adds internal cost to the seed, and that a route must first be installed in the routing table before redistribution will pick it up. Lab guides rarely force the candidate to compare E1 and E2 forwarding decisions.
What to do instead
For every redistribution task, write down four things before configuring: the source protocol and its administrative distance, the seed metric you want (default-metric or metric on the redistribute line), the metric-type, and whether a route-map or prefix-list is filtering. Verify with 'show ip ospf database external' that the forwarding address and metric type are what you intended, and trace the E1/E2 cost to the destination.
On IS-IS questions, the candidate configures the router as level-1-2 and assumes inter-area reachability is automatic, without checking that the level-2 router is setting the ATT bit or that the level-1 router has a default route toward the nearest L1/L2 router. They also misconfigure NET addresses (wrong system ID length, duplicate system IDs) and then blame the adjacency.
IS-IS level terminology (L1, L2, L1/L2) looks like OSPF areas, so candidates map OSPF area logic onto IS-IS and expect an ABR-like behavior. In reality L1 routers only know their own area and rely on the attached bit and a default route; a duplicate system ID silently breaks the LSP database.
What to do instead
Before troubleshooting, run 'show isis neighbors' and confirm the adjacency type and the system ID of each neighbor. Check 'show isis database' for duplicate LSP IDs and confirm each router's NET uses a unique 6-byte system ID. If an L1 router cannot reach another area, verify the L1/L2 router sets the ATT bit ('show isis database detail') and that the L1 router installs a default route.
On BGP path-selection questions, the candidate jumps straight to weight or local preference and skips the earlier tie-breakers, especially the 'weight' (Cisco-only, highest wins), then 'local preference' (highest), then the locally originated route, then AS-path length, then origin, then MED. They also forget that a route learned from an iBGP peer is not preferred over a locally originated route and that the router-ID tie-breaker comes after MED and eBGP-over-iBGP.
Path selection is a long ordered list that is easy to memorize in fragments. Candidates study the list but never practice walking it in order on a topology where multiple attributes differ at once, so they pick the attribute they remember best rather than the first one that breaks the tie.
What to do instead
Memorize the order as a mnemonic and rehearse it: Weight, Local Preference, locally originated, AS-path length, Origin, MED, eBGP over iBGP, lowest IGP metric to next hop, oldest route, lowest router ID, lowest neighbor address. On any exam scenario, list each candidate route's attributes in a table and eliminate them one tie-breaker at a time in that exact order.
On route-reflector and confederation questions, the candidate assumes a route reflector will reflect a route back to the peer it learned it from, or assumes a confederation sub-AS behaves exactly like a normal AS for AS-path and next-hop purposes. They also forget that a route reflector only reflects to clients and non-clients according to cluster-list and originator-ID loop prevention.
The rules for route reflection (client-to-client, client-to-non-client, non-client-to-client, non-client-to-non-client) and the confederation AS-path notation (AS_CONFED_SEQUENCE, AS_CONFED_SET) are rarely exercised in basic labs, so candidates rely on a vague mental model.
What to do instead
Draw the four route-reflector propagation cases explicitly and note that a non-client-to-non-client route is not reflected. For confederations, remember that the confederation ID is what external peers see, sub-AS numbers appear only in AS_CONFED_SEQUENCE, and next-hop is unchanged across sub-AS boundaries. Verify with 'show ip bgp' and read the path field for confederation segments.
On MPLS LDP questions, the candidate assumes an LDP session will come up over any interface that has an IGP adjacency, without checking that 'mpls ip' is enabled on the interface, that the LDP router ID is reachable, and that the label allocation mode (liberal vs conservative) and label distribution mode match. They also miss that LDP uses UDP 646 for discovery and TCP 646 for the session.
Candidates conflate IGP adjacency with LDP adjacency and assume enabling MPLS globally is enough. LDP requires per-interface enablement, a reachable router ID (usually a loopback), and matching session parameters; a mismatch in label distribution or a missing 'mpls ldp router-id' silently prevents label binding.
What to do instead
Check in order: 'mpls ip' on the interface, 'mpls ldp router-id loopback0 force' so the router ID is stable, IGP reachability to the peer's router ID, and 'show mpls ldp neighbor' for the session state. Confirm label bindings with 'show mpls ldp bindings' and the LFIB with 'show mpls forwarding-table'. Remember UDP/TCP 646.
On MPLS TE questions, the candidate configures a tunnel but never verifies that the IGP is flooding TE attributes (IS-IS wide metrics or OSPF opaque LSAs), that CSPF has a viable path, or that the tunnel's autoroute announce actually installs the tunnel as a route. They also forget that TE tunnels need 'mpls traffic-eng tunnels' on every transit interface and that RSVP is the signaling protocol.
MPLS TE spans IGP extensions, RSVP signaling, and CSPF path computation, and candidates learn the tunnel interface commands without the prerequisite chain. If TE flooding is off or the metric is not wide, CSPF sees no bandwidth and the tunnel stays down.
What to do instead
Verify the chain: 'mpls traffic-eng tunnels' on transit interfaces, 'mpls traffic-eng router-id' and 'mpls traffic-eng level-2' (IS-IS) or 'mpls traffic-eng area' (OSPF), IS-IS wide metrics or OSPF opaque capability, then RSVP bandwidth on links. Confirm with 'show mpls traffic-eng topology' and 'show mpls traffic-eng tunnels' that the path is computed and the tunnel is up before expecting autoroute to install it.
On SR-MPLS and SRv6 questions, the candidate confuses the segment routing global block (SRGB) with the prefix-SID, assumes an adjacency SID is globally significant, or thinks SRv6 locators are the same as SR-MPLS SIDs. They also forget that SR requires IGP extensions (IS-IS or OSPF segment routing) and that TI-LFA is the fast-reroute mechanism, not a separate routing protocol.
Segment routing terminology is dense and new relative to classic MPLS. Candidates mix up global vs local significance, index vs absolute SID, and the SRv6 locator/function split, because they study the concepts separately from the configuration.
What to do instead
Anchor on definitions: SRGB is a per-node label range, a prefix-SID is an index into that range (global significance within the SR domain), an adjacency-SID is locally significant, and an SRv6 locator is an IPv6 prefix with a function appended. Configure 'segment-routing mpls' plus the IGP SR extension, verify with 'show segment-routing mpls mapping-server' or 'show isis segment-routing', and remember TI-LFA provides the backup path.
On PIM-SM questions, the candidate cannot explain the shared tree versus the shortest-path tree, so they misdiagnose why traffic is not flowing: they forget the RP must be reachable, that the (*,G) join goes to the RP, that the switchover to (S,G) is triggered by the first data packet, and that PIM-SSM requires IGMPv3 and does not use an RP.
PIM is a reverse-path-forwarding protocol, and candidates learn the join/prune messages without tracing the RPF check. When traffic fails, they look at the multicast route table without checking the unicast RPF interface, the RP reachability, or whether the receiver sent an IGMPv3 report.
What to do instead
Troubleshoot in order: 'show ip rpf ' to confirm the RPF interface matches the incoming interface, 'show ip pim rp mapping' for RP reachability, 'show ip mroute' to see (*,G) and (S,G) state, and the IGMP version on the receiver interface. For SSM, confirm IGMPv3 and the (S,G) join with no RP.
On MSDP and mLDP questions, the candidate assumes MSDP is needed for SSM or that it carries multicast data, and they conflate mLDP (multipoint LDP for MVPN) with PIM. They also forget that MSDP peers use TCP 639 and that an MSDP mesh group is used to avoid SA flooding loops between RPs.
MSDP is a rendezvous-point-to-rendezvous-point protocol for inter-domain any-source multicast; it distributes source-active messages, not data. mLDP is a label distribution protocol for point-to-multipoint LSPs used in MVPN. Candidates group all multicast protocols together and lose the distinctions.
What to do instead
State each protocol's job: PIM builds trees, MSDP shares SA messages between RPs across domains over TCP 639, mLDP signals P2MP LSPs for MVPN. Use 'show ip msdp peer' and 'show ip msdp sa-cache' to verify SA exchange, and remember SSM needs no RP or MSDP.
On high-availability questions, the candidate treats NSR, NSF, and graceful restart as interchangeable, and cannot say which one preserves forwarding during a supervisor switchover versus a protocol restart. They also forget that BFD must be configured on both ends with matching timers and that TI-LFA and PIC are fast-reroute mechanisms triggered by local repair, not by BGP convergence.
The acronyms overlap: NSR keeps state across a route-processor switchover without help from neighbors; NSF/GR lets a restarting router ask neighbors to hold routes; BFD detects failures faster than IGP hellos; TI-LFA and PIC precompute backup paths. Candidates memorize the names but not the failure each one covers.
What to do instead
Map each mechanism to its failure: NSR for RP switchover with no neighbor impact, NSF/GR for a protocol process restart, BFD for sub-second link/node failure detection (configure 'bfd interval' and 'bfd echo' consistently on both sides), TI-LFA for IGP fast reroute with backup labels, PIC for MPLS TE local protection. Verify with 'show bfd neighbors', 'show isis fast-reroute', and 'show mpls traffic-eng tunnels protection'.