Contact Foundry engineering for information about using this command as part of a virtual server configuration.

Allows you to bind virtual server service to real server services. A virtual server service can bind one or more real-server services.

EXAMPLE:

To bind a virtual server to HTTP services on real servers web1 and web2, enter the following:

ServerIron(config)# server virtual www.foundrynet.com 207.95.5.1
ServerIron(config-vs-www.foundrynet.com)# bind http web1 http web2 http

Syntax: bind <tcp/udp-port-number> <real-server-name> <tcp/udp-port-number>

EXAMPLE:

• TCP/UDP port numbers:

  • default – all the well-known names listed below
  • dns – the well-known name for port 53
  • ftp – the well-known name for port 21. (Ports 20 and 21 both are ftp ports but on the ServerIron, the name “ftp” corresponds to port 21.)
  • http – the well-known name for port 80
  • imap4 – the well-known name for port 143
  • ldap – the well-known name for port 389
  • mms – the well-known name for port 1755
  • nntp – the well-known name for port 119
  • ntp – the well-known name for port 123
  • pnm – the well-known name for port 7070
  • pop2 – the well-known name for port 109
  • pop3 – the well-known name for port 110
  • radius – the well-known name for udp port 1812
  • smtp – the well-known name for port 25
  • snmp – the well-known name for port 161
  • ssl – the well-known name for port 443
  • rtsp – the well-known name for port 554
  • telnet – the well-known name for port 23
  • tftp – the well-known name for port 69

• Virtual server name: any previously defined virtual server

Default value: N/A

Enables the Active Cache feature, which configures the ServerIron to try resolving a client request using a cache server first, then using a load balanced server if the cache does not contain the requested content. For an example of how to use this feature, see the "Configuring Server Load Balancing" chapter in the Foundry ServerIron Installation and Configuration Guide.

EXAMPLE:

To enable Active Cache for VIP “Foundry“, enter the following command:

ServerIron(config-vs-Foundry)# cache-enable

To enable Active Cache for the SSL port (port 443) on VIP “Foundry“, enter the following command:

ServerIron(config-vs-Foundry)# port ssl cache-enable

Syntax: [no] cache-enable

Syntax: [no] port <tcp/udp-port> cache-enable

Possible values: N/A

Clears statistics or clears entries from a cache or table. See the descriptions for the individual clear commands in "Privileged EXEC Commands" .

Disables an individual virtual server or a port on a virtual server.

EXAMPLE:

To disable an individual virtual server, enter commands such as the following:

ServerIron(config)# server virtual www.foo.com
ServerIron(config-vs-www.foo.com)# disable

Syntax: [no] disable

Use the no parameter to re-enable a virtual server after disabling it.

Possible values: N/A

Default value: N/A

EXAMPLE:

To disable a port on a virtual server, enter commands such as the following:

ServerIron(config)# server virtual www.foo.com
ServerIron(config-vs-www.foo.com)# port http disable

Syntax: [no] port <port number | port name> disable

<port number | port name> is a legitimate port number or port name.

Use the no parameter to re-enable a port on a virtual server after disabling it.

Possible values: N/A

Default value: N/A

Specifies the amount by which you want the ServerIron to decrement a VIP’s priority when an application on the VIP fails a health check.

EXAMPLE:

ServerIronB(config-vs-VIP1)# sym-priority 20
ServerIronB(config-vs-VIP1)# dyn-sym-pri-factor 10

The commands in this example configure the decrement value to 10. Each time an application on the VIP fails a health check (fails on all the real servers bound to the VIP), the ServerIron decrements the VIP’s SSLB priority by 10. If the priority reaches a value that is lower than the VIP’s priority on the other ServerIron, the software fails over active load balancing for the VIP to the other ServerIron.

Syntax: [no] dyn-sym-pri-factor <num>

Possible Values: Enter a value from 1 – 255 for <num>

Default: None.

Moves activity to the privileged EXEC level from any level of the CLI, with the exception of the user level.

EXAMPLE:

To move to the privileged level, enter the following from any level of the CLI.

