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).
Testing Topology
For the additional testing, I built the following topology and integrated APIC-EM into my Continue reading
Many networks leverage what is known as a VRF. These are used for traffic isolation and create separate routing instances within a router. It is important that vrf awareness is confirmed for any service (DHCP, Voice GW, etc) being locally provided for a given point in the network. One use case for such a configuration might be for voice isolation with or without MPLS. In the case that a router is providing voice gateway functionality (i.e. FXO/FXS to VOIP), the voice functions must understand the VRF construct in order to properly fulfill the role.
TL;DR–This configuration sometimes does not behave as expected and, in my experience, may require a reboot after following the documented procedure.
The configuration for VRF-Aware H.323 and SIP for Voice Gateways can be found at the URL below.
http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t15/stork.html
Notice that it makes reference to the fact that the services need to be restarted–
To configure a voice VRF, you must shut down voice services on the gateway, assign a previously defined VPN VRF to the VoIP SPI, and then restart voice services.
As one researches this particular configuration, the concept of voice “multi-vrf” will likely come up. Based on my Continue reading