Cisco CCNP Enterprise Core Exam Prep

8.4 Apply ACLs with Correct Placement and Direction

ACL placement is where good intentions go to either work or fail. Direction decides which traffic is evaluated, and placement decides where the decision is enforced. Together, they determine whether packets get filtered before they ever reach the next hop.

Foundational Concepts That Drive Placement

An ACL is evaluated in order, top to bottom, and the first matching entry wins. If no entry matches, the implicit behavior is to deny. That means your “allow” rules must be specific enough to match the intended traffic, and your “deny” rules must be placed after the relevant allows.

Direction matters because an interface sees different traffic depending on where you attach the ACL:

• Inbound ACLs filter traffic entering the router or switch interface.
• Outbound ACLs filter traffic leaving the interface.

On a typical enterprise edge, inbound ACLs are often used to protect the device and the inside network from unwanted sources. Outbound ACLs are often used to restrict what the device sends toward a specific destination segment.

Placement Rules That Prevent Common Mistakes

Start by identifying the traffic flow you want to control. Then choose the interface and direction where the packet is still in the form you expect.

1. Protect the device first: If the goal is to restrict management access to the router or switch, place the ACL inbound on the management-facing interface. This ensures the device never processes disallowed sessions.
2. Control transit traffic: If the goal is to restrict traffic between VLANs or toward a WAN, place the ACL inbound on the interface that receives the traffic from the source side, or place it outbound on the interface that sends traffic toward the destination side. Pick one approach and be consistent.
3. Avoid “wrong interface” debugging: If you apply an ACL to the wrong interface, the packet will never match, and you’ll chase ghosts in counters.
4. Use the most specific match possible: If you allow a subnet broadly and later try to block a smaller subnet, the earlier allow will already match. Order is not optional.

Example: Inbound ACL on a User-Facing Interface

Goal: Only allow SSH from a specific admin subnet to the router’s user-facing interface.

Assume:

• Admin subnet: 10.10.10.0/24
• SSH TCP port: 22
• Interface: GigabitEthernet0/0 (user-facing)

Best practice: Place the ACL inbound so disallowed SSH attempts are dropped before the session is established.

ip access-list extended MGMT_SSH
 permit tcp 10.10.10.0 0.0.0.255 any eq 22
 deny   tcp any any eq 22
 permit ip any any

interface GigabitEthernet0/0
 ip access-group MGMT_SSH in

Why the final permit ip any any? Because this ACL is only meant to restrict SSH, not all traffic. If you omit it, the implicit deny at the end would block everything that doesn’t match the SSH rules.

Example: Outbound ACL Toward a Partner Network

Goal: Allow only HTTP and HTTPS from the internal server subnet to a partner network.

Assume:

• Server subnet: 192.168.50.0/24
• Partner subnet: 203.0.113.0/24
• Interface: GigabitEthernet0/1 (toward partner)

Best practice: Place the ACL outbound on the partner-facing interface so you filter what the router sends.

ip access-list extended PARTNER_WEB
 permit tcp 192.168.50.0 0.0.0.255 203.0.113.0 0.0.0.255 eq 80
 permit tcp 192.168.50.0 0.0.0.255 203.0.113.0 0.0.0.255 eq 443
 deny   ip any any

interface GigabitEthernet0/1
 ip access-group PARTNER_WEB out

Here the explicit deny ip any any is intentional because the policy is “only web.” The implicit deny would do the same job, but explicit denial makes the intent visible during review.

Verification That Confirms Placement and Direction

After applying an ACL, verify three things: attachment, match behavior, and counters.

• Confirm the ACL is attached to the correct interface and direction.
• Generate traffic that should match and traffic that should not.
• Check hit counts to ensure the expected entries increment.

Use these checks:

• show ip interface <interface> to confirm the ACL attachment.
• show access-lists <name> to confirm counters.

If counters stay at zero, the ACL is either attached to the wrong interface/direction or the match criteria don’t reflect the real traffic (wrong subnet mask, wrong port, or unexpected source IP due to NAT).

8.5 Troubleshoot Packet Drops with Counters and Debug Output

Troubleshoot Packet Drops With Counters And Debug Output

Packet drops are rarely random. They usually fall into a small set of causes: the packet never matches the rule you think it does, it matches the rule but the direction is wrong, it hits an ACL counter you ignored, or it gets dropped later by another feature (like control-plane protection or a VLAN mismatch). The goal of this section is to build a repeatable path from “something is not working” to “here is the exact drop reason.”

Start with the Symptom and Define the Expected Path

First, write down what should happen for a single test flow: source IP, destination IP, protocol, and direction (inbound or outbound on the device). Then decide where the drop would occur. For example, if a host in VLAN 10 cannot reach a server in VLAN 20, the drop could happen on the SVI, on the routed interface, or on an intermediate hop. A quick sanity check is to verify L2 reachability (ARP) and L3 reachability (routing table entry) before touching ACL counters.

Use Counters to Narrow the Suspects

ACL counters are your first “truth serum.” They tell you whether traffic matched a rule, even if the traffic never reaches the final destination.

1. Confirm the ACL is the one applied where you’re looking. On Cisco IOS, placement matters: inbound vs outbound changes everything.
2. Check counters before and after a controlled test. Run one ping or one TCP attempt, then re-check counters.
3. Look for the specific rule that increments. If “deny ip any any” increments, your earlier rules didn’t match.

Example: You suspect an extended ACL blocks VLAN 10 to VLAN 20.

• ACL rule order:
  • permit ip 10.10.10.0 0.0.0.255 10.20.20.0 0.0.0.255
  • deny ip any any
• If you ping from VLAN 10 to VLAN 20 and only the deny ip any any counter increases, the permit rule isn’t matching. Common reasons include wrong subnet masks, wrong direction, or the traffic is actually using a different source IP (like a gateway address due to NAT or misconfigured host).

Interpret Debug Output Without Getting Lost

Debug output is powerful but easy to misuse. Treat it like a microscope: narrow the scope, capture a small window, and stop quickly.

Best practice workflow:

• Enable debug only for the relevant feature and interface.
• Generate a single test flow.
• Observe the first meaningful lines, then disable debug.

For ACL-related drops, debug often shows packet processing decisions, but it may not explicitly say “ACL rule X denied.” That’s why counters and debug complement each other: counters tell you “a rule matched,” debug helps explain “why the packet was processed in that way.”

Mind Map: Drop Troubleshooting Flow

Common Counter Patterns and What They Mean

• Only the deny rule increments. The packet is reaching the ACL but not matching any earlier permit statements.
• No ACL counters increment. The ACL might not be applied to the correct interface/direction, or the traffic never reaches the device where the ACL lives.
• Permit increments but traffic still fails. The packet may be permitted by the ACL but dropped later by another mechanism, such as control-plane filtering, VLAN mismatch, or a missing return route.

Example: Direction Mistake on an Interface

You apply an ACL inbound on an interface but your mental model assumes outbound. You test with ping from VLAN 10 to VLAN 20.

• If the deny counter increments, the packet is being evaluated in the inbound direction.
• Fix is not “change the rule,” it’s “apply the rule in the correct direction or adjust the rule logic.”

A practical habit: after any ACL change, run one test flow and confirm the counter increments on the rule you expect.

Example: Debug Plus Counters for a Mask Error

Suppose your permit rule uses 10.10.10.0 0.0.0.127 but VLAN 10 actually uses 10.10.10.0/24. The permit rule won’t match half the addresses.

• Counters show deny increments.
• Debug shows packets are processed but not matched to the permit criteria.
• Correct the wildcard mask, then re-test and confirm the permit counter increments.

    flowchart TD
A[Traffic fails] --> B[Check ARP and routing basics]
B --> C{ACL counters increment?}
C -->|No| D[Verify ACL placement and direction]
C -->|Yes| E{Which rule increments?}
E -->|Deny| F[Validate match fields: IPs, masks, protocol]
E -->|Permit| G[Look for later drops and return path issues]
F --> H[Use narrow debug to confirm processing]
G --> H
H --> I[Re-test one controlled flow and confirm counters]
I --> J[Stop debug and finalize]

Operational Discipline That Prevents “Debug Whack-A-Mole”

Always correlate time: note the counter values, run one test, then re-check. If you change multiple variables at once, you lose the ability to attribute the outcome to a specific fix. When the counters and debug agree on the same story, you can stop—because you’ve found the reason the packet was dropped, not just the symptom.

9.1 Configure Local Authentication and Secure Password Handling

Local authentication means the device itself stores credentials and checks them during login. In exam scenarios, the most common mistakes are not “wrong passwords,” but missing or mismatched authentication method order, weak password handling, and forgetting to verify the exact login path (console, VTY, or auxiliary).

Foundations of Local Authentication

Start by identifying which access method you’re securing:

• Console: typically uses local credentials directly.
• VTY lines: remote access via SSH or Telnet uses line configuration plus the global AAA method list.
• Auxiliary: rare in modern labs, but still follows line-based rules.

Then decide how the device should authenticate:

• Without AAA: line commands reference local users directly.
• With AAA: you define an authentication method list and include local as one of the methods.

A simple rule for verification: always confirm both the user database and the authentication path.

Secure Password Handling Principles

Local users are created with username and a password. For secure handling, focus on three areas: hashing, privilege separation, and limiting exposure.

