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
| description | Description of the Session Filter |
| destination-port | Destination port or port range (eg. 5000-6000, 5000) |
| destination-prefix | Destination IP prefix |
| filter-name | Session filter name |
| ip-version | IP version/family (default is IPv4) |
| modules | Module-specific logging |
| Org | Organization Name |
| protocol | Protocol value (e.g., ICMP = 8) |
| routing-instance | Routing instance name |
| source-port | Source port or port range (eg. 5000-6000, 5000) |
| source-prefix | Source 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 DNSresult Successorg Customer1routing-instance DNSip-version ipv4source-prefix 192.168.130.0/24destination-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.