ServerIron(config-vs-www.rumors.com)# end

ServerIron#

Syntax: end

Possible values: N/A

Default value: N/A

Moves activity up one level from the current level. In this case, activity will be moved to the global level.

EXAMPLE:

ServerIron(config-vs-www.rumors.com)# exit
ServerIron(config)#

Syntax: exit

Possible values: N/A

Default value: N/A

Configures a public IP address for a VIP.

EXAMPLE:

To configure a public IP address for a VIP that will be used only by the peer GSLB ServerIron, enter commands such as the following:

ServerIron-B(config)# server virtual dns-test 192.168.10.1
ServerIron-B(config-vs-dns-test)# gslb-ip 207.95.55.23 for-peer-only
ServerIron-B(config-vs-dns-test)# exit

To configure a public IP address for a VIP that will be used both by the peer GSLB ServerIron and locally, by the ServerIron itself, enter commands such as the following.

ServerIron-B(config)# server virtual dns-test 192.168.10.1
ServerIron-B(config-vs-dns-test)# gslb-ip 207.95.55.23 for-self-and-peer
ServerIron-B(config-vs-dns-test)# exit

Syntax: gslb-ip <IP address> <for-peer-only | for-self-and-peer>

Possible values:

<IP address> is the public IP address for the VIP.

<for-peer-only> specifies that only the peer GSLB ServerIron will use this public VIP address. The ServerIron will continue to use the private IP address of the VIP for the local site, if present.

<for-self-and-peer> specifies that both the peer GSLB ServerIron and the local ServerIron will use this public IP address for the VIP.

Default value: N/A

Enables you to define a range of virtual IP addresses (VIPs) simply by defining a base VIP and the number of hosts in the range.

EXAMPLE:

To define a range of 500 contiguous VIPs, enter the following commands:

ServerIron(config)# server virtual-name lotsofhosts 209.157.22.99
ServerIron(config-vs-lotsofhosts)# host-range 500
ServerIron(config-vs-lotsofhosts)# exit
ServerIron(config)# server virtual-name cache1 10.4.4.4
ServerIron(config-rs-cache1)# host-range 500
ServerIron(config-rs-cache1)# exit

Syntax: host-range <range>

Possible values: 0 – 4294967295

Default value: N/A

Applies a previously defined host-range map to a virtual server.

EXAMPLE:

ServerIron(config)# server virtual vs1 192.168.9.10
ServerIron(config-vs-vs1)# host-range-map 1

Syntax: [no] host-range-map <map-number>

Possible values: Host-range map number

Default value: N/A

In configurations that use remote failover servers, the remote server sends replies back to the ServerIron or directly to the client:

• If you configure a source IP address and enable source NAT, the remote server sends the response back to the ServerIron.

• If you do not use source NAT (whether you have configured a source IP address or not), the remote real server sends the response directly to the client. In this case, the client refuses the connection request because the client believes it is talking to the virtual IP address, not the real server IP address. In this case, you can configure the ServerIron to send an HTTP redirect message to the client so that the client redirects its HTTP connection to the real server’s IP address instead of the VIP.

EXAMPLE:

To enable HTTP redirect, enter the following command:

ServerIron(config-vs-lotsofhosts)# httpredirect

Syntax: httpredirect

Possible values: N/A

Default value: Disabled

This command is used to disable other commands. To do so, place the word no before the command.

Allows you to add a TCP/UDP port to a VIP. If you are using the SwitchBack feature, you can use the dsr parameter to enable SwitchBack for the port.

EXAMPLE:

To add port 80 (HTTP) to a VIP called Web1, enter the following command:

ServerIron(config-vs-Web1)# port http

EXAMPLE:

To add port 80 (HTTP) to a VIP called Web69 and enable SwitchBack for the port, enter the following command:

ServerIron(config-vs-Web69)# port http dsr

Syntax: port <tcp/udp-port> [dsr]

EXAMPLE:

To disable port 8080 on VIP Web69, enter the following command:

