Manual Chapter : BIG-IP Reference Guide v4.0: bigpipe Command Reference

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 4.0 PTF-04, 4.0 PTF-03, 4.0 PTF-02, 4.0 PTF-01, 4.0.0
Manual Chapter


2

bigpipe Command Reference



bigpipe commands

This chapter lists the various bigpipe commands, including syntax requirements and functional descriptions. Table 2.1 outlines the conventions used in the command line syntax.

Command line conventions
Item in text Description
\ Continue to the next line without typing a line break.
< > You enter text for the enclosed item. For example, if the command has <your name>, type in your name.
| Separates alternate options for a command.
[ ] Syntax inside the brackets is optional.
... Indicates that you can type a series of items.

The following table provides a concise listing of the individual bigpipe commands.

Command Description
-? Displays online help for an individual bigpipe command.
config Synchronizes the /config/bigip.conf between the two BIG-IP Controller units in a redundant system.
conn Shows information about current connections such as the source IP address, virtual server and port, and node.
failover Sets the BIG-IP Controller as active or standby.
global Sets global variable definitions.
-h and -help Displays online help for bigpipe command syntax.
interface Sets options on individual interfaces.
load Loads the BIG-IP Controller configuration and resets
maint Toggles the BIG-IP Controller into and out of maintenance mode.
makecookie Loads the BIG-IP Controller configuration without resetting the current configuration.
merge Loads a saved BIG-IP Controller configuration without resetting the current configuration.
monitor Defines a health check monitor
-n Displays addresses ports numerically rather than by name
nat Defines external network address translations for nodes.
node Defines node property settings.
pool Defines load balancing pools.
proxy Defines the properties of the SSL gateway for the SSL Accelerator.
ratio Sets load-balancing weights and priority levels used in the Ratio and Priority load balancing modes.
reset Clears the BIG-IP Controller configuration and counter values.
rule Defines load balancing rules.
save Writes the current configuration to a file.
self Assigns a self IP address for a VLAN or interface
service Defines properties for services.
snat Defines and sets options for SNAT (Secure NAT).
summary Displays summary statistics for the BIG-IP Controller.
trunk Aggregates links to form a trunk
unit Displays the unit number assigned to a particular BIG-IP Controller.
verbose Used to modify the verbose log level.
verify Parses the command line and checks syntax without executing the specified command.
version Displays the bigpipe utility version number.
virtual Defines virtual servers, virtual server mappings, and virtual server properties.
vlan Defines VLANs, VLAN mappings, and VLAN properties.
vlangroup Defines VLAN groups

-?

b <command> -?

For certain commands, displays online help, including complete syntax, description, and other related information. For example, to see online help for the bigpipe service command, type:

b service -?

config

 b config sync   
b config sync all
b config sync running
b config save <file>
b config install <file>

Synchronizes configurations of two BIG-IP Controllers in a redundant system by collecting and copying the configuration file(s) from the active unit to the standby unit (config sync). Also archives configuration files for backup purposes (config save) and installs saved files (config install).

Synchronizing configuration files

config sync without the all option synchronizes only the basic configuration file /config/bigip.conf.

config sync all synchronizes the following configuration files:

  • The common BIG/db keys
  • All common files in /config
  • All common files in /etc

    config sync running synchronizes the running version of /config/bigip.conf, which is the image that resides in memory as the system runs. This file is loaded into memory on the standby unit, it is not saved.

Saving configuration files to an archive

config save <file> saves all configuration files to a single archive file <file>.ucs on the local unit without copying it to the standby unit. By default, <file>.ucs is saved to the directory /user/local/ucs. An alternate location can be specified by expressing <file> as a relative or absolute path. For example:

b config save /user/local/config_backup/my_conf

This writes the file my_conf.ucs to the directory /user/local/config_backup.

Installing an archived configuration file

config install <file> de-archives the configuration files saved as <file>.ucs to their working locations on the local unit.

If you use command line utilities to set configuration options, be sure to save the current configuration to the relevant files before you use the configuration synchronization feature. (Alternatively, if you want to test the memory version on the standby unit first, use bigpipe config sync running.) Use the following bigpipe command to save the current configuration:

b save

Note: A file named /usr/local/ucs/cs_backup.ucs is created prior to installing a UCS from a remote machine.

conn

 b conn [ <client_ip>[:<service>] ] dump [mirror]   

Displays information about current client connections to virtual addresses and virtual servers.

The following command displays all current client connections:

b conn dump

The output shows the source IP, virtual server and port, and node connected to.

Figure 2.1 Formatted output of the conn command

 bigip conn dump    

from virtual node
100.100.100.30:49152 -> 100.100.100.100:23 -> 200.200.200.10:23
100.100.101.90:49153 -> 100.100.100.100:80 -> 200.200.200.10:80
...

This command can also show connections that are active on the given controller as well as those that are standby connections for the peer BIG-IP Controller. By default, the dump command only shows items that are active on the given unit. To see standby items, you must use the mirror qualifier.

b conn dump mirror

failover

 b failover active | standby | show | init | failback    

This group of commands affects the fail-over status of the BIG-IP Controller.

In an active/standby or active-active configuration, run the following command to place a controller in standby mode:

b failover standby

Show the status of the controller with the following command:

b failover show

Note: The failback command is only applicable if you are running a redundant system in active-active mode.

In an active-active configuration, run the following command after you issue the bigpipe failover standby command. This allows the inactive controller to resume handling connections:

b failover failback

You can use the bigpipe failover init command to refresh the parameters of the fail-over daemon (/sbin/sod) with any new configuration data entered in the BIG/db database.

b failover init

global

 b global auto_lasthop enable | disable | show   
b global fastest_max_idle_time <seconds>
b global fastflow_active auto | on | off | show
b global fastflow_active auto | on | off | show
b global gateway failsafe arm | disarm | show
b global mirror enable | disable | show
b global memory_reboot_percent <percent>
b global open_3dns_ports enable | disable | show
b global open_corba_ports enable | disable | sho
b global open_snmp_ports enable | disable | show
b global open_telnet_port enable | disable
b global open_ftp_ports enable|disable
b global open_ssh_port enable | disable
b global open_rsh_ports enable | disable
b global persist_map_proxies enable | disable
b global persist timer limit | timout | show
b global persist across_services enable | disable
b global persist across_virtuals enable|disable
b global sticky table_limit <max_num> | show
b global verbose_log_level <level>
b global webadmin_port <port>

auto_lasthop

When this variable is enabled, it automatically designates the lasthop router inside IP address as a lasthop route for replies to inbound traffic If auto_lasthop is disabled, the lasthop router inside IP address must be specified as a lasthop pool. The default setting is enable.

fastest_max_idle_time

Sets the number of seconds a node can be left idle by the fastest load balancing mode. This forces the BIG-IP Controller to send fewer connections to a node that is responding slowly, and also allows the BIG-IP Controller to periodically recalculate the response time of the slow node.

fastflow_active

You can use this variable to control additional enhancements that speed packet flow for TCP connections when the packets are not fragmented. In most configurations these software enhancements are automatically turned on and do not require any additional configuration.

However, you may want to turn off these enhancements for individual virtual servers that use IPFW rate filters. With the speed enhancements on, IPFW only examines the first SYN packet in any given connection. If you want to filter all packets, you should turn the speed enhancements off. To do this, you first set the global state of the system on, and then you turn the feature off for individual virtual servers that use IPFW rate filtering. You can also change the settings for these enhancements from the command line or in the Configuration utility.

There are three global states you can set with fastflow_active. The default state is auto. The global states are:

off

auto

on

The additional speed enhancements are globally disabled if the sysctl variable fastflow_active is off or if fastflow_active is set to auto and an IPFW rate filter exists in the configuration.

To provide the benefits of software acceleration for virtual servers that do not use rate filtering and turn off software acceleration for virtual servers that use IPFW rate filtering, you can set the sysctl variable fastflow_active to on with the following command:

sysctl -w fastflow_active on

After you set the sysctl variable, use the following bigpipe command to disable software acceleration for virtual servers that use IPFW rate filtering:

b virtual <ip>:<port> accelerate disable

gateway

Turns the gateway fail-safe feature on and off. This command is supported only for redundant systems.

The typical use of gateway fail-safe is a setup where active and standby BIG-IP Controllers use different routers as gateways to the internet. Fail-over is triggered if the gateway for the active controller is unreachable.

To arm fail-safe on the gateway, enter the following command:

b global gateway failsafe arm

To disarm fail-safe on the gateway, enter the following command:

b global gateway failsafe disarm

To see the current fail-safe status for the gateway, enter the following command:

b global gateway failsafe show

For more information about configuring gateway fail-safe, see Health monitors, on page 1-120.

mirror

Enables mirroring functions globally for the BIG-IP Controller. The mirror feature duplicates the active controller's real-time connection or persistence information state on the standby controller for smooth transition to the inactive controller at failover. The default setting is enabled.

memory_reboot_percent

The value you type, 80 or higher, is the percentage of memory that is in use before the BIG-IP Controller automatically reboots. The default value for this variable is 0, which is disabled. The minimum value for this variable is 80, or 80 percent of the total physical memory on the controller.

open_3dns_ports

This variable is required only when running one or more separate 3-DNS Controllers in the network. It does not apply to running the 3-DNS software module on the BIG-IP Controller itself. The variable is disabled on the BIG-IP Controller when the 3-DNS Controller is not present in the network configuration. (See the 3-DNS Administrator Guide for more information.)

open_corba_ports

This variable enables and disables the CORBA ports, which allow administrative CORBA connections. The default setting is disabled.

open_snmp_ports

This variable enables and disables the SNMP ports, which allow administrative SNMP connections. The default setting is disabled.

open_telnet_port

This variable enables or disables ports for Telnet access, and the default setting is disable.

The following command sets this variable to open the Telnet port (23) to allow administrative Telnet connections. This is useful for BIG-IP Controllers that do not support encrypted communications, or for a controller that needs to communicate with 3-DNS Controllers that do not support encrypted communications.

The following command opens the Telnet port.

b global open_telnet_port enable

The following command closes the Telnet port.

b global open_telnet_port disable

open_ftp_ports

This variable enables or disables ports for FTP access, and the default setting is disable.

The following command open the FTP ports (20 and 21) to allow administrative FTP connections, which is useful for BIG-IP Controllers that do not support encrypted communications.

b global open_ftp_ports enable

The following command closes FTP ports.

b global open_ftp_ports disable

open_ssh_por

This variable enables or disables ports for SSH access on BIG-IP Controllers that support encrypted communication. The default setting is enable.

The following command opens the SSH port (22) to allow encrypted administrative connections.

b global open_ssh_port enable

The following command closes the SSH port.

b global open_ssh_port disable

open_rsh_ports

This variable enables or disables ports for RSH access, and it is useful for BIG-IP Controllers that do not support encrypted communications, or for connecting to 3-DNS Controllers that do not support encrypted communication. The default setting is disable.

The following command opens the RSH ports (512, 513, and 514) to allow RSH connections.

b global open_rsh_ports enable

The following command closes RSH ports.

b global open_rsh_ports disable

persist map_proxies

The default setting for the map proxies for the persistence variable is enable. The AOL proxy addresses are hard-coded in this release. This enables you to use client IP address persistence with a simple persist mask, but forces all AOL clients to persist to the same server. All AOL clients will persist to the node that was picked for the first AOL client connection received.

The class B networks, 195.93 and 205.188, are mapped to 152.163 for persistence. For example, client 195.93.3.4 would map to 152.63.3.4 for persistence records only. This mapping is done prior to applying the persist mask. Use bigpipe pool persist dump to verify that the mapping is working.

We recommend that in addition to setting this sysctl variable, you set a persist mask of 255.255.0.0 so that all the AOL addresses map to a common address. For example, Table 2.2 is an example of how setting this variable and a persist mask of 255.255.0.0 would map a sample set of client addresses.

Address mapping of sample clients
Sample Client Address Persist Address
152.44.12.3 195.93.0.0
152.2.99.7 195.93.0.0
170.11.19.22 195.93.0.0
202.67.34.11 195.93.0.0
205.188.11.2 195.93.0.0
208.33.23.4 208.33.0.0 (non AOL address is not mapped)

persist timer

The following command forces the persistent connection timer to reset on each packet for persistent sessions. This is the default value.

b global persist timer limit

The following command resets the timer only when the persistent connection is initiated.

b global persist timer timout

Note: For SSL persistence, the timer is always reset on each packet.

persist across_services

When this variable is enabled, all simple persistence connections from a client IP address that go to the same virtual address also go to the same node (matches the client address and the virtual IP address but not the virtual port).

The default setting for this variable is disabled.

persist across_virtuals