1. Use hashed passwords
   • Prefer secret over password. secret stores an encrypted hash; password may store a weaker form depending on platform settings.
   • Example: create a user with privilege level and hashed secret.

conf t
username admin privilege 15 secret Admin!234
username ops privilege 5 secret Ops!234
end

2. Avoid shared accounts

   • Use distinct usernames for different roles so you can attribute actions and troubleshoot accurately.
   • In labs, it’s easy to reuse admin and then wonder why audit trails look identical.

3. Control privilege levels

   • Assign privilege 15 only to accounts that truly need full access.
   • Use lower privilege levels for operators who should run show commands and limited configuration tasks.

Configure Local Authentication for Console and VTY

If you use AAA, you must ensure the method list includes local. If you don’t, line configuration must directly allow local login.

Example: AAA Method Lists with Local

conf t
aaa new-model
aaa authentication login default local
aaa authorization exec default local
end

Then ensure VTY lines use AAA for login:

conf t
line vty 0 4
login authentication default
end

For console, you can rely on local login behavior, but it’s still good practice to explicitly confirm:

conf t
line console 0
login authentication default
end

Verification Steps That Actually Matter

Use targeted show commands to confirm each layer:

• User database: confirm usernames exist and privilege levels match expectations.
• AAA status: confirm AAA is enabled and method lists are applied.
• Line behavior: confirm the line uses the intended authentication method.

show running-config | section aaa
show users
show ip ssh
show line vty 0 4
show running-config | include username

If a login fails, check the exact path: a user might exist, but the VTY line might still be using a different method list than you think.

Practical Example: Fixing a Login That Fails

Assume you created username ops secret Ops!234, but remote login still fails. The fastest systematic check is:

1. Confirm the username exists in the running config.
2. Confirm AAA is enabled and the authentication method list includes local.
3. Confirm VTY lines reference the correct method list.

If step 2 is missing, the device may not consult the local database at all. If step 3 is wrong, the device may consult a different method list than the one you edited.

Summary Checklist

• Create users with secret, not password.
• Use AAA method lists when you want consistent behavior across lines.
• Apply the method list to the correct line types.
• Verify with show commands that confirm both the user database and the line’s authentication behavior.

9.2 Implement AAA with RADIUS and TACACS Plus

AAA splits access control into three jobs: authentication proves identity, authorization decides what the user can do, and accounting records what happened. In practice, you’ll wire these jobs to a centralized server so multiple devices enforce the same rules. The exam angle is usually not “can you configure it,” but “can you prove it works” with the right show and debug outputs.

Foundational Concepts That Matter in Real Configs

RADIUS is commonly used for network access and uses UDP. It’s a frequent fit for Wi-Fi, VPN, and switch or router login where the device needs to ask, “Is this user allowed?” quickly.

TACACS Plus is commonly used for administrative access and uses TCP. It separates authentication and authorization more cleanly per request, which is why many environments prefer it for command authorization.

A key best practice is to keep the device’s local database as a fallback. That way, if the AAA server is unreachable, you can still regain access rather than locking yourself out.

Configure the Server Groups and Method Lists

On the network device, you define server groups and method lists. A method list is the ordered set of sources the device tries. Order matters: if the first method fails, the device moves to the next one.

Use separate method lists for user login and enable/privileged access. That separation prevents accidental privilege escalation when the authorization intent differs.

Example: RADIUS for User Login and TACACS Plus for Privileged Access

aaa new-model

radius-server host 192.0.2.10 auth-port 1812 acct-port 1813 key RADIUSKEY
radius-server timeout 5
radius-server retransmit 3

tacacs server TACACS1
 address ipv4 192.0.2.20
 key TACACSK

aaa group server radius RADGRP
 server 192.0.2.10 auth-port 1812 acct-port 1813

aaa group server tacacs+ TACGRP
 server name TACACS1

aaa authentication login default group RADGRP local
aaa authorization exec default group TACGRP local
aaa authorization commands 15 default group TACGRP local
aaa accounting exec default start-stop group RADGRP
aaa accounting commands 15 default start-stop group RADGRP

This example uses RADIUS for accounting and TACACS Plus for command authorization. If your environment uses TACACS Plus for accounting too, you’d switch the accounting method lists accordingly.

Add Command Authorization Without Guessing

Command authorization is where TACACS Plus shines. The server can allow or deny specific command patterns, and the device enforces those decisions at runtime.

A practical way to avoid surprises is to start with a small set of allowed commands for privilege level 15, then expand. For instance, allow show commands first, then add configuration commands once you confirm the server policy matches the exact command syntax you expect.

Verify with Targeted Checks

Verification should be systematic: confirm reachability, confirm method list selection, then confirm server responses.

1. Confirm AAA is enabled: show run | include aaa new-model.
2. Confirm server definitions: show radius summary and show tacacs server.
3. Confirm method lists: show aaa method.
4. Watch live AAA decisions: enable debugging briefly during a controlled login attempt.

debug aaa authentication
debug aaa authorization
debug radius

After the test, disable debugging to avoid excessive logging.

Common Failure Patterns and How to Prove the Cause

• Wrong shared key: authentication fails even though the server is reachable. Debug output typically shows the request arriving but being rejected.
• Port mismatch: RADIUS auth or accounting fails if the device uses different ports than the server expects. Check auth-port and acct-port alignment.
• Method list ordering mistakes: if local is placed before the server group, local users may bypass centralized policy. Confirm the order in aaa authentication login and aaa authorization lines.
• Command authorization mismatch: the server denies a command because the pattern doesn’t match. Test with the exact command you plan to authorize.

Practical Example Workflow for a Clean Implementation

Start with a single test user and a single device. Configure method lists, confirm server reachability, then attempt a login and an enable/privileged action. If authorization fails, adjust the server policy first, not the device method list. Once the test user works, repeat with a second account that has a different privilege intent so you validate both allow and deny behavior.

When everything is stable, keep the fallback local method in place. It’s not a backup plan for convenience; it’s the difference between “we fixed it” and “we’re locked out.”

9.3 Use Authorization for Command Level Control

Authorization for Command Level Control

Command authorization answers a simple question: who is allowed to run which commands, and under what conditions? In AAA terms, authentication proves identity, while authorization decides permissions. Command-level control is especially useful on shared devices where “read-only” access is not enough, but full admin access is too risky.

Foundational Model

Start with the AAA flow for a management session. First, the device authenticates the user using a method such as local, RADIUS, or TACACS+. Next, the device requests authorization for the command set. The authorization result is typically a privilege level or a named authorization profile that maps to allowed commands. Finally, the device enforces the rules at execution time, not just at login.

A practical mental model is “gatekeeping at the door and at the counter.” Login is the door; command execution is the counter. If you only control the door, users can still do damage once they get inside.

Authorization Granularity

Command authorization can be coarse or fine:

• Privilege level control: Users are assigned a privilege level (for example, 1 for limited show commands, 15 for full configuration). This is fast to implement but can be too blunt.
• Command set control: Users are allowed specific commands or command groups. This is more precise and aligns better with operational roles like NOC, network engineer, and security admin.

In Cisco IOS XE AAA, command authorization is commonly implemented with TACACS+ or RADIUS, where the server returns an authorization policy that the device enforces.

Example: Role-Based Command Control

Assume three roles for a branch router:

• NOC: Allowed to run show commands, and allowed to clear specific counters.
• NetOps: Allowed to view and modify routing configuration.
• Security Admin: Allowed to manage ACLs and AAA-related settings.

A common mistake is giving NOC privilege 15 “temporarily.” Instead, keep NOC at a low privilege and authorize only the exact commands they need. For example, permit show ip route, show interfaces status, and clear counters but deny configure terminal.

Example: How Denials Look in Practice

When command authorization denies a command, the device should respond consistently, and the server should log the attempt. In a lab, try this sequence:

1. Log in as the NOC user.
2. Run an allowed command like show ip route.
3. Attempt a denied command like configure terminal.
4. Confirm the denial message and verify the AAA server recorded the request.

This is where command authorization becomes useful for troubleshooting: you can distinguish “command not found” from “command blocked by policy.”

Configuration Pattern for Command Authorization

The exact syntax varies by platform and AAA server, but the structure is consistent: define AAA server groups, enable AAA for the relevant access method, and configure authorization for command execution.

aaa new-model

aaa group server tacacs+ TACACS-GRP
 server name TACACS1

aaa authentication login MGMT-AUTH group TACACS-GRP local
aaa authorization exec MGMT-AUTH group TACACS-GRP
aaa authorization commands 15 MGMT-CMD group TACACS-GRP

line vty 0 4
 login authentication MGMT-AUTH
 authorization commands 15 MGMT-CMD

In this pattern, authorization commands 15 means the device will request command authorization for users attempting to operate at privilege 15. If your design uses privilege levels differently, adjust the mapping so the authorization request triggers at the right moment.

Best Practices That Actually Matter

• Use least privilege by role, not by convenience. If a user needs configuration access, create a role that matches that job.
• Keep command groups small and testable. If you allow “everything in config mode,” you’ve basically re-created full admin access.
• Pair authorization with accounting. Authorization tells you what was allowed or denied; accounting tells you what was executed.
• Validate with a dry run. Before rolling out a new policy, test with at least one account per role and confirm both device behavior and server logs.

Quick Checklist for Exam-Style Scenarios

