Intelligent Traffic Director offers simplicity, flexibility, and scalability. This makes it easier for customers to deploy a traffic distribution solution in a wide variety of use cases without the use of any external hardware. Here are a few common deployment scenarios:

• Firewall cluster optimization

• Predictable redundancy and scaling of security services such as Intrusion Prevention System, Intrusion Detection System and more.

• High-scale DNS solutions for enterprise and service providers

• Scaling specialized web services such as SSL Accelerators, HTTP compression, and others

• Using the data plane of the network to distribute high bandwidth applications

The following example use cases are supported by the Cisco ITD feature:

• Load-balance traffic to 256 servers of 10Gbps each.

• Load-balance to a cluster of Firewalls. ITD is much superior than policy-based routing (PBR).

• Scale up NG IPS and WAF by load-balancing to standalone devices.

• Scale the WAAS / WAE solution.

• Scale the VDS-TC (video-caching) solution.

• Replace ECMP/Port-channel to avoid re-hashing. ITD is resilient.

ITD on the Cisco NX-OS switch enables the following:

Operational Simplicity

• Transparent connectivity for appliance and server clustering

• Optimized for fast and simple provisioning

Investment Protection

• Supported on all Cisco Nexus 5000, 6000, 7000, and 9000 switching platforms. No new hardware is required.

• End device agnostic. It supports all servers and service appliances.

You can connect servers to the Cisco NX-OS device in one-arm deployment mode. In this topology, the server is not in the direct path of client or server traffic, which enables you to plug in a server into the network with no changes to the existing topology or network.

The ITD feature supports an appliance cluster connected to a virtual port channel (vPC). The ITD service runs on each Cisco NX-OS switch and ITD programs each switch to provide flow coherent traffic passing through the nodes.

The sandwich deployment mode uses two Cisco NX-OS 7000 Series switches to provide stateful handling of traffic.

The main requirement in this mode is that both forward and reverse traffic of a flow must go through the same appliance. Examples include firewalls and load balancer deployments, where traffic between client and server must flow through the same appliance.

The key features are:

• An ITD service for each network segment—one for outside network and another for inside network.

• A source-IP load balancing scheme where the ITD service operates on the interface that connects to the outside world in an ingress direction.

• A destination-IP load balancing scheme where the ITD service operates on the interface that connects to the servers in the ingress direction.

The ITD service can be configured to host a virtual IP (VIP) on a Cisco NX-OS 7000 Series switch. Internet traffic destined for the VIP will be load balanced to the active nodes. Unlike traditional server load balancers, source NAT is not needed as the ITD service is not a stateful load balancer.

Note	You need to configure ITD service similarly on each Cisco NX-OS 7000 Series switch. The ITD service configuration needs to be done manually on each switch.

Attention

Configure a single VIP address for an ITD service serving a group of nodes (or device group).

Network Address Translation (NAT) is a commonly deployed feature in load balancing, firewall, and service appliances. Destination NAT is one of the types of NAT that is used in load balancing.

The ITD feature supports device groups. When you configure a device group you can specify the following:

• The device group's nodes

• The device group's probe

This feature enables users to dynamically add or remove nodes with minimal disruption to existing traffic. ITD now maintains an intermittent state of nodes when the nodes are deleted or added in a service that is active. In addition, ITD automatically re-programs the buckets when the user adds or deletes the node with minimum disruption to service. This feature is supported:

• at Device-group level

• in Virtual IP Address (VIP), and also without VIP

• in multiple VIP device-group feature

The Include ACL feature allows traffic selection for ITD load-balancing by defining the IP addresses to be allowed through ITD. The ACL configured under this feature defines permit ACEs to match traffic for load-balancing. Any unmatched addresses in the ACL will bypass ITD. The Include ACL and Exclude ACL features can be used in conjunction for granular traffic selection within ITD. Both these ACLs can only have permit ACEs but not deny ACEs. In circumstances where service appliances cater only to specific internet traffic, ITD selects the traffic to load-balance or redirect the traffic while the rest of the traffic is routed normally through the RIB.

The Include ACL feature is used to achieve traffic selection and traffic filtering within the ITD. The VIP feature can only match destination fields, whereas the Include ACL feature matches both source and destination fields.

The ITD feature enables you to configure specific load-balancing options by using the loadbalance command.

The optional keywords for the loadbalance command are as follows:

• buckets —Specifies the number of buckets to create. Buckets must be configured in powers of two. One or more buckets are mapped to a node in the cluster. If you configure more buckets than the number of nodes, the buckets are applied in round robin fashion across all the nodes.