When this variable is enabled, all simple persistent connections from the same client IP address are sent to the same node (matches the client IP address but not the virtual address or virtual port the client is using). The default setting for this variable is disabled.

sticky table_limit

This is the maximum number of sticky entries allowed to accumulate on the BIG-IP Controller when using destination address affinity (sticky persistence). When the maximum value is reached, the BIG-IP Controller stops accumulating sticky entries. The default value for this entry is 2048.

verbose_log_leve

This variable set logging levels for both TCP and UDP traffic. Each log level is identified by a level number used in place of the <level> parameter.

The following command turns on port denial logging for both TCP and UDP traffic. This logs TCP and UDP port denials to the virtual server address and the BIG-IP Controller address.

verbose_log_level=15

The following command turns logging off altogether:

verbose_log_level=0

Setting log levels only for TCP traffic

The following command turns on only TCP port denial logging, which logs TCP port denials to the BIG-IP Controller address.

verbose_log_level=2

The following command turns on virtual TCP port denial logging, which logs TCP port denials to the virtual server address.

verbose_log_level=8

Setting log levels for UDP traffic

The following command turns on only UDP port denial logging, which logs UDP port denials to the BIG-IP Controller address.

verbose_log_level=1

The following command turns on only virtual UDP port denial logging, which logs UDP port denials to the virtual server address.

verbose_log_level=4

webadmin_port

Specifies the port number used for administrative web access. The default port for web administration is port 443.

-h and -help

 b [-h | -help ]    

Displays the bigpipe command syntax or usage text for all current commands.

Note: More detailed man pages are available for some individual bigpipe commands. To display detailed online help for the bigpipe command, type: man bigpipe.

interface

 b interface <if_name> media <media_type>|show   
b interface <if_name> duplex full|half|auto|show
b interface [<if_name>] show

Displays names of installed network interface cards and allows you to set properties for each network interface card.

Setting the media type

The media type may be set to the specific media type for the interface card or it may be set to auto for auto detection. If the media type is set is set to auto and the card does not support auto detection, the default type for that interface will be used, for example 1000BaseTX.

Setting the duplex mode

Duplex mode may be set to full or half duplex. If the media type does not allow duplex mode to be set, this will be indicated by an onscreen message. If media type is set to auto, or if setting duplex mode is not supported, the duplex setting will not be saved to bigip.conf.

load

 b [verify] load [<filename>|-]  
b [-log] load [<filename>|-]

Resets all of the BIG-IP Controller settings and then loads the configuration settings, by default from the /config/bigip.conf and /config/bigip_base.conf file.

For testing purposes, you can save a test configuration by renaming it to avoid confusion with the boot configuration file. To load a test configuration, use the load command with the <filename> parameter. For example, if you renamed your configuration file to /config/bigtest.conf, the command would be:

b load /config/bigtest.conf

The command checks the syntax and logic, reporting any errors that would be encountered if the command executed.

You can type b load - in place of a file name, to display the configuration on the standard output device.

b save -

Use the load command together with the verify command to validate the specified configuration file. For example, to check the syntax of the configuration file /config/altbigpipe.conf, use the following command:

b verify load /config/altbigip.conf

The -log option will cause any error messages to be written to /var/log/bigip in addition to the terminal.

maint

 b maint   

Toggles a BIG-IP Controller into and out of Maintenance mode. When in Maintenance mode, a BIG-IP Controller accepts no new connections, but it does allow existing connections to complete.

The maint command interactively prompts you to enter or exit the maintenance mode.

b maint

If the BIG-IP Controller is already in maintenance mode, the maint command takes the BIG-IP Controller out of maintenance mode. If the BIG-IP Controller is in maintenance mode for more than 20 minutes, that the BIG-IP Controller immediately begins to accept new connection requests.

If the BIG-IP Controller has been in maintenance mode for more than 20 minutes, it automatically updates all network ARP caches; this process normally takes a few seconds. However, you can speed the process up by reloading the configuration file, using the following command:

b -f /config/bigip.conf

makecookie

 b makecookie <ip_addr:service>  

Generates a cookie string with encoding automatically added for cookie persistence Passive mode:

b makecookie <server_address:service> [ > <file>]

This command prints a cookie template similar to the templates shown in Figure 2.2 and Figure 2.3.

Figure 2.2 Sample cookie template

 Set-Cookie:BIGipServer[poolname]=336268299.20480.0000; path=/  

Figure 2.3 Sample cookie template with additional information

 Set-Cookie:BIGipServer[poolname]=336268299.20480.0000; expires=Sat, 01-Jan-2000 00:00:00 GMT; path=/   

To create your cookie using the sample string above, simply enter the actual pool names and the desired expiration date and time.

merge

 b [-log] merge [<file_name>]   

Use the merge command to load the BIG-IP Controller configuration from <file_name> without resetting the current configuration.

monitor

 b monitor <monitor_name> {use <monitor_template> [<attr>  <attr_value>]... }    
b monitor show [all]
b monitor dump [all]
b monitor <name> show
b monitor <name> delete
b monitor <name> enable | disable
b monitor instance <ip>:<service> enable | disable
b monitor instance <ip> enable | disable

Defines a health monitor. A health monitor is a configuration object that defines how and at what intervals a node is pinged to determine if it is up or down. Once a monitor is defined, instances of the monitor are created for a node or nodes, one instance per node, using the bigpipe node command.

Showing, disabling, and deleting monitors

There are monitor commands for showing, disabling, and deleting monitors.

To show monitors

You can display a selected monitor or all monitors using the bigpipe monitor show command:

b monitor <name> show

b monitor show all

To disable a monitor or monitor instance

All monitors and monitors instances are enabled by default. You can disable a selected monitor or monitor instance, which effectively removes the monitor or instance from service. To disable a monitor and all of its instances, use the bigpipe monitor <name> disable command:

b monitor <name> disable

To disable a monitor instance, use the bigpipe monitor instance <add:port> disable command:

b monitor instance <addr:port> disable

To re-enable a disabled monitor or monitor instance

Disabled monitors and instances may be re-enabled as follows:

b monitor <name> enable

b monitor instance <addr:port> enable

To delete monitors

You can delete a monitor with no existing node associations and no references in a monitor rule. To delete a monitor, use the bigpipe monitor <name> delete command:

b monitor my_http delete

If the monitor has instances, the instances must first be deleted using the bigpipe node <addr:port> monitor delete command. (Refer to To show associations, on page 2-44 and To delete associations, on page 2-44).

Monitor templates

A monitor is configured based on a monitor template contained in the file /etc/base_monitors.conf. Each monitor template a has monitor type corresponding to a service type, such as http, https, ftp, tcp, which the template usually takes as its name as well. The monitor templates may be grouped into three categories: simple monitors, EAV monitors, and ECV monitors. Each template has its own set of configurable attributes. Each of these attributes has a default value specified in the monitor template. As an example, the monitor template icmp in /etc/default_monitors.conf is shown in Figure 2.4.

Figure 2.4 Sample monitor template

 monitor type icmp {
interval 5
timeout 16
dest *
}

icmp is the template used for the default monitor in the BIG-IP Controller and has three attributes, interval, timeout and dest, each with a default value. (All monitor templates have these three basic attributes. As will be seen, other monitor templates have additional attributes as required by the service type.) Only those attributes that are to be changed for the custom monitor being defined are included in the command syntax. For example:

b monitor my_icmp { use icmp interval 10 timout 20 }

This command creates the entry in bigip.conf shown in Figure 2.5.

Figure 2.5 Monitor entry in bigip.conf

 monitor my_icmp{
use icmp
interval 10
timout 20
}

Once the custom monitor exists, you can associate it with a node or a series of nodes using the bigpipe node command.

b node 11.11.11.1 11.11.11.2 11.11.11.3 use monitor my_icmp

Monitor template attributes

Table 2.3 lists the monitor templates and shows the template-specific attribute sets for each.

