Applies To:
Show VersionsBIG-IP versions 1.x - 4.x
- 4.1.1 PTF-06, 4.1.1 PTF-05, 4.1.1 PTF-04, 4.1.1 PTF-03, 4.1.1 PTF-02, 4.1.1 PTF-01, 4.1.1, 4.1.0
7
bigpipe Command Reference
bigpipe commands
This chapter lists the various bigpipe commands, including syntax requirements and functional descriptions. Table 7.1 outlines the conventions used in the command line syntax.
The following table provides a concise listing of the individual bigpipe commands, along with the page reference where you can find the detailed description.
Command |
Description |
Page |
-? |
Displays online help for an individual bigpipe command. |
|
config |
Synchronizes the /config/bigip.conf between the two BIG-IP 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 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 configuration and resets. |
|
maint |
Toggles the BIG-IP into and out of maintenance mode. |
|
makecookie |
Loads the BIG-IP configuration without resetting the current configuration. |
|
merge |
Loads a saved BIG-IP configuration without resetting the current configuration. |
|
mirror |
Copies traffic from any port or set of ports to a single, separate port. |
|
monitor |
Defines a health check monitor. |
|
-n |
Displays addresses and 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 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). |
|
stp |
Implements spanning tree protocol (STP). |
|
summary |
Displays summary statistics for the BIG-IP. |
|
trunk |
Aggregates links to form a trunk. |
|
unit |
Displays the unit number assigned to a particular BIG-IP. |
|
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 units 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> reinstalls the archived 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 7.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 BIG-IP, as well as those that are standby connections for the peer BIG-IP. 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.
In an active/standby or active-active configuration, run the following command to place a BIG-IP in standby mode:
b failover standby
Show the status of the BIG-IP 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 unit to resume handling connections:
b failover failback
You can use the bigpipe failover init command to refresh the parameters of the fail-over mechanism 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 ipforwarding enable | disable
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>
b global l2_aging_time <seconds>
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 to send fewer connections to a node that is responding slowly, and also allows the BIG-IP 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 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 command to disable software acceleration for virtual servers that use IPFW rate filtering:
b virtual <ip>:<port> accelerate disable
gateway failsafe
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 units use different routers as gateways to the Internet. Fail-over is triggered if the gateway for the active unit 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 3-87.
ip forwarding
Enables IP forwarding for the BIG-IP. IP forwarding exposes all of the node IP addresses to the external network, making them routable on that network. The default setting is disabled.
mirror
Enables mirroring functions globally for the BIG-IP. The mirror feature duplicates the active unit's real-time connection or persistence information state on the standby unit for smooth transition to the inactive unit at fail-over. 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 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 system.
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 itself. The variable is disabled on the BIG-IP 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 units that do not support encrypted communications, or for a unit that needs to communicate with the 3-DNS software. (See the 3-DNS Administrator Guide for more information.)
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 units 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_ports
This variable enables or disables ports for SSH access on BIG-IP units 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 units that do not support encrypted communications, or for connecting to 3-DNS Controllers that do not support encrypted communication. (See the 3-DNS Administrator Guide for more information.)
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 7.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.
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 timeout
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 when using destination address affinity (sticky persistence). When the maximum value is reached, the BIG-IP stops accumulating sticky entries. The default value for this entry is 2048.
verbose_log_level
This variable sets 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 address.
b global verbose_log_level 15
The following command turns logging off altogether:
b global 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 address.
b global verbose_log_level 2
The following command turns on virtual TCP port denial logging, which logs TCP port denials to the virtual server address.
b global 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 address.
b global 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.
b global verbose_log_level 4
webadmin_port
Specifies the port number used for administrative web access. The default port for web administration is port 443.
l2_aging_time
Specifies a time period after which dynamic entries in the L2 forwarding table are flushed out if the MAC address is no longer present on the network. The default value is 300 seconds.
-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 [verbose]
b interface [<if_name>] stats reset
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 settings and then loads the configuration settings, by default from the /config/bigip.conf and /config/bigip_base.conf files.
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 into and out of Maintenance mode. When in Maintenance mode, a BIG-IP 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 is already in maintenance mode, the maint command takes the BIG-IP out of maintenance mode. If the BIG-IP is in maintenance mode for more than 20 minutes, that the BIG-IP immediately begins to accept new connection requests.
If the BIG-IP 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 7.2 and Figure 7.3.
Figure 7.2 Sample cookie template
Set-Cookie:BIGipServer[poolname]=336268299.20480.0000; path=/
Figure 7.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 configuration from <file_name> without resetting the current configuration.
mirror
b mirror <mirror_to_if> interfaces add <if_list>
b mirror <mirror_to_if> interfaces delete <if_list>
For the BIG-IP Application Switch, you can copy traffic from any port or set of ports to a single, separate port. This is called port mirroring. You should attach a sniffer device to the target port, called the mirror-to port, for debugging and/or monitoring.
Creating a port mirror
Creating a port mirror consists of specifying a mirror-to port and adding to it one or more ports (that is, a port list) to be mirrored. The bigpipe syntax for setting up port mirroring is:
b mirror <mirror_to_if> interfaces add <if_list>
For example, you could type the following command:
b mirror 3.24 interfaces add 3.1 3.3 3.10
Deleting interfaces from a port mirror or deleting a port mirror
The bigpipe syntax for deleting interfaces from the port mirror is:
b mirror <mirror_to_if> interfaces delete <if_list>
For example, you could type the following command:
b mirror 3.24 interfaces delete 3.10
The bigpipe syntax for deleting the port mirror is:
b mirror <mirror_to_if> delete
For example, you could type the following command:
b mirror 3.24 delete
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 7-40 and To delete associations, on page 7-40).
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 7.4.
Figure 7.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 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 7.5.
Figure 7.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 7.3 lists the monitor templates and shows the template-specific attribute sets for each.
Table 7.4 defines the attributes used in the templates.
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 is 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 manual 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 log in using the ISQL/w program before attempting logins from the BIG-IP.
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 that you want 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 path name 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 7.6.
Figure 7.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
-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 host name, respectively. For example, type the following command to display services numerically:
b -n virtual
Figure 7.7 shows an example of output that uses IP address instead of host names.
Figure 7.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 <orig_addr> and an unused routable address on the network in front of the BIG-IP <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 7.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 7.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.
- 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. Any VLANs to which the NAT is not to be mapped must be explicitly disabled using the vlan <vlan_name> disable syntax.
Viewing the unit ID number
You can use the unit <unit ID> parameter to specify the BIG-IP to which this NAT applies in an active-active redundant system.
Disabling ARP requests
By default, the BIG-IP 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 BIG-IP:
b node show
When you issue the node show command, the BIG-IP 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 the 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 7.9 shows the output of this command.
Figure 7.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 use this command:
node <node_list> monitor use <monitor>
To add multiple monitors to a node
To place multiple monitors on a node, use this command:
node <node> monitor use <monitor1> and <monitor2>...
For more information on using the node command with health monitors, refer to monitor, on page 7-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. Use pools to group members together with a common load balancing mode and persistence mode.
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 7.6, on page 7-42. You can also find detailed information about setting up persistence with pools in Persistence, on page 3-18.
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 7.5.
For more information about the load balancing modes, refer to Proxies, on page 3-61.
Table 7.6 shows additional elements available for the pool command.
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 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 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 7.7.
Activating Insert HTTP cookie persistence
If you specify Insert mode, the BIG-IP 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.
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 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 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 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 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.
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 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 BIG-IP distributes traffic to the next higher priority group, and so on.
An example is shown in Figure 7.10.
Figure 7.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 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 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 7.11.
Figure 7.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.comThe 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.
proxy
b proxy <ip>:<service> [<unit <id>] target <server|virtual> <ip>:<service> clientssl enable clientssl key <clientssl_key> clientssl cert <clientssl_cert> [serverssl enable [serverssl key <erverssl_key> serverssl cert <serverssl_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> unit <unit_id> | show
b proxy <ip>:<service> target show
b proxy <ip>:<service> clientssl <enable | disable | show
b proxy <ip>:<service> [clientssl] key <clientssl_key> | show
b proxy <ip>:<service> [clientssl] cert <clientssl_cert> | show
b proxy <ip>:<service> serverssl enable | disable | show
b proxy <ip>:<service> serverssl key <serverssl_key> | show
b proxy <ip>:<service> serverssl cert <serverssl_cert> | show
b proxy <ip>:<service> akamaize enable | disable | show
b proxy <ip>:<service> lasthop pool none | <lasthop_pool_name> | show
b proxy <ip:service> vlans <vlan_list> enable | disable
b proxy <ip>:<service> vlans enable all
b proxy <ip:service> vlans show
b proxy <ip: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. For detailed information about setting up the SSL Accelerator feature, see the BIG-IP Solutions Guide, Chapter 9, Configuring an SSL Accelerator. For detailed information about setting up the content converter feature, see the BIG-IP Solutions Guide, Chapter 14, Configuring a Content Converter.
To create a client-side SSL gateway
Use the following command syntax to create an SSL gateway:
b proxy <ip>:<service> [unit <unit_id>] \
target <server|virtual> <ip>:<service> \
clientssl enable \
clientssl key <clientssl_key> \
clientssl cert <clientssl_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 \
clientssl enable \
clientssl key my.server.net.key \
clientssl cert my.server.net.crt
Note that when the configuration is written out in the bigip.conf file, the line clientssl enable is automatically added. When the client-side SSL gateway is written in the /config/bigip.conf file, it looks like the sample in Figure 7.12.
Figure 7.12 An example client-side SSL gateway configuration
proxy 10.1.1.1:https unit 1 {
target virtual 20.1.1.1:http
clientssl enable
clientssl key my.server.net.key
clientssl cert my.server.net.crt
}Creating a client-side and server-side SSL gateway from the command line
Use the following command syntax to create an SSL gateway:
b proxy <ip>:<service> \
unit <unit_id>\
target virtual <ip>:<service> \
clientssl enable \
clientssl key <clientssl_key> \
clientssl cert <clientssl_cert> \
serverssl enable
Optionally, you may specify a key file and a certificate file for the proxy as a client. To do this, type the following command:
b proxy <ip>:<service> \
unit <unit_id> \
target virtual <ip>:<service> \
clientssl enable \
clientssl key <clientssl_key> \
clientssl cert <clientssl_cert> \
serverssl enable \
serverssl key <serverssl_key> \
serverssl cert <serverssl_cert>
When the client-side and server-side SSL gateway is written in the /config/bigip.conf file, it looks like the sample in Figure 7.13.
Figure 7.13 An example client-side and server-side SSL gateway configuration
proxy 10.1.1.1:https unit 1 {
target virtual 20.1.1.1:https
clientssl enable
clientssl key my.server.net.key
clientssl cert my.server.net.crt
serverssl enable
serverssl key my.client.net.key
serverssl cert my.client.net.key
}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
- On the BIG-IP, open the Akamai configuration file /etc/config/akamai.conf in an editor like vi or pico.
- 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
- 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.
- 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
- 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 <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 7.14.
Figure 7.14 An example content converter gateway configuration
proxy 10.1.1.1:https unit 1 {
target virtual 20.1.1.1:http
akamaize enable
}Disabling ARP requests
By default, the BIG-IP 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.
Disabling VLANs for a gateway
A gateway is mapped by default to all VLANs on the internal and external networks of the BIG-IP. Any VLANs to which the gateway is not to be mapped must be explicitly disabled using the vlan <vlan_name> disable syntax.
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, 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), or if you want to exclude one or more routers from auto_lasthop you can direct your replies to the last hop router using a last hop pool. The lasthop pool will take precedence over auto_lasthop.
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 <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
Enabling, disabling, or deleting a gateway from the command line
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 gateway 209.100.19.22:80, you might type the following command:
b proxy 209.100.19.22:443 enable
If you want to disable the gateway 209.100.19.22:80, 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:80, type the following command:
b proxy 209.100.19.22:443 delete
Displaying configuration information for a gateway from the command line
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:443, type the following command:
b proxy 209.100.19.22:443 show
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 effect 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 7.15.
Figure 7.15 Ratio weights for node addresses
192.168.200.51 ratio = 3
192.168.200.52 ratio = 1To 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 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:
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. Rules allow a virtual server to access any number of pools on the BIG-IP. For more detailed information about using rules, see Health monitors, on page 3-87.
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 3-87.
Table 7.9 lists all the elements you can use to create rules.
save
b save [ <filename> | - ]
b base save [ <filename> | - ]The bigpipe save and base save write the current BIG-IP 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 units 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. A self IP address is an IP address mapping to a VLAN or VLAN group and their associated interfaces on a BIG-IP. A one true self IP address is assigned to each interface on the unit as part of first time boot configuration, and also a floating (shared) self IP address for units 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 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 7-90.
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 7.16.
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 7-90.
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. 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 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
stp
b stp <stp_name> interfaces add <if _list> | all
b stp <stp_name> hello <interval>
b stp <stp_name> max_age <interval>
b stp <stp_name> forward_delay <interval>
b stp <stp_name> interfaces delete <if _list>
b stp <stp_name> enable|disable
The BIG-IP IP Application Switch provides Spanning Tree Protocol (STP) implementation for loop resolution in configurations where one or more external switches is connected in parallel with the BIG-IP. This feature allows you to configure two or more interfaces on the platform as an STP domain. For interfaces in the STP domain, the spanning tree algorithm identifies the most efficient path between the network segments, and establishes the switch associated with that path as the root. Links forming redundant paths are shut down, to be re-activated only if the root fails.
The STP domain should contain all ports that are connected in parallel to an external switch where there are nodes on the link capable of generating or receiving traffic. You will want a second domain if there is an additional switch or switches connected in parallel with additional BIG-IP interfaces.
Warning: Use of STP may slow performance significantly, particularly if more than one STP domain is created, and may have unforeseen effects on complex networks. It is important to test your STP configuration before placing it online. For more information about Spanning Tree Protocol, refer to IEEE 802.1D.
Creating and deleting STP domains
To create an STP domain from the command line, use the following syntax.
b stp <stp_name> interfaces add <if _list> | all
For example, if you want to create an STP domain named mystp that contains the interfaces 1.1 and 1.2, type the following command:
b stp mystp interfaces add 1.1 1.2
If you want to create an STP domain named mystp that contains all interfaces on the BIG-IP, type:
b stp <stp_name> interfaces add all
To delete an STP domain, use the following syntax:
b stp <stp_name> delete
Setting time intervals for an STP domain
You can set the time intervals in seconds for hello, max_age, and forward_delay for the STP domain using the following syntax:
b stp <stp_name> hello <interval>
b stp <stp_name> max_age <interval>
b stp <stp_name> forward_delay <interval>
Adding or deleting interfaces in an STP domain
To add interfaces to an STP domain, use the following syntax:
b stp <stp_name> interfaces add <if _list>
To delete interfaces from an STP domain, use the following syntax:
b stp <stp_name> interfaces delete <if _list>
Disabling and re-enabling an STP domain
To disable an STP domain, use the following syntax:
b stp <stp_name> disable
To re-enable interfaces on an STP domain, use the following syntax:
b stp <stp_name> enable
Note: Disabling or deleting all interfaces on an STP domain causes the domain to be disabled. It cannot be re-enabled without adding interfaces.
Disabling and re-enabling interfaces in an STP domain
To disable specific interfaces in the STP domain, use the following syntax.
b stp <stp_name> interfaces disable <if_list>
To re-enable interfaces in an STP domain, use the following syntax.
b stp <stp_name> interfaces enable <if_list>
summary
b summary
Displays a summary of current usage statistics. The output display format for the summary command is shown in Figure 7.17. You can find detailed descriptions of each of statistic displayed by the summary command in Monitoring the BIG-IP, on page 11-2
Figure 7.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.10trunk
b trunk <controlling_if> define <if_list>
b trunk [<controlling_if>] show [verbose]
b trunk [<controlling_if>] stats reset
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. Gigabit and fast ethernet links cannot be placed in the same trunk.
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 2-2.
unit
b unit [show]
b unit peer [show]The unit number on a BIG-IP designates which virtual servers use a particular unit in an active-active redundant configuration. You can use the bigpipe unit command to display the unit number assigned to a particular BIG-IP. 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 BIG-IP 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 unit shows as unit 1 and 2, and the standby unit has no unit numbers.
Tip: The bigpipe unit peer show command is the best way to determine whether the respective state mirroring mechanisms 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 7.10 defines the command and shows the equivalencies.
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 operating system and the features enabled.
For example, for a BIG-IP HA, the bigpipe version command displays the output shown in Figure 7.18
Figure 7.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 Filtervirtual
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>] 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 7-41.
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 7-60.
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 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. 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 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, 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 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 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, 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 you want to exclude one or more routers from auto_lasthop, or if 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. If auto_lasthop is enabled, the last hop pool takes precedence.
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 unit maintains the same state information as the active unit. Then when a failover occurs, transactions such as FTP file transfers continue as though uninterrupted.
Note: Mirroring slows BIG-IP 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 was last rebooted, or since the BIG-IP 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 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
vlan <vlan name> l2_agingtime <seconds>
vlan <vlan name> fdb add <MAC address> interface <ifname>
vlan <vlan name> fdb delete <MAC address> interface <ifname>
vlan <vlan name> fdb static show
vlan <vlan name> fdb dynamic show
vlan <vlan name> fdb show
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 7.11
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 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 (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 through that VLAN.
Setting the fail-over timeout and arming the fail-safe
For redundant BIG-IP 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. You can enable a failsafe mechanism 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 the following command:
b vlan <vlan_name> timeout <timeout_in_seconds>
To arm the failsafe, use this command:
b vlan <vlan_name> failsafe arm
To disarm the failsafe, use this syntax:
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 units 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 units 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 unit 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 units in the redundant system.
b vlan <vlan_name> 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 bigpipe 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 units in the redundant system.
The shared MAC address is used only when the BIG-IP 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 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.
Viewing and editing the L2 forwarding table
As described in VLAN grouping and L2 forwarding, on page 2-7, L2 forwarding is the means by which packets are exchanged directly between nodes on separate VLANs that are members of the same VLAN group. You accomplish this by using a simple forwarding table for each VLAN with proxy forward enabled. The forwarding table has an entry for each node in the VLAN, and associates the MAC address of that node with the BIG-IP interface using this format:
<MAC address> -> <if>
For example:
00:a0:c9:9e:1e:2f -> 4.1
You can view this table and you can add and delete entries. Automatically learned entries are called static. Entries that you add manually to the table are called dynamic. You can view and editing the L2 forwarding table using the bigpipe vlan <vlan_name> fdb command.
To view the L2 forwarding table from the command line
To view the L2 forwarding table, type the following command:
b vlan <vlan name> fdb show
For example, to view the L2 forwarding table for the internal VLAN, type the following command:
b vlan internal show
This produces a response like this:
Forwarding table --
00:40:05:30:cc:94 -> 5.1
To view L2 forwarding table static entries from the command line
To view the L2 forwarding static table entries from the command line, use the following syntax:
b vlan <vlan name> fdb show
For example, to view the static entries for the internal VLAN, type the following command:
b vlan internal show
To view L2 forwarding table dynamic entries from the command line
To view the L2 forwarding dynamic table entries from the command line, use the following syntax:
b vlan <vlan name> fdb dynamic show
For example, to view the dynamic entries for the internal VLAN, type the following command:
b vlan internal dynamic show
To add an entry to the L2 forwarding table at the command line
To add an entry to the L2 forwarding table, use the following syntax:
b vlan <vlan name> fdb add <MAC address> interface <ifname>
For example:
b vlan internal fdb add 0:d0:b7:61:27:48 interface 4.1
To delete an entry from the L2 forwarding table at the command line
To delete an entry to the L2 forwarding table, use the following syntax:
b vlan <vlan name> fdb delete <MAC address> interface <ifname>
For example:
b vlan <vlan name> fdb delete 00:a0:c9:9e:1e:2f interface 4.1
vlan <vlan name> fdb static show
vlan <vlan name> fdb dynamic show
vlan <vlan name> fdb show
Setting the L2 forwarding aging time
Entries in the L2 forwarding table have a life span, after which they are removed from the table if the MAC address is no longer present on the network. This is called the L2 forward aging time and it is set using the global command bigpipe global l2_agingtime as follows:
b global l2_agingtime <time_in_seconds>
Example:
b global l2_agingtime 200
The default value is 300 seconds.
vlangroup
b vlangroup <vlagroup_name> { vlans add <vlan_list> }
b vlan <vlangroup_name> proxy_forward enable | disable
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.
- On the BIG-IP, open the Akamai configuration file /etc/config/akamai.conf in an editor like vi or pico.