• Identify the access method (VTY, console) and confirm AAA is enabled for it.
• Determine whether the question expects privilege-level control or command-set control.
• Verify the authorization method is configured for exec and/or commands.
• Confirm the server returns the expected policy and that denials are logged.
• Use targeted show commands to confirm the active AAA policy and user privilege state.

Command authorization is the part of AAA that turns “you can log in” into “you can do only what you should.” When it’s configured cleanly, troubleshooting becomes straightforward: the device enforces policy, and the server explains why.

9.4 Configure Accounting for Auditing and Change Tracking

Accounting in AAA records what users did after they were authenticated and authorized. In practice, it helps you answer two questions quickly: “Who made this change?” and “When did it happen?” The goal is not to log everything forever, but to log the right events with enough context to reconstruct a timeline.

Foundational Concepts for Accounting

Accounting typically runs in parallel with authentication and authorization. When a session starts, the device sends a start record; when the session ends, it sends a stop record. For command accounting, the device can also send per-command records, depending on platform support and configuration.

A useful mental model is three layers of evidence:

• Identity evidence comes from authentication.
• Permission evidence comes from authorization.
• Activity evidence comes from accounting.

If you only have identity and permission, you can prove who was allowed to do something, but not what they actually did. If you only have accounting, you may know actions occurred, but not reliably tie them to a specific login method or policy outcome.

Designing What to Record

Start by deciding which access methods matter for auditing. Common targets include:

• CLI sessions (SSH, console, Telnet if present)
• Privileged EXEC transitions
• Configuration changes

Then decide the granularity:

• Session-level accounting is usually enough to track “login window” and “source IP.”
• Command-level accounting is needed when you must prove exact commands executed.

A practical best practice is to align accounting scope with risk. For example, if users can only view operational data, session-level records may be sufficient. If users can change routing policy or security settings, command-level records become more valuable.

Configuring RADIUS Accounting for Session Tracking

On Cisco IOS XE, AAA accounting is commonly sent to a RADIUS server. The device must know the server, the accounting method, and which AAA lists to apply.

Example configuration (illustrative):

aaa accounting exec default start-stop group RAD
aaa accounting commands 15 default start-stop group RAD
aaa new-model
radius-server host 192.0.2.10 auth-port 1812 acct-port 1813 key RADIUSKEY
radius-server timeout 3
radius-server retransmit 2

This sets two accounting streams:

• Exec accounting records session start and stop.
• Commands accounting records commands executed at privilege level 15.

If your environment uses TACACS+ instead, the structure is similar, but the transport and server configuration differ.

Applying Accounting to the Right AAA Lists

Accounting rules attach to AAA “lists” such as exec and commands. The key is privilege level mapping. If you only enable command accounting at level 15, you will miss changes made at lower privilege levels.

A systematic approach:

1. Identify which privilege levels can execute configuration commands.
2. Enable command accounting for those levels.
3. Confirm that privilege transitions are authorized and consistent with your operational model.

Verifying Accounting Behavior

Verification should be methodical: confirm server reachability, confirm AAA accounting triggers, then confirm record content.

Use these checks:

• Confirm the RADIUS server is reachable from the device.
• Confirm AAA accounting is enabled for the expected access method.
• Generate a controlled login and logout, then check the server logs.

On the device, you can watch for AAA accounting events. On the server, confirm you receive start and stop records with matching session identifiers.

Interpreting Accounting Records for Audits

When you review records, focus on fields that let you reconstruct events:

• Username and authentication method
• Source IP and terminal type
• Session start and stop timestamps
• Privilege level and command text (if command accounting is enabled)
• Session identifiers that tie start and stop together

A simple audit workflow:

• Find the time window of the change.
• Locate the session that overlaps that window.
• Extract the command list for that session.
• Cross-check whether the commands align with the resulting configuration diffs.

If timestamps don’t line up, the issue is often clock drift. Ensure device time and server time are consistent so your timeline doesn’t turn into a guessing game.

Example: Proving a Configuration Change

Assume a user reports that they “only checked something.” With accounting enabled, you can verify:

• The session start time and source IP.
• Whether they entered privileged mode.
• The exact commands executed at privilege level 15.

If the command list includes configuration commands that modify routing or security settings, the audit trail shows the action occurred during that session. If command accounting is missing for the relevant privilege level, the audit may show only the login window, which is why privilege mapping matters.

Operational Best Practices

Keep accounting consistent with your operational reality:

• Use start-stop for session tracking so records always close.
• Enable command accounting only where it provides value, since it increases log volume.
• Ensure time synchronization so audits remain readable.
• Test with a controlled session before relying on the logs for real investigations.

Accounting is the part of AAA that turns “allowed” into “actually done.” When configured carefully, it makes audits faster and reduces the number of times you have to ask, “Can we prove it?”

9.5 Troubleshoot AAA Failures with Logs and Test Commands

AAA failures usually look like “authentication failed” or “authorization denied,” but the root cause is often earlier: the request never reaches the AAA server, the server rejects the user, or the device applies the wrong policy. The fastest path is to separate the problem into three layers: reachability, identity, and authorization.

Foundational Checks Before You Touch Policies

Start with the basics that determine whether AAA can even work.

1. Confirm the AAA method list is actually used. A common mistake is configuring AAA for the wrong access type (for example, console vs. VTY) or forgetting to apply the method list to the intended line.
2. Verify the RADIUS/TACACS+ server reachability. Check IP routing, VRF placement, and UDP/TCP reachability. If the device cannot reach the server, you will see timeouts rather than rejections.
3. Validate shared secrets and source interface. A mismatch causes the server to ignore requests. Also confirm the source interface used for AAA so the server sees the expected client.

Use Logs to Classify the Failure

Device logs tell you what stage failed. Treat the log line as a breadcrumb trail.

• Timeouts suggest reachability, routing, firewall, or secret mismatch.
• Reject messages suggest the server received the request and decided “no.”
• Local fallback indicates the AAA method list includes local authentication after AAA fails.

A practical approach is to reproduce the failure in a controlled way: attempt login from a single test host, then immediately review the device log for the corresponding AAA events. If you have multiple simultaneous attempts, you lose the ability to correlate.

Test Commands That Narrow the Problem

Use targeted test commands to confirm each layer.

Example: Confirm AAA Method List Usage

Run verification commands to ensure the correct method list is tied to the correct line.

show running-config | section aaa
show running-config | section line vty
show aaa method-lists
show authentication sessions

If the method list you expect is not referenced by the active line configuration, the server will never be consulted.

Example: Validate RADIUS Server Connectivity

When using RADIUS, confirm the server is reachable from the device and that the device uses the expected source.

show ip route <radius-server-ip>
show run | section radius-server
show run | section aaa
show tcp brief | include 1812

If you see no route or the wrong VRF, you’ll get timeouts even with perfect credentials.

Turn on Debug Carefully and Read It Like a Checklist

Debug output can be noisy, so enable it briefly and only while reproducing the failure.

debug radius authentication
debug radius authorization
debug aaa authentication
debug aaa authorization

Then attempt a login and watch for these patterns:

• Request sent, no response: reachability or secret mismatch.
• Response received with reject: server-side policy or user attributes.
• Authentication succeeds, authorization fails: method list or command/service authorization mismatch.

After the test, disable debugging to avoid performance impact.

Correlate Device Logs with Server Decisions

Device logs show what the device asked; server logs show what the server decided. Correlation is easiest when you align timestamps and session identifiers.

• For authentication failures, confirm the server recognized the username and validated the password.
• For authorization failures, confirm the server returned the correct attributes for the requested service.
• For accounting issues, confirm the server accepts start/stop records and that the device is configured to send them.

Common Root Causes and How to Confirm Them

1. Wrong Service Type in Authorization

   • Symptom: authentication works, but you cannot enter the expected privilege or execute commands.
   • Confirmation: debug shows authorization rejects after successful authentication.

2. Method List Applied to the Wrong Line

   • Symptom: device uses local authentication or a different method list than expected.
   • Confirmation: running config shows method list mismatch; debug shows no AAA server traffic.

3. Secret Mismatch or Source Interface Mismatch

   • Symptom: timeouts or generic failures.
   • Confirmation: server logs show no matching request; device debug shows requests without valid responses.

4. User Exists but Missing Required Attributes

   • Symptom: server rejects authorization even though credentials are correct.
   • Confirmation: server logs indicate missing group/profile attributes; device debug shows authorization reject.

Example: A Clean Troubleshooting Sequence

When a VTY login fails, follow this order: verify the VTY method list, confirm route and source interface to the AAA server, reproduce the login once, classify the log outcome (timeout vs reject), then use debug for authentication and authorization to pinpoint the stage. Finally, compare the device’s request details with the server’s decision so you fix the correct configuration instead of guessing.

10.1 Configure SSH with Strong Cryptographic Settings

SSH security is mostly about two things: choosing algorithms that are still considered safe, and making sure the device actually uses them. The goal is to prevent weak key exchange, weak host key types, and legacy ciphers from being negotiated during session setup.

Foundational Concepts That Affect SSH Strength

SSH sessions start with a key exchange, then negotiate encryption and integrity algorithms, and finally authenticate users. If any step allows weak algorithms, the session can still end up weaker than you intended. Strong cryptographic settings therefore focus on:

• Host key type: the server’s identity key used during negotiation.
• Key exchange method: how both sides derive session keys.
• Encryption cipher: how payloads are encrypted.
• MAC or integrity: how tampering is detected.
• Authentication method: how the user proves identity.

A practical best practice is to configure SSH first, then verify what the server will actually offer, and only then test with a known-good client.

Configure Host Keys and Key Sizes

On Cisco IOS XE, you typically generate an RSA or ECDSA host key. RSA is widely supported; ECDSA is often more efficient. Either way, the key size matters.

Example: generate an RSA host key and ensure it is large enough.

conf t
crypto key generate rsa modulus 4096
ip ssh version 2
end
wr mem

If your platform supports ECDSA host keys, you can generate those as well, but keep the configuration consistent so clients don’t end up negotiating an unexpected fallback.

Restrict Key Exchange, Ciphers, and MACs

Strong SSH configurations explicitly limit what the server will negotiate. The exact command syntax varies by platform and software release, but the logic is consistent: define allowed sets for key exchange, encryption, and integrity.

Example: set strong algorithm preferences using SSH algorithm configuration (syntax may vary).

conf t
ip ssh server algorithm encryption aes128-ctr aes256-ctr
ip ssh server algorithm mac hmac-sha2-256 hmac-sha2-512
ip ssh server algorithm kex diffie-hellman-group14-sha256
end
wr mem

If your device supports additional modern key exchange methods, prefer them over older groups. If you are unsure what your platform accepts, use the device’s help output to list valid algorithm names, then apply only those you can confirm.

Enforce SSH Version 2 and Limit Authentication Weakness

SSH version 1 is obsolete and should not be enabled. Next, reduce the chance of password-based guessing by using SSH keys for administrators.

Example: require SSH v2 and enable local user authentication as a fallback.

conf t
ip ssh version 2
username admin privilege 15 secret <strong-secret>
line vty 0 4
transport input ssh
login local
end
wr mem

For stronger control, prefer public key authentication for admin accounts. Even then, keep a local fallback only if you have a clear operational reason.

Verification That Confirms Real Negotiation

Configuration is only half the story; verification tells you what actually happens. Use show commands to confirm:

• SSH is enabled and listening on the expected interfaces.
• The device has the host key type you generated.
• VTY lines accept only SSH.
• The negotiated algorithms match your allowed sets.

Example: check SSH and VTY state.

show ip ssh
show crypto key mypubkey rsa
show running-config | section line vty
show running-config | include ip ssh server algorithm

To confirm negotiation, initiate an SSH session from a client that can display algorithm selection. If the session uses an algorithm you did not allow, your server configuration is either incomplete or not being applied as expected.

Common Pitfalls and How to Avoid Them

• Forgetting VTY transport restrictions: SSH algorithms won’t matter if Telnet is still allowed.
• Assuming host key generation is enough: clients still negotiate key exchange, ciphers, and MACs.
• Over-restricting without testing: some management systems use older SSH clients; test with the exact client you deploy.
• Inconsistent settings across devices: if multiple switches/routers must be managed similarly, keep algorithm policies aligned.

Quick Checklist for Exam-Style Scenarios

1. Generate a strong host key and ensure SSH v2 is enabled.
2. Restrict key exchange, encryption, and MAC to strong allowed sets.
3. Limit VTY transport to SSH only.
4. Prefer SSH keys for admin access.
5. Verify with show commands and confirm negotiated algorithms during a test session.

10.2 Harden Management Interfaces and Access Methods

Management access is where “it works” turns into “it’s safe.” Hardening means reducing who can reach the device, how they authenticate, and what they can do once inside. This section focuses on practical controls you can verify with show commands and simple tests.

Management Plane Basics and Threat Model

Start by separating planes in your head: data traffic forwards packets, while the management plane accepts sessions for CLI, SSH, HTTPS, SNMP, and other services. Most hardening mistakes happen when management services are reachable from the same networks as user traffic.

A simple baseline threat model helps you choose controls:

• Unauthorized access attempts from reachable IP ranges
• Credential guessing against exposed services
• Accidental privilege escalation via overly broad roles
• Configuration drift that reopens access

Access Methods and Service Exposure Control

Harden by limiting exposure first, then strengthening authentication.

1. Restrict which interfaces accept management sessions

• Use ACLs on VTY lines or management VRFs so only approved subnets can connect.
• Example: allow only the jump host subnet to reach SSH.

2. Disable unused management services

• If you do not use Telnet, disable it.
• If you do not use HTTP, disable it and rely on SSH.

3. Use a dedicated management VRF when possible

• Keep management routing separate so accidental route leaks do not expose services.

SSH Hardening for CLI Access

SSH is the usual workhorse for CLI management. The goal is to require strong algorithms, prevent weak authentication paths, and log what matters.

Key practices:

• Enforce SSH only on VTY lines
• Use local user accounts or AAA with RADIUS/TACACS+
• Set session timeouts to reduce idle exposure
• Limit concurrent sessions if your platform supports it

Example configuration (adapt addresses and usernames):

ip access-list standard MGMT_SSH
 permit 10.10.20.0 0.0.0.255
 deny   any

line vty 0 4
 access-class MGMT_SSH in
 transport input ssh
 exec-timeout 10 0
 login local

Verification ideas:

• Confirm VTY transport shows only SSH
• Confirm ACL counters increase when you test from allowed and blocked hosts

HTTPS and API Management Hardening

If you enable HTTPS for management, treat it like a public-facing service even when it is internal.

Practices:

• Restrict HTTPS access with an ACL tied to the management interface or VRF
• Use strong TLS settings and valid certificates
• Require authentication for every request path

Example access control pattern:

ip access-list standard MGMT_HTTPS
 permit 10.10.30.0 0.0.0.255
 deny   any

interface Vlan 10
 ip access-group MGMT_HTTPS in

Verification ideas:

• Test from an allowed host and confirm the session establishes
• Test from a blocked host and confirm the ACL counters increment

SNMP and Telemetry Access Controls

SNMP is often left too open. Tighten it by restricting source IPs and using secure versions.

Practices:

• Prefer SNMPv3 with authentication and privacy
• Restrict SNMP to a monitoring subnet
• Use separate credentials per device role

Example concept:

• Monitoring server subnet can query; all others get dropped

AAA and Authorization for Command Control

Authentication proves identity; authorization decides what that identity can do.

Integrated approach:

• Use AAA so authentication and authorization are consistent across devices
• Ensure privilege levels match job functions
• Require accounting so you can trace changes and troubleshooting sessions

A practical workflow:

1. Create a role for read-only operators
2. Create a role for network engineers with configuration permissions
3. Map users to roles via AAA
4. Verify with a test login and attempt a harmless privileged command

Role-Based Privilege and Least Privilege

Least privilege is not just a principle; it prevents accidental damage.

Common mistakes to avoid:

• Using the same account for monitoring and configuration
• Granting full privileges to everyone who needs troubleshooting
• Leaving default accounts enabled

Verification ideas:

• Confirm the user’s privilege level after login
• Confirm denied commands produce an authorization error, not a confusing prompt

Logging, Session Auditing, and Change Traceability

Hardening without visibility is like locking a door and never checking if it was used.

Practices:

• Enable logging for authentication failures
• Log successful logins for management accounts
• Ensure syslog reaches a trusted collector
• Use accounting so you can correlate “who did what”

Test method:

• Attempt a blocked SSH login and confirm the failure is logged
• Attempt an allowed login and confirm the session is recorded

Example: End-to-End Access Test

Use a repeatable test plan so you know the hardening actually works.

1. From an allowed host, connect via SSH and run a read-only command.
2. From a blocked host, attempt SSH and confirm the connection fails.
3. Check ACL counters and authentication logs.
4. Confirm the user cannot run a privileged configuration command.

If any step fails, fix the specific layer: reachability (ACL/VRF), transport (SSH/HTTPS settings), identity (AAA/user), or authorization (role/privilege).

10.3 Configure TLS for HTTPS Based Services

HTTPS on Cisco devices typically means: terminate TLS on the device, present a certificate, and allow only secure protocol and cipher choices. The goal is to make the web service predictable for both browsers and automation tools, while keeping management access tight.

Foundations That Matter Before You Touch Config

Start with three basics: certificate identity, trust chain, and service binding.

1. Certificate identity: The certificate’s Subject Alternative Name (SAN) must match the hostname or IP clients use. If users browse to https://switch1.example.com, SAN must include switch1.example.com.
2. Trust chain: Clients must trust the issuing CA. If you use a private CA, browsers and scripts need that CA in their trust store.
3. Service binding: The HTTPS server must be enabled, and it must reference the correct certificate.

A quick sanity check: decide the exact URL users will type, then ensure the certificate covers that exact value. This prevents the classic “certificate is valid but for the wrong name” problem.

Certificate Options and Practical Choices

You can use certificates from a CA or create a local trust model. For exam-style lab work, a CA-signed certificate is common, but a self-signed certificate is also workable if you control the client trust.

Use a trustpoint to manage the certificate lifecycle. The trustpoint stores the keypair and certificate details, and the HTTPS server points to that trustpoint.

Example: Create a Trustpoint and Enable HTTPS

Below is a typical flow for a device that will use a CA-issued certificate. Adjust names and CA enrollment method to match your lab.

conf t
crypto pki trustpoint TP-HTTPS
 enrollment terminal
 subject-name CN=switch1.example.com
 rsakeypair TP-HTTPS