ServerIron(config-vs-Web69)# port 8080 disable

Syntax: port <tcp/udp-port> [disable]

EXAMPLE:

To configure port 80 on VIP Web69 to support concurrent connections from a client, enter the following command:

ServerIron(config-vs-Web69)# port 8080 concurrent

Syntax: port <tcp/udp-port> [concurrent]

EXAMPLE:

To make port 80 on VIP Web69 "sticky" so that subsequent requests for the port from the same client go to the same real server, enter the following command:

ServerIron(config-vs-Web69)# port 8080 sticky

Syntax: port <tcp/udp-port> [sticky]

EXAMPLE:

To disable port translation for port 180 on VIP2, thus allowing many-to-one port binding for the port, enter the following commands.

ServerIron(config)# server virtual-name VIP1 209.157.22.88
ServerIron(config-vs-VIP1)# port http
ServerIron(config-vs-VIP1)# bind http r1 http r2 http
ServerIron(config-vs-VIP1)# exit
ServerIron(config)# server virtual-name VIP2 209.157.22.99
ServerIron(config-vs-VIP2)# port http
ServerIron(config-vs-VIP2)# no port http translate
ServerIron(config-vs-VIP2)# bind http r1 180 r2 180

Syntax: port <tcp/udp-port> [translate]

EXAMPLE:

To enable URL switching on a virtual server, enter the following commands.

ServerIron(config)# server virtual-name mysite 209.157.22.63
ServerIron(config-vs-mysite)# port http
ServerIron(config-vs-mysite)# port http url-map p1
ServerIron(config-vs-mysite)# port http url-switch
ServerIron(config-vs-mysite)# bind http rs1 http
ServerIron(config-vs-mysite)# bind http rs2 http
ServerIron(config-vs-mysite)# bind http rs3 http
ServerIron(config-vs-mysite)# exit

Syntax: port http

Syntax: port http url-map <policy-name>

Syntax: port http url-switch

Syntax: bind http <real-server-name> http

EXAMPLE:

URL string hashing causes HTTP requests that contain the same URL string always to go to the same real server. When an HTTP request comes into a virtual server, the ServerIron examines its URL string and automatically selects a real server from among those bound to the virtual server. The HTTP request, as well as all subsequent HTTP requests that contain the same URL string, go to that real server.

You can optionally include the HTTP request’s host ID in the hashing calculation. The host ID specifies the network location of the resource; for example www.foundrynet.com.

For example, when URL string hashing is enabled, the ServerIron performs hashing on the URL string:

/doc/ServerIron/0702/url_switching.html

You can now configure the ServerIron to perform hashing on both the host ID and the URL string:

www.foundrynet.com/doc/ServerIron/0702/url_switching.html

To allow the host ID to be included in URL string hashing, enter commands such as the following:

ServerIron(config)# server virtual URLhash 209.157.22.241
ServerIron(config-vs-URLhash)# port http
ServerIron(config-vs-URLhash)# port http hash-url-string
ServerIron(config-vs-URLhash)# port http port http hash-host-id
ServerIron(config-vs-URLhash)# bind http rs7 http
ServerIron(config-vs-URLhash)# bind http rs8 http
ServerIron(config-vs-URLhash)# bind http rs9 http
ServerIron(config-vs-URLhash)# exit

Syntax: port http hash-host-id

EXAMPLE:

To configure session persistence in a proxy environment, configure a standard IP ACL containing the addresses, then use the sticky-acl option with the application ports on the virtual server. The sticky-acl option configures the Virtual Source feature.

In a Virtual Source configuration, the ServerIron sends all client traffic from a specified range of IP addresses to the same real server for the application ports you specify. To specify the IP addresses, configure a standard IP ACL. Use this command in configurations where a proxy device allocates IP addresses to client traffic before sending the traffic to the VIP. In some configurations, the proxy device assigns different IP addresses to traffic from the same client. Unless you configure the addresses to go to the same real server, the ServerIron might load balance the client traffic to different servers. This makes applications that require continued access to the same real server unusable.

