Custom protocols
The Custom Protocols view enhances the process of recognizing network protocols in DC Netscope.
By default, DC Netscope identifies the protocols of a network flow based on the network port used for the flow. While this method is functional for flows using default ports associated with a protocol, protocol recognition fails when non-default ports are used.
With Custom Protocols, you can define rules that allow you to:
- Associate flows that do not use default ports with a specific protocol.
- Define a new network protocol.
- Create precise rules targeting specific hosts.
Overview
The Custom Protocols view is structured as follows: each card represents a rule defining a network protocol. A rule consists of one or more criteria that enable DC Netscope to determine when to apply the rule. Please note that custom protocol rules only apply to unknown flows.
Here is an example of interacting with the component:
Defining a Rule
When adding a criterion, it is possible to select two kind of rules : sql rules or classical rules.
SQL based rules
In the text field, you can define SQL boolean expressions based on columns :

Underneath, what is defined in the field will be used as an expression in a where claused of an SQL query.
We use the duckdb flavor, which is described here : DuckDB SQL documentation .
In DUCKDB, strings are defined using single quotes. DC Netscope will automatically rewriter double quotes as single quotes.
The columns that you can use are :
start_time: timestamp of the flowsrc_name: name of the source resource of the flowsrc_resource_uuid: uuid of the source resource of the flowsrc_ipaddr: ip address of the source resource of the flowdst_name: name of the destination resource of the flowdst_resource_uuid: uuid of the destination resource of the flowdst_ipaddr: ip address of the destination resource of the flowdst_port: port of the flowprotocol: protocol of the flow (default:'unknown')direction: 0 if the dst_port is on the source, 1 if the dst_port is on the targetproto_raw: transport protocol (tcp:'06 TCP')exchanged_bytes: amount of bytes in the flowexchanged_packets: amount of packets in the flow
Here are several example of sql rules:
src_name='vm1' and port=443 and proto_raw like '%TCP%': source is vm1, and traffic in on port 443 using TCP.(src_name='vm1' or src_name='vm2) and port=8000: source can be vm1 or vm2, but the port must be 8000.scr_name like '%-prod': all source that ends with-prod.
Classical rules
You can define several types of criteria within a rule: Simple Criterion
A simple criterion specifies a value that one of the flow's attributes must satisfy.
Below are examples of simple criteria:
Compound Criterion
A compound criterion consists of multiple sub-criteria. It can be configured in two ways:
- All the following are true: The compound criterion is satisfied if all sub-criteria are met.
- At least one is true: The compound criterion is satisfied if at least one sub-criterion is met.
Below is an example of a compound criterion:
Not Criterion
A not criterion is satisfied if its sub-criterion is not met. Criterion Actions
The three icons above allow you to (from left to right):
- Edit the criterion.
- Add sub-criteria for compound or not criteria.
- Delete the criterion.
Rule Actions
Several actions can be performed on a rule. By default, the action buttons on the right side of a rule include:
The actions are as follows:
- Check: Verifies the syntax of the criteria.
- Edit: Enters edit mode for the rule.
- Delete: Deletes the rule.
When you click the edit icon, the following buttons appear:
Clicking Save exits edit mode and saves the changes locally.
Below is an example of these interactions:
Synchronizing Rules with the Database
Once the local state of the rules is satisfactory, you can push the protocol rules to the DC Netscope server by clicking the PUSH TO SERVER button.
Conversely, to retrieve the latest rules stored on the server or to discard local modifications, click the PULL FROM SERVER button.