CCNP Service Provider common mistakes
CCNP Service Provider · Understand the traps and how to avoid them.
Treating the core as a place to summarize routes: leaking full IGP prefixes into the core instead of keeping the core IGP lean and carrying customer/internal prefixes in BGP with next-hop-self and proper route reflectors.
Candidates carry over enterprise habits where the IGP carries everything, and they underestimate how IGP scale and SPF churn degrade a service provider core; they also forget that iBGP full mesh does not scale and that route reflectors or confederations are required.
What to do instead
Practice a lab where the core runs IS-IS or OSPF only for loopbacks and link addresses, with iBGP carrying all other prefixes via route reflectors; verify with show ip bgp summary and show isis database that the IGP LSDB stays small, and confirm next-hop-self or next-hop-unchanged behavior on reflector boundaries.
Designing redundancy that is not actually redundant: building square topologies where two paths share a common node or link, or relying on a single route reflector cluster without path diversity.
Diagrams look resilient on paper, but candidates fail to trace the physical and logical failure domains, and they forget that a single RR or a shared aggregation node is a single point of failure regardless of how many links terminate on it.
What to do instead
For every proposed design, draw the topology and remove each node and each link in turn, asking whether any prefix loses reachability; add path diversity at the RR layer (redundant RRs in separate clusters or diverse PoPs) and confirm with show commands plus a simulated interface shutdown in the lab.
Convergence and fast-reroute questions answered by rote: candidates configure BFD and label it done without tuning IGP timers, LDP synchronization, or TI-LFA, and cannot explain the order of operations during a link failure.
Fast convergence in an SP network depends on layered mechanisms (physical detection, BFD, IGP SPF/LFA, MPLS FRR, BGP PIC), and candidates memorize feature names without understanding which layer triggers first or what breaks when LDP and IGP are not synchronized.
What to do instead
Build a failure lab: enable BFD, IGP LFA or TI-LFA, and BGP PIC, then shut a link and read the logs and show isis fast-reroute / show mpls traffic-eng fast-reroute output to see which mechanism fired; deliberately break LDP-IGP sync and observe the traffic loss, then fix it with mpls ldp igp sync.
Misconfiguring OSPF or IS-IS area/level boundaries: putting a summary on the wrong router, using a stub or totally stubby area where external reachability is needed, or leaking prefixes between IS-IS levels without a route leak policy.
Candidates confuse the direction of summarization (ABR vs ASBR, L1/L2 leak direction) and forget that stub areas block Type 5 LSAs, which silently removes external routes. They also overlook IS-IS default route advertisement from L1/L2 routers.
What to do instead
In the lab, place summaries explicitly on ABRs and L1/L2 routers, then verify with show ip ospf database summary and show isis database detail that the expected LSAs or LSPs appear only on the correct side; test stub behavior by checking for a default route and absence of Type 5 LSAs in the stub area.
Assuming MPLS forwarding works once LDP is up: candidates verify labels are exchanged but never check that the label stack matches the forwarding path, that PHP behavior is understood, or that MTU and label-stack depth are handled.
LDP session state does not prove end-to-end label forwarding; mismatched label bindings, PHP, explicit-null, and MTU issues on label-stacked packets cause silent drops that candidates do not test for. They also forget that the penultimate hop pops the label, so the egress interface must have the right behavior.
What to do instead
Trace a labeled packet hop by hop using show mpls forwarding-table, show mpls ldp bindings, and a traceroute with MPLS echo requests; explicitly verify PHP and explicit-null behavior, and test large packets across the MPLS core to expose MTU and fragmentation problems.
Building Layer 3 VPNs without validating the control plane and data plane separately: candidates configure VRFs and MP-BGP but never confirm route targets, RD uniqueness, or that the PE-CE protocol is redistributed correctly into the VRF.
An L3VPN has several independent failure points (VRF definition, RD/RT import-export, MP-BGP VPNv4/VPNv6 advertisement, PE-CE routing, and label allocation), and candidates test only end-to-end ping, which hides which layer is broken. They also reuse RDs across VRFs and misconfigure route-target direction.
What to do instead
Verify in stages: show ip vrf and show ip route vrf on the PE, show bgp vpnv4 unicast all on both PEs to confirm RT import/export and next-hop, then show mpls forwarding-table vrf to confirm the VPN label; test with a PE-CE routing change and confirm redistribution into MP-BGP.
Treating MPLS TE or SR as a black box: candidates configure a TE tunnel or SR policy but cannot explain the path computation, the role of the IGP extensions, or what happens when the primary path fails.
Traffic engineering and segment routing require understanding of IGP extensions (TE extensions, SR extensions), path computation, and FRR interaction; candidates memorize CLI without knowing how the headend learns the topology or how the backup path is precomputed.
What to do instead
In the lab, build an explicit-path TE tunnel and an SR policy with a candidate path, then verify with show mpls traffic-eng tunnels and show segment-routing traffic-eng policy that the path matches the intended hops; shut a link on the path and confirm the backup or reoptimization behavior, explaining each step in writing.
Automating with scripts that are not idempotent or that lack error handling: candidates push configuration with a loop over devices and assume success, without checking return codes, diffing before/after, or handling partial failure.
Candidates learn Python or Ansible syntax but not operational discipline; they do not design for reruns, do not validate device state after a push, and do not account for devices being unreachable or in a partial state.
What to do instead
Write automation that is idempotent and validates: use Ansible modules with check mode and diff, or a Python script using NETCONF/NCclient or RESTCONF that compares intended versus actual state, checks return status, and logs per-device results; rerun the same playbook twice and confirm the second run reports no changes.
Ignoring model-driven telemetry and assurance data models: candidates configure SNMP polling and call it monitoring, without understanding YANG models, gNMI/gRPC subscriptions, or how streaming telemetry differs from polling.
Assurance content increasingly assumes model-driven telemetry, and candidates default to familiar SNMP traps and CLI polling; they do not know how to subscribe to a YANG path, how to interpret streaming data, or why polling misses microbursts.
What to do instead
Practice subscribing to a YANG path with gNMI or gRPC (for example an interface counters path) and compare the streamed samples with a polled counter; learn to read the YANG tree for the relevant model and verify subscription state with the device's telemetry show commands.
Skipping verification of the automation control plane: candidates run Ansible or Python against production-like devices without inventory grouping, credentials handling, or a rollback plan, and cannot explain what happens when a task fails mid-run.
Lab exercises often succeed on the first try, so candidates never build inventory structure, secrets management, or rollback; they also do not test failure injection, so partial configuration remains on devices after a failed run.
What to do instead
Structure inventory by role and site, store credentials in Ansible Vault or an external secret store, and add a rollback or remediation task; deliberately fail a task mid-playbook in the lab and verify that the device state is recovered, documenting the recovery procedure.