ServerIron(config)# access-list 1 permit 209.157.22.0
ServerIron(config)# server virtual fromproxy 1.1.1.1
ServerIron(config-vs-fromproxy)# port 80 sticky-acl 1

Syntax: [no] access-list <num> deny | permit <source-ip> | <hostname> <wildcard> [log]

or

Syntax: [no] access-list <num> deny | permit <source-ip>/<mask-bits> | <hostname> [log]

Syntax: [no] port <tcp/udp-port> sticky-acl <num>

For standard IP ACL configuration information, see the “Configuring Standard ACLs” section in the “Using Access Control Lists (ACLs)” chapter of the Foundry Switch and Router Installation and Basic Configuration Guide.

EXAMPLE:

To configure an application port to be stateless, enable the stateless parameter on the port in the virtual server. Here is an example:

ServerIron(config)# server real R1 10.10.10.1
ServerIron(config-rs-R1)# port http
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real R2 10.10.11.1
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# exit
ServerIron(config)# server virtual StatelessHTTP 192.168.4.69
ServerIron(config-vs-StatelessHTTP)# port http stateless
ServerIron(config-vs-StatelessHTTP)# bind http R1 http
ServerIron(config-vs-StatelessHTTP)# bind http R2 http

Syntax: [no] port <tcp/udp-port> stateless

The <tcp/udp-port> parameter specifies the application port you want to make stateless.

EXAMPLE:

You can use the stateless option when configuring an application port on a virtual server to make that port stateless. By default, the port is stateless for both TCP and UDP. You can specify the protocol for which you want the port to be stateless. For example, you can configure port DNS to be stateless for TCP while remaining stateful for UDP.

Here is an example:

ServerIron(config)# server real R1 10.10.10.1
ServerIron(config-rs-R1)# port http
ServerIron(config-rs-R1)# exit
ServerIron(config)# server real R2 10.10.11.1
ServerIron(config-rs-R2)# port http
ServerIron(config-rs-R2)# exit
ServerIron(config)# server virtual StatelessDNS 192.168.4.69
ServerIron(config-vs-StatelessDNS)# port dns stateless tcp
ServerIron(config-vs-StatelessDNS)# bind dns R1 dns
ServerIron(config-vs-StatelessDNS)# bind dns R2 dns

Syntax: [no] port <tcp/udp-port> [stateless [tcp | udp] [no-hash]]

The <tcp/udp-port> parameter specifies the application port you want to make stateless.

The stateless parameter configures the port to be stateless.

The tcp | udp parameter restricts stateless operation to the specified protocol (TCP or UDP).

The no-hash parameter disables the SLB hashing mechanism for the port (and protocol, if specified). When hashing is disabled, the ServerIron uses the round-robin load balancing method to select a real server for each request.

EXAMPLE:

By default, stateless SLB uses a hashing algorithm to select a real server. The ServerIron calculates a hash value for a given client request based on the request’s source IP address and source TCP/UDP port. The request is sent to a real server corresponding to this hash value.

For UDP connections consisting of one client packet and one server response packet, you can disable the stateless SLB hashing algorithm. When the stateless SLB hashing algorithm is disabled for UDP ports, the ServerIron uses the round-robin load balancing method to select a real server for the request. In this case, the ServerIron load balances UDP packets destined for the VIP without creating a session and without calculating hash values based on UDP port number and source IP address.

DNS is an example of a UDP port where this feature can be used. The advantage of disabling the stateless SLB hashing algorithm is that a new real server can be selected immediately after it is brought up.

For example, to disable the stateless SLB hashing algorithm for the DNS port (UDP port 53):

ServerIron(config)# server virtual Stateless 192.168.4.69
ServerIron(config-vs-Stateless)# port dns stateless no-hash

Syntax: [no] port <udp-portnum> stateless no-hash

The <udp-port> parameter specifies the UDP application port you want to make stateless.

EXAMPLE:

This example applies to health-check policies (see "healthck (ServerIronXL with software versions prior to 07.3.05)" ). After you configure logical expressions, you can bind them to application ports on VIPs. A health-check policy does not take effect until you bind the policy to an application port on a VIP.

