Packet Tracing

What are your feelings

Troubleshooting: Packet Tracing #

In this article, we will look at how to make use of the inbuilt feature of Versa VOS to debug the life of a packet or a session. This will help engineers and Enterprise troubleshoot and identify issues much faster.

Traditional debug-level logs put a lot of load on the production system and is generally not recommended. However, by using the Packet tracing feature and the logs generated by it, we can identify the root cause of an issue.

The packet tracking logs are stored in /var/log/versa/versa-pkttrace.log

The packet trace option, comes with a host of option as listed below

descriptionDescription of the Session Filter
destination-portDestination port or port range (eg. 5000-6000, 5000)
destination-prefixDestination IP prefix
filter-nameSession filter name
ip-versionIP version/family (default is IPv4)
modulesModule-specific logging
OrgOrganization Name
protocolProtocol value (e.g., ICMP = 8)
routing-instanceRouting instance name
source-portSource port or port range (eg. 5000-6000, 5000)
source-prefixSource IP prefix

Configuration #

In this section we will see how to create a Packet Trace filter to trace DNS packets originating from the subnet 192.168.130.0/24.

Step 1: Create a packet trace filter using the command
request debug session filter-create
- this has to be followed by configurign all or required packet trace option. 

In this case, we will create a packet filter with the name DNS with Protocol 17 (UDP) for DNS packets going from the LAN subnet toward the DNS Server 8.8.8.8/32

root@gotham-cli> request debug session filter-create filter-name DNS org Customer1 source-prefix 192.168.130.0/24 destination-prefix 8.8.8.8/32 protocol 17 routing-instance riCustomer1

Packet trace filters are per tenant; so in case of a multi-tenant CPE, other tenants are not penalized because of extra lookup and logging done for a specific tenant.

Step 2: To view the packet trace filter, execute teh command
request debug session filter-display <<filter_name>> 
root@gotham-cli> request debug session filter-display DNS
result Success 
org Customer1 
routing-instance DNS 
ip-version ipv4 
source-prefix 192.168.130.0/24 
destination-prefix 8.8.8.8/32

The command shows that the packet trace filter has been successfully created and all the other options associated with it.

Step 3: To view the packet trace table (Datapath), use the command 
show debug filter trace table
root@gotham-cli> show debug filter trace table 
 
Legends
  C/Catg - Category
  L/Prio - Level/priority
  P/Prot - Protocol


 +------------+---+-----+-----+-----------+--------------------+--------------------+-------------+-------------+
 |   Rule Hdl | C |  L  |  P  |    VRF    |     SOURCE-IP      |       DEST-IP      |    SPORT    |    DPORT    |
 +------------+---+-----+-----+-----------+--------------------+--------------------+-------------+-------------+
 | 0x00010000 | A |  22 |  17 |    8-8    |   192.168.130.0/24 |         8.8.8.8/32 |     0-65535 |     0-65535 |
 +------------+---+-----+-----+-----------+--------------------+--------------------+-------------+-------------+
 | Total IPv4 Filters: 1                                                                                        |
 +--------------------------------------------------------------------------------------------------------------+




root@gotham-cli> show debug filter trace stats 


 Rule Handle 0x00010000 :     1

It is a good practice to stop and delete the packet trace filter once the logs are captured. A packet trace filter can be deleted using the command request debug session filter-delete <filter_name>

Summary #

In this article, we saw how to create packet trace filters which can be used for debugging or troubleshooting data path issues. By using the filtering options available, enterprise and users can configure more granular packet captures that will help identify issues faster.