Controller path trace and ACL analysis: from APIC-EM to Catalyst Center

The question every engineer is asked

"Why can't this PC reach that server?" Answering it by hand means logging in to each device on the way, checking routes, interfaces and access control lists (ACLs), and working out which way the traffic actually goes, which may differ from the way back. A controller already knows the topology and can read every device's tables, so it can answer much faster. That is the idea behind path trace.

APIC-EM: the legacy tool

The Application Policy Infrastructure Controller Enterprise Module (APIC-EM) was Cisco's first enterprise SDN controller, and its path trace with ACL analysis appeared in the CCNA syllabus of its time. It is now legacy: Cisco ended sales years ago and replaced it with DNA Center, which was renamed Catalyst Center in 2023. The concept is still worth learning because the same feature, improved, is part of Catalyst Center Assurance.

The workflow was simple:

1. The controller first discovers the network, logging in to devices to learn the topology, hosts and interfaces.
2. You choose a source and destination, usually host IP addresses, and optionally the protocol and port, such as TCP 443.
3. You tick ACL trace if you want access lists checked.
4. The controller reads routing, ARP and MAC tables from each device to follow the path, and evaluates every ACL applied on the interfaces the flow crosses.
5. It draws the path on a map, marks each hop, and shows which ACL entry permits or denies the flow.

The modern version

In Catalyst Center Assurance, path trace is available from a device or client view and can include more than ACLs: interface statistics, QoS settings and device health along the path. It also handles overlay fabrics such as SD-Access, where a simple traceroute would only show the underlay. Paths can be re-run on a schedule and exposed through the controller's REST API, so a script or ticketing system can start a trace automatically. Other vendors' controllers and many cloud platforms offer similar "reachability analysis" tools.

Tip: a path trace is only as good as the controller's data. If a device was never discovered, or its credentials changed, the trace stops at a blind spot. Keep discovery and credentials up to date.

Doing it by hand

You still need to be able to check a path without a controller, for exams and for networks that do not have one:

show ip route 10.50.8.20
show ip cef 10.50.8.20
show ip interface GigabitEthernet0/1
show access-lists
traceroute 10.50.8.20 source Vlan30

• The routing table and CEF entry show the next hop and exit interface.
• show ip interface shows which ACLs are applied in each direction.
• show access-lists shows hit counters; a deny line whose counter rises while you test is a strong clue.
• Remember the return path. A flow can fail because the reply is blocked or routed elsewhere. On a Cisco ASA, packet-tracer simulates a packet through the firewall's rules.

Real-world example: the payroll server that half worked

At a fictional manufacturing company, the finance team could open the payroll web page but uploads failed. The network engineer ran a path trace in Catalyst Center from a finance PC to the server on TCP 443, which was permitted all the way. Uploads, however, used a second service on TCP 8443. A second trace on that port showed a deny entry in an ACL on the data centre distribution switch, added during a security review months earlier. The engineer raised a change to permit TCP 8443 from the finance subnet only, confirmed the ACL counters, and re-ran the trace to show a clean path before closing the ticket.