To bind a health-check policy to an application port on a VIP, enter commands such as the following:

ServerIron(config)# server virtual-name VIP1 1.1.1.1
ServerIron(config-vs-VIP1)# port http healthck Router2

This command configures virtual IP address VIP1 to use the heath-check policy named "Router2" to check the health of HTTP (port 80) for the VIP.

Syntax: [no] port <tcp/udp-portnum> healthck <policy-name>

The <tcp/udp-portnum> parameter specifies a TCP or UDP application port. The <policy-name> parameter specifies the health-check policy you want to use to check the Layer 3 health of a device associated with the application port.

EXAMPLE:

When fast aging for UDP sessions is configured, a client request causes the ServerIron to add an entry to its session table; when a response is detected, the ServerIron immediately deletes the session table entry.

When this feature is configured, if the ServerIron detects a server response to a client request, and the response is not fragmented, the session table entry is deleted immediately. If the response is fragmented, the ServerIron waits for the last fragment to arrive, forwards it to the client, and then sends the session to the delete queue. The session stays in the delete queue for 8 seconds by default before being deleted. You can change the amount of time the session stays in the delete queue to between 1 – 40 seconds.

To activate this feature for port 1234:

ServerIron(config)# server virtual vs1 192.168.1.2
ServerIron(config-vs-vs1)# port 1234 udp-fast-age

Syntax: port <udp-portnum> udp-fast-age

EXAMPLE:

To enable a VIP to use the servers designated as backups only as backups, and use the other servers as the primary load-balancing servers, enter the following command at the configuration level for the VIP:

ServerIron(config-vs-VIP1)# port http lb-pri-servers

This command enables VIP1 to use the backup and primary servers for application port HTTP.

To configure the VIP and application port to continue using the backup servers even after the primary servers become available again, use the backup-stay-active parameter, as in the following example:

ServerIron(config-vs-VIP1)# port http lb-pri-servers backup-stay-active

Syntax: [no] port <tcp/udp-port> lb-pri-servers [backup-stay-active]

You also must explicitly designate the backup real servers as backups. See "backup" .

EXAMPLE:

This example configures the ServerIron to stop sending packets for an established connection to a real server if the requested application is down on the server.

In some configurations, such as those that use a cluster of servers for an application, you might want to configure the ServerIron to stop sending traffic for established connections to a server when the requested application is down on the server. For example, this feature is useful in an NFS configuration.

When you enable this feature, the ServerIron does one of the following in addition to redirecting future requests away from the real server:

• UDP – For an unavailable UDP application, the ServerIron terminates the connection.

• TCP – For an unavailable TCP application, the ServerIron resets the connection.

To configure the ServerIron to stop sending requests for an established connection to a real server for an application that is down on the server, enter the following command at the configuration level for the VIP:

ServerIron(config-vs-VIP1)# port 80 reset-on-port-fail

This command configures the ServerIron to stop sending traffic on existing HTTP connections to a real server bound to VIP1 if the HTTP application has failed on the server. The ServerIron instead terminates the connection (if UDP) or resets the connection (if TCP).

Syntax: [no] port <tcp/udp-portnum> reset-port-on-fail

EXAMPLE:

This example configures the ServerIron to age DNS or RADIUS sessions using the UDP age timer. By default, the ServerIron immediately deletes a UDP DNS or RADIUS session table entry when the ServerIron receives a reply for the application from a real server.

ServerIron(config-vs-VIP1)# port dns udp-normal-age

Syntax: [no] port dns | radius udp-normal-age

Possible values: See above

Default value: N/A

EXAMPLE:

This example configures VIP spoofing, where the ServerIron, when it receives traffic from a real server on a specified port, forwards it not to the original client, but to the cache server where the SLB traffic was initiated. VIP spoofing can be used in configurations that use an SSL accelerator as a cache server, which may require traffic from a real server to first go back to the cache server before going to the original client.

