Expert Services Troubleshooting: NAT, DHCP, and SLA Ticket Scenarios

Services break in ways that routing never does. A route either exists or it does not; a NAT translation either happened or it did not, and if it did not, the packet was silently dropped with no log and no routing-table clue. Services troubleshooting is a different discipline - it is about knowing which translation table, which binding, or which tracking object to look at, because the symptom is almost always just "it does not work" with nothing obvious in show ip route.

This article is five services faults, grounded in the real behaviour from building the services lab for this domain, with the diagnostic command for each. For the theory, see the IP services pillar.

The method

Services faults do not show up in the routing table. Go straight to the service's own state table:

Ticket 1: "Two overlapping customers can reach the shared server, but one sees the other's traffic"

Symptom. Two VRFs with overlapping 10.5.5.0/24, NATed to a shared exit. Both work, but return traffic is going to the wrong customer, or translations are colliding.

Diagnosis. Look at each VRF's translation table:

R1#show ip nat translations vrf RED
icmp 192.168.99.201:1024 10.5.5.50:0  192.168.99.100:0  192.168.99.100:1024

R1#show ip nat translations vrf BLUE
icmp 192.168.99.202:1024 10.5.5.50:0  192.168.99.100:0  192.168.99.100:1024

Healthy is what you see above - identical inside-local (10.5.5.50) in each, but distinct inside-global (.201 vs .202). If instead both VRFs show the same inside-global, or the translations appear in the wrong VRF, the NAT is not VRF-aware.

Cause. The vrf keyword is missing on the ip nat inside source statement, so NAT treats the two 10.5.5.50s as one and they collide. Or both VRFs share one pool.

Fix. A distinct pool and ACL per VRF, and the vrf keyword on each rule:

ip nat inside source list RED-ACL  pool RED-POOL-NAT  vrf RED  overload
ip nat inside source list BLUE-ACL pool BLUE-POOL-NAT vrf BLUE overload

Lesson: for VRF-aware NAT, everything must be per-VRF - the pool, the ACL, and the vrf keyword. Verify by checking that show ip nat translations vrf X shows a distinct inside-global per VRF. Full detail in VRF-aware NAT.

Ticket 2: "Some clients get no DHCP address"

Symptom. New clients on a subnet are not getting addresses. Others already have leases.

Diagnosis.

R1#show ip dhcp pool CLIENTS
 Total addresses    : 254
 Leased addresses   : 254           <-- pool is full
 Excluded addresses : 9

If leased equals total, the pool is exhausted. Also check for conflicts, which take addresses out of service:

R1#show ip dhcp conflict
IP address       Detection method   Detection time
10.7.7.55        Ping               Jul 12 2026 ...

Cause. Two possibilities. Either the lease is too long for the churn (dead reservations for devices that left hold addresses for a day), or a duplicate-IP conflict took addresses out of the pool because a static device was not excluded.

Fix. Shorten the lease to the device dwell time (lease 0 1 0 for a one-hour guest network), and exclude every statically-assigned address (ip dhcp excluded-address). Clear stale conflicts with clear ip dhcp conflict *.

Lesson: "no DHCP address" is a pool problem 90% of the time. show ip dhcp pool tells you instantly whether it is exhaustion; show ip dhcp conflict tells you whether duplicates are eating it.

Ticket 3: "SNMP polling works but one OID returns nothing"

Symptom. The NMS polls the router fine for interface stats, but a specific OID (say a temperature sensor or a Cisco-specific table) returns "no such object".

Diagnosis.

R1#show snmp view | include PLVIEW
PLVIEW iso - included
PLVIEW internet - included

Cause. The OID being polled is not in the view the user's group is bound to. SNMPv3 views are default-deny: anything not explicitly included is invisible, and the router returns nothing rather than an error.

Fix. Add the OID subtree to the view:

snmp-server view PLVIEW 1.3.6.1.4.1.9 included    ! include the Cisco enterprise subtree

Lesson: when SNMPv3 polling works for some OIDs but not others, it is almost always a view restriction, not a connectivity problem. show snmp view shows exactly what is permitted. (And if nothing works, or traps do not arrive, check the engine ID - see SNMPv3 in production.)

