Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation
Guide That Contains This Content
[+] Expand All
[-] Collapse All

    IDP Series Operating System Overview

    The following topics explain the features of the IDP Series operating system:

    IDP Series Multicore Architecture

    The IDP Series operating system separates control plane and data plane processes, making the IDP Series devices resilient to periods of heavy load, such as a denial-of-service attack (DoS attack) or distributed denial-of-service attack (DDoS attack). In high-end platforms, control plane and data plane processes run on separate CPU, bolstering resiliency and performance. Figure 1 shows the processes that run on each core CPU for IDP Series platforms.

    Figure 1: IDP Multicore Architecture

    Image g036635.gif

    Table 1 describes how CPUs are dedicated on IDP Series platforms.

    Table 1: IDP Multicore Architecture

    Platform

    Multicore Architecture

    IDP8200

    The IDP8200 appliance has eight core CPUs:

    • One CPU is dedicated to control plane processes, including configuration and logging processes.
    • One CPU is dedicated to the JNET driver processes, which handle traffic transmission and buffering. The JNET driver runs in polling mode.
    • The remaining CPUs are dedicated to data plane processes, including the IDP engine processes that inspect traffic and take action against attacks.

    Note: When you use the scio or sctop utilities to monitor IDP processes, you can specify the -c CPU option to display statistics related to processing on a particular IDP engine. For example, to display CPU utilization for CPU 2, the syntax is scio -c 2 idp-cpu-utilization. Without the -c option, scio displays an aggregate for all IDP engines.

    IDP1100, IDP800, IDP250

    The IDP1100, IDP800, and IDP250 appliances have two core CPUs:

    • One CPU is used for both control plane and JNET driver processes. The JNET driver runs in NAPI mode: when traffic is low, the JNET driver operates in interrupt mode; when traffic is high, the JNET driver switches to polling mode.
    • The second CPU is dedicated to data plane processes.

    IDP600, IDP200, IDP75

    The IDP600, IDP200, and IDP75 appliances have one core CPU. The JNET driver runs in NAPI mode: when traffic is low, the JNET driver operates in interrupt mode; when traffic is high, the JNET driver switches to polling mode.

    Note: If you use port monitoring utilities such as the Linux lsof command to view port activity, you will notice activity by host 127.0.0.1 (example below). These entries identify internal system communication. Communication on port 9101 and above and activity identifying Bacula processes is related to the internal communication between the control plane and data plane. This activity is essential to proper functioning of the IDP OS.


    [root@idp-75-172-22-151-70 ~]# lsof -n -i
    COMMAND     PID   USER   FD   TYPE DEVICE SIZE NODE NAME
    idpengine  3164   root    4u  IPv4  39333       TCP *:bacula-dir (LISTEN)
    idpengine  3164   root    5u  IPv4  40576       TCP 127.0.0.1:bacula-dir->127.0.0.1:39472 (ESTABLISHED)
    idpengine  3164   root    6u  IPv4  39336       TCP 127.0.0.1:50000 (LISTEN)
    idpengine  3164   root    7u  IPv4 302480       TCP 127.0.0.1:50000->127.0.0.1:37684 (ESTABLISHED)
    idpengine  3164   root    9u  IPv4 302372       TCP 127.0.0.1:bacula-dir->127.0.0.1:59114 (ESTABLISHED)
    ..

    Auto-Recovery Feature

    The auto-recovery feature monitors the status of individual IDP engines. In the event an IDP engine is terminated, the auto-recovery daemon logs the event, attempts to restart the IDP engine, and logs recovery. The auto-recovery feature is enabled by default.

    The auto-recovery feature bolsters resiliency of IDP Series devices by enabling restart per IDP engine. In case of failure by an IDP engine, the other IDP engines in the data plane do not need to be restarted. If an IDP engine becomes overloaded or terminates, the JNET driver buffers packets for the active sessions while the IDP engine restarts. If the IDP engine does not restart after six attempts, the IDP Series device may enter internal bypass (if enabled).

    The auto-recovery feature is complemented by the bypass under congestion feature. When the IDP engine recovers, it processes the buffered packets. If the buffer becomes large enough, it triggers bypass under congestion instead of resulting in subsequent failure.

    Note: The auto-recovery process ensures the IDP engine restarts with the same device configuration, feature configuration, and security policy that were in place before the restart. However, because the application identification feature uses the first packets of a session as a key to determining the application, the auto-recovery process cannot reliably identify the application for buffered sessions. As a result, in processing buffered traffic, the application identification feature is unavailable and application rate limiting cannot be applied. In addition, the latest interval of application volume tracking data is discarded.

    Flow Bypass Feature

    The flow bypass feature prevents the IDP Series device from becoming a point of failure when the network is congested. With flow bypass enabled, when the IDP system packet receive queue reaches a rising threshold that you specify, the IDP engine marks the flow as a bypass flow and passes it through, uninspected. The IDP Series device passes through subsequent flows until the IDP system receive queue falls below a reset threshold that you also specify. On IDP8200, which has multiple IDP engines, the flow bypass feature operates per IDP engine; that is, when the IDP packet receive queue for an individual IDP engine reaches its rising threshold, the individual IDP engine takes the flow bypass action and other IDP engines continue to inspect flows.

    The flow bypass feature is disabled by default. It is intended for use in networks that prioritize availability over security.

    For procedures for enabling the flow bypass feature, configuring its thresholds, and monitoring the feature, see the IDP Series Administration Guide.

    Key Processes

    Table 2 describes the key processes.

    Table 2: Processes

    Process

    Description

    agent

    Manages communication between the IDP Series device and Network and Security Manager.

    idpengine

    Performs packet processing, including decapsulation or decryption, defragmentation, reassembly, inspection, and rule actions.

    idpHMD

    Generates SNMP alerts when thresholds are crossed for tracked resources on the device. Responds to SNMP poll requests. Resources are CPU, memory, hard disk space, and session count.

    idpLogReader

    Gathers logs generated by idpengine and stores the information in a local log database. The agent process forwards the data to NSM, where you can view records.

    pkid

    Inspects SSL traffic, if SSL inspection is turned on.

    profiler

    Gathers information about hosts and applications in your network. Profiler stores the information in the Profiler database. The agent process forwards the data to NSM, where you can view records.

    sciod

    Handles policy push, information retrieval, Profiler status, and so on.


    Published: 2011-02-08