See "Enhanced SSL Accelerator Support" in the Foundry ServerIron Installation and Configuration Guide for a sample VIP spoofing configuration.

ServerIron(config-vs-VIP1)# port http spoofing

Syntax: [no] port http spoofing

Possible values: N/A

Default value: N/A

EXAMPLE:

This example inserts a standard HTTP Via: header into HTTP requests coming into the virtual server mysite.

ServerIron(config)# server virtual-name mysite 192.168.9.51
ServerIron(config-vs-mysite)# port http request-insert "Via: ServerIron 8100SR"
ServerIron(config-vs-mysite)# exit

Syntax: port <virtual port> request-insert <header>

Possible values:

<virtual port> is any valid port

<header> is the HTTP header message to insert in the HTTP requests or responses.

Default value: N/A

EXAMPLE:

This example inserts a header into the HTTP responses it sends from the virtual server.

ServerIron(config)# server virtual-name mysite 192.168.9.51
ServerIron(config-vs-mysite)# port http response-insert "FDRY-SI: proto=HTTP+MMS"
ServerIron(config-vs-mysite)# exit

In this example, the ServerIron inserts the following header into the HTTP responses it sends from the virtual server:

FDRY-SI: proto=HTTP+MMS\r\n

This is an example of a customized header. The ServerIron can insert both standard and customized HTTP headers into HTTP requests or responses.

Syntax: port <virtual port> response-insert <header>

Possible values:

<virtual port> is any valid port

<header> is the HTTP header message to insert in the HTTP requests or responses.

Default value: N/A

EXAMPLE:

This example inserts the Client IP address as an HTTP header into HTTP requests.

ServerIron(config)# server virtual-name mysite 192.168.9.51
ServerIron(config-vs-mysite)# port http request-insert client-ip
ServerIron(config-vs-mysite)# exit

When you enter this command, the ServerIron inserts the following header into all HTTP requests coming into the virtual port:

Client-IP: <source IP>\r\n

Syntax: [no] port <virtual port> request-insert client-ip

Possible values: <virtual port> is any valid port

Default value: N/A

This command is used to select the session's distribution algorithm that will be used on the specified virtual server. This command will override any globally configured value for a virtual server. By default, the least connections method is enabled.

EXAMPLE:

To change the virtual server predictor method from the default value of least connections to the round-robin method, enter the following:

ServerIron(config)# server virtual www.foundrynet.com 207.95.5.1
ServerIron(config-vs-www.foundrynet.com)# predictor round-robin

Syntax: [no] predictor least-conn | least-sess | least-local-sess | response-time | round-robin | weighted

Possible values: See above

Default value: least-conn

This command returns you from any level of the CLI to the User EXEC mode.

EXAMPLE:

ServerIron(config-vs-Foundry)# quit
ServerIron>

Syntax: quit

Possible values: N/A

Default value: N/A

Displays the real and virtual server configuration information on a remote site ServerIron in the GSLB ServerIron’s CLI. The command also displays the session and CPU information used by the GSLB policy. You can view detailed configuration information and statistics for the site ServerIron, from the GSLB ServerIron’s management console. For more information, see the "Configuring Global Server Load Balancing" chapter in the Foundry ServerIron Installation and Configuration Guide.

Displays a variety of configuration and statistical information about the ServerIron. To see a description of the show commands, see "Show Commands" .

Allows you to disable or re-enable this feature. Use this command only if advised to do so by Foundry technical support.

Enables active-active Symmetric SLB on a VIP.

EXAMPLE:

ServerIronA(config)# server virtual-name VIP1 1.1.1.1
ServerIronA(config-vs-VIP1)# port 80
ServerIronA(config-vs-VIP1)# sym-priority 69
ServerIronA(config-vs-VIP1)# sym-active

This example configures VIP1 by adding port 80, enabling SSLB, then enabling active-active SSLB. The sym-priority command enables SSLB. The command requires a number from 1 – 255 to enable SSLB. Once you enter the sym-active command to enable active-active SSLB, the software ignores the priority value you specified.

