Sun Fire B10n Content Load Balancing Blade Version 1.3 Administration Guide

This chapter describes the management and control interfaces available through the Sun Fire B10n blade command line interface (CLI). It lists the CLI commands under the various management categories with the appropriate options.

This chapter includes the following sections:

• Typographic Conventions Specific to the Sun Fire B10n Command Line Interface
• User Access
• Configuring the Networking
• Monitoring
• Configuring SSL Device Entries
• Configuring Multiple SSL Devices
• Configuring the Content Load Balancing Blade
• Load Balancing Service Configuration and Management
• Server Configuration
• Load Balancing Rule Configuration
• Load Balancing Group Configuration and Management
• Load Balancing Configuration Listings
• Configuring the System
• Flash File System Commands
• Other Useful Commands

---

Typographic Conventions Specific to the Sun Fire B10n Command Line Interface

Command descriptions use these conventions:

• Commands and keywords are in boldface in code boxes, and in courier in tables and text.
• Arguments for which you supply values are in italic in code boxes, tables, and text.
• Required options are grouped in braces ({ }) and separated by vertical bars (|).
• Optional elements are grouped in square brackets ([ ]) and separated by vertical bars (|).

---

User Access

The Sun Fire B10n blade has two levels of user access:

• Supervisor - In the Level 2 access mode, you can access all commands. You can add or change user name, password, and access level.
• General - In the Level 1 access mode, you can query the system status and configuration, but you cannot modify the configuration.

TABLE 4-1 describes the user commands.Table describing user commands.

Using the login Command

The login command is used to log in initially as the administrator. It can also be used to log in as another user with a different access level than the one you currently have.

The login command has no defaults and can be used at any access level. The corresponding command is logout.

1. Access the console for the blade:

sc> console Sn

Where S indicates the slot and n is the number of the slot containing the blade you you want to configure.

2. Log in as admin to access the command-line interface:

Login: admin

Password: admin

puma{admin}#

3. Change the admin password:

puma{admin}# user password admin

Enter new password: 

Confirm new password:

Adding Users

Only the administrator (Supervisor) with Level 2 access can add new users who can be given all the privileges of the administrator or limited privileges, depending on the assigned access level. By default, the user is created with Level 1 access.

TABLE 4-2 lists the parameters for user access command:Table describing user access parameters.

As admin, you can add new users, assign access level, and a default password:

puma{admin}# user add name username [access {1|2}]

puma{admin}# user access name username access {1|2}

puma{admin}# user password login-name

As admin, you can change a user's access level:

puma{admin}# user access name username access {1|2}

The following example changes the access level of user1 to 1.

puma{admin}# user access name user1 access 1

As admin, you can change a user's password level:

puma{admin}# user password username

Enter new password:******

Confirm new password:******

puma{admin}#

As admin, you can remove a user:

puma{admin}# user delete username

As admin, you can list all users:

puma{admin}# user show

You can also list all users with the show user command:

As admin, you can list all users:

puma{admin}# show user

Both commands list all users currently existing in the system, along with their respective access levels.

---

Configuring the Networking

This section describes how to configure the network for the Sun Fire B10n blade

1. As admin, use the following command:

puma{admin} # config

2. As admin in config mode, use the following command:

puma(config){admin}# ip interface {0|1} ip-addr mask netmask

The config ip interface command configures the IP address on the content load balancing blade to be used for management and control. Use this IP address for tasks such as opening a Telnet session on the content load balancing blade.

TABLE 4-3 describes the parameters for setting the real IP addresses.Table describing parameters for setting the real IP addresses.

Examples

The first example sets the IP address on interface 0 as 192.50.50.144 and the subnet mask as 255.255.255.0.

puma(config){admin}# ip interface 0 192.50.50.144 mask 255.255.255.0

The following example sets the IP address on interface 1 as 192.50.50.145 and the subnet mask as 255.255.255.0.

puma(config){admin}# ip interface 1 192.50.50.145 mask 255.255.255.0

As any user, use the following command:

puma{user} # ping {ip-addr | hostname} [packet-count]

The ping command determines whether the Sun Fire B10n blade has connectivity or whether a host is available on the network. The command output shows whether the response was received, that is, the host exists on the network.

If the host is not responding then ping displays this message:

no answer from hostname

If the host is available on the network then ping displays this message:

hostname is alive

TABLE 4-4 describes the parameters for sending a ping request.Table describing the parameters for sending a ping request.

As admin in config mode, use the following command:

puma(config){admin}# no ip interface {0|1}

This command unconfigures a network interface on the Sun Fire B10n blade.

You can configure both a primary and a secondary Domain Name Server (DNS) for the Sun Fire B10n blade. When supplied with a hostname, the DNS server resolves it and obtains the corresponding IP address.

As admin in config mode, use the following command:

puma(config){admin}# dns server ip-addr {primary|secondary}

As admin in config mode, use the following command:

puma(config){admin}# remove dns server ip-addr 

As admin in config mode, use the following command:

puma(config){admin}# dns suffix suffix-name

This sets the suffix to be added to the hostnames before resolution with a DNS resolver to get the IP address.

As any user, use the following command:

puma{user}# show network

As admin in config mode, use the following command:

puma(config){admin}# no dns suffix 

As admin in config mode, use the following command:

puma(config){admin}# default gateway ip-addr

Where ip-addr is the gateway IP address.

As admin in config mode, use the following command:

puma(config){admin}# no default gateway 

As admin in config mode, use the following command:

puma(config){admin}# default hostname hostname

This example configures the default hostname as B10n-no-1:

puma(config){admin}# default hostname B10n-no-1

After you set up the hostname, your CLI prompt displays the hostname:

B10n-no-1(config){admin}# 

As any user, use the following command:

puma{user} # show network

This command returns the following information:

• IP address and netmask on the two interfaces
• The default gateway
• The DNS server and suffix configurations
• The management VLAN
• If set, what is the value
• Whether it is enabled or not

• The default data VLAN
• If set, what is the value
• Whether it is enabled or not.

• The server monitoring information

1. As admin, use the following command:

puma{admin}# show arp

The output from this command shows all the entries in the ARP table.

The following example shows a typical output from the show arp command:

LINK LEVEL ARP TABLE

destination      gateway            flags Refcnt  Use           Interface