exit

crypto pki enroll TP-HTTPS

ip http secure-server
ip http server

ip http secure-port 443
ip http secure-trustpoint TP-HTTPS
end

Two notes that save time:

• ip http secure-server enables the TLS-wrapped service.
• ip http secure-trustpoint selects which certificate the server presents.

If your platform uses slightly different command names, the concept stays the same: enable HTTPS, then point it at the trustpoint.

Example: Verify Certificate Binding and TLS Behavior

Verification should confirm three things: the trustpoint has a certificate, the certificate identity looks right, and the HTTPS service is actually listening.

show crypto pki certificates TP-HTTPS
show ip http secure-server
show tcp brief | include :443
show run | section ip http

When checking certificate details, focus on SAN entries. If SAN doesn’t include the exact hostname you browse to, browsers will warn even if the certificate is otherwise “valid.”

Hardening TLS Without Breaking Clients

Hardening is mostly about limiting protocol versions and cipher choices. The safest approach is to start with a conservative baseline that still matches common client capabilities.

In practice, you’ll configure allowed TLS versions and avoid legacy protocols. If you restrict too aggressively, some clients will fail the handshake. For exam labs, keep the policy consistent across devices so troubleshooting is about configuration errors, not client compatibility.

Troubleshooting Handshakes Like a Checklist

When HTTPS fails, don’t guess. Use a sequence.

1. Client error message: “Name mismatch” usually means SAN is wrong. “Untrusted issuer” means CA trust is missing.
2. Device certificate presence: Confirm the trustpoint has an installed certificate.
3. Correct binding: Confirm HTTPS is using the intended trustpoint.
4. Service reachability: Confirm TCP/443 is listening on the expected VRF and interface.
5. Protocol mismatch: If you restricted TLS versions, verify the client supports what you allowed.

A small but useful habit: test from the same type of client you expect in the lab (browser vs. script). Different clients surface different errors, and those errors point to different root causes.

Example: Secure Access with ACL Placement

TLS secures the session, but you still need to control who can reach the service. Apply an ACL to the management plane interface or use management access restrictions.

ip access-list standard MGMT-HTTPS
 permit 192.0.2.10
 permit 192.0.2.20
 deny   any

interface Vlan10
 ip access-group MGMT-HTTPS in
end

This keeps the TLS work focused: if a client is blocked, the failure is intentional and easy to explain; if it connects, TLS errors are more likely to be certificate or protocol related.

10.4 Manage Certificates with Trustpoints and Validation

Certificates are how devices prove identity to each other. On Cisco IOS XE, trustpoints give you a place to store certificates and related keys, while validation ensures the certificate you receive is actually the one you expect. The trick is to treat certificate handling like configuration hygiene: predictable inputs, explicit verification, and repeatable checks.

Core Concepts You Must Keep Straight

A trustpoint is a named container on the device. It can hold:

• A local identity certificate (the device’s own cert) and its private key.
• One or more CA certificates used to validate peers.
• Parameters that control how the device validates certificates.

A certificate validation process typically checks:

• The certificate chain builds to a trusted CA.
• The certificate is within its validity period.
• The certificate’s identity matches what you’re connecting to (hostname or IP subject/subjectAltName).
• The certificate is not revoked (if you enable revocation checking).

Trustpoint Workflow from Basics to Real Verification

Decide What You Are Trusting

First, identify whether the device is acting as a server (presenting its identity to clients) or a client (validating a server).

• For management HTTPS/SSH server behavior, you need an identity certificate.
• For outbound TLS connections, you need CA trust to validate the remote server.

Create the Trustpoint Container

Create a trustpoint name that matches its purpose, such as TP-HTTPS-IDENTITY or TP-REMOTE-CA. Keep names consistent because show commands will reference them.

Load or Enroll Certificates

You can install certificates in two common ways:

• Manual installation: paste the CA certificate and the device certificate.
• Enrollment: request certificates from a CA using supported mechanisms.

For exam-style troubleshooting, manual installation is easiest to reason about because you can verify exactly what’s stored.

Bind the Trustpoint to Services

Once the trustpoint holds the correct identity certificate, bind it to the service that needs it, such as HTTPS.

Validate with Targeted Show Commands

Validation is not a single command; it’s a sequence:

• Confirm the trustpoint has the expected certificate.
• Confirm the CA chain is present.
• Confirm the service is using the intended trustpoint.
• Confirm the peer certificate matches expectations.

Example: Trustpoint Setup for HTTPS Identity

Assume you want the switch to present a certificate for HTTPS management.

conf t
crypto pki trustpoint TP-HTTPS-IDENTITY
 enrollment terminal
 subject-name CN=switch1.example.local
 rsakeypair TP-HTTPS-IDENTITY
exit

crypto pki certificate chain TP-HTTPS-IDENTITY
 certificate <paste-device-cert>
quit

ip http secure-server
ip http secure-trustpoint TP-HTTPS-IDENTITY
end

After configuration, verify:

• The trustpoint exists and has a certificate.
• The HTTPS server is bound to that trustpoint.

show crypto pki trustpoints
show crypto pki certificates
show ip http secure-server status
show running-config | include secure-trustpoint

Example: CA Trust and Certificate Validation for Outbound TLS

If the device initiates TLS to a remote server, you must trust the CA that issued that server certificate.

conf t
crypto pki trustpoint TP-REMOTE-CA
 enrollment none
 subject-name CN=Remote-CA
exit

crypto pki trustpoint TP-REMOTE-CA
 revocation-check none
exit

crypto pki certificate chain TP-REMOTE-CA
 certificate <paste-ca-cert>
quit
end

Then ensure the TLS client uses that trustpoint (the exact binding depends on the feature using TLS). Validation should confirm the chain builds successfully.

Practical Validation Checklist for Exam Scenarios

1. Confirm the trustpoint name used by the service matches what you configured.
2. Confirm the certificate type: identity cert for server use, CA cert for validation.
3. Check validity period by inspecting certificate details.
4. Check identity match: if the peer certificate is for serverA, connecting to serverB can fail even when the CA is correct.
5. Check chain completeness: missing intermediate CAs often look like “unknown issuer.”

Troubleshooting Example: Identity Mismatch

If a client connects using an IP address but the server certificate only lists a DNS name, validation can fail. The fix is to ensure the certificate includes the correct subjectAltName entries for the way you connect.

Validation reasoning stays simple: the CA trust may be correct, but the identity check still blocks the session. That’s why you verify both the chain and the identity, not just the issuer.

10.5 Troubleshoot Handshakes and Certificate Validation Errors

When an HTTPS or SSH session fails, the failure usually happens in one of two places: the device can’t establish the secure channel (handshake), or it can establish it but rejects the peer’s identity (certificate validation). Treat these as separate problems and you’ll stop chasing ghosts.

Build a Quick Mental Model of the TLS Handshake

A typical TLS handshake has a few checkpoints:

1. Client hello: the client proposes protocol versions and cipher suites.
2. Server hello: the server selects parameters and sends its certificate.
3. Key exchange: both sides derive shared keys.
4. Certificate validation: the client checks the server certificate chain, hostname, and trust.
5. Finished messages: both sides confirm the handshake integrity.

If you see errors before any certificate is presented, focus on reachability, protocol mismatch, or unsupported ciphers. If you see the certificate but then fail, focus on trust chain and identity checks.

Gather Evidence with Targeted Verification

Start with the smallest set of commands that answer the right questions.

• Confirm the service is actually configured: the correct interface, VRF, and transport method.
• Confirm the certificate is installed and usable: the certificate exists, is not expired, and matches the intended use.
• Confirm the peer is contacting the right name: hostname used by the client must match what the certificate covers.

On Cisco IOS XE, the most useful approach is to enable logs or debug output only long enough to capture the handshake failure, then disable it. Debugging forever is how you turn a troubleshooting session into a lifestyle.

Mind Map of Common Failure Points

Diagnose Certificate Trust Chain Problems

Trust chain errors usually mean the client cannot build a path from the server certificate to a trusted CA.

Example: Missing CA in trustpoint

• The server presents a certificate signed by an intermediate CA.
• The client trusts only the root CA, but the intermediate isn’t available or the device trust store doesn’t include the needed CA.
• Result: validation fails even though the certificate is otherwise well-formed.

What to check

• The trustpoint CA certificate is the correct root or intermediate.
• The certificate chain presented by the server is complete for the client’s validation method.

Diagnose Hostname and Identity Mismatches

Even with a valid chain, hostname checks can fail.

Example: Client connects by IP

• The certificate’s Subject Alternative Name (SAN) includes router.example.com but not 192.0.2.10.
• The client uses https://192.0.2.10.
• Result: certificate validation fails due to identity mismatch.

Fix options

• Use the DNS name that matches the SAN.
• Reissue the certificate with SAN entries that cover the access method used by clients.

Diagnose Expired or Incorrectly Scoped Certificates

A certificate can be “valid” structurally but still rejected.

Example: Expired certificate

• The device presents a certificate whose validity period has ended.
• The handshake may proceed far enough to show the certificate, but validation fails.

What to check

• Certificate validity dates.
• Correct certificate usage for the service (management HTTPS vs other services).

Use a Systematic Troubleshooting Flow

Follow this order to avoid redundant checks:

