C H A P T E R 4 |
Command-Line Options |
This chapter describes the management and control interfaces available through the Sun Fire B10n content load balancing 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:
Command descriptions use these conventions:
Note - Keywords are not case-sensitive, but user-specified values are. |
The Sun Fire B10n content load balancing blade has two levels of user access:
TABLE 4-1 describes the user commands.
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.
Note - For security reasons, always logout before you leave the console. |
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}# |
Note - The default admin password is admin. To ensure security, change the default password before configuring the content load balancing blade. |
puma{admin}# user password admin Enter new password: Confirm new password: |
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..
Note - If you do not specify the access level when you add a user, the default access (Level 1) will be used. |
TABLE 4-2 lists the parameters for user access command:
As admin, you can add new users, assign access level, and a default password:
puma{admin}# user add name user_name [access {1|2}] puma{admin}# user access name user_name access {1|2} puma{admin}# user password login-name |
As admin, you can change a user's access level:
puma{admin}# user access name user_name 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 user_name Enter new password:****** Confirm new password:****** puma{admin}# |
As admin, you can remove a user:
puma{admin}# user delete user_name |
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.
This section describes how to configure the network for the Sun Fire B10n content load balancing blade
1. As admin, enter config mode:
puma{admin} # config |
puma(config){admin}# ip interface {0|1} ip_addr mask net_mask |
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.
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, enter the ping command along with the specific IP address or hostname you want to ping and the packet count:
B10n {user} # ping {ip_address | host_name} [packet_count] |
The ping command determines whether the Sun Fire B10n content load balancing 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 host |
If the host is available on the network then ping displays this message:
host is alive |
TABLE 4-4 describes the parameters for sending a ping request.
As admin in config mode, unconfigure the network interface:
puma(config){admin}# no ip interface {0|1} |
This command unconfigures a network interface on the Sun Fire B10n content load balancing blade.
You can configure both a primary and a secondary Domain Name Server (DNS) for the Sun Fire B10n content load balancing blade. When supplied with a hostname, the DNS server resolves it and obtains the corresponding IP address.
As admin in config mode, configure a DNS server:
puma(config){admin}# dns server ip_addr {primary|secondary} |
As admin in config mode, remove a DNS server:
puma(config){admin}# remove dns server ip_addr |
As admin in config mode, configure the DNS suffix:
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, enter the show network command:
puma{user}# show network |
As admin in config mode, remove the DNS suffix:
puma(config){admin}# no dns suffix |
As admin in config mode, set the default gateway:
puma(config){admin}# default gateway ip_addr |
Where ip_addr is the gateway IP address.
As admin in config mode, unset the default gateway:
puma(config){admin}# no default gateway |
As admin in config mode, set the default hostname:
puma(config){admin}# default hostname host_name |
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 takes the hostname:
B10n-no-1(config){admin}# |
As any user, enter the show network command:
puma{user} # show network |
This command returns the following information:
1. As admin, enter the show arp 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:
As admin in config mode, configure the subnet mask for a VIP:
puma(config){admin} # vip-netmask {ip_addr | host_name} mask net_mask |
TABLE 4-5 describes the parameters for configuring the subnet mask for a VIP.
As any user, enter the show vip command:
puma{user}# show vip |
This command lists all the VIPs configured on the Sun Fire B10n content load balancing blade.
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 content load balancing blade using SNMP. You can check network connectivity by issuing a ping to each blade server from the monitoring module in the content load balancing blade.
As admin in config mode, set the server for monitoring:
puma(config){admin} # server-monitor [interval monitoring_interval] [max-try max_try_count] |
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-6 describes the parameters for setting up a server for monitoring.
The Sun Fire B10n content load balancing 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, enter the ssl name command and the parameters:
puma(config){admin}# ssl name ssl_blade_name {ssl_ip_1 | host_name_1} [{ssl_ip_2 | host_name_2}] |
TABLE 4-7 describes the parameters for adding SSL blade configurations.
(Optional) IP address of the SSL blade on the other interface. |
|
(Optional) Host name of the SSL blade on the same interface. |
The remove ssl name command removes an SSL blade entry.
As admin in config mode, enter the remove ssl name command and the parameters:
puma(config){admin}# remove ssl name ssl_blade_name |
As admin in config mode, enter the following command:
puma(config){admin}# ssl port-pair ssl_blade_name secureport secure_port_num clearport clear_port_num |
The ssl port-pair command configures an SSL blade entry with a secure port and the corresponding clear port, that is, a port pair configuration.
Note - A maximum of four such port pairs can be added to an SSL blade entry. Each of the eight ports must be unique. Maximum value of each port is 1024. |
TABLE 4-8 describes the parameters for adding and removing port pairs.
As admin in config mode, enter the following command:
puma(config){admin}# remove ssl port-pair ssl_blade_name secureport secure_port_num clearport clear_port_num |
The remove ssl port-pair command removes a port pair configuration from an SSL blade entry.
Note - If the SSL blade has either of its interfaces included in any service, then this command fails. |
As admin in config mode, enter the following command:
puma(config){admin}# ssl if ssl_blade_name {ssl_ip|host_name} |
The ssl if command configures an interface for an SSL blade entry.
Note - A maximum of two interfaces can be configured for an SSL blade entry at any time. |
TABLE 4-9 describes the variables for adding or removing an interface.
As admin in config mode, enter the following command:
puma(config){admin}# remove ssl if ssl_blade_name {ssl_ip|host_name} |
The remove ssl if command removes an interface from an SSL blade entry.
Note - An SSL blade entry must have at least one interface configured. It is not possible to remove an interface that is included in one or more services. |
The enable ssl name command enables an SSL blade entry.
As admin in config mode, enter the enable ssl name command:
puma(config){admin}# enable ssl name ssl_blade_name |
By default, an SSL entry is enabled when it is created.
The no enable ssl name command disables an SSL blade entry.
As admin in config mode, enter the no enable ssl name command:
puma(config){admin}# no enable ssl name ssl_blade_name |
As any user, enter the show ssl command:
B10n {user} # show ssl [ssl_blade_name] |
You can use this command to display the SSL blades configured for the content load balancing blade. By specifying the ssl_blade_name, you can show one specific 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.
Note - For each of these parameters, the content load balancing blade starts up with a set of defaults that match those on the servers at the time of deployment. |
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, set the default TCP parameters.:
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-10 describes the options for setting the TCP parameters for the content load balancing blade.
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.
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 content load balancing 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.
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, set the default TCP handoff parameters:
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.
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, enter the show default tcp 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.
A load balancing service on Sun Fire B10n content load balancing 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.
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.
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, create the load balancing service, using the parameters needed:
puma(config){admin}# service name service_name vip {vip_addr | host_name}:port_num:{tcp|udp} [ssl ssl_port_num] interface {0|1} [lb-layer {4|7}] [L7-proto {http|ftp}] |
TABLE 4-11 describes the parameters for creating a load balancing service.
The default load balancing is at Layer 4. The default Layer 7 protocol is HTTP.
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 |
The service ssl command adds one or more SSL devices to the SSL load balancing group of a service.
As admin in config mode, type the following command, using the parameters needed:
puma(config){admin}# service ssl service_name ssl ssl_blade_name:{active|standby} [ssl_blade_name:{active|standby}....] |
TABLE 4-12 describes the parameters for adding one or more SSL devices to the SSL load balancing group of a service.
The service ssl command should be invoked at least once for any service that has one or more end points enabled for SSL.
As admin in config mode, type the following command, using the parameters needed:
puma(config){admin}# remove service ssl service_name ssl ssl_blade_name [ssl_blade_name] |
This command removes one or more SSL devices from the SSL load balancing group of a service.
TABLE 4-13 describes the parameters for removing one or more SSL devices from the SSL load balancing group of a service.
As admin in config mode, type the following command, using the parameters needed:
puma(config){admin}# modify service ssl mode service_name ssl ssl_blade_name [ssl_blade_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-12 describes the parameters for modifying one or more SSL devices in the SSL load balancing group of a service as either active or standby.
To Add a Default Load Balancing Group to a Load Balancing Service |
As admin in config mode, type the service lb-group default command, using the parameters needed:
The 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-15 describes the parameters for adding a default load balancing group to a load balancing service.
Note - Port NAT is not supported at this time. So the port and protocol field values are ignored. |
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.
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.
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, enter the service tcp-params command, using the TCP parameters for a service:
puma(config){admin}# service tcp-params service_name [window tcp_window] [window-scale tcp_ws_factor] [ts] [sack] |
TABLE 4-16 describes 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.
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.
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, enter the service tcp-handoff-params command:
puma(config){admin}# service tcp-handoff-params service_name max-open max_open_resends |
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.
The default is the same as that set for the content load balancing blade.
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, enter the service point command:
puma(config){admin}# service point service_name point {ip_addr | host_name}:port_num:proto:ssl:ssl_port_number:interface [{ip_addr | host_name}:port_num:proto:ssl:ssl_ port_number:interface...] |
TABLE 4-17 describes the service point parameters available for a service.
Note - A maximum of three end points are allowed for each service. This includes the end point with which the service was created. |
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, enter the remove service point command:
puma(config){admin}# remove service point service_name point {ip_addr | host_name}:port_num:proto [{ip_addr | host_name}:port_num:proto...] |
TABLE 4-18 describes the service point parameters to be removed from a service
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 |
To Configure a Service for Client IP or Subnet-Based Persistence |
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, enter the service ip-persist command:
puma(config){admin}# service ip-persist service_name [mask mask_len] [timeout timeout_val] |
TABLE 4-19 describes the parameters for configuring a service for persistence.
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.
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 named SVC1 using mask 16 and a timeout of 10 minutes.
puma(config){admin}# service ip-persist SVC1 mask 16 timeout 10 |
To Remove Client IP or Subnet Based Persistence from a Service |
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, enter the no service ip-persist command:
puma(config){admin}# no service ip-persist service_name |
puma(config){admin}# no service ip-persist SVC1 |
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.
Note - End point tracking is added only to the primary VIP, that is, the VIP end point with which the service was created. Port tracking is added to all the VIP end points of a multihomed service. |
Note - The maximum number of service points that can be added for tracking is five. |
As admin in config mode, enter the service tracking command:
puma(config){admin}# service tracking service_name track {vip_addr | host_name}:port:proto [{vip_addr | host_name}:port:proto] timeout timeout_val |
TABLE 4-20 describes the parameters for configuring a service for service point tracking.
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.
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, enter the remove service tracking command:
puma(config){admin}# remove service tracking service_name track {vip_addr | host_name}:port:proto |
This command removes a tracking service point from a service. See TABLE 4-20 for descriptions of the parameters.
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, enter the following command:
puma(config){admin}# service cookie-persist service_name cookie cookie_name offset offset_len delim delimiter_character |
2. Enter the build rules command:
puma(config){admin}# build rules |
Note - Don't run traffic to this service yet, wait for the build to return with completion status. |
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-21 describes the parameters for configuring a service for cookie-based persistence.
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, enter 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.
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, enter the following command.
puma(config){admin}# enable service name service_name |
Where service_name is the name of the service to be enabled.
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, enter the no enable service 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, enter the remove service name command.
puma(config){admin}# remove service name service_name |
Where service_name is the name of the service to be removed.
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 |
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, enter the enable server command:
puma(config){admin}# enable server {ip_addr | host_name} [service service_name] |
TABLE 4-22 describes the parameters for enabling a server.
Name of the load balancing service on which the back end server is enabled or disabled. |
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.
Note - If the server is the only active server on any load balancing group, then any subsequent traffic to that server is still sent to the server instead of being dropped. |
If the server is the only one in any load balancing group, then this command fails.
As admin, enter the no enable server command:
{puma(config){admin}# no enable server {ip_addr | host_name} [service service_name] |
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 |
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.
Note - The configured rule name must be unique across all types of rules (IP rules, HTTP rules, and so on). |
As admin in config mode, enter the ip-rule command:
puma(config){admin}# ip-rule name rule ip_addr:port mask ip_addr_mask:port_mask priority [{high | low}] |
TABLE 4-23 describes the parameters for creating an IP load balancing rule.
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 |
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.
Note - The configured rule name must be unique across all types of rules (IP rules, HTTP rules and such). |
As admin in config mode, enter the http-rule command:
puma(config){admin}# http-rule name {static | dynamic | cgi | cookie} string rule_string |
TABLE 4-24 describes the parameters for creating an HTTP load balancing rule.
Actual rule string. For example, *.gif can be the rule for a static URL type. The length of the string is restricted to 256 bytes. |
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, enter the remove rule command:
puma(config){admin}# remove rule rule_name [rule_name.....] |
Where rule_name is the name of the load balancing rule to be removed.
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.
Note - You cannot add, modify, or delete configurations related to the service, lb-group, or rules while the rule building is in progress. |
As admin in config mode, enter the build rules 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, enter the show build status command:
puma{user}# show build status |
To Get the Status for the Last Build for Load Balancing Rules |
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, enter the show last build status 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, enter the no build rules command:
puma(config){admin}# no build rules |
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 content load balancing blade.
As admin in config mode, create a default load balancing group:
As admin in config mode, create a load balancing group:
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-25.
For example, the following command would fail if you tried to enter it on one line:
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-25 describes the parameters for creating load balancing groups.
Note - Port NAT is not supported at this time. So the port and protocol field values are ignored. |
As admin in config mode, add a rule to a load balancing group:
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.
Note - This command cannot be used to add rules to the default group. |
TABLE 4-26 describes the parameters for adding rules to a load balancing group.
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, remove a rule from a load balancing group:
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.
puma(config){admin}# remove service lb-group rule SVC1 rule HttpCgiR1 |
As admin in config mode, add a server to a load balancing group:
puma(config){admin}# service lb-group server service_name:lb_group_name server {ip_addr | host_name}:port:protocol:weight:active [{ip_addr | host_name}: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-27 describes the parameters for adding servers to a load balancing group.
Note - Port NAT is not supported at this time. So the port and protocol field values are ignored. |
puma(config){admin}# service lb-group server SVC1:default server 192.50.50.210:80:10:1 |
As admin in config mode, remove a server from a load balancing group:
puma(config){admin}# remove service lb-group server service_name:lb_group_name server {ip_addr | host_name}:port:protocol [{ip_addr | host_name}: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-28 describes the parameters for removing servers from a load balancing group.
Name of the load balancing service to which this LB group belongs. |
|
Port on the back end server where this service can be provided. |
|
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 |
To Set Servers for a Load Balancing Group as Active or Standby |
As admin in config mode, set a server for a load balancing group as active or standby:
puma(config){admin}# modify service lb-group server service_name:lb_group_name server {ip_addr | host_name}:port:protocol [{ip_addr | host_name}:port:protocol...] mode {active|standby} |
This command sets one or more servers for a load balancing group as active or standby.
Note - A load balancing group must have at least one active server. |
TABLE 4-29 describes the parameters for setting servers for a load balancing group to active or standby.
Note - Port NAT is not supported at this time. So the port and protocol field values are ignored. |
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 mode standby |
As admin in config mode, remove one or more load balancing service groups:
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.
The following example removes the load balancing group GRP1 from the service SVC1.
puma(config){admin}# remove service lb-group name SVC1:GRP1 |
The Sun Fire B10n content load balancing 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, enter the show service command.
B10n {user}# show service service_name |
Where service_name is the name of the service to be retrieved.
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:
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, enter the following command:
puma{user}# show rule [rule_name] |
Where rule_name is the name of the rule to be retrieved.
The command provides output showing 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).
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).
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, enter the following command:
puma{user}# show service-lb-group service_name [lb_group_name] |
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.
Table containing all the relevant load balancing groups. Each group has a row containing the following information:
If a load balancing group is specified, then all this information is listed for that particular group.
puma{user}# show service-lb-group SVC1 |
puma{user}# show service-lb-group SVC1 default |
The show server command lists 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.
As any user, enter the following command:
B10n {user}# show server |
The following information is listed for each server entry:
The Sun Fire B10n content load balancing 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, set the boot image:
puma(config){admin}# boot image {1|2|diag} |
Options for the boot image are 1, 2, or diag.
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 |
puma(config){admin}# reboot |
1. As admin, download the new boot image:
puma{admin}# update image {hostname|ip_addr} file file_name 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.
The following example updates image 2 using the file pkgname from the remote server at IP address 192.50.50.201:
1. As admin, update the image:
puma{admin}# update image 192.50.50.201 file pkgname image 2 |
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, enter the following command:
puma(config){admin}# diag level {0|1|2} verbose {0|1|2} |
TABLE 4-30 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.
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, enter the following command:
puma(config){admin}# debug module module_name level {0-5} |
TABLE 4-31 describes the parameters for configuring the debug level for specified modules:
TABLE 4-32 describes the module names to use for configuring the debug level:
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, enter the following command:
puma(config){admin}# shutdown [force] |
Where force forces the shutdown without asking for confirmation.
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, enter the following command:
puma(config){admin}# reboot [force] |
Where force forces the reboot without asking for confirmation.
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}# reboots force |
Shows the current system date and time.
As any user, type 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, type the following command:
puma{user}# show system |
The show uptime command shows the uptime for the system.
As any user, type the following comma nd:
puma{user}# show uptime |
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, type the following comma nd:
puma{user}# dump memory addr [size] |
TABLE 4-33 describes the parameters for the dump memory command:
Address on the system memory to dump from (in hex without the leading `0x'). |
|
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, type the following comma nd:
puma{user}# dump module module_name [index] |
TABLE 4-34 describes the parameters for the dump module command:
TABLE 4-35 describes the valid module names to use with dump module command:
The following table lists the modules in the NPU by index:
The following example dumps module NPU 3 to the screen:
puma{user1}# dump module npu 3 |
The export config command exports a configuration file to another machine. After you specify the user name for logging into the remote host, the content load balancing blade responds to this command with a prompt for the password.
This interactive command prompts you for the hostname/IP address of the remote host to export the configuration to, the configuration file to export, the path on the remote host to export the file to, the username, and the password.
As admin in config mode, enter the following command:
puma(config){admin}# export config |
The import config command imports a configuration file from another machine. After you specify the user name for logging into the remote host, the content load balancing blade responds to this command with a prompt for the password.
This interactive command prompts you for the hostname/IP address of the remote host to import the configuration from, the configuration file to import, the path on the remote host to import the file from, the username, and the password.
As admin in config mode, enter the following command:
{admin}# import config |
As admin in config mode, enter the following command:
puma(config){admin}# commit [force] |
This command saves all the configuration writes into nonvolatile memory so that the writes can be recovered upon a restart. This is an interactive command and it prompts you for confirmation. To bypass the interactive mode, use the force option.
As any user, enter the following command:
puma{user}# dump config |
This command displays all the configurations saved in the flash memory.
The erase config-files command erase the current configuration in flash. By default, the command is interactive and asks for confirmation before removing the configuration in flash memory.
A maximum of two configuration files can be in flash memory. The configuration file that will be removed by the erase config-files command is the current configuration file, which you can obtain with the show system command.
As admin in config mode, enter the following command:
puma(config){admin}# erase config-files [force] |
Where force forces the removal of the current configuration file.
The following example forces the removal of the current configuration file:
puma(config){admin}# erase config-files force |
To Specify the Configuration in Flash to Use after a System Reboot |
There can be two configuration files in flash. The boot config command specifies which configuration file to use the next time the load balancing blade comes up after a system reboot.
As admin in config mode, enter the following command:
puma(config){admin}# boot config {1|2} |
Where 1 is configuration 1 and 2 is configuration 2.
The following example specifies that configuration file 2 be used when the system reboots:
puma(config){admin}# boot config 2 |
As admin, enter the following command:
puma{admin}# cat file_name |
The cat command outputs a file in the flash file system to the screen.
As any user, enter the following command:
puma{user}# cd new_directory |
As any user, enter the following command:
puma{user}# cp src_file dst_file |
As admin in non-config mode, enter the following command:
puma{admin}# mv old_file new_file |
As admin in non-config mode, enter the following command:
puma{admin}# rm filename |
As admin in non-config mode, enter the following command:
puma{admin}# mkdir dir_name |
As admin, enter the following command:
puma{admin}# rmdir dir_name |
As any user, enter the following command:
puma{user}# ls |
As any user, enter the following command:
puma{user}# pwd |
As any user, enter the following command:
puma{user}# tar tar_file_name dir_name |
Where tar_file_name is the name of the tar file created and dir_name is the name of the file or directory to be compressed.
As any user, enter the following command:
puma{user}# untar tar_file_name |
Where, tar_file_name is the name of the compressed file.
As any user, enter the following command:
puma{user}# tarinfo tar_file_name |
Where, tar_file_name is the name of the compressed file whose contents you want to display.
As any user, enter the following command
puma{user}# clear |
As any user, enter the following command:
puma{user}# alias addgrp set service lb-group |
As any user, enter the following command:
puma{user}# broadcast "mesg" |
Where mesg is the message string to be broadcast. The string must be surrounded by double quotes.
Use this command to send a message to all the users logged into the Sun Fire B10n content load balancing blade.
As any user, enter the following command
puma{user}# echo string |
As any user, enter the following command:
puma{user}# tree |
Returns the command-line interface tree.
As any user, enter the following command:
puma{user}# history |
Prints out all the commands executed till now in this session.
As any user, enter the following command:
puma{user}# help command |
Using the help command alone gets help on all commands. Entering a specific command, such as set service lb-group server, returns help for that specific command.
You can also get help by entering the command name and a question mark (?), for example:
puma{user}# service ? |
As any user, enter the following command:
puma{user}# logout |
Logs out from the current console session.