The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This chapter describes how to configure the Distributed Packet Tracer (DPT) feature using the CLIs.
This chapter contains the following sections:
Your software release might not support all the features documented in this module. For the latest caveats and feature information, see the Bug Search Tool at https://tools.cisco.com/bugsearch/ and the release notes for your software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the “New and Changed Information” section or the "Feature History" table.
This table lists the release history for this feature.
|
Feature Name |
Releases |
Feature Information |
|---|---|---|
|
Distributed Packet Tracer (DPT) |
8.2(1) |
This feature was introduced. |
Distributed Packet Tracer (DPT) is a utility integrated within Cisco Nexus 7000/7700 platforms that can be used to trace the path of the packet through the switch. DPT can be invoked using the command line or remotely using NX-API/JSON/XML and can be configured to match specific traffic flows.
DPT provides information about flows traversing through the switch and the results of forwarding decisions for identified flows such as- forward and drop.
Supported Hardware
DPT supports M3 and F3 series modules in Cisco NX-OS Release 8.2(1).
DPT supports only the below modules:
Supported Flow Filters
In Cisco NXOS Release 8.2(1) and in Cisco NX-OS Release 8.3(1), DPT implementation supports only the below filters:
The above listed filters are supported on the FabricPath network (this does not include DFA), however filtering based on FTAG and FP TTL are not supported.
IP packet encapsulated in plain FabricPath header (this does not include DFA) is supported.
Only outer header filtering is supported. VXLAN/OTV/GRE inner IPv4/IPv6 filters are not supported. Filtering of MPLS encapsulated packets is not supported.
Configuration
DPT can be configured by:
You use the setup utility mainly for configuring the system initially, when no configuration is present. However, you can use the setup utility at any time for basic device configuration. The setup utility keeps the configured values when you skip steps in the script. For example, if you have already configured the mgmt0 interface, the setup utility does not change that configuration if you skip that step. However, if there is a default value for the step, the setup utility changes to the configuration using that default, not the configured value. Be sure to carefully check the configuration changes before you save the configuration.
Unsupported Hardware
In case of mixed chassis with supported and unsupported modules, DPT provides result only from the supported modules.
Timestamp
Timestamp presented in result CLI does not necessarily match the exact time when a packet arrives on the device. DPT checks hardware tables at specific intervals (default is 30 seconds). Therefore timestamp can be shifted by 30 seconds in comparison to actual time of packet arrival. Timestamp always references to local switch time.
Packet Count
Due to hardware limitations DPT can show only if the flow is present or not but it cannot count the number of packets transferred in the interval. If a specific flow is presented, packet count always shows one packet regardless of the number of packets sent through the switch.
Platform Limitations
DPT is mutually exclusive with ELAM feature. Any ELAM configuration will be overwritten by DPT and also manual ELAM execution can overwrite the applied DPT configuration. It is recommended not to use both features (DPT and ELAM) for troubleshooting at the same time because it provides incorrect results.
A few limitations can affect the accuracy of DPT due to the hardware architecture. When DPT does not capture traffic it does not mean that the packet did not arrive on the destination switch. There are chances that not all packets are received or forwarded.
The following scenarios/factors could occur due to the limitations impacting DPT:
Packet drops that occur inside packet buffers (ingress/egress/fabric) are not reflected in the final result. For example:
Decisions on egress forwarding ASIC are not reflected in the DPT. For example
Packets sent from CPU are not captured by the DPT. Only egress ASIC sees the outbound CPU packets.
This section describes the standard workflow of Distributed Packet Tracer (DPT) usage.
To use DPT, feature dpt needs to be enabled in global configuration mode. Other commands are executed from the privilege EXEC mode.
Configure and Start the DPT capture
|
Step 1 |
Enable the DPT feature. Example: |
|
Step 2 |
Create a flow; for example with a flow name, "first-flow" with a specific filter. Example:Maximum of 10 flow definitions can be created. Capture is performed only on the ingress side. After the creation flow status is in initialized status. This means that the flow is created in the supervisor database; however it is not installed in hardware. Multiple flows can be created. It is recommended to use specific filters as much as possible; for example, use VLAN to capture traffic between layer 2 interfaces or in the fabric path network. |
|
Step 3 |
Apply the newly created flow to the hardware. Example:In the above example, flow has been installed in the hardware ASIC but result collection has not started. The state is similar to the ELAM when the trigger has been configured. You can apply only one flow at a time in the hardware. You must release the old flow before applying a new flow. |
|
Step 4 |
Start the flow capture. Example:DPT collects the results once the flow is started. Flow start and stop time can be specified in absolute calendar values or delay seconds from the current time. In above example, the results collection happens in 10 second interval. The default results collection interval is 30 seconds, if not specified in the command. The capture time is limited to 4 hours by default from the start time, if not specified in the command. You must specify the start and end time if you need to run the capture for a longer time. |
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
Verify if the flow is started/armed. Example: |
|
|
Step 2 |
Verify the capture results. Example:Results are collected in 10 seconds interval; maximum 180 results are stored per flow. When DPT cannot decode a result it will show as "n/a". These results support XML/JSON format. DPT also supports NXAPI for remote execution from NMS. |
|
|
Step 3 |
Verify the detailed results. Example: |
| Command or Action | Purpose | |
|---|---|---|
|
Step 1 |
Stop the flow. Example: |
|
|
Step 2 |
Release the flow. Example: |
|
|
Step 3 |
Delete the flow. Example: |
The following example shows the shows the multi-destination case (unknown-unicast, multicast, and broadcast).
Device# show dpt result flow first-flow
------------------------------------------------------------------------------------------------------------------------------------------------------------
Flow ID: first-flow Start-time [2017-09-05 11:52:20] End-time [2017-09-05 15:52:20] Interval [10]
------------------------------------------------------------------------------------------------------------------------------------------------------------
Idx |Result|Drop | Timestamp |Input |Output
| |reason| |interface |Vlan |BD |VNI |Rate |Count |interface |Vlan |BD |VNI |Rate |Count
------------------------------------------------------------------------------------------------------------------------------------------------------------
1 fwd n/a 2017-08-24 14:04:25 Ethernet1/19/3 0 n/a n/a n/a 1 multi-dest LTL_0xc019 3000 n/a n/a n/a 1
In this example, the output interfaces are not listed as the traffic is forwarded to multiple destination ports; only the internal port index (LTL) is specified.
The following example provides a list of specific interfaces:
Device# show system internal pixm info ltl 0xc019
LTL res_id ltl_flag cb_flag MI[0]
0xc019 0x00000000 0x00000000 0x00000000 0x0fff
Member info
------------------
IFIDX LTL
---------------------------------
Eth101/1/8 0x252c
Eth101/1/14 0x2532
Eth101/1/2 0x2526
Eth101/1/4 0x2528
...
Po101 0x0e00
Eth102/1/2 0x2586
Eth102/1/7 0x258b
Eth1/19/4 0x0bde
Eth102/1/8 0x258c
Eth102/1/9 0x258d
The following example shows the drop result when the traffic is dropped by the egress VACL on SVI 3000.
Device# show dpt result flow first-flow
-----------------------------------------------------------------------------
Flow ID: first-flow Start-time [2017-09-05 11:52:20] End-time [2017-09-05 15:52:20] Interval [10]
-----------------------------------------------------------------------------------------------------------------------------------------
Idx |Result|Drop | Timestamp |Input |Output
| |reason| |interface |Vlan |BD |VNI |Rate |Count |interface |Vlan |BD |VNI |Rate |Count
-----------------------------------------------------------------------------------------------------------------------------------------
1 drop n/a 2017-08-24 14:04:25 Ethernet1/19/3 0 n/a n/a n/a 1 Drop LTL:0xcad 3000 n/a n/a n/a 1
Drop reason decode is not supported in Cisco NX-OS Release 8.2(1). Perform a manual traffic forwarding result analysis to determine the exact drop reason with the assistance of Cisco TAC.
In corner cases DPT might not be able to identify if packet has been forwarded or dropped. In such a case the result status has "n/a" field and the output interface has the destination LTL index. For these cases, additional manual traffic analysis is required with the assistance of Cisco TAC.
Device# show dpt result flow first-flow
-----------------------------------------------------------------------------
Flow ID: first-flow Start-time [2017-09-05 11:52:20] End-time [2017-09-05 15:52:20] Interval [10]
-----------------------------------------------------------------------------------------------------------------------------------------
Idx |Result|Drop | Timestamp |Input |Output
| |reason| |interface |Vlan |BD |VNI |Rate |Count |interface |Vlan |BD |VNI |Rate |Count
-----------------------------------------------------------------------------------------------------------------------------------------
1 n/a n/a 2017-08-24 14:04:25 Ethernet1/19/3 0 n/a n/a n/a 1 LTL_0xccc 3000 n/a n/a n/a 1
Drop reason decode is not supported in Cisco NX-OS Release 8.2(1). Perform a manual traffic forwarding result analysis to determine the exact drop reason with the assistance of Cisco TAC.
Feedback