How Does CSDS Traffic Orchestrator Work
In this topic, you’ll learn how CSDS Traffic Orchestrator works in the MX Series routers.
What is CSDS Traffic Orchestrator in MX Series
Connected Security Distributed Services Traffic Orchestrator (CSDS-TO) provides stateless translated and non-translated traffic load balancing functionality as an inline Packet Forwarding Engine (PFE) service in MX Series routers. Load balancing in this context is a method where the device (MX Series with CSDS-TO) distributes the incoming transit traffic across the configured servers (SRX Series Firewalls) that are in service.
Benefits
- CSDS-TO performs stateless load balancing, which means no state information is created for a connection.
- No scaling limitations.
- Throughput is close to line rate.
Traffic Orchestrator for CSDS Architecture
You can operate CSDS-TO in the following two modes in MX Series:
-
Translated (Layer 3) mode—Do not use this mode, for CSDS solution .
-
Non-translated Direct Server Return (Layer 3) mode—Use this mode for scale-out solution.
See Figure 1 to understand CSDS-TO in MX Series. CSDS-TO functionality on MX Series includes the following:
-
CSDS-TO configures a list of available SRX Series Firewalls addresses. The Packet Forwarding Engine (PFE) programs the selector table based on these SRX Series Firewalls.
-
CSDS-TO performs ICMP based health check for each SRX Series Firewalls using the MX Series Routing Engine (RE). The RE-based health checks support probe types such as ICMP, TCP, UDP, HTTP, and SSL. If health check passes for any firewalls, CSDS-TO installs specific IP route or wildcard IP route in the routing table with next-hop as composite next-hop.
-
The MX Series programs composite next-hop in the PFE with all available SRX Series Firewalls in the selector table. Filter-based forwarding enables the client to server traffic to be directed to the CSDS-TO. The MX Series matches the specific IP route or wildcard IP route to distribute the traffic between the available SRX Series Firewalls using source or destination hash. The server to client is directly routed back to the client, bypassing the CSDS-TO.
RE-Based Health Check for CSDS Traffic Orchestrator
CSDS-TO runs the health check process on the Routing Engine (RE) instead of the service-PIC on the next generation MX routers. This feature is applicable for both MSP and USF.
To enable the health-check process (net-monitord) on RE, you can use the
command, set services traffic-load-balance
routing-engine-mode. This configuration
ensures
that the process responsible for managing and orchestrating traffic
distribution and redirection connects to the local instance of the
network monitoring process instead of the remote instance running on
the service-PIC.
The health-check probe types that are supported on the RE-based health-checks are ICMP, TCP, UDP, HTTP and SSL probes.
Loopback interface is used instead of the service interface for the CSDS-TO configuration.
The interfaces ms-x/y/0 or vms-x/y/0 respectively for MSP and USF are not needed by CSDS-TO when net-monitord is running on RE. Replace reference of the ms-x/y/0 or vms-x/y/0 interface with loopback interface lo.x.
instance Instance_V4 {
interface lo0.0; #loop back interface instead of ms-interface#
client-interface ge-2/2/4.0;
server-interface ge-2/2/5.0;
client-vrf client_vrf_1;
server-vrf server_vrf_1;
group group1 {
real-services [ rs_1 rs_2 rs_3 rs_4 rs_5 rs_6 rs_7 rs_8 ];
routing-instance server_vrf_1;
health-check-interface-subunit 0;
network-monitoring-profile nm_prof_icmp;
}
}To enable RE-based health checks, you must configure the routing-engine-mode to enable net-monitord on RE. A validation for the configuration is added and both interface ms-x/y/0.0 or interface vms-x/y/0.0 cannot be configured together in the respective mode of operation, namely, MSP or USF.