Syntax: [no] sym-active

Possible values: N/A

Default value: Disabled

Assigns a Symmetric SLB priority to a virtual IP address (VIP). The priority determines which ServerIron in a Symmetric SLB configuration is the default active ServerIron for the VIP. The priority can be from 0 (disabled) – 255 (highest priority).

See the "Configuring Symmetric SLB and SwitchBack" chapter of the Foundry ServerIron Installation and Configuration Guide for more information about this feature.

EXAMPLE:

To configure VIPs V1 and V2 on two ServerIrons for Symmetric SLB, enter the following commands. After you enter these commands, the first ServerIron is the active ServerIron for VIP V1 (1.1.1.1) and is the backup ServerIron for VIP2 (2.2.2.2). The second ServerIron is the active ServerIron for VIP V2 (2.2.2.2) and the backup ServerIron for VIP1 (1.1.1.1).

Commands for the first ServerIron:

ServerIron(config)# server virtual-name V1 1.1.1.1
ServerIron(config-vs-V1)# sym-priority 2
ServerIron(config-vs-V1)# exit
ServerIron(config)# server virtual-name V2 2.2.2.2
ServerIron(config-vs-V2)# sym-priority 254
ServerIron(config-vs-V2)# write mem

Commands for the second ServerIron:

ServerIron(config)# server virtual-name V1 1.1.1.1
ServerIron(config-vs-V1)# sym-priority 254
ServerIron(config-vs-V1)# exit
ServerIron(config)# server virtual-name V2 2.2.2.2
ServerIron(config-vs-V2)# sym-priority 2
ServerIron(config-vs-V2)# write mem

Syntax: sym-priority <num>

Possible values: 0 – 255; setting the priority to 0 removes the priority setting

Default value: N/A

Configures up to four TCP/UDP ports to “track” another, “primary” TCP/UDP port. This feature enables the ServerIron to group applications. After the ServerIron sends a request for the master TCP/UDP port to a real server, requests from the same client for the ports that track the master port also go to the same real server.

For more information about this feature, see the "Configuring Server Load Balancing" chapter in the Foundry ServerIron Installation and Configuration Guide.

EXAMPLE:

To configure TCP/UDP ports 8080 and 9090 to track port 80, enter the following command

ServerIron(config-vs-Foundry)# track 80 8080 9090

Syntax: track <primary-port> <tcp/udp-port> [<tcp/udp-port>[<tcp/udp-port>[<tcp/udp-port>]]]

Possible values: a TCP or UDP port number.

Default value: N/A

Causes the ServerIron to use the same server for applications associated with a set of grouped ports, as long as the all the ports in the group are active. After the ServerIron sends a client to a real server for any of the grouped ports, subsequent requests from that client for any of the grouped ports go to the same real server.

For more information about this feature, see the "Configuring Server Load Balancing" chapter in the Foundry ServerIron Installation and Configuration Guide.

EXAMPLE:

To group the HTTP port (80), Telnet port (23), and TFTP port (69) together:

ServerIron(config-vs-v1)# track-group 80 69 23

Whenever a client attempts to connect to a port within the group, the ServerIron ensures all ports in the group are active before granting the connection.

Possible values: a TCP or UDP port number. Up to eight ports can be grouped together using the track group function. A port can be part of only one group. The track-group and track commands for a port are mutually exclusive.

Default value: N/A

Enables an individual VIP for transparent VIP. Transparent VIP applies only to the VIPs on which you enable it.

EXAMPLE:

ServerIron(config-vs-TransVIP)# transparent-vip

Syntax: [no] transparent-vip

Possible values: N/A

Default value: Disabled

Saves the running-time configuration into the startup-config file.

EXAMPLE:

ServerIron(config-vs-Foundry)# write memory

Syntax: write memory

Possible values: N/A

Default value: N/A

Displays the running-configuration of the ServerIron on the terminal screen.

EXAMPLE:

ServerIron(config-vs-Foundry)# write terminal

Syntax: write terminal

Possible values: N/A

Default value: N/A