For greater security, you can configure multiple network interfaces to segregate the different types of CLM traffic.

When the CLM uses only one network for all communication, the CLM client traffic shares the same network as the NE mediation traffic and the internal communication between CLM elements. Such a configuration may pose a considerable security risk.

You can segregate the CLM client, mediation, and internal traffic by configuring the CLM to use interfaces in separate networks for each traffic type.

The multi-interface implementation isolates different traffic types to one or more of the following networks:

• client—UI, browser, and other northbound client traffic

• mediation—for direct communication with NEs

• internal—for communication such as the following:

  • between CLM cluster members

  • CLM DR functions such as data replication and keepalive messaging

Using separate networks enables you to apply additional security policies. For example, the CLM PostgreSQL service is an internal service only, and the only legitimate clients are CLM components, and not northbound browser or API clients. To help secure the PostgreSQL service from unintended access, you can apply a firewall rule to block the PostgreSQL port on the client interface.

You can convert an existing CLM system from a single-interface deployment to a multi-interface deployment.

You specify the CLM cluster interface addresses for your deployment in the platform—ingressApplications section of the CLM configuration file. The configuration steps are described in each CLM deployment procedure, and the parameters are shown below for network planning purposes.

Note: The client_IP value is mandatory; the address is used for interfaces that remain unconfigured, such as in a single-interface deployment.

Note: If the client network uses IPv6, you must specify the CLM cluster hostname as the client_IP value.

Note: The trapForwarder addresses that you specify must differ from the client_IP value, even in a single-interface deployment.

  ingressApplications:

    ingressController:

      clientAddresses:

        virtualIp: "client_IP"

        advertised: "client_public_address"

      internalAddresses:

        virtualIp: "internal_IP"

        advertised: "internal_public_address"

where

client_IP is the address for external client access

internal_IP is the address for internal communication

each public_address value is an optional address to advertise instead of the associated _IP value, for example, in a NAT environment