Ticket 4: "The EPC capture buffer is empty / fills instantly"

Symptom. An Embedded Packet Capture either captures nothing, or fills up before the event you are hunting.

Diagnosis.

R1#show monitor capture buffer EPCBUF parameters
Buffer Size : 262144 bytes, Max Element Size : 1518 bytes, Packets : 0

Causes and fixes. Several distinct problems present the same way:

• Nothing captured, and the config was rejected? You used the modern monitor capture NAME interface syntax on a platform that only supports the classic monitor capture buffer/point model. Switch syntaxes.
• Nothing captured, config accepted? The capture point is not associated with the buffer, or not started. monitor capture point associate then start.
• Nothing captured, but traffic is flowing? Your ACL filter matches only one direction, or the wrong addresses. Match both directions of the conversation.
• Buffer full before the event? A linear buffer stopped when full. Use circular to keep the most recent packets, or raise the size.

Lesson: show monitor capture buffer X parameters tells you the packet count and the point status in one view. An empty buffer with an inactive point means it was never started; a full linear buffer means your event happened after it filled. Full detail in Embedded Packet Capture.

Ticket 5: "The IPv6 downstream interface has no address after a delegation change"

Symptom. A DHCPv6-PD delegated prefix changed (the ISP renumbered), but a downstream interface still has the old address, or no address.

Diagnosis. Check the general-prefix chain:

R2#show ipv6 general-prefix
IPv6 Prefix DELEGATED-FROM-R1, acquired via DHCP PD
  2001:DB8:AAAA::/64 Valid lifetime 3575, preferred lifetime 1775
   Ethernet0/1 (Address command)

R2#show ipv6 interface Ethernet0/1
    2001:DB8:AAAA::1, subnet is 2001:DB8:AAAA::/64

Cause. If the general prefix shows the new prefix but the interface still shows the old address, the interface is not referencing the general prefix by name - it has a hard-coded address instead. If the general prefix itself is missing, the PD lease was lost (check show ipv6 dhcp binding on the delegating router).

Fix. Number the interface from the general prefix so it tracks changes automatically:

interface Ethernet0/1
 ipv6 address DELEGATED-FROM-R1 ::1:0:0:0:1/64

Lesson: the whole point of a general prefix is automatic renumbering. If an interface is not updating when the delegation changes, it is not referencing the general prefix - it has a static address. show ipv6 general-prefix shows the current prefix and which interfaces reference it. Detail in IPv6 services closure.

The commands, collected

! NAT
show ip nat translations [vrf X]
show ip nat statistics

! DHCP
show ip dhcp binding
show ip dhcp pool
show ip dhcp conflict

! SNMP
show snmp view
show snmp user
show snmp host

! EPC
show monitor capture buffer X parameters
show monitor capture buffer X

! IPv6 services
show ipv6 dhcp binding        (delegating router)
show ipv6 general-prefix      (requesting router)
show ipv6 interface X

! Tracking / SLA (if used for NAT/route failover)
show ip sla statistics
show track

Key takeaways

• Services faults do not appear in the routing table. Go to the service's own state table: translations, bindings, views, tracking objects.
• VRF-aware NAT colliding: the vrf keyword is missing or a pool is shared. Verify a distinct inside-global per VRF with show ip nat translations vrf X.
• No DHCP address: pool exhaustion or a conflict. show ip dhcp pool and show ip dhcp conflict. Fix with shorter leases and proper exclusions.
• SNMP OID missing: a view restriction, not connectivity. show snmp view. (Nothing working at all = engine-ID mismatch.)
• Empty/full EPC buffer: wrong syntax for the platform, unstarted point, one-directional filter, or a full linear buffer. show monitor capture buffer X parameters.
• IPv6 interface not renumbering: it has a static address instead of referencing the general prefix. show ipv6 general-prefix.

That closes the expert services series, and with it the CCIE Infrastructure Security and Services domain. The full cluster index lives on the IP services pillar, cross-linked to infrastructure security.