APIC-EM Path Trace Examples – Overlay Networks

Since seeing the APIC-EM Path Trace demo for the first time and seeing how it represents CAPWAP, I’ve been curious how well it deals with other types of overlay/underlay networking. This article is a brief synopsis of that testing and provides some visuals around what was produced with this free management tool.

TL;DR–APIC-EM adds value to most network path traces and typically represents what it knows. The single exception is with MPLS VPNv4. If the MPLS PE nodes are pulled into the device inventory, path trace has a total lack of understanding around the recursive lookup into the global vrf that is required for VPNv4 functionality.

CAPWAP Representation — The Gold Standard

I wanted to start out by showing what an ideal representation of an overlay network would be for a tool like this. Path Trace understands AND clearly represents both the underlay and the overlay network for traffic flowing through a CAPWAP tunnel. The image below shows the extent of the tunnel (darker gray) and the physical components that are responsible for delivery (both through the tunnel and outside of the tunnel).

pathtrace-capwap

 

Testing Topology

For the additional testing, I built the following topology and integrated APIC-EM into my VIRL configuration. Scrolling vertically, you will see an area for testing DMVPN, MPLS VPNv4 and GRE. All testing was performed using APIC-EM version 1.3.9.

pattrace-testingtopo

DMVPN Testing and Path Trace Representation

The image below shows a path trace from a loopback IP address on Client 1 to a similar address on Client 2. For brevity, I only requested the trace in one direction. As can be seen, the utility is aware of the overlay and represents it in the output. However, the underlay is only represented as a cloud. This does not seem to change if APIC-EM has the underlay components in the device inventory.

  • Trace Represented
  • Overlay Aware
  • Underlay Unaware

pathtrace-dmvpn

GRE Testing and Path Trace Representation

A very similar test was performed between Client 1 and Client 5. Path Trace seems to handle GRE differently. In this case, the GRE endpoints are not shown connected via IGP (endpoints have static routes between each other, EIGRP is adjacent through the tunnel). So path trace represents the adjacency as Traceroute.

  • Trace Represented
  • Overlay Unaware
  • Underlay Unaware

pathtrace-gre

MPLS VPNv4 Testing and Path Trace Representation

My final test was to do a path trace from an IP address on Client 1 to and address on Client 4. As shown below, MPLS VPNv4 doesn’t seem to be interpreted and expressed as well as the other two overlays I tested. It is fairly easy to think about how an abstracted MPLS cloud could be represented by running a traceroute. However, there is really no additional value that APIC-EM adds to the understanding of MPLS when the PE nodes are included.

  • Trace Represented (only when MPLS PE nodes are excluded from inventory)
  • Overlay Unaware
  • Underlay Unaware

Initial Test (including MPLS PE nodes in inventory). As can be seen, the customer vrf is understood, but the recursive lookup is not.

pathtracempls

A final test with the MPLS PE nodes removed from inventory shows Path Trace using a  to represent the path.

pathtracemplsnope

Conclusion

The purpose of this article was to find the limits of the APIC-EM path trace tool. This utility allows administrators and engineers the ability to quickly understand the path a flow, or pair of flows, takes through the network. The only place that I found that the tool really didn’t add value was with an enterprise owned MPLS network.

While many organizations do own and maintain MPLS networks for end to end segmentation, I still see a SP provided MPLS network as more typical. In the latter case, the MPLS PE node would not be in the inventory and APIC-EM should properly represent what it knows. So for those who run Cisco networks and don’t have a tool like this, I highly recommend deploying APIC-EM for the Path Trace functionality.

 —

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

No related content found.

About Paul Stewart, CCIE 26009 (Security)

Paul is a Network and Security Engineer, Trainer and Blogger who enjoys understanding how things really work. With over 15 years of experience in the technology industry, Paul has helped many organizations build, maintain and secure their networks and systems.
This entry was posted in Uncategorized. Bookmark the permalink.

One Response to APIC-EM Path Trace Examples – Overlay Networks

  1. Pingback: Quickly Adding an NMS to VIRL - PacketU

Leave a Reply