Configuring APPID Support for Unidirectional Traffic
With asymmetrical routing, a networking device sees only one side of the network sessions, either from client to server or from server to client. Additional functionality is required to support application identification with unidirectional traffic. This addition enables a session for a specified service set to support an asymmetrical routing environment, and allows complete application matches using existing application signatures for traffic in the client-to-server direction only.
To enable APPID to support application matching on unidirectional traffic:
- Include the support-uni-directional-traffic statement:[edit services service-set service-set-name service-set-options]user@host# support-uni-directional-traffic
This enables the session belonging to the specified service set to support the asymmetrical routing environment. The APPID module then reports complete matches for the unidirectional traffic.
- Include the enable-asymmetric-traffic-processing statement:[edit services service-set service-set-name service-set-options]user@host# enable-asymmetic-traffic-processing
This enables the framework and plug-in to handle unidirectional traffic at a service-set level.
When you enable these settings, APPID treats unidirectional TCP traffic like a UDP connection. UDP traffic itself does not receive any special treatment because the service PIC cannot determine whether UDP traffic is unidirectional or bidirectional. The settings do not affect processing of sessions created with bidirectional traffic.
If the traffic includes both unidirectional and bidirectional sessions, the APPID module uses heuristics to decide whether to change the reporting logic.
 | Note: This feature does not change the processing for any services except APPID. However, other services, including stateful firewall, AACL, and IDP, can process unidirectional traffic in a limited manner. |