• mask-position — Specifies the mask position of the load balancing. This keyword is useful when a packet classification has to be made based on specific octets or bits of an IP addresses. By default the system uses the last octet's starting most significant bits (MSBs).

  If you prefer to use nondefault bits/octets, you can use the mask-position keyword to provide the starting point at which bits the traffic classification is to be made. For example, you can start at the 8th bit for the second octet and the 16th bit for the third octet of an IP address.

• src or dst ip— Specifies load balancing based on source or destination IP address.

• src ip or src ip-l4port— Specifies load balancing based on source IP address, or source IP address and source L4 port.

• dst ip or dst ip-l4port— Specifies load balancing based on destination IP address, or destination IP address and destination L4 port.

ITD supports N+1 redundancy where M nodes can act as standby nodes for N active nodes.

When an active node fails, ITD looks for an operational standby node and selects the first available standby node to replace the failed node. ITD reconfigures the switch to redirect the traffic segment that was originally headed toward the failed node to the newly active node. The service does not impose any fixed mapping of standby nodes to active nodes.

When the failed node becomes operational again, it is reinstated as an active node and traffic from the acting standby node is redirected back to the original node and the standby node reverts to the pool of standby nodes.

When multiple nodes fail, traffic destined to all failed nodes gets redirected to the first available standby node.

A node can be configured as a standby at the node-level or device-group-level. A node-level standby receives traffic only if its associated active node fails. A device-group-level standby receives traffic if any of the active nodes fail.

You can configure the ITD service to apply traffic redirection policies on multiple ingress interfaces. This feature allows you to use a single ITD service to redirect traffic arriving on different interfaces to a group of nodes. The ingress interface command enables you to configure multiple ingress interfaces.

The same ingress interface can be configured in two ITD services, allowing one IPv4 ITD service and one IPv6 ITD service.

Configuring the same ingress interface in both IPv4 and IPv6 ITD services allows both IPv4 and IPv6 traffic to arrive on the same ingress interface. An IPv4 ITD policy is applied to redirect IPv4 traffic and an IPv6 ITD policy is applied to redirect IPv6 traffic.

Note	Make sure the ingress interface is not configured in more than one IPv4 ITD service and/or more than one IPv6 ITD service. The system does not automatically check this.

Failaction for ITD enables traffic on the failed nodes to be reassigned to the first available active node. Once the failed node comes back, it automatically resumes serving the connections. The failaction command enables this feature.

When the node is down, the traffic bucket associated with the node is reassigned to the first active node found in the configured set of nodes. If the newly reassigned node also fails, traffic is reassigned to the next available active node. Once the failed node becomes active again, traffic is diverted back to the new node and resumes serving connections.

Note	You must configure probe under an ITD device group, before enabling the failaction feature.

From Cisco NX-OS Release 8.4(1), the ITD failaction feature is enhanced to optimally pre-fetch the failaction node per bucket (i.e., the status of the service nodes before reassigning the failed node’s buckets to the next available active nodes). This functionality is automatically added when a user upgrades to Cisco NX-OS Release 8.4(1). You do not need to configure any commands to enable this functionality.

From Cisco NX-OS Release 8.3(1), the ITD failaction feature is enhanced to optimally pre-fetch the status of the service nodes before reassigning the failed node’s buckets to the next available active nodes. This functionality is automatically added when a user upgrades to Cisco NX-OS Release 8.3(1). You do not need to configure any commands to enable this functionality.

When a node is down, instead of assigning it to the next available active node, the pre-fetch optimization internally fetches the status of all the available nodes and then reassigns the failed node to an active node. Similarly, in a least bucket node fail reassignment, the pre-fetch optimization fetches the status of all the nodes before reassigning the failed node buckets to the least bucketed node.

Prior to Cisco NX-OS Release 8.3(1), when the node is down, the bucket associated with the node is reassigned to the first active node found in the configured set of nodes. If the newly reassigned node also fails, the traffic bucket is reassigned to the next available active node. The reassignment is done in a round robin fashion across nodes. The delay in reassigning the failed node bucket to an active node impacts the network performance.

Currently, the pre-fetch optimization is enabled for the failaction node least-bucket and failaction node per-bucket options.

The following example shows the failaction assignment functionality before and after pre-fetch optimization.

This example shows a running configuration:

configure terminal
 itd device-group webservers
  node ip 10.2.1.10
  node ip 10.2.1.20
  node ip 10.2.1.30
  itd http_service
  device-group webservers
  ingress interface Ethernet 3/1
  no shutdown
  exit
 itd session device-group webservers
  no node ip 10.2.1.30
  node ip 10.2.1.50
 commit