--------------------------------------------------------------------------

192.50.50.11     00:03:af:26:73:07405    0       35330         iq0

192.50.50.12     00:03:af:26:97:fb405    1       16653         iq0

--------------------------------------------------------------------------

See To Configure the Subnet Mask for a VIP to create a VIP subnet mask.

As any user, use the following command:

puma{user}# show vip

This command lists all the VIPs configured on the Sun Fire B10n blade.

As any user, use the following command:

puma{user}# show end-points

This command lists all the end points in the system. It lists all the 3 tuples, their type, for example, tracking end points, service end points, and so on, and the name of the service to which they belong.

---

Monitoring

The blade servers are monitored for health and connectivity. This involves collecting data such as server response time (or server load), network latency to a server, whether the server is up, whether the network (either the network connection between the content load balancing blade and the server or the network interface on the server) is up, and so on. The actual data collection on each server is performed by a control module residing on the server. The statistics are obtained by the management module on the Sun Fire B10n blade using SNMP.

As admin in config mode, use the following command:

puma(config){admin}# server-monitor interval interval-val [max-try max-try-val]

The config server-monitor command configures the monitoring parameters for detecting loss of connectivity to a back end server or a failure of the server itself.

TABLE 4-5 describes the parameters for setting up a server for monitoring.Table describing the parameters for setting up a server for monitoring.

As admin in config mode, use the following command:

puma(config){admin}# service app-monitor name service-name interval interval-val max-try max-try-val {{proto {tcp | http}} | {script filename}}

The config service app-monitor command configures the monitoring parameters for detecting the health of the application for a particular service.

TABLE 4-6 describes the parameters for this command:

As admin in config mode, use the following command:

puma(config){admin}# service app-monitor-param name service-name param param-name param-value

This command configures parameters for the specified protocol. HTTP supports setting of the URL.

TABLE 4-8 describes the parameters for this command:

As admin in config mode, use the following command:

puma(config){admin}# [no] enable service app-monitor name service-name

Where service-name is the name of the service for which application monitoring is to be enabled or disabled.

---

Configuring SSL Device Entries

The Sun Fire B10n blade can be configured to work in conjunction with one or more SSL proxy blades for content load balancing SSL traffic. You must configure an SSL entry on the content load balancing blade for each SSL proxy blade in the system.

The config ssl name command adds an entry for an SSL proxy blade on the content load balancing blade with at least one interface configured.

As admin in config mode, use the following command:

puma(config){admin}# ssl name ssl-device-name {ssl-ip-1 | hostname-1} [{ssl-ip-2 | hostname-2}]

Examples

The first example creates an SSL device ssl1, with an IP address of 192.50.50.12.

puma{config}{admin}# ssl name ssl1 192.50.50.12

The second example creates an SSL device ssl2, with an IP address of 192.50.50.14 and 192.50.50.15.

puma{config}{admin}# ssl name ssl1 192.50.50.14 192.50.50.15

TABLE 4-8 describes the parameters for adding SSL device configurations.Table describing the variables for adding SSL blade configurations.

The remove ssl name command removes an SSL device entry.

As admin in config mode, use the following command:

puma(config){admin}# remove ssl name {ssl-device-name}

Example

The following example removes an SSL device ssl3.

puma{config}{admin}# remove ssl name ssl3

As admin in config mode, use the following command:

puma(config){admin}# ssl port-pair ssl-device-name secureport secure-port-num clearport clear-port-num

Example

The following example adds a port pair to an SSL device ssl1, with secure port as 443 and clear port as 880.

puma{config}{admin}# ssl port-pair ssl1 secureport 443 clearport 880

The ssl port-pair command configures an SSL device entry with a secure port and the corresponding clear port, that is, a port pair configuration.

TABLE 4-9 describes the parameters for adding and removing port pairs.Table describing the parameters for adding and removing port pairs.

As admin in config mode, use the following command:

puma(config){admin}# remove ssl port-pair {ssl-device-name} secureport {secure-port-num} clearport {clear-port-num}

Example

The following example removes a port pair from an SSL device ssl1.

puma{config}{admin}# remove ssl port-pair ssl1 secureport 443 clearport 880

The remove ssl port-pair command removes a port pair configuration from an SSL device entry.

As admin in config mode, use the following command:

puma(config){admin}# ssl if ssl-device-name {ssl-ip|hostname}

Example

The following example adds interface 192.50.50.13 to an existing SSL device ssl1.

puma{config}{admin}# ssl if ssl1 192.50.50.13

The ssl if command configures an interface for an SSL device entry.

TABLE 4-10 describes the variables for adding or removing an interface.Table describing the variables for adding or removing an SSL blade interface.

As admin in config mode, use the following command:

puma(config){admin}# remove ssl if ssl-device-name {ssl-ip|hostname}

Example

The following example removes an interface 192.50.50.13 from an SSL device ssl1.

puma{config}{admin}# remove ssl if ssl1 192.50.50.13

The remove ssl if command removes an interface from an SSL device entry.

The enable ssl name command enables an SSL device entry.

As admin in config mode, use the following command:

puma(config){admin}# enable ssl name {ssl-device-name}

By default, an SSL entry is enabled when it is created.

The no enable ssl name command disables an SSL device entry.

As admin in config mode, use the following command:

puma(config){admin}# no enable ssl name {ssl-device-name}

As any user, use the following command:

B10n {user} # show ssl [ssl-device-name]

You can use this command to display the SSL devices configured for the content load balancing blade. By specifying the ssl-device-name, you can show one specific blade.

---

Configuring Multiple SSL Devices

To configure multiple SSL devices, repeat the steps under Configuring SSL Device Entries for each SSL device to be added. All the configured SSL devices can be displayed using the show ssl command.

---

Configuring the Content Load Balancing Blade

For Layer 7 load balancing, some TCP parameters must be configured on the content load balancing blade. The TCP stack in each of the blade servers being load balanced must be configured with the same parameters.

The config default tcp-params command sets the TCP parameters on the content load balancing blade to be used for TCP connections that are Layer 7 load balanced. These parameters must be set for each blade and serve as defaults. They can be overwritten for each individual service if required.)

As admin in config mode, use the following command:

puma(config){admin}# default tcp-params [window tcp-window] [window-scale tcp-ws-factor] [ts] [sack]