1. Confirm connectivity: can the client reach the correct IP/port in the correct VRF?
2. Confirm service and certificate binding: is the certificate applied to the exact service endpoint?
3. Confirm protocol and cipher compatibility: does the client request something the server can negotiate?
4. Confirm trust chain: does the client trust the CA that signed the server certificate?
5. Confirm identity: does the certificate SAN match the hostname or IP used by the client?
6. Confirm certificate state: not expired, correct validity, correct scope.

Practical Example Workflow

Scenario: HTTPS to a switch fails with a certificate validation error.

• Step 1: Verify the client reaches the switch management interface and port.
• Step 2: Verify the switch has the intended certificate installed and bound to HTTPS.
• Step 3: Check the certificate SAN includes the name the client uses.
• Step 4: Confirm the client trusts the CA that signed the switch certificate.
• Step 5: If the client uses an IP address, either switch to the DNS name or reissue the certificate with the IP in SAN.

Once you separate handshake negotiation from certificate validation, the error message stops being a riddle and becomes a checklist.

11.1 Understand Data Models and Configuration Concepts

A data model is the structured way a device represents configuration and operational state. In NETCONF and RESTCONF, the model matters because the protocol exchanges data that must match a known schema. If you treat the device like a text editor, you’ll fight the tooling. If you treat it like a structured database with rules, everything becomes easier.

Configuration Data Versus Operational Data

Configuration data is what you intend the device to run. Operational data is what the device is actually doing right now. For example, an interface can be configured with an IP address, but the operational state also includes whether the interface is up, what counters look like, and whether the neighbor relationships are established.

In practice, this split shows up in verification steps:

• You configure under a specific container path (configuration).
• You verify under state paths that reflect current reality (operational).

The Building Blocks of YANG Models

Most modern schema-driven management uses YANG. Think of YANG as a map of containers and leaves:

• Containers group related settings.
• Lists represent repeated objects, like multiple interfaces.
• Leaves hold actual values, like an IP address or a boolean flag.

A key idea is that the same conceptual feature can appear in multiple places: once as configuration, and again as state. The model keeps those roles consistent.

Hierarchical Paths and Identifiers

When you request or set data, you address it by a hierarchical path. Lists require keys to identify which instance you mean. For example, an interface list might be keyed by the interface name. Without the key, the device can’t know whether you meant GigabitEthernet0/0 or GigabitEthernet0/1.

A practical habit: always write down the exact list key you’re targeting before you send a request.

Candidate, Running, and Startup Concepts

Many devices support multiple configuration datastores. The common pattern is:

• Running: what is currently active.
• Candidate: a staging area for changes.
• Startup: what will be used after reboot.

Even if your lab uses only one datastore, the mental model helps you understand why a change might not appear immediately after a commit, or why it disappears after a reload.

How NETCONF and RESTCONF Use the Model

NETCONF commonly uses operations like “get” and “edit-config” against datastores. RESTCONF exposes similar data through HTTP resources, but the schema still governs what paths exist and what values are valid.

The integrated takeaway: the protocol is the transport; the model is the contract.

Example: Interface IP Configuration with Clear Separation

Suppose you want to configure an interface IP address.

1. Choose the list instance: the interface name is the list key.
2. Set configuration leaves: assign the IP address and subnet mask under the configuration container.
3. Verify operational state: check that the interface is up and that the address appears in operational data.

If the interface remains down, the configuration might still be present, but operational state won’t show the expected forwarding behavior. That’s not a contradiction; it’s the model doing its job.

Example: Why Keys Prevent Accidental Changes

Imagine you send a request that targets an interface list without specifying the key. The device can’t guess which entry you mean, so the request should fail or be rejected. In a lab, this is a good thing: it forces you to be precise. In a real workflow, precision is what keeps “works on my terminal” from becoming “works on the wrong interface.”

Example: Candidate Versus Running in a Change Workflow

A typical safe workflow is:

• Stage changes in candidate.
• Validate by checking relevant operational indicators after the change is applied or committed.
• Commit so running reflects the intended configuration.
• Optionally copy to startup so the change survives a reload.

If you skip the commit step, running won’t reflect your staged edits. If you skip copying to startup, the configuration may vanish after reboot. The model explains both outcomes without guessing.

Practical Mental Checklist Before You Send Data Requests

• Which datastore am I editing or reading?
• Am I touching configuration or operational state?
• What is the exact list key for the object I’m targeting?
• Are the values I’m sending consistent with the schema types?

Once these questions become automatic, the rest of the automation work feels like structured plumbing rather than interpretive dance.

11.2 Configure NETCONF Access and Verify Sessions

NETCONF access is mostly about two things: getting a secure transport in place and ensuring the server and client agree on how to authenticate and exchange messages. In practice, you’ll configure SSH-based NETCONF, confirm the server is listening for NETCONF, and then verify that a client can open a session and perform a safe read or edit.

NETCONF Access Foundations

NETCONF typically runs over SSH. That means your device must have:

• An SSH server enabled with strong cryptographic settings.
• A NETCONF subsystem bound to the SSH transport.
• AAA or local authentication configured so the client can log in.
• Authorization that allows the user to perform the intended operations.

A common exam-style mistake is to verify SSH login works, then assume NETCONF works too. NETCONF adds a subsystem layer, so you must confirm the NETCONF subsystem is active.

Configure SSH for NETCONF

Start by ensuring SSH is configured correctly. Use a dedicated management VRF if your platform supports it, and restrict access with ACLs where appropriate. Then create a user account with the right privilege level.

Example: Enable SSH and create a NETCONF-capable user

conf t
ip ssh version 2
username netconfuser privilege 15 secret 0 Netconf!Pass1
crypto key generate rsa modulus 2048
ip ssh time-out 60
ip ssh authentication-retries 3
end

After this, verify SSH works from the client by logging in with the same username. If SSH login fails, NETCONF will fail too, but the reverse is not guaranteed.

Enable NETCONF Subsystem

Next, bind NETCONF to the SSH server. On many Cisco platforms, NETCONF is enabled via the SSH subsystem configuration.

Example: Enable NETCONF subsystem

conf t
netconf-yang
ssh server netconf
end

If your device uses a different command set, the goal is the same: the SSH server must advertise and accept the NETCONF subsystem during session negotiation.

Configure Authentication and Authorization

If you use AAA, confirm the method list includes the authentication source you expect. For local authentication, confirm the user exists and the password/secret is correct. For authorization, confirm the role or privilege level allows the operations you plan to test.

A practical approach is to test with a read-only user first. That reduces the chance of accidental configuration changes while you validate session establishment.

Verify NETCONF Server State

Use show commands to confirm NETCONF is enabled and that the subsystem is available. Then verify that the server is ready to accept sessions.

Example: Verify NETCONF and SSH readiness

show netconf
show ssh server
show running-config | include netconf|ssh server

Interpretation tips:

• If NETCONF is not shown as enabled, stop and fix subsystem configuration.
• If SSH is enabled but NETCONF is absent, you likely missed the subsystem binding.

Verify Sessions from a Client

Once the server side is correct, verify the client can open a NETCONF session. A good verification sequence is:

1. Establish a session.
2. Confirm the server capabilities.
3. Perform a harmless read operation.
4. Optionally perform a minimal edit using a candidate datastore if supported.

Example: NETCONF client session test

# Pseudocode Style Commands
# 1) Connect using SSH with NETCONF subsystem
# 2) Request Server Capabilities
# 3) Read a small configuration subtree

netconf-cli --host 192.0.2.10 --user netconfuser --capabilities
netconf-cli --host 192.0.2.10 --user netconfuser --get-config "/interfaces"

If your client reports that it connected but did not negotiate NETCONF, focus on subsystem configuration and SSH negotiation. If it negotiates NETCONF but denies operations, focus on authorization.

Common Failure Patterns and Targeted Fixes

• SSH login works, NETCONF fails: NETCONF subsystem not enabled or not bound to SSH.
• Session opens, but capabilities are missing: client is not actually using NETCONF subsystem or is using the wrong transport parameters.
• Read fails with permission errors: user privilege or role does not allow the requested datastore access.
• Edit fails with validation errors: the payload doesn’t match the expected YANG model or the target datastore rules.

Verification Summary

A correct NETCONF access setup is proven, not assumed. Confirm SSH is working, confirm NETCONF subsystem availability, authenticate successfully, and then validate the session by reading a small, known subtree. Once that’s stable, you can move to controlled edits with confidence that the session layer is solid.

11.3 Configure RESTCONF Access and Validate Endpoints

RESTCONF is HTTP-based management that exposes device configuration and state through standardized resources. To configure it cleanly, you need three things: a reachable transport (HTTPs), an authentication method, and an addressable URL structure that matches what the device actually serves.

Foundations You Must Get Right First

Start by confirming the device supports RESTCONF and that HTTPS is working. RESTCONF typically rides on the same TLS services used for management web access, so if SSH works but HTTPS fails, RESTCONF will not magically succeed.

Next, decide how clients will authenticate. Many labs use local usernames with AAA or local authentication, but the key is consistency: the RESTCONF server must accept the same credentials your client will send.

Finally, understand endpoint paths. RESTCONF URLs are not arbitrary; they follow a predictable pattern that maps to the YANG data model. If you validate the base path first, you avoid chasing errors caused by a wrong resource path.

Configure RESTCONF Access

