Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
ON THIS PAGE
 

Verifying the Output of ALG Sessions

This section contains examples of successful output from ALG sessions and information on system log configuration. You can compare the results of your sessions to check whether the configurations are functioning correctly.

FTP Example

This example analyzes the output during an active FTP session. It consists of four different flows; two are control flows and two are data flows. The example consists of the following parts:

Sample Output

MS-MPC Card

For MS-MPCs, the following is a complete sample output from the show services stateful-firewall conversations application-protocol ftp operational mode command:

For each flow, the first line shows flow information, including protocol (TCP), source address, source port, destination address, destination port, flow state, direction, and frame count.

  • The state of a flow can be Watch, Forward, or Drop:

    • A Watch flow state indicates that the control flow is monitored by the ALG for information in the payload. NAT processing is performed on the header and payload as needed.

    • A Forward flow forwards the packets without monitoring the payload. NAT is performed on the header as needed.

    • A Drop flow drops any packet that matches the 5 tuple.

  • The frame count (Frm count) shows the number of packets that were processed on that flow.

The second line shows the NAT information.

  • source indicates source NAT.

  • dest indicates destination NAT.

  • The first address and port in the NAT line are the original address and port being translated for that flow.

  • The second address and port in the NAT line are the translated address and port for that flow.

MX-SPC3 Card

On the MX-SPC3 services card, the following is a complete sample output from the show services sessions application-protocol ftp operational mode command:

For each session:

  • The first line shows flow information, including session ID, service-set name, policy name, session timeout, logical system name, and its state.

  • The second line, Resource information, indicates the session is created by ALG, including the ALG name (FTP ALG) and ASL group id, which is 1and the ASL resource id, which is 0 for control session and 1 for data session.

  • The third line In is forward flow and the fourth line Out is reverse flow, including the source address, source port, destination address, destination port, protocol (TCP), session conn-tag, incoming for Inand outgoing for Out interface, received frame count and bytes. NAT is performed on the header as needed.

FTP System Log Messages

System log messages are generated during an FTP session. For more information about system logs, see System Log Messages.

MS-MPC Card

The following system log messages are generated during creation of the FTP control flow:

  • Rule Accept system log:

  • Create Accept Flow system log:

  • System log for data flow creation:

MX-SPC3 CardCard

The following system log messages are generated during creation of the FTP control flow:

  • System log for FTP control session creation:

  • System log for FTP data session creation:

  • System log for FTP data session destroy:

  • System log for FTP control session destroy:

Analysis

Control Flows

MS-MPC Card

The control flows are established after the three-way handshake is complete.

  • Control flow from FTP client to FTP server. TCP destination port is 21.

  • Control flow from FTP server to FTP client. TCP source port is 21.

MX-SPC3 Card

The control flows are established after the three-way handshake is complete.

  • Control session from FTP client to FTP server, TCP destination port is 21.

  • Data session from FTP client to FTP server, it’s for FTP passive mode.

  • Data session from FTP server to FTP client, it’s for FTP active mode:

Data Flows

A data port of 20 is negotiated for data transfer during the course of the FTP control protocol. These two flows are data flows between the FTP client and the FTP server:

Troubleshooting Questions

  1. How do I know if the FTP ALG is active?

    • The ALG protocol field in the conversation should display ftp.

    • There should be a valid frame count (Frm count) in the control flows.

    • A valid frame count in the data flows indicates that data transfer has taken place.

  2. What do I need to check if the FTP connection is established but data transfer does not take place?

    • Most probably, the control connection is up, but the data connection is down.

    • Check the conversations output to determine whether both the control and data flows are present.

  3. How do I interpret each flow? What does each flow mean?

    • FTP control flow initiator flow—Flow with destination port 21

    • FTP control flow responder flow—Flow with source port ;21

    • FTP data flow initiator flow—Flow with destination port 20

    • FTP data flow responder flow—Flow with source port 20

RTSP ALG Example

The following is an example of an RTSP conversation. The application uses the RTSP protocol for control connection. Once the connection is set up, the media is sent using UDP protocol (RTP).

This example consists of the following:

Sample Output for MS-MPCs

Here is the output from the show services stateful-firewall conversations operational mode command:

Sample Output for MX-SPC3 Services Card

Here is the output from the show services sessions application-protocol rtsp operational mode command:

Analysis

An RTSP conversation should consist of TCP flows corresponding to the RTSP control connection. There should be two flows, one in each direction, from client to server and from server to client:

  • The RTSP control connection for the initiator flow is sent from destination port 554.

  • The RTSP control connection for the responder flow is sent from source port 554.

The UDP flows correspond to RTP media sent over the RTSP connection.

Troubleshooting Questions

  1. Media does not work when the RTSP ALG is configured. What do I do?

    • Check RTSP conversations to see whether both TCP and UDP flows exist.

    • The ALG protocol should be displayed as rtsp.

    Note:

    The state of the flow is displayed as Watch, because the ALG processing is taking place and the client is essentially “watching” or processing payload corresponding to the application. For FTP and RTSP ALG flows, the control connections are always Watch flows.

  2. How do I check for ALG errors?

    • You can check for errors by issuing the following command. Each ALG has a separate field for ALG packet errors.

System Log Messages

Enabling system log generation and checking the system log are also helpful for ALG flow analysis. This section contains the following:

System Log Configuration

You can configure the enabling of system log messages at a number of different levels in the Junos OS CLI. As shown in the following sample configurations, the choice of level depends on how specific you want the event logging to be and what options you want to include. For details on the configuration options, see the Junos OS Administration Library for Routing Devices (system level) or the Junos OS Services Interfaces Library for Routing Devices (all other levels).

  1. At the topmost global level:

  2. At the service set level:

  3. At the service rule level:

System Log Output

System log messages are generated during flow creation, as shown in the following examples:

The following system log message indicates that the ASP matched an accept rule:

For a complete listing of system log messages, see the System Log Explorer.