The following example sets the TCP default window to 2048, the window scaling factor to 1, and the TCP timestamp and SACK options:

puma(config){admin}# default tcp-params window 2048 window-scale 1 ts sack

TABLE 4-11 describes the options for setting the TCP parameters for the content load balancing blade.Table describing the options for setting the TCP parameters.

Defaults

tcp-window defaults to 8192. tcp-ws-factor defaults to 0, that is, the window scaling option is not supported. The SACK option is supported by default, but the timestamp option is not.

Examples

The first example sets the TCP window to 2048:

puma(config){admin}# default tcp-params window 2048

The following example scales the window to 1 and includes the timestamp option:

puma(config){admin}# default tcp-params window-scale 1 ts

The third example adds only the timestamp and SACK options:

puma(config){admin}# default tcp-params ts sack

For TCP load balancing services, the Sun Fire B10n blade performs a connection handoff to the back end servers. The maximum number of times the handoff message is to be retransmitted to a server before trying a new server is a parameter that is set to a default value on the content load balancing blade. The default can be changed as needed. This feature applies to Layer 7 load balancing services only.

The default tcp-handoff-params command sets the default TCP connection handoff parameters on the content load balancing blade. These parameters are set for each blade and serve as defaults. They can be overwritten for a service if required.

As admin in config mode, use the following command:

puma(config){admin}# default tcp-handoff-params {max-open-resend}

Where max-open-resends is the maximum number of times the OPEN message is retransmitted to the same server before load balancing again. The default value for max-open-resends is 5.

Example

The following example sets the value for the maximum retransmissions of the handoff message.

puma(config){admin}# default tcp-handoff-params 7

As any user, use the following command:

B10n {user} # show default tcp

The show default tcp command shows default TCP parameters, TCP DoS defense parameters, and TCP connection handoff parameters configured on the content load balancing blade.

---

Load Balancing Service Configuration and Management

A load balancing service on Sun Fire B10n blade is characterized by a VIP, a port, and a protocol, the interface on content load balancing blade to which the service is bound, SSL support, the load balancing layer and, if applicable, the load balancing protocol. Other configurations can be added incrementally to a service.

Creating a Load Balancing Service

The service command creates an entry for a load balancing service on the blade. Once you have created the service, you can add more configurations to it as needed.

Note that before a created service can be functional, a minimum of two commands must be executed for the service. First, a default group of servers and a load balancing scheme must be specified by using the config service lb-group default command. Second, the service (which is created in a disabled state) must be enabled by the enable service command.

The available load balancing schemes are as follows:

• Round-robin (round-robin)
• Weighted round-robin (wt-round-robin)
• Static (static)
• Weighted least connections (wt-least-conn)
• Response time (response-time)

For rule-based load balancing, the service must be linked to one or more blade servers, a load balancing scheme, and optionally, a load balancing rule by the config service lb-group command.

As admin in config mode, use the following command:

puma(config){admin}# service name service-name vip {VIP-address | hostname}:port-num:{tcp|udp} [ssl decrypted-port] interface {0|1} [lb-layer {4|7}] [L7-proto {http|ftp}]

TABLE 4-12 describes the parameters for creating a load balancing service.Table describing the parameters for creating a load balancing service.

Defaults

The default load balancing is at Layer 4. The default Layer 7 protocol is HTTP. Each service must have a unique 3-tuple (vip, port-num, {tcp|udp}). If your service is an SSL service, it should also have a unique decrypted 3-tuple (vip,
decrypted-port, {tcp|udp}).

Examples

The first example creates a service named SVC0, with a VIP of 192.50.50.1, on port 80, using the TCP scheme. SVC0 is a Layer 4 load balanced TCP service.

puma(config){admin}# service name SVC0 vip 192.50.50.1:80:tcp interface 0

The second example, creates a service named svc2, which is a Layer 4 load balanced SSL service bound to interface 0 of the content load balancing blade. The SSL decrypted port is 880.

puma(config){admin}# service name svc2 vip 192.50.50.1:443:tcp ssl 880 interface 0

The last example creates a service named SVC1, which is a Layer 7 load balanced HTTP service.

puma(config){admin}# service name SVC1 vip 192.50.50.1:8080:tcp interface 1 lb-layer 7 L7-proto http

As admin in config mode, use the following command:

puma(config){admin} # vip-netmask {ip-addr | hostname} mask netmask

TABLE 4-13 describes the parameters for configuring the subnet mask for a VIP.Table describing the parameters for configuring the subnet mask for a VIP.

The service ssl command adds one or more SSL devices to the SSL load balancing group of a service.

As admin in config mode, use the following command:

puma(config){admin}# service ssl service-name ssl ssl-device-name:{active|standby} [ssl-device-name:{active|standby}....]

Examples

The following example adds an SSL device named ssl1 to the Service SVC1.

puma{config}{admin}# service ssl SVC1 ssl ssl1:active

To add a second SSL device to the same service, the command should be invoked again for the second SSL device.

puma{config}{admin}# service ssl SVC1 ssl ssl2:active

Both devices can be added in one command also.

puma{config}{admin}# service ssl SVC1 ssl ssl1:active ssl2:active

One device can be added as Active and another device can be added as Standby.

puma{config}{admin}# service ssl SVC1 ssl ssl1:active ssl2:standby

TABLE 4-14 describes the parameters for adding one or more SSL devices to the SSL load balancing group of a service. Table describing the parameters for adding SSL devices to a service.

Usage Guidelines

The service ssl command should be invoked at least once for any service that has one or more end points enabled for SSL.

If additional SSL devices are created after executing the service ssl command, execute this command again with the new SSL device name.

puma(config){admin}# service ssl service-name ssl ssl-device-name:{active|standby} [ssl-device-name:{active|standby}]

As admin in config mode, use the following command:

puma(config){admin}# remove service ssl service-name ssl ssl-device-name [ssl-device-name]

Example

The following example removes an SSL device ssl1 from the service SVC1.

puma{config}{admin}# remove service ssl SVC1 ssl ssl1

This command removes one or more SSL devices from the SSL load balancing group of a service.

TABLE 4-15 describes the parameters for removing one or more SSL devices from the SSL load balancing group of a service.

As admin in config mode, use the following command:

puma(config){admin}# modify service ssl mode service-name ssl ssl-device-name [ssl-device-name...] mode {active|standby}

This command sets one or more SSL devices in the SSL load balancing group of a service as either active or standby.

TABLE 4-14 describes the parameters for modifying one or more SSL devices in the SSL load balancing group of a service as either active or standby.

As admin in config mode, use the following command:

puma(config){admin}# service lb-group default service-name server {ip-addr | hostname}:port:protocol:weight:active [{ip-addr| hostname}:port:protocol:weight:active...] [scheme {round-robin|wt-round-robin|static|wt-least-conn|response-time}] 

The config service lb-group default command configures one or more servers to which a request for a service is directed if it does not match any of the rules in any of the load balancing groups configured for that service. The load balancing scheme is also configured. This is the default load balancing group for the service. All the load balancing group commands can be applied to this group with the load balancing group name specified as the default.

TABLE 4-17 describes the parameters for this command.Table describing the parameters for adding a default load balancing group to a load balancing service.

Defaults

The default load balancing scheme is round robin for a TCP service. When the load balancing scheme is weighted round robin and the weight is specified as 0 for a server, then the default weight is 1. For round robin and static load balancing schemes the weight field is ignored.

Usage Guidelines

Invoke this command at least once for any service after the service is created and before it starts accepting connections.

For a UDP service, the only load balancing scheme supported is static.

Examples

The first example uses the default scheme and only one server.

puma(config){admin}# service lb-group default SVC1 server 192.50.50.201:0:tcp:5:1

The following example sets three servers, uses the TCP protocol, and specifies the scheme as weighted round robin.

puma(config){admin}# service lb-group default SVC1 server 192.50.50.201:0:tcp:5:0 192.50.50.202:0:tcp:10:1 192.50.50.203:0:tcp:7:1 scheme wt-round-robin

As admin in config mode, use the following command:

puma(config){admin}# service tcp-params service-name [window tcp-window] [window-scale tcp-ws-factor] [ts] [sack] 

TABLE 4-18 describes the TCP parameters to set for a service.Table describing the TCP parameters to set for a service.

The service tcp-params command overwrites the default TCP settings on the load balancer and is valid only if the protocol for the service is TCP and the load balancing is done at Layer 7.

For most cases, use the TCP parameters set by the config default tcp-params command for each content load balancing blade since those are the parameters with which all the back end servers served by the content load balancing blade are configured. If this command is invoked for any service to change these defaults, the network administrator must modify the TCP parameters of the servers accordingly. But if any one of these servers is included in another service with different TCP parameters, then this command fails.

Defaults are the values configured for the content load balancing blade.

Usage Guidelines

For most cases, the TCP parameters set by the default tcp-params command on each content load balancing blade should be used. Those are the parameters with which all the back end servers served by the content load balancing blade are configured. If this command is invoked at all for any service to change these defaults, the network administrator should ensure that the servers added to this service have their TCP parameters modified accordingly. But if any one of these servers is included in another service with different TCP parameters, then this command fails.

Example

puma(config){admin}# service tcp-params SVC1 window 2048 window-scale 1 ts

The service tcp-handoff-params command modifies the default TCP connection handoff parameters for a service. This command is valid only if the protocol for the service is TCP.

As admin in config mode, use the following command:

puma(config){admin}# service tcp-handoff-params service-name max-open max-open-resends 

Where:

service-name is the name of the service

max-open uses the value specified in the max-open-resends argument.

max-open-resends is the maximum number of times the OPEN message is retransmitted to the same server before load balancing again.

Defaults

The default is the same as that set for the content load balancing blade.

Example

The following example sets the maximum number of times the OPEN message is retransmitted to the same server before load balancing again to four times for the service SVC1.

puma(config){admin}# service tcp-handoff-params SVC1 max-open 4

The service point command adds one or more IP address, port, and protocol combinations to a given service, making the service multihomed.

If the VIP is already bound to an interface in any service, be sure to specify that interface. Two service end points on a given service cannot have the same VIP. The protocol for every added end point should be the same as the service protocol.

As admin in config mode, use the following command:

puma(config){admin}# service point service-name point {ip-addr | hostname}:port-num:proto:ssl:decrypted-portber:interface [{ip-addr | hostname}:port-num:proto:ssl:ssl- port-number:interface...] 

TABLE 4-19 describes the service point parameters available for a service.Table describing the service point parameters available for a service.

Examples

The first example adds two service points to the service SVC1, both using TCP protocol, on port 80, with no SSL support.

puma(config){admin}# service point SVC1 point 192.50.51.1:80:tcp:0:0:0 192.50.51.2:80:tcp:0:0:0

The following example adds one service point to the service svc2 on interface 0, port 80, protocol TCP, with SSL support and the decrypted port specified as 880.

puma(config){admin}# service point svc2 point 192.50.51.3:80:tcp:1:880:0

The remove service point command removes one or more service points from a given service.

As admin in config mode, use the following command:

puma(config){admin}# remove service point service-name point {ip-addr | hostname}:port-num:proto [{ip-addr | hostname}:port-num:proto...] 

TABLE 4-20 describes the service point parameters to be removed from a serviceTable describing service point parameters to be removed from a service..

Example

This example removes a service point with VIP 192.50.51.1, port 80, and protocol TCP from the service SVC1.

puma(config){admin}# remove service point SVC1 point 192.50.51.1:80:tcp

The service ip-persist command configures a service for persistence based on the client IP address or subnet.

If configured for client IP persistence, all traffic to this service coming from the same client IP (or same subnet in case a mask is specified) is sent to the same back end server. The timer specifies the inactivity interval after which this persistence ceases to exist, that is, subsequent traffic from the same client IP (or subnet) to this service is load balanced to another blade server.

As admin in config mode, use the following command:

puma(config){admin}# service ip-persist service-name [mask mask-len] [timeout timeout-val]

TABLE 4-21 describes the parameters for configuring a service for persistence.Table describing the parameters for configuring a service for persistence

Defaults

The default behavior is IP persistence for a specific client IP (when a subnet is not specified, that is, mask-len = 0). The default timeout value is the same as that configured for service point tracking if such a configuration exists, otherwise the timeout is five minutes.

Examples

The first example sets service IP persistence for the service named SVC1.