1. Enable HTTPS management.
2. Enable RESTCONF service.
3. Ensure the RESTCONF listener is reachable from your management network.
4. Create or verify a user account and authentication method.
5. Confirm the server is advertising the RESTCONF capability.

On Cisco IOS XE, the exact commands vary by platform and software release, but the workflow is consistent. Use these checks to validate each step.

Minimal Configuration Checklist

• TLS is enabled for management.
• RESTCONF is enabled.
• User credentials exist.
• Management ACLs allow the client.

Example Configuration and Verification

# Verify HTTPS and RESTCONF availability (examples)
show ip http secure-server
show restconf
show running-config | include restconf|http secure-server

If your platform uses a RESTCONF-specific enable command, apply it, then re-run the verification commands. If show restconf reports the service is disabled or not listening, stop and fix that before testing URLs.

Validate Endpoints Like a Pro (Without Guessing)

Validation should proceed from broad to specific.

Step 1: Validate the Base RESTCONF Path

Your goal is to confirm the server responds to RESTCONF requests at the expected root. A correct base response proves TLS, authentication, and routing are working.

Step 2: Validate Resource Discovery

RESTCONF servers usually support discovery of available modules and resources. If discovery fails, you may have a wrong URL prefix or the server is not exposing the expected YANG modules.

Step 3: Validate a Known Resource

Pick a resource you expect to exist, such as interface operational state or running configuration. If you can read a known resource, you can usually write to it later (with correct permissions).

Example RESTCONF Requests

Use a simple GET first. Keep the payload empty and focus on status codes and response bodies.

# Example GET to a Base or Module Endpoint
curl -k -u USER:PASS \
  -H "Accept: application/yang-data+json" \
  https://DEVICE_IP/restconf/

If the server responds with 401, credentials are wrong. If it responds with 404, the URL prefix is wrong. If it responds with 403, authentication succeeded but authorization failed.

Now test a concrete resource. The exact path depends on the device’s RESTCONF implementation and YANG module names.

# Example GET to a Common Operational Resource
curl -k -u USER:PASS \
  -H "Accept: application/yang-data+json" \
  https://DEVICE_IP/restconf/data/ietf-interfaces:interfaces

A successful response returns JSON data for interfaces. If you receive an error indicating an unknown module, verify that the module is enabled and that the device supports that YANG model.

Practical Validation Rules That Prevent Wasted Time

• Always test the base path before testing a specific resource.
• Use GET for validation; only move to PUT/PATCH after you can read the target.
• Treat HTTP status codes as a map, not a mystery novel.
• If JSON parsing fails on the client, confirm the Accept header matches the expected YANG JSON format.

Quick Example Workflow for a Lab

1. Enable HTTPS and RESTCONF.
2. Confirm the service is listening.
3. Run a base GET to confirm reachability and authentication.
4. Run a GET for a known module resource.
5. Record the exact working URL for later automation steps.

When these steps succeed, you have a reliable RESTCONF endpoint that your automation scripts can target without trial-and-error gymnastics.

11.4 Use Scripting to Automate Configuration Changes

Automation is useful when you can describe the change precisely and verify it reliably. In this section, you’ll build that habit: define intent, generate configuration, apply it safely, and confirm the outcome with targeted checks.

Start with Change Intent and Inputs

Begin by writing the change as a small checklist. For example: “Create VLAN 30, allow it on trunk ports Gi1/0/1–Gi1/0/4, and verify the VLAN exists and trunks carry it.” Then list inputs your script will need:

• Device identifier (hostname or management IP)
• Target VLAN ID and name
• Trunk interface list
• Expected verification outputs (e.g., VLAN present, trunk allowed list includes VLAN)

A good script treats these as variables, not hardcoded strings. That makes the same logic reusable across sites.

Choose a Safe Execution Model

For configuration changes, prefer an approach that supports:

• Deterministic command generation
• Clear separation between “what to do” and “how to apply”
• Prechecks and postchecks

A practical pattern is:

1. Collect current state
2. Compute the delta
3. Apply only what’s needed
4. Verify with show commands
5. Record what happened

This avoids the classic mistake of reapplying the same config and then wondering why verification is noisy.

Build Idempotent Configuration Logic

Idempotent means running the script twice produces the same end state. For VLAN creation, you can check whether the VLAN already exists before issuing the command. For trunk configuration, you can compare the current allowed VLAN list with the desired list and only add missing VLANs.

Example logic for trunking:

• Desired allowed VLANs: {10, 20, 30}
• Current allowed VLANs: {10, 20}
• Action: add VLAN 30

This keeps changes minimal and makes troubleshooting easier.

Use Prechecks and Postchecks That Match the Intent

Prechecks confirm prerequisites. Postchecks confirm success. Keep them aligned with the checklist you wrote.

For the VLAN and trunk example, prechecks might include:

• Device reachability
• Interfaces exist and are trunk-capable
• VLAN ID is within allowed range

Postchecks might include:

• show vlan brief shows VLAN 30
• show interfaces trunk shows VLAN 30 in the allowed list

When verification fails, the script should report which check failed and include the relevant command output.

Example Mind Map for a Configuration Change Script

Example Script Flow with Concrete Commands

Below is a compact flow you can adapt. It assumes you already have a way to connect to the device and run commands.

# Pseudocode-Style Flow for VLAN and Trunk Automation
inputs = {
  "vlan_id": 30,
  "vlan_name": "ENG-OPS",
  "trunks": ["Gi1/0/1","Gi1/0/2","Gi1/0/3","Gi1/0/4"]
}

current_vlans = run("show vlan brief")
if f"{inputs['vlan_id']}" not in current_vlans:
  cmds.append(f"vlan {inputs['vlan_id']}")
  cmds.append(f" name {inputs['vlan_name']}")

for intf in inputs["trunks"]:
  trunk_out = run(f"show interfaces trunk {intf} switchport")
  if f"{inputs['vlan_id']}" not in trunk_out:
    cmds.append(f"interface {intf}")
    cmds.append(" switchport mode trunk")
    cmds.append(f" switchport trunk allowed vlan add {inputs['vlan_id']}")

apply(cmds)
verify("show vlan brief", f"{inputs['vlan_id']}")
verify("show interfaces trunk", f"{inputs['vlan_id']}")

A key detail: the script checks the current state before generating commands. That’s what makes it predictable.

Verification Output Handling That Helps Debugging

When a check fails, include the exact command output snippet that caused the failure. For example, if VLAN 30 is missing from show interfaces trunk, print the trunk line for that interface only. This reduces the time spent scanning logs.

Also, record the commands you applied. If you later need to explain what changed, you’ll have a clean audit trail.

Practical Lab Exercise for Exam Style Scenarios

Use one change request per run:

• Run 1: VLAN 30 exists, but trunk permissions are missing
• Run 2: VLAN 30 does not exist
• Run 3: One trunk interface is down or misconfigured

Your script should handle each case without crashing, and it should report which precheck or postcheck failed. That behavior is exactly what exam troubleshooting questions reward: you can reason from evidence, not guess from symptoms.

11.5 Validate Automation Results with Diff and Rollback Checks

Automation is only as good as its verification. This section shows a practical, repeatable way to confirm that what you intended to change is what actually changed, and that you can safely undo it when reality disagrees.

Core Validation Flow

Start with a simple sequence that you can run every time:

1. Capture baseline state before changes.
2. Apply the automation in a controlled manner.
3. Capture post-change state.
4. Compute a diff between baseline and post-change.
5. Run rollback checks to confirm the device can return to a known-good state.
6. Decide: keep, adjust, or revert.

The key idea is to treat verification as a pipeline, not a single command. If you only check after the change, you’ll spend time guessing what moved.

What to Capture Before and After

Capture data that answers three questions: What changed? Did it change correctly? Did anything else move?

Use a mix of configuration and operational state:

• Candidate configuration or running configuration snippets that your automation touches.
• Operational outputs that reflect behavior, such as interface status, routing table entries, or policy counters.
• Change metadata like timestamps and commit identifiers when available.

A good baseline is narrow enough to be readable, but broad enough to catch side effects. For example, if your script updates VLAN and trunk settings, include both the VLAN database and the trunk interface configuration in the captured set.

Diff Checks That Actually Help

A diff is only useful if you know what “good” looks like. Use these diff patterns:

• Expected additions: new lines or new objects (e.g., a new route-map sequence).
• Expected modifications: changed values (e.g., ACL permit statements updated).
• Expected removals: lines that should disappear (e.g., old prefix-list entries).
• Unexpected changes: anything else, even if it seems harmless.

When diffing, normalize output so formatting differences don’t create false alarms. For example, compare configuration in a consistent order, and avoid mixing raw CLI output with structured exports unless you normalize them.

Rollback Checks That Confirm Reversibility

Rollback is not just “do you have a backup.” It’s “can you restore and does the restored state match the baseline.” Use two layers:

• Restore capability check: verify the backup exists and is complete.
• State match check: after rollback, diff the restored state against the baseline.

If you use a configuration replace or revert mechanism, confirm that the device accepted the operation cleanly and that the operational state is consistent with the baseline.

Example: Diffing a Targeted Configuration Change

Assume your automation updates an interface description and a trunk allowed VLAN list. Your verification should focus on exactly those lines.

# Capture Baseline
show running-config interface GigabitEthernet0/1
show running-config interface GigabitEthernet0/1 switchport

