CCNP ENCOR Command List
The configure-and-verify commands used throughout the ENCOR labs — OSPF, BGP, ACLs, CoPP, RESTCONF/NETCONF, and EEM.
Multiarea OSPF & BGP
HSRP, VRRP, PBR, NAT
ACLs & Control Plane Policing
RESTCONF, NETCONF & EEM
Fast diagnostic commands
show ip ospf neighbor / show ip bgp summary — confirm adjacencies/peerings before assuming a routing-logic problem.
show interfaces trunk — compare native VLAN on both ends before assuming a deeper Layer 2 fault.
show ip sla configuration / show track — confirm an IP SLA operation is actually scheduled before assuming a tracked object should be Up.
show crypto ipsec sa — confirm a GRE-over-IPsec tunnel is genuinely encrypting, not just up/up.
Real scenarios you'll actually face
"The BGP neighbor has been stuck in Active/Idle for twenty minutes and won't establish." `show ip bgp summary` showing anything other than a number in the State/PfxRcd column means the session never reached Established — check basic IP reachability to the neighbor address first (a surprising number of BGP problems are actually just "can I even ping the other end"), then confirm the remote-as matches what the OTHER side thinks it's peering with, since a mismatched AS number on either side silently prevents the session from ever forming, with no obvious error pointing at the actual cause.
"HSRP failed over during maintenance, and when the primary router came back, it never took the active role back." This isn't a bug — priority alone only decides the FIRST election. `standby preempt` is the specific setting that lets a higher-priority router reclaim active status after it returns, and it's commonly left off because it doesn't matter until the exact moment you need it, during an actual failover. Traffic keeps flowing through the now-standby-turned-active router with no user-visible symptom at all, which is exactly why this gets caught during a planned maintenance test, not by a monitoring alert.
"The EEM applet I configured never fires, even though the condition it's supposed to catch clearly happened." EEM's syslog pattern match needs to be an EXACT match against the device's actual, real syslog text — `GigabitEthernet0/1` and `Gi0/1` are not interchangeable as far as EEM's pattern engine is concerned, even though a human reading the log would consider them identical. `show logging` to copy the EXACT text the device actually generated, not what you assume it generated, is the fix — guessing at the abbreviation format is the most common reason a perfectly reasonable-looking EEM applet silently never triggers.
Want a printable copy?
This complete guide is also available as a professionally formatted PDF.
Download PDF ↓