puma(config){admin}# service ip-persist SVC1

The following example sets service IP persistence for the service SVC1 using mask 16 and a timeout of 20 minutes.

puma(config){admin}# service ip-persist SVC1 mask 16 timeout 20

When client IP persistence is removed from a service, then any new connections to the service are load balanced again.

As admin in config mode, use the following command:

puma(config){admin}# no service ip-persist service-name 

Example

puma(config){admin}# no service ip-persist SVC1

Configuring a Service for Service Point Tracking

The service tracking command configures a service for tracking one or more service points with or without the destination VIPs specified.

If configured for service point tracking, all traffic to this service coming from the same client IP and destined to any of the tracking service points specified in the configuration is sent to the same back end server. The timer specifies the inactivity interval after which this persistence ceases to exist, that is, subsequent traffic from the same client IP, destined to any of the tracking service points configured is load balanced to another back end server. Service point tracking is a special case of client IP-based persistence.

In case the VIP to track is not specified (that is, specified as 0), the service performs port tracking on the specified service points.

As admin in config mode, use the following command:

puma(config){admin}# service tracking service-name track {ip-addr | hostname}:port:proto [{ip-addr | hostname}:port:proto] timeout timeout-val

TABLE 4-22 describes the parameters for configuring a service for service point tracking.

Defaults

The default behavior is port tracking on the specified service points (when the VIP is specified as 0). The default timeout value is the same as that configured for client IP persistence if such a configuration exists, else five minutes.

Examples

The first example sets port tracking for the service named SVC1, at port 443, using the TCP protocol.

puma(config){admin}# service tracking SVC1 track 0:443:tcp

The following example sets end point tracking entries for the service named SVC1: One tracking end point is given by VIP 188.88.8.1, port 9090, protocol TCP. The other end point has VIP 177.77.7.1. port 80, using the TCP protocol.

puma(config){admin}# service tracking SVC1 track 188.88.8.1:9090:tcp 177.77.7.1:80:tcp timeout 20

As admin in config mode, use the following command:

puma(config){admin}# remove service tracking service-name track {ip-addr | hostname}:port:proto

This command removes a tracking service point from a service. See TABLE 4-22 for descriptions of the parameters.

Examples

The first example removes port tracking for the service named SVC1, at port 443, using the TCP protocol.

puma(config){admin}# remove service tracking SVC1 track 0:443:tcp

The following example removes two end point tracking end points from the service SVC1.

puma(config){admin}# remove service tracking SVC1 track 188.88.8.1:9090:tcp 177.77.7.1:80:tcp

The purpose of the service cookie-persist command is to handle cookies embedded in a packet and ensure persistence across connections for an application offered by a particular blade server in this service.

1. As admin in config mode, use the following command:

puma(config){admin}# service cookie-persist service-name cookie cookie-name offset offset-len delim delimiter-character

2. As admin in config mode, use the following command:

puma(config){admin}# build rules

3. As admin in config mode, use the following command:

puma(config){admin}# show build status

When the build is completed, the completion message is printed out. Then you can run traffic to this service.

TABLE 4-23 describes the parameters for configuring a service for cookie-based persistence.Table describing the parameters for configuring a service for cookie-based persistence.

Example

The following example sets the service for cookie-based persistence for the service named SVC1, for the cookie named Car, the offset length is set for 10 and the delimiter character is a colon.

puma(config){admin}# service cookie-persist SVC1 cookie Car offset 10 delim :

The remove service cookie-persist command removes cookie based persistence from a service for a specific cookie name.

As admin in config mode, use the following command.

puma(config){admin}# remove service cookie-persist service-name cookie-name

Where service-name is the name of the service entry and cookie-name is the name of the cookie.

Example

The following example removes the service for cookie-based persistence for the service named SVC1, for the cookie named Car:

puma(config){admin}# remove service cookie-persist SVC1 cookie Car

When a service is created, it is disabled by default. For the service to accept traffic, it must be enabled by invoking the enable service command. When a service is enabled, all the load balancing groups it contains get enabled too.

As admin in config mode, use the following command:

puma(config){admin}# enable service name service-name

Where service-name is the name of the service to be enabled.

Example

The following example enables the service named SVC1.

puma(config){admin}# enable service name SVC1

The no enable service command disables a specified load balancing service. When a service is disabled, all the load balancing groups it contains are disabled. By default all services are disabled upon creation.

As admin in config mode, use the following command:

puma(config){admin}# no enable service name service-name

Where service-name is the name of the service to be disabled.

The remove service name command removes one or more load balancing services.

As admin, use the following command:

puma(config){admin}# remove service name service-name

Where service-name is the name of the service to be removed.

Examples

The first example removes one service named SVC1.

puma(config){admin}# remove service name SVC1

The following example removes two services: SVC1 and svc2.

puma(config){admin}# remove service name SVC1 svc2

---

Server Configuration

The enable server command enables a specific back end server on all services or on a specified service. By default the server is enabled on all services.

As admin in config mode, use the following command:

puma(config){admin}# enable server {ip-addr | hostname} [service service-name]

TABLE 4-24 describes the parameters for enabling a server.Table describing the parameters for enabling or disabling a server.

Examples

The first example enables the server at the IP address of 192.50.50.201 in all services.

puma(config){admin}# enable server 192.50.50.201

The following example enables the server at the IP address of 192.50.50.201 in the service SVC1.

puma(config){admin}# enable server 192.50.50.201 service SVC1

The no enable server command disables a specific back end server on all services or on a specified service. By default, the server is enabled on all services.

If the server is the only one in any load balancing group, then this command fails.

As admin, use the following command:

{puma(config){admin}# no enable server {ip-addr | hostname} [service service-name]

Examples

The first example disables the server at the IP address of 192.50.50.201 in all services.

puma(config){admin}# no enable server 192.50.50.201

The following example disables the server at the IP address of 192.50.50.201 in the service SVC1.

puma(config){admin}# no enable server 192.50.50.201 service SVC1

As admin in config mode, use the following command:

{puma(config){admin}# remove server {hostname|ip-addr}

Where hostname|ip-addr is the hostname or IP address of the server to be removed.

---

Load Balancing Rule Configuration

Creating an IP Load Balancing Rule

The config ip-rule command creates a load balancing rule for IP traffic. By default, the rule has low priority.

An IP rule with a high priority gets a higher priority for a given service than IP rules specified with low priority or no priority. When an IP rule is used in conjunction with Layer 7 rules such as HTTP rules in a service, then a high priority puts it at a priority higher than static URLs and a low priority puts it at a priority lower than dynamic URLs. Within multiple IP rules of the same priority class (that is, high or low), the relative priority is determined by the number of bits specified in the IP address and port masks, that is, fewer number of bits masked out results in a higher priority.

As admin in config mode, use the following command:

puma(config){admin}# ip-rule name rule ip-addr:port mask ip-addr-mask:port-mask priority [{high | low}]

TABLE 4-25 describes the parameters for creating an IP load balancing rule.Table describing the parameters for creating an IP load balancing rule.

Examples

The first example adds an IP rule named IPRule1 and sets the priority at high.

puma(config){admin}# ip-rule IPRule1 rule 172.88.8.1:21 mask 255.255.255.0:1 priority high

The following example adds ip-rule IPRule2 and uses the default priority.

puma(config){admin}# ip-rule IPRule2 rule 172.88.8.1:3241 mask 255.255.0.0:0

Creating an HTTP Load Balancing Rule

The config http-rule command creates a load balancing rule for HTTP traffic.

Depending on the rule type, the HTTP rules are assigned different priority classes within a service. Listed in order of decreasing priority, these classes are, static URL, cookie, CGI, and dynamic URLs. Within a particular priority class, individual rules are further prioritized based on the actual rule string, for example, a fully specified rule has a higher priority than a rule with wildcards.

As admin in config mode, use the following command:

puma(config){admin}# http-rule name {static | dynamic | cgi | cookie} string rule-string

TABLE 4-26 describes the parameters for creating an HTTP load balancing rule.Table describing the parameters for creating an HTTP load balancing rule.

Examples

The first example adds an HTTP rule named HttpR1 of the static URL type with a *.gif rule-string.

puma(config){admin}# http-rule HttpR1 static string *.gif

The following example adds the HTTP rule HttpCgiR1, which is CGI-based with server=server1 as the rule-string.

puma(config){admin}# http-rule HttpCgiR1 cgi string server=server1

The final example adds the HTTP rule HttpCookieR1, which is cookie-based with a server=server2 as the rule-string.

puma(config){admin}# http-rule HttpCookieR1 cookie string server=server2

The remove rule command removes one or more a load balancing rules of any type, including IP, HTTP, and others.

If the rule is part of one or more load balancing groups, it cannot be removed.

As admin in config mode, use the following command:

puma(config){admin}# remove rule rule-name [rule-name.....] 

Where rule-name is the name of the load balancing rule to be removed.

Examples

The following example removes the rules HttpR1 and HttpCgiR1 from the system:

puma(config){admin}# remove rule HttpR1 HttpCgiR1

The build rules command creates a new build for the load balancing rules on the content load balancing blade. This command must be invoked before any modifications made to rules associated with load balancing groups can take effect.

As admin in config mode, use the following command:

puma(config){admin}# build rules 

The show build status command displays the status of the current build for the load balancing rules on the content load balancing blade.

As any user, use the following command:

puma{user}# show build status 

The show last build status command displays the status of the last build for the load balancing rules on content load balancing blade.

As any user, use the following command:

puma{user}# show last build status 

If a build is in progress, the no build rules command stops the current build for the load balancing rules on the content load balancing blade.

As admin in config mode, use the following command:

puma(config){admin}# no build rules 

---

Load Balancing Group Configuration and Management

Before a load balancing service can be functional, it must be associated with one or more blade servers, a load balancing scheme, and a load balancing rule. This association is called a load balancing group which is a complete functional unit required for load balancing with the Sun Fire B10n blade.

The available load balancing schemes are as follows:

• Round-robin (round-robin)
• Weighted round-robin (wt-round-robin)
• Static (static)
• Weighted least connections (wt-least-conn)
• Response time (response-time)

As admin in config mode, use the following command:

puma(config){admin}# service lb-group default service-name server {hostname|ip-addr}:port:protocol:weight:active [{ hostname|ip-addr}:port:protocol:weight:active...] [scheme {round-robin|wt-round-robin|wt-least-conn|response-time|static}] 

As admin in config mode, use the following command:

puma(config){admin}# service lb-group name lb-group-name service service-name server { hostname|ip-addr}:port:protocol:weight:active [{ip-addr|hostname}:port:protocol:weight:active...] rule rule-name [scheme {round-robin | wt-round-robin|wt-least-conn|response-time|static}]

This command must be followed by the build rules command at the completion of which the new rule added becomes effective.

Whenever a service is created, a default load balancing group is associated with it. So, default is not an acceptable value for the group name as it is reserved for the default load balancing group.

An IP rule can be added to a Layer 4 service as well as a Layer 7 service, but HTTP rules can be added only to Layer 7 services.

If the service protocol is configured as UDP, then the only load balancing scheme allowed is static and only IP (Layer 4) rules can be associated with the service.

If the load balancing scheme is static or round-robin, then the weight field is ignored.

If you are configuring a service for UDP, the only load balancing scheme allowed is static.

Whenever a service is created, a default load balancing group is associated with it. See TABLE 4-27.

For example, the following command would fail if you tried to enter it on one line:

puma(config){admin}# config service lb-group default lb4rr-8 server 192.168.101.2:6300:tcp:5:1   192.168.101.35:6300:tcp:5:1 192.168.101.4:6300:tcp:5:1 192.168.101.5:6300:tcp:5:1 1 92.168.101.33:6300:tcp:5:1 192.168.101.34:6300:tcp:5:1 scheme wt-round-robin

Examples

While the example shows the scheme being defined as weighted round robin, you might prefer some other scheme. Note that weighted round robin can be weighed either by server load or response time.

puma(config){admin}# service lb-group name GRP1 service SVC1 server 192.50.50.203:80:tcp:10:1 192.50.50.204:80:tcp:20:1 192.50.50.205:80:tcp:15:0 rule HttpR1 scheme wt-round-robin

TABLE 4-27 describes the parameters for creating load balancing groups.Table describing the parameters for creating load balancing groups.

As admin in config mode, use the following command:

puma(config){admin}# service lb-group rule service-name:lb-group-name rule rule-name [rule-name.....]

The service lb-group rule command adds one or more rules to a load balancing group. When a request matches this service, it is matched against all the rules linked with the service and if any rule matches the request, then it is load balanced to the servers configured for this load balancing group.

This command should be followed by the build rules at the completion of which the new rule(s) added becomes effective.

A rule (with a given content) can be added to a service only once, that is, it can appear only once in at most one load balancing group for a given service. Addition of duplicate rules to a service fails.

An IP rule can be added to a Layer 4 service as well as a Layer 7 service, but HTTP rules can be added only to Layer 7 services.

TABLE 4-28 describes the parameters for adding rules to a load balancing group.Table describing the parameters for adding rules to a load balancing group.

Examples

The first example adds an HTTP cookie rule to SVC1 and GRP1.

puma(config){admin}# service lb-group rule SVC1:GRP1 rule HttpCookieR1

The following example adds a CGI rule to SVC1.

puma(config){admin}# service lb-group rule SVC1:GRP1 rule HttpCgiR1

As admin in config mode, use the following command:

puma(config){admin}# remove service lb-group rule service-name rule rule-name [rule-name.....]

The remove service lb-group rule command removes one or more rules from a load balancing group.

This command should be followed by a build rules command after the completion of which the rule removal becomes effective.

If the rule being removed from the load balancing group is the last rule present and the service is configured for Layer 7 load balancing, then this command fails.

Example

puma(config){admin}# remove service lb-group rule SVC1 rule HttpCgiR1

As admin in config mode, use the following command:

puma(config){admin}# service lb-group server service-name:lb-group-name server {ip-addr |hostname}:port:protocol:weight:active [{ip-addr | hostname}:port:protocol:weight:active...]

The service lb-group server command adds one or more servers to a load balancing group.

If the load balancing scheme is weighted round robin and the weight is specified as 0 for a server, then the default weight is 1.

TABLE 4-29 describes the parameters for adding servers to a load balancing group.

Example

puma(config){admin}# service lb-group server SVC1:default server 192.50.50.210:80:10:1

As admin in config mode, use the following command:

puma(config){admin}# remove service lb-group server service-name:lb-group-name server {ip-addr | hostname}:port:protocol [{ip-addr | hostname}:port:protocol...]

The remove service lb-group server command removes one or more servers from a load balancing group.

If the server being removed from the load balancing group is the last one present, then this command fails.

TABLE 4-30 describes the parameters for removing servers from a load balancing group.

Examples

The following example removes the service SVC1 from lb-group server with the IP address of 192.50.50.210 on port 80.

puma(config){admin}# remove service lb-group server SVC1:default server 192.50.50.210:80

As admin in config mode, use the following command:

puma(config){admin}# modify service lb-group server service-name:lb-group-name server {hostname|ip-addr}:port:protocol [{hostname|ip-addr}:port:protocol...] mode {active|standby}

This command sets one or more servers for a load balancing group as active or standby.

TABLE 4-31 describes the parameters for this command.Table describing the parameters for setting servers for a load balancing group to active or standby.

Example

The following example, modifies service SVC1 on the server with the IP address of 192.50.50.210 at port 80 and places it in standby mode.

puma(config){admin}# modify service lb-group server SVC1:default server 192.50.50.210:80:tcp mode standby

As admin in config mode, use the following command:

puma(config){admin}# modify service lb-group scheme service-name:lb-group-name scheme {round-robin|wt-round-robin|wt-least-conn|response-time|static}

TABLE 4-32Table describing the parameters for adding SSL devices to a service. describes the parameters for this command.

As admin in config mode, use the following command:

puma(config){admin}# modify service lb-group weight service-name:lb-group-name server {hostname|ip-addr}:port:proto:wgt  [{hostname|ip-addr}:port:proto:wgt...]]

TABLE 4-32Table describing the parameters for adding SSL devices to a service. describes the parameters for this command.

As admin in config mode, use the following command:

puma(config){admin}# remove service lb-group name service-name:lb-group-name [service-name:lb-group-name]

The remove service lb-group command removes one or more load balancing groups from a service.

The default load balancing group cannot be removed by this command.

This command should always be followed by a build rules command before the removal of the rules contained in this load balancing group is effective.

Examples

The following example removes the load balancing group GRP1 from the service SVC1.

puma(config){admin}# remove service lb-group name SVC1:GRP1

---

Load Balancing Configuration Listings

The Sun Fire B10n blade enables you to list load balancing configurations by service, rule, group, or servers.

The show service command lists the configurations of a particular service if specified. Otherwise this command lists the configurations of all the load balancing services that have been created. By default, all services are listed.

As any user, use the following command:

B10n {user}# show service service-name

Where service-name is the name of the service to be retrieved.

Returns

Table of services listed by name with the values of the following basic parameters listed against each service, or the configurations of a single service if specified:

• Primary service point IP address and port
• Service protocol (TCP/UDP)
• Layer at which the service is load balanced (Layer 4 or Layer 7)
• Status of the service (enabled/disabled)
• List of default servers and default load balancing scheme
• List of service association names linked to the service
• VLAN tag for data traffic if configured
• Persistence (IP persistence and service point tracking) configurations, if any
• SSL configurations if any
• list of service points (VIP and port) with the SSL support (whether SSL enabled or not) and the binding interface listed for each service point
• DoS avoidance status (enabled/disabled)

The show rule command lists a particular load balancing rule if specified. Otherwise the command lists all the load balancing rules that have been created so far. By default, all rules are listed.

As any user, use the following command:

puma{user}# show rule [rule-name]

Where rule-name is the name of the rule to be retrieved.

Returns

A list of load balancing rule names with their respective type and content specified (or the type and content of a single rule if specified). If a particular rule name is specified, then all the services and the corresponding load balancing group in which the rule is included in each service is also listed.

Examples

To show all load balancing rule names and their respective type and content, use the following example:

puma{user}# show rule

To see specific rule type and content, specify the rule name:

puma{user}# show rule HttpCookieR1

As any user, use the following command:

puma{user}# show service-lb-group service-name [lb-group-name]

Where:

service-name is the name of the load balancing service to which this load balancing group belongs.

lb-group is the name of the load balancing group entry to be retrieved.

The show service-lb-group command lists the information about a particular load balancing group if specified. Otherwise this command lists the information about all the load balancing groups for a given service.

Returns

Table containing all the relevant load balancing groups. Each group has a row containing the following information:

• Load balancing group name
• Name of the service to which it belongs
• Names and actual rule strings of all the rules linked with it
• Load balancing scheme used
• All the servers and services associated with it (with the weight specified against each server if the load balancing scheme is weighted round robin)

If a load balancing group is specified, then all this information is listed for that particular group.

Examples

puma{user}# show service-lb-group SVC1

puma{user}# show service-lb-group SVC1 default

The show server command lists a particular server if specified. Otherwise, all the servers in the system that are included in one or more load balancing service associations for all the services configured on the content load balancing blade are listed

As any user, use the following command:

puma{user}# show server [hostname|ip-addr]

Where hostname is the name and ip-addr is the IP address of the server to be retrieved.

Returns

A list of server names with the following specified for each server:

• server IP address
• enabled/disabled
• up/down

If a particular server name is specified, then all the services and the corresponding load balancing groups in which the server is included in each service are also listed.

---

Configuring the System

The Sun Fire B10n blade can be loaded with three different images and booted. The three images are image 1, image 2, and diag.

The image can be upgraded interactively or non interactively.

1. As admin in config mode, use the following command:

puma(config){admin}# boot image {1|2|diag}

Options for the boot image are 1, 2, or diag.

Example

This example sets the diagnostics image to be used for the next reboot.

1. Set the diagnostics image to be used for the next reboot:

puma(config){admin}# boot image diag 

2. To make this the permanent setting, use the commit command:

puma(config){admin}# commit 

3. Reboot the system:

puma(config){admin}# reboot 

1. As admin, use the following command:

puma{admin}# update image {hostname|ip-addr} file filename image {1|2|diag}

This command downloads a new boot image over the network and writes it into flash PROM. The new image takes effect after a system reboot. This command is available in interactive and noninteractive modes.

Example

The following example updates image 2 using the file pkgname command from the remote server at IP address 192.50.50.201:

1. As admin, use the following command:

puma{admin}# update image 192.50.50.201 file pkgname image 2

2. Reboot the system:

puma{admin}# reboot

The diag level command configures the diagnostics level and also the level of verbosity of the diagnostics.

As admin in config mode, use the following command:

puma(config){admin}# diag level {0|1|2} verbose {0|1|2}

TABLE 4-34 describes the parameters for configuring the diagnostic and verbosity level.

By default, the diagnostics level is 0 and the verbosity level is 0.

These values are used whenever the system boots with the diag image.

Examples

The following example configures the diagnostic level as 1 and the verbosity as 2:

puma(config){admin}# diag level 1 verbose 2

The debug module command configures the debug level for a specified module in the system.

As admin in config mode, use the following command:

puma(config){admin}# debug module module-name level {0-5}

TABLE 4-35 describes the parameters for configuring the debug level for specified modules:Table describing the parameters for configuring the debug level for specific modules.

TABLE 4-36 describes the module names to use for configuring the debug level:Table describing the module names to use for configuring the debug level.

Example

The following example configures the load balancing module at level 2.

puma(config){admin}# debug module lb level 2

The shutdown command does a graceful shutdown of the system. This command is available in both interactive and non-interactive mode. By default, this command is in the interactive mode and asks for confirmation before shutting down the system.

As admin in config mode, use the following command:

puma(config){admin}# shutdown [force]

Where force forces the shutdown without asking for confirmation.

Examples

The first example shuts down the system using the interactive mode.:

puma(config){admin}# shutdown

The following example shuts down the system using the non-interactive mode:

puma(config){admin}# shutdown force

The reboot command resets the system. It is available in both interactive and non-interactive mode. By default, this command is in the interactive mode and asks the user for confirmation before rebooting the system.

As admin, use the following command:

puma(config){admin}# reboot [force]

Where force forces the reboot without asking for confirmation. This command checks if there is a difference between the running configuration and the saved configuration. This command gives a warning for unsaved configurations before rebooting.

Examples

The first example reboots the system using the interactive mode.:

puma(config){admin}# reboot

The following example reboots the system using the non-interactive mode:

puma(config){admin}# reboot force

Shows the current system date and time.

As any user, use the following comma nd:

puma{user}# show date

The show system command shows the current system settings. It gives information about the current image, its version, the current configuration file in flash being used, and so on.

As any user, use the following command:

puma{user}# show system

The show uptime command shows the uptime for the system.

As any user, use the following comma nd:

puma{user}# show uptime

The show configuration command lists all of the blade configurations as the collective output from commands: show network, show service, show server, show rule and show vip.

As any user, use the following command:

puma{user}# show configuration

The show compare-config command compares the configuration in running memory with its correspondent configuration saved in the Flash File System. This helps you determine if the configuration has been changed and if the need to save the configuration is required.

As any user, use the following command:

puma{user}# show compare-config

The show running-config command displays the configuration that is in the running memory.

As any user, use the following command:

puma{user}# show running-config

The show saved-config command shows the configuration saved in the Flash File System with the option of 1 or 2. 1 indicates config-1 and 2 indicates config-2.

As any user, use the following command:

puma{user}# show saved-config

The dump memory command dumps the system memory to the screen. By default 32 bytes are dumped starting from the specified memory location.

As any user, use the following comma nd:

puma{user}# dump memory addr [size]

TABLE 4-37 describes the parameters for the dump memory command:Table describing the parameters for the dump memory command.

Examples

The first example dumps memory from address 56789abc using the default size.

puma{user1}# dump memory 56789abc

The following example dumps memory from address 56789abc, but specifies the size of 8 bytes:.

puma{user1}# dump memory 56789abc 8

The dump module command dumps the information regarding a specific module to the screen.

As any user, use the following comma nd:

puma{user}# dump module module-name [index]

TABLE 4-38 describes the parameters for the dump module command:Table describing the parameters for the dump module command.

TABLE 4-39 describes the valid module names to use with dump module command:Table describing the valid module names to use with the dump module command.

The following table lists the modules in the NPU by index:Table listing the modules in the NPU by index.

Examples

The following example displays the Order Manager (OM) module in the NPU.

puma{user1}# dump module npu 4

The following table lists the tasks available for display by index in the dump module task command.