# After Automation
show running-config interface GigabitEthernet0/1
show running-config interface GigabitEthernet0/1 switchport

# Diff Locally (example Placeholders)
diff baseline_if0_1.txt post_if0_1.txt

Interpretation rules:

• You should see the description line change.
• You should see the switchport trunk allowed vlan list change.
• You should not see unrelated lines change, such as mode, native VLAN, or shutdown state.

If you do see unrelated changes, treat it as a bug in the automation scope or a hidden dependency in the template.

Example: Rollback with State Match

Suppose the change breaks a trunking expectation. Your rollback check should prove the device returned to the baseline.

# Restore from Backup or Revert to Prior Config
# (command varies by platform/workflow)
configure replace flash:backup.cfg force

# Verify Restored Config Matches Baseline
show running-config interface GigabitEthernet0/1

# Diff Restored vs Baseline
diff baseline_if0_1.txt restored_if0_1.txt

A successful rollback is not “the interface is up again.” It’s “the restored configuration matches what you captured before the change,” and the operational outputs align with that configuration.

Practical Decision Rules

Use a simple gate so you don’t argue with yourself:

• If diff matches expected changes and operational checks pass, keep the change.
• If diff shows unexpected changes, revert and fix the automation scope.
• If diff matches expected changes but operational checks fail, revert and investigate device behavior or prerequisites.

This approach keeps the workflow deterministic: you’re not relying on memory, and you’re not hoping the device “probably” did the right thing.

12.1 Build a Python Workflow for Device Inventory and Checks

A solid inventory workflow answers two questions reliably: “What devices exist?” and “Are they behaving as expected?” The trick is to separate discovery, data normalization, and verification so each step can be tested and rerun without surprises.

Inventory Workflow Overview

Start with a source of truth for targets. In labs, that might be a CSV file; in real networks, it could be a database or an internal system. Your Python code should treat the source as input, not as logic.

1. Load targets: read device identifiers, management IPs, and credentials references.
2. Connect safely: set timeouts, retry a limited number of times, and record failures.
3. Collect facts: gather hostname, platform, software version, interface counts, and routing protocol presence.
4. Normalize data: convert fields into consistent formats (for example, version strings and interface naming).
5. Run checks: compare collected facts against rules (for example, “SSH enabled” or “OSPF process present”).
6. Report results: output a structured summary and a human-readable table.

Data Model That Prevents Confusion

Use a simple internal schema so checks don’t depend on raw command output. For each device, store:

• device_id, mgmt_ip, hostname
• platform, os_version
• features: booleans like ssh_enabled, ntp_configured
• routing: detected protocols and key parameters
• interfaces: counts and any critical interface states
• errors: connection or parsing issues

This design keeps your verification logic stable even when command output formatting changes slightly.

Example: Minimal Fact Collection and Rule Checks

Below is a compact pattern that shows the workflow without getting lost in transport details. Replace the send_command stub with your chosen connection method.

import csv

def load_targets(path):
    with open(path, newline="") as f:
        return list(csv.DictReader(f))

def send_command(conn, cmd):
    # Replace with Real Command Execution
    return conn[cmd]

def collect_facts(conn):
    return {
        "hostname": send_command(conn, "show run | i hostname"),
        "platform": send_command(conn, "show version | i Cisco"),
        "os_version": send_command(conn, "show version | i Version"),
        "ssh_enabled": "ip ssh" in send_command(conn, "show run | i ip ssh"),
    }

def check_rules(facts):
    issues = []
    if not facts["ssh_enabled"]:
        issues.append("SSH is not enabled")
    return issues

A key best practice is to keep collect_facts focused on extraction, not decision-making. Then check_rules becomes a list of clear comparisons.

Example: Orchestrating the Workflow

This orchestrator loops through devices, collects facts, runs checks, and records outcomes. Notice how failures are captured as data, not thrown away.

def run_inventory(targets, connect_fn):
    results = []
    for t in targets:
        device = {"device_id": t["device_id"], "mgmt_ip": t["mgmt_ip"]}
        try:
            conn = connect_fn(t)
            facts = collect_facts(conn)
            issues = check_rules(facts)
            device.update(facts)
            device["issues"] = issues
            device["status"] = "PASS" if not issues else "FAIL"
        except Exception as e:
            device["status"] = "ERROR"
            device["errors"] = str(e)
        results.append(device)
    return results

Practical Checks That Map to Exam Thinking

Inventory checks should be specific enough to be actionable. Examples:

• Management security: verify SSH is enabled and that local user authentication exists.
• Time sanity: confirm NTP is configured so logs and troubleshooting timestamps line up.
• Routing presence: detect whether expected routing processes are configured.
• Interface readiness: count critical interfaces and flag those administratively down.

When you write each rule, define the expected condition in plain language, then implement it as a boolean test against normalized facts.

Operational Notes for Reliable Runs

Use deterministic command sets, consistent parsing, and stable output formats. If you run the workflow on 50 devices, you want the report to be comparable across runs, not a different-shaped mess each time. A good report includes counts of PASS/FAIL/ERROR plus a per-device issue list that points directly to what to fix.

12.2 Use API Calls to Retrieve State and Parse Outputs

API-based verification is about two things: getting the right state from the device and turning that state into something you can compare, validate, and act on. The trick is to treat “state retrieval” as a repeatable pipeline rather than a one-off command replacement.

Foundational Model for State Retrieval

Start by separating concerns:

1. Transport: NETCONF or RESTCONF carries requests and responses.
2. Data model: the response follows a schema (for example, interface operational data).
3. Parsing: you extract fields you care about.
4. Validation: you compare extracted values to expected rules.
5. Reporting: you produce a concise result for humans and a structured result for automation.

A practical mindset: if you can’t point to the exact field you extracted, you can’t reliably validate it.

NETCONF Retrieval and XML Parsing

NETCONF responses are XML, so parsing usually means selecting nodes by path and converting strings into types. A common verification task is confirming that an interface is operationally up and that counters are increasing.

Example: retrieve interface operational state

# Pseudocode for NETCONF XML parsing
xml = netconf_get(filter_xpath="/interfaces-state/interface[name='GigabitEthernet0/0']")
oper = xpath_text(xml, "oper-status")
rx = int(xpath_text(xml, "statistics/rx-unicast-packets"))
tx = int(xpath_text(xml, "statistics/tx-unicast-packets"))

result = {
  "oper_status": oper,
  "rx_unicast_packets": rx,
  "tx_unicast_packets": tx
}

Best practice: treat missing fields as a distinct outcome. If oper-status is absent, that’s not the same as “down.” Your parser should record “field missing” so troubleshooting can start immediately.

RESTCONF Retrieval and JSON Parsing

RESTCONF typically returns JSON, which makes extraction straightforward but still error-prone if you assume fields always exist. Use defensive parsing: check for keys, handle nulls, and normalize types.

Example: retrieve interface counters via RESTCONF

# Pseudocode for RESTCONF JSON parsing
resp = http_get("/restconf/data/ietf-interfaces:interfaces-state/interface=GigabitEthernet0/0")
data = resp.json()

iface = data["ietf-interfaces:interface"]
oper = iface.get("oper-status")
rx = int(iface.get("statistics", {}).get("rx-unicast-packets", 0))

checks = {
  "oper_status": oper,
  "rx_unicast_packets": rx
}

A small but important nuance: some devices report counters as strings. Converting to integers early prevents subtle comparison bugs later.

Parsing Strategy That Scales

When you move from one field to many, ad-hoc parsing becomes fragile. Use a consistent strategy:

1. Normalize the response shape: convert lists vs dicts into a predictable structure.
2. Extract with a schema of your own: define which fields you expect and their types.
3. Validate with rules: presence checks, allowed values, and numeric thresholds.
4. Record evidence: keep the raw extracted values so the report is explainable.

Mind Map: Validation Rules for Extracted Fields

Integrated Example: Interface Up Check with Counter Sanity

A cohesive verification routine often does more than one call. For example, you can confirm the interface is operationally up and that traffic is plausible.

1. Call API to get oper-status.
2. If oper-status is not up, stop and report the extracted value.
3. If oper-status is up, take a second sample after a short interval.
4. Compare counters to ensure they increased.

This avoids wasting time parsing counters when the interface is clearly down. It also produces a clean failure mode: either the interface is down, or the interface is up but traffic counters are stuck.

Practical Output Format for Automation

Your parsed results should be structured so later steps can consume them. A simple pattern is:

• status: pass, fail, or indeterminate
• evidence: extracted fields
• reason: one sentence explaining the decision

That keeps your automation readable and your troubleshooting faster, because the “why” is already attached to the data.

# Pseudocode for Delta Computation
current_vlans = get_vlans()
trunks = get_trunk_ports()

if 30 not in current_vlans:
  plan.add('vlan 30')

for p in ['Gi0/1','Gi0/2']:
  allowed = get_allowed_vlans(p)
  if 30 not in allowed:
    plan.add(f'interface {p}')
    plan.add('switchport trunk allowed vlan add 30')

# Pseudocode for ACL Membership
entries = parse_acl('EDGE-IN')
needle = ('permit','tcp','10.10.10.0/24','any','eq 443')

if needle not in entries:
  plan.add('ip access-list extended EDGE-IN')
  plan.add('permit tcp 10.10.10.0 0.0.0.255 any eq 443')