The monitor templates
Name/Type Template-Specific Attribute Set
icmp none
tcp_echo transparent (optional)
tcp send ""
recv ""
transparent (optional) reverse (optional)
http username ""
password ""
send "GET /index.html"
recv ""
get (optional)
url (optional)
transparent (optional)
reverse (optional)
https username ""
password ""
send "GET /index.html"
recv ""
get (optional)
url (optional)
transparent (optional
reverse (optional
external run ""
args ""
ftp username "anonymous"
password "bigip1@internal"
get "/README"
url (optional)
nntp username ""
password ""
newsgroup "local"
pop3 username ""
password ""
smtp domain "bigip1@internal"
imap username ""
password ""
folder "INBOX"
message_num (optional)
radius username "username"
password "password"
secret "12345678"
ldap base "o=Org, c=US"
filter "sn=Doe"
sql username ""
password ""
database ""
https_443 dest *:443

Table 2.4 defines the attributes used in the templates.

Monitor attributes
Attribute Definition
interval <seconds> Ping frequency time interval in seconds.
timeout <seconds> Ping timeout in seconds.
dest <node_addr> Ping destination node. <node_address> Usually *:* for simple monitors, *:* for all others, causing the monitor instance to ping the address or address:port for which it is instantiated. Specifying address and/or port forces the destination to that address/port.
send <string> Send string for ECV. Default send and recv values are empty (""), matching any string.
recv <string> Receive expression for ECV. Default send and recv values are empty (""), matching any string.
get <string> For the http and https monitorsget replaces the recv statement, automatically filling in "GET". For the ftp monitor get can be used to specify a full path to a file. L. This will automatically fill in dest.
url For the http and https, and ftp monitors, url replaces the recv statement, supplying a URL and automatically fill in dest.with the URL address.
reverse A mode that sets the node down if the received content matches the recv string.
transparent A mode that forces pinging through the node to the dest address for transparent nodes, such as firewalls.
run <program> An external user-added EAV program.
args <program_args> List of command line arguments for external program. args are quoted strings set apart by spaces.
username <username> Username for services with password security. For ldap this is a distinguished name (an LDAP-format username).
password <password> Password for services with password security.
newsgroup <newsgroup> Newsgroup, for type nntp EAV checking only
database <database> Database name, for type sql EAV checking only.
domain <domain_name> Domain name, for type smtp EAV checking only
secret Shared secret for radius EAV checking only.
folder Folder name for imap EAV checking only.
message_num optional message number for imap EAV checking only
base Starting place in the LDAP hierarchy from which to begin the query, for ldap EAV checking only.
filter LDAP- format key of what is to be searched for, for ldap EAV checking only.

Send, receive and get statements

The ECV monitor templates http, https, and tcp have the attributes send and recv for the send string and receive expression, respectively.

The most common send string is "GET /" which simply retrieves a default HTML page for a web site. To retrieve a specific page from a web site, simply enter a fully qualified path name:

"GET /www/support/customer_info_form.html"

The receive expression is the text string the monitor looks for in the returned resource. The most common receive expressions contain a text string that would be included in a particular HTML page on your site. The text string can be regular text, HTML tags, or image names.

The sample receive expression below searches for a standard HTML tag.

"<HEAD>"

You can also use the default null recv value "". In this case, any content retrieved is considered a match. If both send and recv are left empty, only a simple connection check is performed.

For http and ftp, the special attributes get or url may be used in place of send and recv statements. get takes the full path to the file as a value and automatically fills in the dest value with the address the path resolves to. The following two statements are equivalent:

send "GET/"

get "/"

url takes the URL as a value and automatically fills in the dest value with the address the URL resolves to. The URL is then resolved to supply the dest address automatically. The third statement below is equivalent to the first two combined:

dest 198.192.112.13:22

get "/"

url "ftp://www.my_domain.com/"

Transparent and reverse modes

The ECV monitors have optional keywords transparent and reverse. (transparent is also used by the simple monitor template tcp_echo.) The normal and default mode for a monitor is to ping the dest node by an unspecified route and to mark the node up if the test is successful. There are two other modes, transparent and reverse.

In transparent mode, the monitor is forced to ping through the node it is associated with, usually a firewall, to the dest node. (In other words, if there are two firewalls in a load balancing pool, the destination node will always be pinged through the one specified and not through the one picked by the load balancing method.) In this way, the transparent node is tested as well.

In reverse mode, the monitor marks the node down when the test is successful. For example, if the content on your web site home page is dynamic and changes frequently, you may want to set up a reverse ECV service check that looks for the string "Error". A match for this string would mean that the web server was down. Transparent mode can also be used with the monitor template tcp_echo.

Testing SQL service checks

SQL service checks may require manually testing before being implemented in a monitor, as follows:

cd /usr/local/lib/pingers

./tdslogin 192.168.1.1 1433 mydata user1 mypass1

Replace the IP address, port, database, user, and password in this example with your own information.

You should receive the message:

Login succeeded!

If you receive the connection refused message, verify that the IP and port are correct.

If you are still having trouble, you should verify that you can log in using another tool. For example, if you have Microsoft NT SQL Server version 6.5, there is a client program ISQL/w included with the SQL software. This client program performs simple logins to SQL servers. Use this program to test whether you can login using the ISQL/w program before attempting logins from the BIG-IP Controller.

On the SQL Server, you can run the SQL Enterprise Manager to add logins. When first entering the SQL Enterprise Manager, you may be prompted for the SQL server to manage.

You can register servers by entering the machine name, user name, and password. If these names are correct, the server will be registered and you will be able to click an icon for the server. When you expand the subtree for the server, there will be an icon for Logins.

Underneath this subtree, you can find the SQL logins. Here, you can change passwords or add new logins by right-clicking the Logins icon. Click this icon to open an option to Add login. After you open this option, enter the user name and password for the new login, as well as which databases the login is allowed to access. You must grant the test account access to the database you specify in the EAV configuration.

Running user-added EAVs

You may add your own pingers to those contained in /user/local/lib/pingers. For running these added programs, the monitor template external is used. The program is specified as the value or the attribute run. The monitor will look for the run program in /user/local/lib/pingers. If the program resides elsewhere, a fully qualified pathname must be entered. Any command line arguments to be used with the program are entered as args values. For example, suppose the program my_pinger is to be run with a -q option, so that it would be entered on a command line as follows:

my_pinger -q

This monitor might be specified as follows:

monitor custom {use external run "my_pinger" args "-q"}

Alternatively, you may pass arguments to the external monitor as environment variables. For example, you might want to enter this command:

/var/my_pinger /www/test_files/first_test

This could be specified in the conventional manner:

b monitor custom { use external run "/var/my_pinger" args "www/test_files/first_test" }

It could also be specified in this way:

b monitor custom { use external run "/var/my_pinger" DIRECTORY " "www/test_files" FILE "first_test" }

This defines the monitor as shown in Figure 2.6.

Figure 2.6 Monitor definition for external pinger

 monitor custom { 
use external
run "/var/my_pinger"
DIRECTORY "www/test_files"
FILE "first_test"
}

The custom monitor requirements free the monitor definition from the rigidity of a strictly ordered command line entry. The arguments are now order-independent and may be used or ignored by the external executable.

Node and port aliasing

Usually the health of a node is checked by pinging that node. For this reason the dest attribute is usually set to "*" or "*:*". This will cause the instance of the monitor created for that node to take the address and port of the node as its destination. Suppose, for example, that the following command were entered:

b node 11.11.11.1:80 11.11.11.2:80 11.11.11.3:80 use monitor my_tcp

Assuming the dest attribute on the monitor was left at the default *:*, this will create three monitor instances with the following destinations:

11.11.11.1:80

11.11.11.2:80

11.11.11.3:80

An explicit dest value is used only to force the instance destination to a specific address or port which may not be that of the node. This will cause the monitor to ping to that forced destination by an unspecified path. (If it is necessary to ping the forced destination through the node, as when a router address is checked through a firewall, then the transparent attribute is used. This applies only to the ECV monitors and to tcp_echo.) Thus, for the example above, an explicit dest value of *:443, would create three instances of the monitor with the following destinations:

11.11.11.1:443

11.11.11.2:443

11.11.11.3:443

This is referred to as port aliasing. The node itself can also be aliased by assigning an explicit node address to dest. For example, if dest were set to 11.11.11.5:*, the monitor instances created for nodes 11.11.11.1:80, 11.11.11.2:80, 11.11.11.3:80 and 11.11.11.4:80 would have the following destinations:

11.11.11.5:80

11.11.11.5:80

11.11.11.5:80

Logical grouping

In the example above, only one monitor, my_tcp, has been associated with the nodes. You may associate more than one monitor. This creates a rule, and the node will be marked down if the rule evaluates to false. The most common example is use of an HTTP monitor and an HTTPS monitor:

node 11.11.11.1:80 11.11.11.2:80 11.11.11.3:80 use monitor my_http and my_https

Logical groupings must be logical, which means that the monitors themselves must be configured with the grouping in mind. In this case, monitor my_http would need to have a dest value of *:* and monitor my_https would need to have a dest value of *:443. This would cause the my_http monitor instances to ping the port 80's of each address and the my_https monitor instances to ping the port 443's of each address. If the dest values of both monitors were set to *:*, then both monitor instances would try to ping port 80. This would both defeat the purpose of the HTTPS monitor and cause an automatic failure, since two monitors would be trying to ping the same address and port simultaneously.

Using wildcards to specify node addresses and ports

The wildcard * can be used to specify node addresses and ports. For example, if a monitor instance of my_tcp_echo were to be created for port 80 on all nodes being load balanced by the BIG-IP, this could be done as follows:

b node *:80 use monitor my_tcp_echo

load the BIG-IP Controller configuration from <file_name> without resetting the current configuration.

-n

b -n

Use the -n option in combination with other commands, such as bigpipe virtual, to display services and IP addresses numerically rather than by service name and hostname, respectively. For example, type the following command to display services numerically:

b -n virtual

Figure 2.7 shows an example of output that uses IP address instead of host names.

Figure 2.7 The output of bigpipe -n virtual

 virtual +------> 11.100.1.1          UNIT 1     
| (cur, max, limit, tot) = (0, 0, 0, 0)
| (pckts,bits) in = (0, 0), out = (0, 0)
+---+--> SERVICE 80 UP
| (cur, max, limit, tot) = (0, 0, 0, 0)
| (pckts,bits) in = (0, 0), out = (0, 0)
MEMBER 11.12.1.100:80 UP
(cur, max, limit, tot) = (0, 0, 0, 0)
(pckts,bits) in = (0, 0), out = (0, 0)

nat

b nat <orig_addr> to <trans_addr> [unit <unit ID>]
b nat <orig_addr> [...<orig_addr>] delete
b nat [<trans_addr> [...<trans_addr>] ] show | delete
b nat [<orig_addr> [...<orig_addr>] ] show | delete
b nat [<orig_addr>...] stats reset
b nat <orig_addr> vlans <vlan_list> enable | disable
b nat <orig_addr> vlans delete all
b nat <orig_addr> vlans show
b nat <orig_addr> arp [enable|disable|show]

Defines an IP address, routable on the external network, that a node can use to initiate connections to hosts on the external network and receive direct connections from clients on the external network. The NAT (Network Address Translation) command defines a mapping between the IP address of a server behind the BIG-IP Controller <orig_addr> and an unused routable address on the network in front of the BIG-IP Controller <trans_addr>.

Defining a NAT

A NAT definition maps the IP address of a node <orig_addr> to a routable address on the external interface <trans_addr>, and can include an optional interface and netmask specification.

To define a NAT

Use the following syntax to define a NAT:

b nat <orig_addr> to <trans_addr> [vlan <vlan_name> disable | enable] [unit <unit ID>]

To delete NATs

Use the following syntax to delete one or more NATs from the system:

b nat <orig_addr> [...<orig_addr>] delete

To display status of NATs

Use the following command to display the status of all NATs included in the configuration:

b nat show

See Figure 2.8 for the output when you display the status of a NAT. Use the following syntax to display the status of one or more selected NATs:

b nat <orig_addr> [...<orig_addr>] show

Figure 2.8 Output when you display the status of a NAT

 NAT { 10.10.10.3 to 9.9.9.9 }    
(pckts,bits) in = (0, 0), out = (0, 0)
NAT { 10.10.10.4 to 12.12.12.12
netmask 255.255.255.0 broadcast 12.12.12.255 }
(pckts,bits) in = (0, 0), out = (0, 0)

To reset statistics for a NAT

Use this command to reset the statistics for an individual NAT:

b nat [<orig_addr>] stats reset

Use the following command to reset the statistics for all NATs:

b nat stats reset

Additional Restrictions

The nat command has the following additional restrictions:

  • The IP address defined in the <orig_addr> parameter must be routable to a specific server behind the BIG-IP Controller.
  • You must delete a NAT before you can redefine it.
  • The interface for a NAT may only be configured when the NAT is first defined.

Disabling VLANs for a NAT

A NAT is mapped by default to all VLANs on the internal and external networks of the BIG-IP Controller. Any VLANs to which the NAT is not to be mapped must be explicitly disabled using the vlan <vlan_name> disable syntax.

Viewing a controller's unit ID number

You can use the unit <unit ID> parameter to specify the controller to which this NAT applies in an active-active redundant system.

Disabling ARP requests

By default, the BIG-IP controller responds to ARP requests for the NAT address and sends a gratuitous ARP request for router table update. If you want to disable the NAT address for ARP requests, you must specify arp disable.

node

b node <node_ip>[:<service>]... enable | disable
b node <node_ip>[:<service>... show
b node <node_ip>[:<service>]... limit <max_conn>
b node [<node_ip>:<service>]... stats reset
b node <node_ip>[:service] up | down
b node <node_ip>[:<service>] monitor use <monitor_name> [and <monitor_name]...
b node [<node_ip>[:<service>]] monitor show | delete
b node <node_ip>[<node_ip>]... virtual | actual

Displays information about nodes and allows you to set properties for nodes, and node addresses. Nodes may be identified using wildcard notation. Thus * represents all nodes on the network, *.80 represents all port 80 nodes, 11.11.11.1:* represents all nodes with address 11.11.11.1.

To enable and disable nodes and node addresses

A node must be enabled in order to accept traffic. When a node is disabled, it will allow existing connections to time out and accept new connections only if they belong to an existing session. (In this way a disabled node differs from a node that is set down. The down node will allow existing connections to time out but will accept no new connections.)

To enable a node address, use the node command with a node address and the enable option:

b node 192.168.21.1 enable

To disable a node address, use the node command with the disable option:

b node 192.168.21.1 disable

To enable one or more node addresses, use the node command with a node address and port, and the enable option:

b node 192.168.21.1:80 enable

To disable one or more node addresses, use the node command with the disable option:

b node 192.168.21.1:80 disable

Marking nodes and node ports up and down

A node must be marked up in order to accept traffic. When a node is marked down it will allow existing connections to time out but will accept no new connections.

To mark a node address down, use the node command with a node address and the down option. (Note that marking a node down prevents the node from accepting new connections. Existing connections are allowed to complete.)

b node 192.168.21.1 down

To mark a node address up, use the node command with the up option:

b node 192.168.21.1 up

To mark a service down, use the node command with a node address and port, and the down option. (Note that marking a port down prevents the port from accepting new connections. Existing connections are allowed to complete.)

b node 192.168.21.1:80 down

To mark a port up, use the node command with up option:

b node 192.168.21.1:80 up

Setting connection limits for nodes and node addresses

Use the following command to set the maximum number of concurrent connections allowed on a node:

b node <node_ip>[:<service>][...<node_ip>[:<service>]] \
limit <max conn>

Note that to remove a connection limit, you also issue the preceding command, but set the <max conn> variable to 0 (zero). For example:

b node 192.168.21.1:80 limit 0

The following example shows how to set the maximum number of concurrent connections to 100 for a list of node addresses:

b node 192.168.21.1 192.168.21.1 192.168.21.1 limit 100

To remove a connection limit, you also issue this command, but set the <max conn> variable to 0 (zero).

Displaying status of all nodes

The following command displays the status of all nodes defined on the controller.

b node show

When you issue the node show command, the BIG-IP Controller displays the node status (up or down, or unchecked), and a node summary of connection statistics, which is further broken down to show statistics by port. The report shows the following information:

  • current number of connections
  • total number of connections made to the node since last boot
  • maximum number of concurrent connections since the last boot
  • concurrent connection limit on the node
  • total number of connections made to the node since last boot
  • total number of inbound and outbound packets and bits

    Figure 2.9 shows the output of this command.

Figure 2.9 Node status and statistics

 bigpipe node 192.168.200.50:20    
NODE 192.168.200.50 UP
| (cur, max, limit, tot) = (0, 0, 0, 0)
| (pckts,bits) in = (0, 0), out = (0, 0)
+- PORT 20 UP
(cur, max, limit, tot) = (0, 0, 0, 0)
(pckts,bits) in = (0, 0), out = (0, 0)

Displaying the status of individual nodes and node addresses

Use this command to display status and statistical information for one or more node addresses:

b node 192.168.21.1 show

The command reads the status of each node address, the number of current connections, total connections, and connections allowed, and the number of cumulative packets and bits sent and received.

Use the following command to display status and statistical information for one or more specific nodes:

b node 192.168.21.1:80 show

Resetting statistics for a node

Use the following command to reset the statistics for an individual node address:

b node [<node_ip>:<service>] stats reset

Associating a health monitor with a node

Use the following command to associate a health monitor with a node:

node <node> monitor use <monitor>

A monitor can be placed on multiple nodes and a node can have multiple monitors placed on it. To place a monitor on multiple nodes:

node <node_list> monitor use <monitor>

To add multiple monitors to a node

To place multiple monitors on a node:

node <node> monitor use <monitor1> and <monitor2>...

For more information on using the node command with health monitors, refer to monitor, on page 2-23.

To show associations

You can display a selected node association or all node associations using the bigpipe node monitor show command:

b node monitor show

b node <addr:port> monitor show

To delete associations

You can delete a selected node association or all node associations using the bigpipe node monitor delete command:

b node monitor delete

b node <addr:port> monitor delete

In deleting specific monitor instances, it is important to consider how the association was created and therefore how it exists in the /config/bigip.conf file. For example, if an association exists through aliasing, the delete cannot be performed on the alias, but instead on the node that was actually associated. Or, if a monitor instance was created using wildcard address or port, the wildcard must be deleted.

For example, if multiple associations were created by entering b node *:80 monitor use my_tcp_echo, you would delete it by typing:

b node *:80 monitor delete

pool

b pool <pool-_name> { lb_method <lb_method_specification> <member_definition>
b pool <pool-_name> { lb_method <lb_method_specification> persist_mode <persist_mode_specification> <member definition>... }
b pool <pool-_name> { lb_method <lb_method_specification> min_active_members <min_value> <member definition>... }
b pool <pool-_name> { lb_method <lb_method_specification> <member_definition> fallback <host>
b pool <pool_name> add { <member definition>... }
b pool <pool_name> delete { <member definition>... }
b pool <pool_name> modify { [lb_method <lb_method_specification>] [persist_mode <persist_mode_specification>] <member definition>... }
b pool <pool_name> delete
b pool [<pool_name>] show
b pool <pool_name> lb_method show
b pool <pool_name> persist dump
b pool <pool_name> persist dump mirror
b pool <pool_name> sticky clear
b pool <pool_name> stats reset

Use the pool command to create, delete, modify, or display the pool definitions on the BIG-IP Controller. Use pools to group members together with a common load balancing mode and persistence mode. For additional information about configuring pools, see the BIG-IP Administrator Guide, Working with Intelligent Traffic Control.

Creating a pool

To create a pool use the following syntax:

b pool <pool_name> {lb_method <lb_method_specification> [persist_mode <persist_mode_specification>] <member_definition>... member <member_definition>}

Each of the elements included in the pool command is described in Table 2.6, on page 2-47. You can also find detailed information about setting up persistence with pools in Setting up persistence for a pool, on page 1-22.

Specifying load balancing mode

The load balancing modes are specified as values of the attribute lb_mode. The lb_mode values are shown in Table 2.5.

Load balancing modes
Mode Name lb_mode attribute value
Round Robin rr or omit lb_mode specification
Ratio

ratio

Ratio Member

ratio_member

Fastest fastest
Fastest Member fastest_member
Least Connections least_conn
Least Connections Member least_conn_member

Observed

observed

Observed Member observed_member
Predictive predictive
Predictive Member predictive_member
Dynamic Ratio dynamic_ratio

For more information about the load balancing modes, refer to Proxies, on page 1-73.

Table 2.6 shows additional elements available for the pool command.

The elements you can use to construct a pool
Pool Element Description
Pool name A string from 1 to 31 characters, for example: new_pool
Member definition member <ip address>:<service> [ratio <value>] [priority <value>]
lb_method_specificaton lb_method [ rr | ratio | fastest | least_conn | predictive | observed | ratio_member | least_conn_member |observed_member | predictive_member | dynamic_ratio ]
min_value minimum number of members that must be active for a priority group to remain active.
persist_mode_specification persist_mode [ cookie | simple | ssl | sticky ]

Deleting a pool

To delete a pool, use the following syntax:

b pool <pool_name> delete

All references to a pool must be removed before a pool can be deleted.

Modifying pools

You can use the command line to add or delete members from a pool. You can also modify the load balancing mode for a pool from the command line. To add a new member to a pool use the following syntax:

b pool <pool_name> add { 1.2.3.2:telnet }

To delete a member from a pool use the following syntax:

b pool <pool_name> delete { 1.2.3.2:telnet }

Displaying pool statistics

Use the following syntax to display all pools:

b pool show

Use the following syntax to display a specific pool:

b pool <pool_name> show

Activating HTTP cookie persistence

The following syntax activates HTTP cookie persistence

b pool <pool_name> { <lb_method_specification> persist_mode cookie cookie_mode passive <member definition> }

Note: The <timeout> value is not used in Passive mode.

Configuring the hash cookie persistence option

If you specify hash mode, the hash mode consistently maps a cookie value to a specific node. When the client returns to the site, the BIG-IP Controller uses the cookie information to return the client to a given node. With this mode, the web server must generate the cookie. The BIG-IP Controller does not create the cookie automatically like it does with Insert mode.

To configure hash cookie persistence

Use the following syntax to configure the hash cookie persistence option:

b pool <pool_name> { <lb_method_specification> persist_mode cookie cookie_mode hash cookie_hash_name <cookie_name> cookie_hash_offset <cookie_value_offset> cookie_hash_length <cookie_value_length> <member definition> }

The <cookie_name>, <cookie_value_offset>, and <cookie_value_length> values are described in Table 2.7.

The cookie hash mode values
Hash mode values Description

<cookie_name>

This is the name of an HTTP cookie being set by a Web site.

<cookie_value_offset>

This is the number of bytes in the cookie to skip before calculating the hash value.

<cookie_value_length>

This is the number of bytes to use when calculating the hash value.

Activating Insert HTTP cookie persistence

If you specify Insert mode, the BIG-IP Controller inserts a cookie from the server in the header of the HTTP response with information about the server to which the client connects. The cookie is named BIGipServer<pool_name>, and it includes the address and port of the server handling the connection. The expiration date for the cookie is set based on the timeout configured on the BIG-IP Controller.

To activate Insert mode

To activate Insert mode from the command line, use the following syntax:

b pool <pool_name> { <lb_method_specification> persist_mode cookie cookie_mode insert cookie_expiration <timeout> <member definition> }

The <timeout> value for the cookie is written using the following format:

<days>d hh:mm:ss

Activating Rewrite mode cookie persistence

If you specify Rewrite mode, the BIG-IP Controller intercepts a Set-Cookie, named BIGipCookie, sent from the server to the client and overwrites the name and value of the cookie. The new cookie is named BIGipServer<pool_name> and it includes the address and port of the server handling the connection.

To use Rewrite mode, you must set up the cookie created by the server. For Rewrite mode to work, the BIG-IP Controller needs a blank cookie coming from the web server to rewrite. With Apache variants, you can add the cookie to every web page header by adding an entry in the httpd.conf file:

Header add Set-Cookie BIGipCookie=00000000000000000000000000000000000000000...

The cookie should contain a total of 120 zeros.

Warning: For backward compatibility, the blank cookie can contain only 75 zeros. However, cookies of this size do not allow you to use rules and persistence together.

To activate Rewrite mode

The following syntax activates Rewrite mode.

b pool <pool_name> { <lb_method_specification> persist_mode cookie cookie_mode rewrite cookie_expiration <timeout> <member definition> }

The <timeout> value for the cookie is written using the following format:

<days>d hh:mm:ss

Activating Passive mode cookie persistence

If you specify Passive mode, the BIG-IP Controller does not insert or search for blank Set-Cookies in the response from the server. It does not try to set up the cookie. In this mode, BIG-IP Controller assumes that the server provides the cookie formatted with the correct node information and timeout.

In order for Passive mode to work, a cookie needs to come from the web server with the appropriate node information in the cookie. With Apache variants, you can add the cookie to every web page header by adding an entry in the httpd.conf file:

Header add Set-Cookie: "BIGipServerMY_POOL=184658624.20480.000; expires=Sat, 19-Aug-2000 19:35:45 GMT; path=/"

In this example, my_pool is the name of the pool that contains the server node, 184658624 is the encoded node address and 20480 is the encoded port.

The equation for an address (a.b.c.d) is:

d*256^3 + c*256^2 + b*256 +a

The way to encode the port is to take the two bytes that store the port and reverse them. So, port 80 becomes 80 * 256 + 0 = 20480. Port 1433 (instead of 5 * 256 + 153) becomes 153 * 256 + 5 = 39173.

After you set up the cookie created by the web server, you must activate Passive mode on the BIG-IP Controller.

Activating sticky persistence

Use the following command to enable sticky persistence for a pool:

b pool <pool_name> modify { persist_mode sticky <enable | disable> sticky_mask <ip address> }

Use the following command to disable sticky persistence for a pool:

b pool <pool_name> modify { persist_mode sticky disable sticky_mask <ip address> }

Use the following command to delete sticky entries for the specified pool:

b pool <pool_name> sticky clear

Activating SSL persistence

Use the following syntax to activate SSL persistence from the command line:

b pool <pool_name> modify { persist_mode ssl ssl_timeout <timeout> }

For example, if you want to set SSL persistence on the pool my_pool, type the following command:

b pool my_pool modify { persist_mode ssl ssl_timeout 3600 }

To apply a simple timeout and persist mask

The complete syntax for the command is:

b pool <pool_name> modify { [<lb_method_specification>] persist_mode simple simple_timeout <timeout> simple_mask <dot_notation_longword> }

For example, the following command would keep persistence information together for all clients within a C class network that connect to the pool classc_pool:

b pool classc_pool modify { persist_mode simple simple_timeout 1200 simple_mask 255.255.255.0 }

You can turn off a persist mask on a pool by using the none option in place of the simple_mask mask. To turn off the persist mask that you set in the preceding example, use the following command:

b pool classc_pool modify { simple_mask none }

To display persistence information for a pool

To show the persistence configuration for the pool:

b pool <pool_name> persist show

To display all persistence information for the pool named classc_pool, use the show option:

b pool classc_pool persist show

Specifying priority based member activation

You can load balance traffic across all members of a pool or only members that are currently activated according to their priority number. In priority based member activation, each member in a pool is assigned a priority number that places it in a priority group designated by that number. With all nodes up, the BIG-IP Controller distributes connections to all nodes in the highest priority group only (the group designated by the highest priority number). The min_active_members value determines the minimum number of members in that must remain up for traffic to be confined to that group. If the number of up nodes in the highest priority group goes below the minimum number, the controller distributes traffic to the next higher priority group, and so on.

An example is shown in Figure 2.10.

Figure 2.10 A pool configured for priority based member activation

 pool my_pool {
lb_mode fastest
min_active_members 2
member 10.12.10.1:80 priority 3
member 10.12.10.2:80 priority 3
member 10.12.10.3:80 priority 3

member 10.12.10.4:80 priority 2
member 10.12.10.5:80 priority 2
member 10.12.10.6:80 priority 2

member 10.12.10.7:80 priority 1
member 10.12.10.8:80 priority 1
member 10.12.10.9:80 priority 1
}

The configuration shown above has three priority groups, 3, 2, and 1. Connections are first distributed to all nodes with priority 3. If fewer than two priority 3 nodes are up, traffic is directed to the priority 2 nodes. If both the priority 3 group and the priority 2 group have fewer than two nodes up, traffic is directed to the priority 1 group. The BIG-IP Controller continuously monitors the higher priority groups, and each time a higher priority group once again has the minimum number of up nodes, the BIG-IP Controller again limits traffic to that group.

Specifying a fallback host for HTTP redirect

You can configure a pool with a fallback host for HTTP redirect. If all members of the pool are down, the HTTP request is then redirected to that fallback host with the HTTP reply Status Code 302 Found. The fallback host may be specified as an IP address or as a fully qualified domain name. In either case it may include a port number, as shown in Figure 2.11.

Figure 2.11 A pool that specifies a fallback host

 pool my_pool {
member 10.12.10.1:80
member 10.12.10.2:80
member 10.12.10.3:80
fallback redirector.sam.com

The example above redirects the request to http://redirector.sam.com.

Note: The HTTP redirect mechanism is not a load balancing option. There is no presumption that the redirect URL will represent a virtual server pointing to the requested HTTP content.

The following table shows how different fallback host specifications would be resolved.

Fallback host name resolution
Requested URL <host> value Redirect URL
http://www.sam.com/ redirector.sam.com http://redirector.sam.com/
http://www.sam.com/ redirector.sam.com:80 http://redirector.sam.com:80/
http://www.sam.com/80 redirector.sam.com http://redirector.sam/
http://www.sam.com:8001/ redirector.sam.com:8002 http://redirector.sam.com:8002/
http://www.sam.com/sales redirector.sam.com http://redirector.sam.com/sales
http://www.sam.com/sales 192.168.101.5 http://192.168.101.5/sales
http://www.sam.com f5.com http://www.f5.com

proxy

b proxy <ip>:<service> [<unit id>] target <server | virtual> <ip>:<service> ssl enable key <key> cert <cert>
b proxy <ip>:<service> [<unit id>] target <server | virtual> <ip>:<service> akamaize enable
b proxy <ip>:<service> enable
b proxy <ip>:<service> disable
b proxy <ip>:<service> delete
b proxy <ip>:<service> show
b proxy <ip>:<service> lasthop pool <pool_name>
b proxy <addr:service> vlans <vlan_list> enable|disable
b proxy <addr:service> vlans show
b proxy <addr:service> arp [enable|disable]

Use the proxy command to create, delete, modify, or display the SSL or content converter gateway definitions on the BIG-IP Controller. For detailed information about setting up the SSL Accelerator feature, see the BIG-IP Administrator Guide, Configuring an SSL Accelerator. For detailed information about setting up the content converter feature, see the BIG-IP Administrator Guide, Configuring a Content Converter.

Creating an SSL gateway

Use the following command syntax to create an SSL gateway:

b proxy <ip>:<service> [vlan <vlan_name> disable | enable] [<unit id>] target <server | virtual> <ip>:<service> ssl enable key <key> cert <cert>

For example, from the command line you can create an SSL gateway that looks like this:

b proxy 10.1.1.1:443 unit 1 { target virtual 20.1.1.1:80 ssl enable key my.server.net.key cert my.server.net.crt }

Note that when the configuration is written out in the bigip.conf file, the line ssl enable is automatically added. When the SSL gateway is written in the /config/bigip.conf file, it looks like the sample in Figure 2.12.

Figure 2.12 An example SSL gateway configuration

 proxy 10.1.1.1:443 3.1 unit 1 {     
target virtual 20.1.1.1:80
ssl enable
key my.server.net.key
cert my.server.net.crt
}

Configuring a content converter

Configuring a content converter consists of two steps. First, configure the Akamai on-the-fly conversion software for your network. Second, create the content converter gateway using the proxy command. ( If the software is not configured first, the attempt to create a proxy will fail.)

To configure the on-the-fly conversion software

  1. On the BIG-IP Controller, bring up the Akamai configuration file /etc/config/akamai.conf in an editor like vi or pico.
  2. Under the heading [CpCode] you will find the text default=XXXXX. Replace the Xs with the CP code provided by your Akamai Integration Consultant as shown below. (When contacting your consultant, specify that you are using the BIG-IP on-the-fly Akamaizer based on Akamai's 1.0 source code.)

    default=773

  3. Under the heading [Serial Number] you will find the text staticSerialNumber=XXXXX. Replace the Xs with the static serial number provided by your Akamai Integration Consultant as shown below.

    staticSerialNumber=1025

    Note: This value needs to be set only if algorithm under [Serial Number] is set to static, as it is in the default file. If you choose to set algorithm to deterministicHash or deterministicHashBounded, the static serial number is not applicable. If you are unsure what method to select, contact your Akamai Integration Consultant.

  4. Under the heading [URLMetaData] you will find the text httpGetDomains=XXXXX. Replace the Xs with domain name of the content to be converted, as shown below.

    httpGetDomains=www.f5.com

  5. Save and exit the file.

To create the content converter gateway

Use the following command syntax to create an content converter gateway:

b proxy <ip>:<service> target server target <server | virtual> <ip>:<service> akamaize enable

For example, from the command line you can create an SSL gateway that looks like this:

b proxy 10.1.1.1:443 unit 1 target virtual 20.1.1.1:80 akamaize enable

Note that when the configuration is written out in the bigip.conf file, the line akamaize enable is automatically added. When the content converter gateway is written in the /config/bigip.conf file, it looks like the sample in Figure 2.13.

Figure 2.13 An example content converter gateway configuration

 proxy 10.1.1.1:443 3.1 unit 1 {     
target virtual 20.1.1.1:80
akamaize enable
}

Disabling ARP requests

By default, the BIG-IP Controller responds to ARP requests for proxy address and sends a gratuitous ARP request for router table update. If you want to disable the proxy address for ARP requests, you must specify arp disable.

Enabling, disabling, or deleting a gateway

You can enable, disable, or delete a gateway with the following syntax:

b proxy <ip>:<service> enable

b proxy <ip>:<service> disable

b proxy <ip>:<service> delete

If you want to enable the SSL gateway 209.100.19.22:443, you might type the following command:

b proxy 209.100.19.22:443 enable

If you want to disable the SSL gateway 209.100.19.22:443, you could type the following command:

b proxy 209.100.19.22:443 disable

For example, if you want to delete the SSL gateway 209.100.19.22:443, type the following command:

b proxy 209.100.19.22:443 delete

Disabling VLANs for a gateway

A gateway is mapped by default to all VLANs on the internal and external networks of the BIG-IP Controller. Any VLANs to which the gateway is not to be mapped must be explicitly disabled using the vlan <vlan_name> disable syntax.

Displaying gateway configuration information

Use the following syntax to view the configuration for the specified gateway:

b proxy <ip>:<service> show

For example, if you want to view configuration information for the SSL gateway 209.100.19.22:80, type the following command:

b proxy 209.100.19.22:80 show

Figure 2.14 is a sample output from the bigpipe proxy show command.

Figure 2.14 Output from the bigpipe proxy show command

     PROXY +---> 11.12.1.200:443 -- Originating Address -- Enabled   Unit 1     
| Key File Name balvenie.scotch.net.key
| Cert File Name balvenie.scotch.net.crt
| LastHop Pool Name
| SSL Encryption: enabled
| Akamiaize Content: disabled
+===> 11.12.1.111:80 -- Destination Address -- server

PROXY +---> 11.12.1.120:443 -- Originating Address -- Enabled Unit 1
| Key File Name balvenie.scotch.net.key
| Cert File Name balvenie.scotch.net.crt
| LastHop Pool Name
| SSL Encryption: enabled
| Akamiaize Content: disabled
+===> 11.12.1.111:80 -- Destination Address -- virtual

Adding a last hop pool to a gateway from the command line

In cases where you have more than one router sending connections to a BIG-IP Controller, connections are automatically sent back through the same router from which they were received when the auto_lasthop global variable is enabled, as it is by default. If the global auto_lasthop is disabled for any reason (for example, you may not want it for a virtual server), you can direct your replies to the last hop router using a last hop pool

To configure a last hop pool, you must first create a pool containing the router inside addresses. After you create the pool, use the following syntax to configure a last hop pool for a gateway:

b proxy <virt_ip>:<service> lasthop pool <pool_name>

For example, if you want to assign the last hop pool named ssllasthop_pool to the SSL gateway 11.12.1.200:443, type the following command:

b proxy 11.12.1.200:443 lasthop pool ssllasthop_pool

ratio

b ratio [<node_ip>] [node_ip> ...] show
b ratio <node_ip> [<node_ip>...] <weight>

For the Ratio load balancing mode, the command sets the weight or proportions for one or more node addresses.

Setting ratio weight for one or more node addresses

The default ratio setting for any node address is 1. If you use the Ratio (as opposed to Ratio Member) load balancing mode, you must set a ratio other than 1 for at least one node address in the configuration. If you do not change at least one ratio setting, the load balancing mode has the same affect as the Round Robin load balancing mode.

Use the following syntax to set the ratio for one or more node addresses:

b ratio <node_ip> [...<node_ip>] <weight>

For example, the following command sets the ratio weight to 3 for a specific node address:

b ratio 192.168.103.20 3

To display the ratio weights for node addresses

The following command displays the current ratio weight settings for all node addresses.

b ratio show

The command displays the output shown in Figure 2.15.

Figure 2.15 Ratio weights for node addresses

 192.168.200.51    ratio = 3    
192.168.200.52 ratio = 1

To display ratio weight for specific node addresses

Use the following syntax to display the ratio setting for one or more node addresses:

b ratio <node_ip> [...<node_ip>] show

Note: The <weight> parameter must be a whole number, equal to or greater than 1.

reset

b reset

Use the following syntax to clear the configuration values and counter values from memory:

b reset

Warning: Use this command with caution. All network traffic stops when you run this command.

Typically, this command is used on a standby BIG-IP Controller prior to loading a new /config/bigip.conf file that contains new service enable and timeout values.

For example, you can execute the following commands on a standby BIG-IP Controller:

b reset

b load <filename>

This sequence of commands ensures that only the values set in the <filename> specified are in use.

rule

b rule <rule_name> ' { <if statement> | <cache_statement} '
b rule <rule_name> delete
b rule [<rule_name>] show

Use the rule command to create, delete, or display the rules on the BIG-IP Controller. Rules allow a virtual server to access any number of pools on the BIG-IP Controller. For more detailed information about using rules, see Health monitors, on page 1-120.

Note: Before you define a rule, you must define the pool or pools that you want the rule to reference.

Creating rules

You can add rules by manually typing them into an existing /config/bigip.conf file. However, you can also use the bigpipe rule command to create, delete, or display rules. To create a rule with bigpipe, type the complete rule on the command line, without line breaks. For example, you can type in this rule:

b rule cgi_rule ' {if (http_uri ends_with "cgi") {use ( cgi_pool )} else {use ( default_pool )}} '

If the http_uri string ends with "cgi" then the members from cgi_pool are used for load balancing. If the http_uri string does not end with "cgi", then the members of default_pool are used for load balancing.

To delete a rule

You can delete a rule using the following syntax:

b rule <rule_name> delete

To display rules

Use the following syntax to display all rules:

b rule show

Use the following syntax to display a specific rule:

b rule <rule_name> show

Associating a rule with virtual server

You can associate a rule with a virtual server by using the following syntax:

bigpipe virtual <virt_ip>:<service> use rule <rule_name>

For example, if you want to associate the rule cgi_rule to the virtual server 10.20.2.101:http, type in the following command:

b virtual 10.20.2.101:http use rule cgi_rule

Rule elements

You can create a rule by combining a number of different elements. A simple rule could contain the following elements:

rule <rule_name> '{ if ( <variable> <binary_operator> "<literal>" ) { use ( <pool_name> ) } else { use ( <another_pool_name> ) } }'

For example, a rule named cgi_rule that sends CGI connections to a load balancing pool named cgi_pool, or HTTP connections to a pool named http_pool looks like this:

b rule cgi_rule ' {if (http_uri ends_with "cgi") {use ( cgi_pool )} else {use ( http_pool )}} '

Note: For more detailed information about using rules, see Health monitors, on page 1-120.

Table 2.9 lists all the elements you can use to create rules.

The elements you can use to construct rules
Element Description
rule definition

rule <rule_name '{ <if_statement> | <cache_statement> } '

if statement

if ( <expression> ) { <statement> }
[ { else <statement> } ] [ { else if <statement> } ]

expression

<literal>
<variable>
( <expression> )
exists <variable>
not <expression>
<expression> <binary_operator> <expression>

statement

<use_statement>
<if_statement>
discard
<cache_statement>

cache statement

cache ( <expression> ) { origin_pool <pool_name> cache_pool <pool_name> [ hot_pool <pool_name> ] [ hot_threshold <hit_rate> ] [ cool_threshold <hit_rate> ] [ hit_period <seconds> ][ content_hash_size <sets_in_content_hash> ] }

use statement

use ( <pool_name> )

IP protocol constants

UDP

TCP

literal

<regex_literal>
<string_literal>
<address_literal>

regular expression literal Is a string of 1 to 63 characters enclosed in quotes that may contain regular expressions
string literal Is a string of 1 to 63 characters enclosed in quotes
address literal

<dot_notation_longword> [netmask <dot_notation_longword>]

Dot notation longword

<0-255>.<0-255>.<0-255>.<0-255>

save

b save [ <filename> | - ]
b base save [ <filename> | - ]

The bigpipe save and base save write the current BIG-IP Controller configuration settings from memory to the configuration files named /config/bigip.conf and /config/bigip_base.conf. (/config/bigip.conf stores high level configuration settings, such as pools, virtual servers, NATs, SNATs, and proxies. /config/bigip_base.conf stores low level configuration settings, like, VLANs, non-floating self IP addresses, and interface settings.)

You can type b save <filename>, or a hyphen character (-) in place of a file name, to display the configuration on the standard output device.

b [base] save -

If you are testing and integrating BIG-IP Controllers into a network, you may want to use multiple test configuration files. Use the following syntax to write the current configuration to a file name that you specify:

b [base] save <filename>

For example, the following command saves the current configuration from memory to an alternate configuration file named /config/bigip.conf2.

b save /config/bigip.conf2

self

b self <addr> vlan <vlan_name> [ netmask <ip_mask> ][ broadcast <broadcast_addr>] [unit <id>]
b self <addr> floating enable | disable
b self <addr> delete
b self <addr> show
b self show
b self <addr> snat automap enable | disable

The self command defines a self IP address on a BIG-IP Controller. A self IP address is an IP address mapping to a VLAN or VLAN group and their associated interfaces on a BIG-IP Controller. A one true self IP address is assigned to each interface on the controller as part of first time boot configuration, and also a floating (shared) self IP address for controllers in a redundant pair. Additional self addresses may be created for health checking, gateway failsafe, routing, or other purposes. These additional self addresses are created using the self command.

Any number of additional self addresses may be added to a VLAN to create aliases. Example:

b self 11.11.11.4 vlan external

b self 11.11.11.5 vlan external

b self 11.11.11.6 vlan external

b self 11.11.11.7 vlan external

Also, any one self IP address may have floating enabled to create a floating self IP address that is shared by both units of a BIG-IP Controller redundant pair:

b self 11.11.11.8 floating enable

Assigning a self IP address to a VLAN automatically maps it to the VLAN's interfaces. Since all interfaces must be mapped to one and only one untagged VLAN, assigning a self IP address to an interface not mapped to an untagged VLAN produces an error message.

Self IP addresses and SNAT auto-mapping

The translation address for SNAT auto-mapping is determined by the enablement of self IP addresses on the external VLAN. For more information about SNAT auto-mapping, refer to Enabling and disabling SNAT auto-mapping, on page 2-101.

service

b service <service> [<service>...] limit <limit>
b service <service> [<service>...] tcp enable | disable
b service <service> [<service>...] timeout tcp <timeout>
b service <service> [<service>...] udp enable | disable
b service <service> [<service>...] timeout udp <timeout>
b service [<service>... ] show
b service [<service>... ] stats reset

Enables and disables network traffic on services, and also sets connection limits and timeouts. You can use port numbers or service names (for example, www, http, or 80) for the <service> parameter. Note that the settings you define with this command control the service for all virtual servers that use it. By default, all services are disabled.

A port is any valid port number, between 0 and 65535, inclusive, or any valid service name in the /etc/services file.

Setting connection limits on services

Use the following syntax to set the maximum number of concurrent connections allowed on a service. Note that you can configure this setting for one or more services.

b service <service> [...<service>] limit <max conn>

To turn off a connection limit for one or more services, use the same command, setting the <max conn> parameter to 0 (zero) like this:

b service <service> [...<service>] limit 0

Displaying service settings

Use the following command to display the settings for all services:

b service show

Use the following syntax to display the settings for a specific service or services:

b service <service> [...<service>] show

The system displays the output shown in Figure 2.16.

Figure 2.16 Service settings

 SERVICE 80 http tcp enabled timeout 1005 udp disabled timeout 60
(cur, max, limit, tot, reaped) = (0, 0, 0, 0, 0)
(pckts,bits) in = (0, 0), out = (0, 0)

Configuring TCP services

You can enable or disable TCP for specific services. The default setting for all services is disabled. Use the following syntax to enable TCP for one or more services:

b service <service> [...<service>] tcp enable

To disable TCP, use this syntax:

b service <service> [...<service>] tcp disable

To set the idle connection timeout for TCP traffic

To set the TCP timeout on one or more services, where the <seconds> parameter is the number of seconds before an idle connection is dropped, use the following syntax:

b service <service> [<service>...] timeout tcp <seconds>

For example, the following command sets the TCP timeout to 300 seconds for port 53:

b service 53 timeout tcp 300

To turn off TCP timeout for a service, use the above command, setting the <seconds> parameter to zero:

b service 53 timeout tcp 0

Configuring UDP services

You can enable or disable UDP for specific services. The default setting for all services is disabled. Use the following syntax to enable UDP for one or more services:

b service <service> [...<service>] udp enable

To disable UDP, use this syntax:

b service <service> [...<service>] udp disable

To set the idle connection timeout for UDP traffic

To set the UDP timeout on one or more services, where the <seconds> parameter is the number of seconds before an idle connection is dropped, use the following syntax:

b service <service> [<service>...] timeout udp <seconds>

For example, the following command sets the UDP timeout to 300 seconds for port 53:

b service 53 timeout udp 300

To turn off UDP timeout for a service, use the above command, setting the <seconds> parameter to zero:

b service 53 timeout udp 0

snat

b snat map <orig_ip> [...<orig_ip>] to <snat_ip><snat_ip> [unit <unit ID>] [netmask <ip>]
b snat map default to <snat_ip> [unit <unit ID>] [netmask <ip>]
b snat <snat_ip> [...<snat_ip>] delete | show
b snat default delete | show
b snat default dump [verbose]
b snat [<snat_ip> [...<snat_ip>] ] dump [verbose]
b snat globals show
b snat default show
b snat [<snat_ip> [...<snat_ip>] ] show
b snat [<orig_ip> [...<orig_ip>] limit <max_conn>
b snat limit <max_conn>
b snat default limit <max conn>
b snat <orig_ip> [...<orig_ip>] mirror enable | disable
b snat default mirror enable | disable
b snat <orig_ip> [...<orig_ip>] timeout tcp | udp <seconds>
b snat default timeout tcp | udp <seconds>
b snat <orig_ip> [...<orig_ip>] stats reset
b snat default stats reset
b snat <orig_ip> [...<orig_ip>]> disable | enable
b snat <snat_ip> [...<snat_ip>] vlans <vlan_list> disable | enable
b snat <snat_ip> [...<snat_ip>] vlans show
b snat <snat_ip> [...<snat_ip>] arp [enable|disable]

Defines one or more addresses that nodes can use as a source IP address when initiating connections to hosts on the external network. Note that clients cannot use SNAT addresses to connect directly to nodes.

Defining the default SNAT

Use the following syntax to define the default SNAT. If you use the netmask parameter and it is different from the external interface default netmask, the command sets the netmask and derives the broadcast address. You can use the unit <unit ID> parameter to specify a unit in an active-active redundant configuration.

b snat map default to <snat_ip> [vlan <vlan_name> disable | enable] [unit <unit ID>] [netmask <ip>]

Creating individual SNAT addresses

Use the following command syntax to create a SNAT mapping:

b snat map <node_ip> [...<node_ip>] to \
<snat_ip> [vlan <vlan_name> disable | enable] [unit <unit ID>] [netmask <ip>]

If the netmask is different from the external interface default netmask, the command sets the netmask and derives the broadcast address.

Creating a network SNAT address

You can specify a SNAT for which the original address is a network:

snat map 192.168.1.0 to 192.168.2.45

snat 192.168.1.0 netmask 255.255.255.0

This assigns all addresses in the Class C network 192.168.1 to SNAT 192.168.2.45. The assigning of a netmask to the original address is applicable when the original address is a network, which has zeros as its host portion.

SNAT auto-mapping

A VLAN may be mapped automatically to a SNAT address. This means that by enabling snat automap on an internal VLAN, a SNAT is performed on any connection made from that VLAN. For more information about SNAT auto-mapping, refer to Enabling and disabling SNAT auto-mapping, on page 2-101.

Deleting SNAT Addresses

The following syntax deletes a specific SNAT:

b snat <snat_ip> | default delete

Disabling VLANs for a SNAT

A SNAT is mapped by default to all VLANs on the internal and external networks of the BIG-IP Controller. Any VLANs to which the SNAT is not to be mapped must be explicitly disabled using the vlan <vlan_name> disable syntax.

Showing SNAT mappings

The following bigpipe commands show mappings:

b snat [<snat_ip>] [...<snat_ip>] show

b snat default show

The following commands show the current SNAT connections:

b snat [<snat_ip>] [...<snat_ip>] dump [ verbose ]

b snat default dump [ verbose ]

The optional verbose keyword provides more detailed output.

The following command prints the global SNAT settings:

b snat globals show

Limiting connections

Use the following commands to set the maximum number of concurrent connections allowed for one or more SNAT addresses. Zero indicates no limit.

b snat <snat_ip> limit <max conn>

The default SNAT address connection limit is set with the following command:

b snat default limit <max conn>

Set the global concurrent connection limit with this command:

b snat limit <max conn>

Enabling mirroring for redundant systems

The following example sets SNAT mirroring for all SNAT connections originating at 192.168.225.100:

b snat 192.168.225.100 mirror enable

Setting idle connection timeouts

Use the following command to set the timeout for idle TCP connections:

b snat timeout tcp <seconds>

Use the following command to set the timeout for idle UDP connections. Note that you must have a timeout set for UDP connections; zero is not allowed:

b snat timeout udp <seconds>

Use the following command to set the timeout for idle TCP connections originating at this node address. Set <seconds> to 0 (zero) to disable TCP timeout for these nodes.

b snat <node_ip> [...<node_ip>] timeout tcp <seconds>

Use the following command to set the timeout for idle TCP connections originating at the default node address. Set <seconds> to 0 (zero) to disable TCP timeout for these nodes.

b snat default timeout tcp <seconds>

Use the following syntax to set the timeout for idle UDP connections originating at this node address. Note that you must have a timeout set for UDP connections; zero is not allowed:

b snat <node_ip> [...<node_ip>] timeout udp <seconds>

Use the following syntax to set the timeout for idle UDP connections originating at the default SNAT address. Note that you must have a timeout set for UDP connections; zero is not allowed:

b snat default timeout udp <seconds>

Disabling ARP requests

By default, the BIG-IP Controller responds to ARP requests for the SNAT address and sends a gratuitous ARP request for router table update. If you want to disable the SNAT address for ARP requests, you must specify arp disable.

Clearing statistics

You can reset statistics by node address. Use the following syntax to clear all statistics for one or more nodes:

b snat <node_ip> [ ...<node_ip> ] stats reset

Use the following command to reset the statistics to zero for the default:

b snat default stats reset

summary

b summary

Displays a summary of current usage statistics. The output display format for the summary command is shown in Figure 2.17. You can find detailed descriptions of each of statistic displayed by the summary command in the BIG-IP Administrator Guide, Monitoring and Administration.

Figure 2.17 The summary output display

 BIG-IP total uptime           = 1 (day) 4 (hr) 40 (min) 8 (sec)
BIG-IP total uptime (secs) = 103208
BIG-IP total # connections = 0
BIG-IP total # pkts = 0
BIG-IP total # bits = 0
BIG-IP total # pkts(inbound) = 0
BIG-IP total # bits(inbound) = 0
BIG-IP total # pkts(outbound) = 0
BIG-IP total # bits(outbound) = 0
BIG-IP error no nodes available = 0
BIG-IP tcp port deny = 0
BIG-IP udp port deny = 0
BIG-IP virtual tcp port deny = 0
BIG-IP virtual udp port deny = 0
BIG-IP max connections deny = 0
BIG-IP virtual duplicate syn ssl = 0
BIG-IP virtual duplicate syn wrong dest = 0
BIG-IP virtual duplicate syn node down = 0
BIG-IP virtual maint mode deny = 0
BIG-IP virtual addr max connections deny = 0
BIG-IP virtual path max connections deny = 0
BIG-IP virtual non syn = 0
BIG-IP error not in out table = 0
BIG-IP error not in in table = 0
BIG-IP error virtual fragment no port = 0
BIG-IP error virtual fragment no conn = 0
BIG-IP error standby shared drop = 0
BIG-IP dropped inbound = 0
BIG-IP dropped outbound = 0
BIG-IP reaped = 0
BIG-IP ssl reaped = 0
BIG-IP persist reaped = 0
BIG-IP udp reaped = 0
BIG-IP malloc errors = 0
BIG-IP bad type = 0
BIG-IP mem pool total 96636758 mem pool used 95552 mem percent used 0.10

trunk

b trunk <controlling_if> define <if_list>
b trunk <controlling_if> show
b trunk show

The trunk command aggregates links (individual physical interfaces) to form a trunk. This link aggregation increases the bandwidth of the individual NICs in an additive manner. Thus, four fast Ethernet links, if aggregated, create a single 400 Mb/s link. The other advantage of link aggregation is link failover. If one link in a trunk goes down, traffic is simply redistributed over the remaining links.

A trunk must have a controlling link and acquires all the attributes of that controlling link from Layer 2 and above. Thus, the trunk automatically acquires the VLAN membership of the controlling link but does not acquire its media type and speed. Outbound packets to the controlling link are load balanced across all of the known-good links in the trunk. Inbound packets from any link in the trunk are treated as if they came from the controlling link.

A maximum of eight links may be aggregated. For optimal performance, links should be aggregated in powers of two. Thus ideally you will aggregate two, four, or eight links.

Creating a trunk

To create a trunk, use the following syntax:

b trunk <controlling_if> define <if_list>

Interfaces are specified using the s.p convention, where s is slot number and p is port number. An <if_list> is one or more such interfaces, with multiple interfaces separated by spaces or commas. A range may be specified as follows:

2.1-2.7

For more information on interface naming, refer to Interface naming convention, on page 1-115.

unit

b unit [show]
b unit peer [show]

The unit number on a BIG-IP Controller designates which virtual servers use a particular controller in an active-active redundant configuration. You can use the bigpipe unit command to display the unit number assigned to a particular BIG-IP Controller. For example, to display the unit number of the unit you are on, type the following command:

b unit show

To display the unit number of the other controller in a redundant system, type in the following command:

b unit peer show

Note: If you use this command on a redundant system in active/standby mode, the active controller shows as unit 1 and 2, and the standby controller has no unit numbers.

Tip: The bigpipe unit peer show command is the best way to determine whether the respective state mirroring daemons are connected.

verbose

b verbose virtual_server_udp_port_denial
b verbose virtual_server_tcp_port_denial
b verbose bigip_udp_ort_denial
b verbose bigip_tcp_port_denial

Used to modify the verbose log level. This command is an alternative to using the bigpipe global verbose command.

Table 2.10 defines the command and shows the equivalencies.

bigpipe verbose and global verbose command equivalencies
b verbose command b global verbose command
b verbose bigip_udp_port_denial Turns UDP port denial logging on. This logs UDP port denials to the BIG-IP Controller address. b global verbose_log_level=1
b verbose bigip_tcp_port_denial Turns TCP port denial logging on. This logs TCP port denials to the BIG-IP Controller address. b global verbose_log_level=2
b verbose virtual_server_udp_port_denial Turns virtual UDP port denial logging on. This logs UDP port denials to the virtual server address. b global verbose_log_level=4
b verbose virtual_server_tcp_port_denial Turns virtual TCP port denial logging on. This logs TCP port denials to the virtual server address. b global verbose_log_level=8
b verbose bigip_udp_port_denial
b verbose bigip_tcp_port_denial
b verbose bigip_udp_ort_denial
b verbose bigip_tcp_port_denial Turns UDP and TCP port denial on for both virtual server and BIG-IP Controller addresses.
b global verbose_log_level=15

verify

b [log] verify <command...]
verify load [<filename>|-]

Parses the command line and checks syntax without executing the specified command. This distinguishes between valid and invalid commands

Use the verify command followed by a command that you want to validate:

b verify virtual 10.10.10.100:80 use pool my_pool

The command checks the syntax and logic, reporting any errors that would be encountered if the command executed.

Use the verify command together with the load <filename> command to validate the specified configuration file. For example, to check the syntax of the configuration file /config/altbigpipe.conf, use the following command:

b verify load /config/altbigip.conf

version

b version

Displays the version of the BIG-IP Controller's operating system and the features enabled.

For example, for a BIG-IP Controller HA, the bigpipe version command displays the output shown in Figure 2.18.

Figure 2.18 The version output display

 Product Code:    
BIG-IP HA

Enabled Features:
SSL Gateway Gateway Failsafe
Static Load Balancing Snat
Nat Pools
Akamaizer Full Proxy
Late Binding HTTP Rules
Mirroring Failover
Node HA Dynamic Load Balancing
Destination Address Affinity Cookie Persistence
SSL Persistence Simple Persistence
EAV ECV SSL
ECV ECV Transparent
Health Check Filter

virtual

b virtual <virt_ip>[:<service>] [unit <ID>] [netmask <ip>] [broadcast <ip>] use pool <pool_name>
b virtual <virt_ip>:<service> [/<bitmask>][unit <ID>] use pool <pool_name>
b virtual <virt_ip>[:<service>] [unit <ID>] [netmask <ip>] [broadcast <ip>] use rule <rule_name>
b virtual <virt_ip>[:<service>] [unit <ID>] [netmask <ip>] forward
b virtual <virt_ip>:<service> translate port enable | disable | show
b virtual <virt_ip>:<service> svc_down_reset enable | disable | show
b virtual <virt_ip>:<service> translate addr enable | disable | show
b virtual <virt_ip>:<service> lasthop pool <pool_name> | none | show
b virtual <virt_ip>:<service> mirror conn enable | disable | show
b virtual [<virt_ip:service>] stats reset
b virtual <virt_ip>:<service> accelerate enable | disable | show
b virtual <virt_ip>:<service> use pool <pool_name> accelerate disable
b virtual <virt_ip>:<service> vlans <vlan_list> disable | enable
b virtual <virt_ip>:<service> vlans show
b virtual <virt_ip> arp enable|disable|show
b virtual <virt_ip> any_ip enable | disable
b virtual <virt_ip> any_ip timeout <seconds>
b virtual <virt_ip>[:<service>] [...<virt_ip>[:<service>]] show
b virtual <virt_ip>[:<service>] [ ... <virt_ip>[:<service>]] enable | disable
b virtual <virt_ip>[:<service>] [ ... <virt_ip>[:<service>]] delete
b virtual <virt_ip>[:<service>] [... <virt_ip>[:<service>]] limit <max_conn>

Creates, deletes, and displays information about virtual servers. This command also sets connection mirroring, connection limits, and timeouts on a virtual server.

Defining a virtual server

Virtual servers are port-specific, and if you are configuring a site that supports more than one service, you need to configure one virtual server for each service offered by the site. Use the following syntax to define the pools or rules to which a virtual server maps. The unit <ID> parameter specifies which unit handles the virtual server in an active-active redundant configuration. You can associate pools or rules with a virtual server. The following sections describe the syntax for associating a pool or a rule with a virtual server.

To configure a virtual server to use a load balancing pool

Use the following syntax to create a virtual server that references a load balancing pool. Note that you must create a pool before you can create a virtual server that references the pool. For information about creating a pool, see Creating a pool, on page 2-45.

b virtual <virt_ip>:<service> [unit <ID>] use pool <pool_name>

For example, if you want to create a virtual server that references the pool my_pool, the command might look like this:

b virtual 11.12.1.53:80 use pool my_pool

To configure a virtual server to use a load balancing rule

Use the following syntax to create a virtual server that references a load balancing rule. Note that you must create a rule before you can create the virtual server that references the rule. For information about creating a rule, see Associating a rule with virtual server, on page 2-66.

b virtual <virt_ip>:<service> [unit <ID>] use rule <rule_name>

For example, if you want to create a virtual server that references the rule my_rule, the command might look like this:

b virtual 11.12.1.53:80 use pool my_rule

Displaying information about virtual servers

Use the following syntax to display information about all virtual servers included in the configuration:

b virtual show

Use the following syntax to display information about one or more virtual servers included in the configuration:

b virtual <virt_ip>:<service> [...<virt_ip>:<service>] show

The command displays information such as the nodes associated with each virtual server, the nodes' status, and the current, total, and maximum number of connections managed by the virtual server since the BIG-IP Controller was last rebooted.

To reset statistics for a virtual server

Use the following command to reset the statistics for an individual virtual server:

b virtual [<virt_ip>:<service>] stats reset

Disabling VLANs for a virtual server

A virtual server is mapped by default to all VLANs on the internal and external networks of the BIG-IP Controller. Any VLANs to which the virtual server is not to be mapped must be explicitly disabled using the vlan <vlan_name> disable syntax:

b virtual <virt_ip>:<service> vlans <vlan_list> disable | enable

All virtual servers that share a virtual IP address must use the same VLANs. Changing the VLAN mapping for a virtual server changes the VLAN mapping for all virtual servers that have the same virtual address.

Disabling ARP requests

By default, the BIG-IP controller responds to ARP requests for the virtual server address and sends a gratuitous ARP request for router table update. If you want to disable the virtual address for ARP requests, you must specify arp disable.

Setting a user-defined netmask and broadcast for a network virtual server

The default netmask for a virtual address, and for each virtual server hosted by that virtual address, is determined by the self IP of the virtual server VLAN, if any, and if not by the network class of the IP address entered for the virtual server. The default broadcast is automatically determined by the BIG-IP Controller, and it is based on the virtual address and the current netmask. You can override the default netmask and broadcast for a network virtual address only.

All virtual servers hosted by the virtual address use the netmask and broadcast of the virtual address, whether they are default values or they are user-defined values.

To define a custom netmask and broadcast

If you want to use a custom netmask and broadcast, you define both when you define the network virtual server:

b virtual <virt_ip>[:<service>] [vlan <vlan_name> disable | enable] [netmask <ip>] [broadcast <ip>] use pool <pool_name>

Note: The BIG-IP Controller calculates the broadcast based on the IP address and the netmask. A user-defined broadcast address is not necessary.

Again, even when you define a custom netmask and broadcast in a specific network virtual server definition, the settings apply to all virtual servers that use the same virtual address. The following sample command shows a user-defined netmask and broadcast:

b virtual www.SiteOne.com:http netmask 255.255.0.0 broadcast 10.0.140.255 use pool my_pool

The /bitmask option shown in the following example applies network and broadcast address masks. In this example, a 24-bit bitmask sets the network mask and broadcast address for the virtual server:

b virtual 206.168.225.0:80/24 use pool my_pool

You can generate the same broadcast address by applying the 255.255.255.0 netmask. The effect of the bitmask is the same as applying the 255.255.255.0 netmask. The broadcast address is derived as 206.168.225.255 from the network mask for this virtual server.

Setting a connection limit

The default setting is to have no limit to the number of concurrent connections allowed on a virtual server. You can set a concurrent connection limit on one or more virtual servers using the following command:

b virtual <virt_ip>[:<service>] [...<virt_ip>[:<service>] ] limit <max conn>

The following example shows two virtual servers set to have a concurrent connection limit of 5000 each:

b virtual www.SiteOne.com:http www.SiteTwo.com:ssl limit 5000

To turn off the limit, set the <max conn> variable to zero:

b virtual <virt_ip>[:<service>] [...<virt_ip>[:<service>] ] limit 0

Setting translation properties for virtual addresses and ports

Turning port translation off for a virtual server is useful if you want to use the virtual server to load balance connections to any service. Use the following syntax to enable or disable port translation for a virtual server.

b virtual <virt_ip>:<service> translate port enable | disable | show

You can also configure the translation properties for a virtual server address. This option is useful when the BIG-IP Controller is load balancing devices that have the same IP address. This is typical with the nPath routing configuration where duplicate IP addresses are configured on the loopback device of several servers. Use the following syntax to enable or disable address translation for a virtual server.

b virtual <virt_ip>:<service> translate addr enable | disable | show

Setting up last hop pools for virtual servers

In cases where you have more than one router sending connections to a BIG-IP Controller, connections are automatically sent back through the same router from which they were received when the auto_lasthop global variable is enabled, as it is by default. If the global auto_lasthop is disabled for any reason (for example, you may not want it for an SSL gateway), you can direct your replies to the last hop router using a last hop pool

To configure a last hop pool, you must first create a pool containing the router inside addresses. After you create the pool, use the following syntax to configure a last hop pool for a virtual server:

b virtual <virt_ip>:<service> lasthop pool <pool_name> | none | show

To remove a lasthop pool from a virtual server:

b virtual <virt_ip>:<service> lasthop pool <pool_name> none

Mirroring virtual server state

Mirroring provides seamless recovery for current connections. When you use the mirroring feature, the standby controller maintains the same state information as the active controller. Then when a failover occurs, transactions such as FTP file transfers continue as though uninterrupted.

Note: Mirroring slows BIG-IP Controller performance and is primarily for long-lived services like FTP and Telnet. Mirroring is not useful for short-lived connections like HTTP.

Since mirroring is not intended to be used for all connections, it must be specifically enabled for each virtual server.

To control mirroring for a virtual server, use the bigpipe virtual mirror command to enable or disable mirroring of connections. The syntax of the command is:

b virtual <virt_ip>:<service> mirror conn enable | disable

To display the current mirroring setting for a virtual server, use the following syntax:

b virtual <virt_ip>:<service> mirror conn show

Note: If you set up mirroring on a virtual server that supports FTP connections, you need to mirror the control port virtual server, and the data port virtual server.

The following example shows the two commands used to enable mirroring for virtual server v1 on the FTP control and data ports:

b virtual v1:21 mirror conn enable

b virtual v1:20 mirror conn enable

Enabling and disabling a virtual server

You can remove an existing virtual server from network service, or return the virtual server to service, using the disable and enable keywords. When you disable a virtual server, the virtual server no longer accepts new connection requests, but it allows current connections to finish processing before the virtual server goes down. Use the following syntax to remove a virtual server from network service:

b virtual <virt_ip>:<service> [...<virt_ip>:<service>] disable

Use the following syntax to return a virtual server to network service:

b virtual <virt_ip>:<service> enable

Enabling and disabling a virtual address

You can remove an existing virtual address from network service, or return the virtual address to service, using the disable and enable keywords. Note that when you enable or disable a virtual address, you inherently enable or disable all of the virtual servers that use the virtual address.

b virtual <virt_ip> disable

Use the following syntax to return a virtual address to network service:

b virtual <virt_ip> enable

Displaying information about virtual addresses

You can also display information about the virtual addresses that host individual virtual servers. Use the following syntax to display information about one or more virtual addresses included in the configuration:

b virtual <virt_ip> [... <virt_ip> ] show

The command displays information such as the virtual servers associated with each virtual address, the status, and the current, total, and maximum number of connections managed by the virtual address since the BIG-IP Controller was last rebooted, or since the BIG-IP Controller became the active unit (redundant configurations only).

Deleting a virtual server

Use the following syntax to permanently delete one or more virtual servers from the BIG-IP Controller configuration:

b virtual <virt_ip>:<service> [... <virt_ip>:<service>] delete

Turning software acceleration off for virtual servers using IPFW rate filters

Additional enhancements are included in this release that speed packet flow for TCP connections when the packets are not fragmented. In most configurations these software enhancements are automatically turned on and do not require any additional configuration.

However, you may want to turn off these enhancements for individual virtual servers that use IPFW rate filters. With the speed enhancements on, IPFW only examines the first SYN packet in any given connection. If you want to filter all packets, you should turn off the speed enhancements. To do this, you must first set the global state of the system on, and then you must turn off the feature for individual virtual servers that use IPFW rate filtering. You can change the settings for these enhancements from the command line or in the Configuration utility.

To set software acceleration controls

Before you can turn off software acceleration for a virtual server, you must set the global variable fastflow_active to on with the following command:

b global fastflow_active on

After you set the sysctl variable, use the following bigpipe commands to disable software acceleration for existing virtual servers that use IPFW rate filtering:

b virtual <ip>:<service> accelerate disable

For example, if you want to turn acceleration off for the virtual server 10.10.10.50:80, type the following command:

b virtual 10.10.10.50:80 accelerate disable

You can define a virtual server with acceleration disabled using the following syntax:

b virtual <ip>:<service> use pool the_pool accelerate disable

For example, if you want to define the virtual server 10.10.10.50:80 with the pool IPFW_pool and acceleration turned off, type the following command:

b virtual 10.10.10.50:80 use pool IPFW_pool accelerate disable

Enabling and disabling Any IP

The any_ip flag, if enabled, enables the virtual server for services other than TCP and UDP. It is used to permit IPSEC (IP Security Protocol) for VPN connections.

vlan

b vlan <vlan_name>
b vlan <name> rename <new_name>
b vlan <vlan_name> delete
b vlan <vlan_name> tag <tag_number>
b vlan <vlan_name> interfaces add [tagged] <if_list>
b vlan <vlan_name> interfaces delete <if_list>
b vlan <vlan_name> interfaces delete all
b vlan <vlan_name> interfaces show
b vlan <vlan_name> port_lockdown enable | disable
b vlan <vlan_name> bridging enable|disable
b vlan <vlangroup_name> proxy_forward enable | disable
b vlan <vlan_name> failsafe arm|disarm|show
b vlan <vlan_name> timeout <seconds>|show
b vlan <vlan_name> snat automap
b vlan show
b vlan <vlan_name> show
b vlan <vlan_name> interfaces show
b vlan <vlan_name> rename <new_vlan_name>
b vlan <if_name> mac_masq <mac_addr> | show
b vlan <if_name> mac_masq 0:0:0:0:0

The vlan command defines VLANs, VLAN mappings, and VLAN properties. By default, each interface on a BIG-IP is an untagged member of an interface-group VLAN. The lowest-numbered interface is assigned to the external VLAN, the interface on the main board is assigned to the admin VLAN, and all other interfaces are assigned to the internal VLAN.

Using the vlan command, you can create tagged and untagged VLANs, make and change assignments of VLANs to interfaces, and configure a range of VLAN attributes. This includes enabling/disabling of port lockdown, arming and disarming failsafe, and setting the failure timeout. VLAN configuration options are shown in Table 2.11

VLAN configuration options
Attributes Description
Default VLAN configuration The First-Time Boot utility provides a default VLAN configuration. On a typical controller with two interfaces, you create an internal and external VLAN.
VLAN Create, rename, or delete a VLAN. Typically, one VLAN is assigned to one interface.
Tag VLANs You can tag VLANs and add multiple tagged VLANs to a single interface.
VLAN security You can set port lockdown by VLAN.
Set fail-safe timeouts You can set a failsafe timeout on a VLAN. You can use a failsafe timeout to trigger fail-over in a redundant system.
Self IP addresses You can set self IP addresses for VLANs.
MAC masquerade You can use this attribute to set up a media access control (MAC) address that is shared by redundant controllers. This allows you to use the BIG-IP Controllers in a topology with secure hubs.

VLAN flexibility is such that separate IP networks can belong to a single VLAN, while a single IP network can be split among multiple VLANs. (The latter case allows the BIG-IP Controller to be inserted into an existing LAN without renaming the nodes.) In either case, the separate networks can be made to behave like a single network for intercommunication purposes. This is done in one of two ways:

  • For nodes on different networks within the same VLAN, direct packet exchange is performed using feature called VLAN bridging.
  • For nodes on the same IP network on different VLANs, direct packet exchange is performed by a feature called L2 forwarding. This requires that the VLANs be grouped.

    Except for self-addresses (which must be mapped explicitly to VLANs), all addresses created as objects on the BIG-IP controller (virtual servers, NATs, SNATs, and proxies) are automatically mapped to all untagged VLANs. Thus bridging will always take place.

Creating and assigning a VLAN

To create a VLAN, use the following syntax:

b vlan <name>

<name> is typically symbolic, as in:

b vlan vlan5

Typically you will define a VLAN and specify the interfaces on the VLAN in the same command:

b vlan vlan5 interfaces add [tagged] <if_list>

Tagged VLANs

A new tagged VLAN is created using the bigpipe vlan tag command, specifying a tag number. For example:

b vlan my_vlan tag 1209

A tagged VLAN is mapped to an interface or interfaces (or an untagged VLAN is tagged and mapped an interface or interfaces) using the tagged flag. For example:

b vlan external interfaces add tagged 4.1 5.1 5.2

The effect of the command is to place a tag on interfaces 4.1.and 5.1, which in turn makes external a tagged VLAN. (However, it remains an untagged VLAN for interfaces which are part of it but not tagged.)

An interface can have more than one tag; it can be a member of more than one tagged VLAN.

b vlan external interfaces add tagged 4.1

b vlan internal interfaces add tagged 4.1

b vlan admin interfaces add tagged 4.1

This permits tagged VLANS to form a VLAN trunk on a single interface.

Enabling and disabling port lockdown

You can lock down a VLAN to prevent direct connection to the BIG-IP Controller through that VLAN.

Setting the fail-over timeout and arming the fail-safe

For redundant BIG-IP Controller pairs, failover (activation of the inactive system) occurs when loss of traffic is detected on a VLAN and traffic is not restored during the failover timeout period for that VLAN. A failsafe mechanism may be enable to attempt to generate traffic when half the timeout has elapsed. If the attempt is successful, the failover is aborted.

Using the vlan command, you may set the timeout period and also arm or disarm the fail-safe.

To set the timeout, type:

b vlan <vlan_name> timeout <timeout_in_seconds>

To arm the failsafe, type:

b vlan <vlan_name> failsafe arm

To disarm the failsafe, type:

b vlan <vlan_name> failsafe disarm

Enabling and disabling SNAT auto-mapping

A VLAN may be mapped automatically to a SNAT address. This means that by enabling snat automap on an internal VLAN, a SNAT is performed on any connection made from that VLAN. If the external VLAN has one self IP address enabled for snat automap, the translation address will be that self IP address.

For VLANs external and internal, this would be implemented as follows:

b vlan internal snat automap enable

b self 10.0.0.1 vlan external snat automap enable

If the external VLAN has more than one self IP address enabled for snat automap (implying more than one IP network), the following rules are followed:

  • If the connection is handled by a non-forwarding virtual server, the translation address will be the self IP address for the node selected by load balancing.
  • If the connection is handled by a forwarding virtual server or no virtual server, the translation address will be the IP address of the next hop to the destination.
  • If there are no self addresses that match the IP network of the node or the next hop, any self IP on the VLAN is eligible.

    The SNAT auto-map feature is useful in the following cases:

  • Where a traditional single SNAT address would quickly exhaust the number of ephemeral ports available. As long as there is more than one eligible self IP address, SNAT auto-mapping can increase the number of simultaneous connections possible by using the same ephemeral port on multiple addresses.
  • When the equivalent of a default SNAT is required for BIG-IP Controllers in active-active mode. (The conventional default SNAT does not work in active-active mode.)
  • Where there is a need to ensure that outbound traffic returning through ISPs or NAT-less firewalls returns through the same ISP or firewall.

    ISPs and NAT-less firewalls are handled in the following manner. If multiple external interfaces are available, the inside addresses of the firewalls in the load balancing pool may each be connected to different interfaces and assigned to different VLANs. Each VLAN is then automatically mapped to a SNAT when the snat automap flag is enabled. The snat automap flag must also be enabled for the internal VLAN. For example, if the internal VLAN were named internal, and the external VLANs were named external1 and external2, the following commands would be entered:

    b vlan internal snat_automap enable

    b vlan external1 snat_automap enable

    b vlan external2 snat_automap enable

    If multiple external interfaces are not available, the ISP routers or firewalls are assigned to different IP networks. This will already be the case for ISPs. For firewalls, the separate IP address ranges must be established on the inside and outside interfaces of each firewall. The separate networks are then assigned separate self addresses, for example, 10.0.0.1 and 11.0.0.1. Thus if the internal and external VLANs were named internal and external, the following commands would be entered:

    b self 10.0.0.1 vlans add external snat automap enable

    b self 11.0.0.1 vlans add external snat automap enable

    b vlan internal snat automap enable

Setting the MAC masquerade address

Sharing the MAC masquerade address makes it possible to use BIG-IP Controllers in a network topology using secure hubs. The MAC address for a VLAN is the first interface to which the VLAN is mapped. You can view the VLAN-to--interface mapping using the following command:

b vlan show

You can view the media access control (MAC) address on a given controller using the following command:

b interface show

Use the following syntax to set the MAC masquerade address that will be shared by both BIG-IP Controllers in the redundant system.

b interface <ifname> mac_masq <MAC_addr>

Warning: You must specify a default route before using the mac_masq command. You specify the default route in the /etc/hosts and /etc/netstart files.

Find the MAC address on both the active and standby units and choose one that is similar but unique. A safe technique for choosing the shared MAC address follows:

Suppose you want to set up mac_masq on the external interfaces. Using the b interface show command on the active and standby units, you note that their MAC addresses are:

Active: 3.1 = 0:0:0:ac:4c:a2

Standby: 3.1 = 0:0:0:ad:4d:f3

In order to avoid packet collisions, you now must choose a unique MAC address. The safest way to do this is to select one of the addresses and logically OR the first byte with 0x40. This makes the MAC address a locally administered MAC address.

In this example, either 40:0:0:ac:4c:a2 or 40:0:0:ad:4d:f3 would be a suitable shared MAC address to use on both BIG-IP Controllers in the redundant system.

The shared MAC address is used only when the BIG-IP Controller is in active mode. When the unit is in standby mode, the original MAC address of the network card is used.

If you do not configure mac_masq on startup, or when transitioning from standby mode to active mode, the BIG-IP Controller sends gratuitous ARP requests to notify the default router and other machines on the local Ethernet segment that its MAC address has changed. See RFC 826 for more details on ARP.

Note: You can use the same technique to configure a shared MAC address for each interface.

vlangroup

b vlangroup <vlagroup_name> { vlans add <vlan_list> }
b vlangroup <vlangroup_name> delete

The vlangroup command defines a VLAN group, which is a grouping of two or more VLANs belonging to the same IP network for the purpose of allowing L2 packet forwarding between those VLANs.

The VLANs between which the packets are to be passed must be on the same IP network, and they must be grouped using the vlangroup command. For example:

b vlangroup network11 { vlans add internal external }

A self IP address must be assigned to the VLAN group using the following command:

b self <ip_addr> vlan network11

L2 forwarding must be enabled for the VLAN group using the vlan proxy_forward attribute. This attribute is enabled by default when the VLAN group is enabled.