Manual Chapter : BIG-IP Reference Guide v4.5:Administering the BIG-IP System

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 4.6.1, 4.6.0, 4.5 PTF-08, 4.5 PTF-07, 4.5 PTF-06, 4.5 PTF-05, 4.5 PTF-04, 4.5 PTF-03, 4.5 PTF-02, 4.5 PTF-01, 4.5.9, 4.5.0
Manual Chapter


17

Administering the BIG-IP System


Monitoring and administration utilities

The BIG-IP system provides several utilities for monitoring and administering the BIG-IP system.

  • The Configuration utility
    You can use the Configuration utility to manage any feature on the BIG-IP system. For example, you can reset any statistic, or all statistics, for virtual servers, nodes, NATs, and SNATs, using the Configuration utility.
  • bigpipe
    If you type certain bigpipe commands, such as bigpipe virtual or bigpipe node, and use the show keyword in the command, the command displays statistical information about the elements that you configure using that command. You can also use bigpipe commands to selectively reset any statistic collected by the BIG-IP system.
  • bigtop
    The bigtop utility provides statistical monitoring. You can set a refresh interval, and you can specify a sort order.
  • Syslog
    Syslog is the standard UNIX system logging utility that monitors critical system events, as well as configuration changes made on the BIG-IP system.
  • bigdb
    bigdb is a database that contains various configuration information for the BIG-IP system.

Using the bigpipe utility as a monitoring tool

Using the bigpipe utility, you can view information about the BIG-IP system itself, as well as elements such as virtual servers, virtual addresses, virtual ports, nodes, and node addresses. Typically, the bigpipe utility provides the following statistics:

  • Current number of connections
  • Maximum number of concurrent connections
  • Total number of connections since the last system reboot
  • Total number of bits (inbound, outbound, total)
  • Total number of packets (inbound, outbound, total)

Monitoring the BIG-IP system

The bigpipe summary command displays performance statistics for the BIG-IP system itself. These statistics can be used to monitor and troubleshoot your BIG-IP system.

The output of the bigpipe summary command includes current usage statistics, such as the amount of time a BIG-IP system has been running since the last reboot. To display a summary of the performance statistics for the BIG-IP system, type the following command:

b summary

If you need to reboot the BIG-IP system but want to retain the current summary information, you can save the information in a file prior to rebooting. For more information, see Retaining current statistics during reboot .

The performance statistics display in the format shown in Figure 17.1 (the output has been truncated for this example).

Figure 17.1 The bigpipe summary display screen


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

BIG-IP no handler deny = 0
BIG-IP error not in out table = 0
BIG-IP error not in in table = 0
BIG-IP error virtual fragment no port = 0
BIG-IP error virtual fragment no conn = 0
BIG-IP error standby shared drop = 0
BIG-IP dropped inbound = 0
BIG-IP dropped outbound = 0
BIG-IP reaped = 0
BIG-IP ssl reaped = 0
BIG-IP persist reaped = 0
BIG-IP udp reaped = 0
BIG-IP malloc errors = 0
BIG-IP bad type = 0
BIG-IP mem pool total 96636758 mem pool used 95552 mem percent used 0.10
 

Explanation of summary statistics

Table 17.1 contains descriptions of each individual statistic included in the bigpipe summary display screen.

 

Statistic

Description

total uptime

Total time elapsed since the BIG-IP system was last booted. Output is displayed in days, hours, minutes, and seconds.

total uptime (secs)

Total uptime since the last reboot, displayed in seconds.

total # connections

Total number of connections handled by the BIG-IP system since the last reboot. In this case, a connection is a data path between a client machine, a virtual server, NAT or SNAT, and a node. Connections last until timed out by either a reaper or UDP timer. This is important to note, because a BIG-IP system with short time-outs is likely to show more connections than a BIG-IP system with long time-outs.

total # pkts

Total number of packets handled by the BIG-IP system since the last reboot. This value equals the sum of total # pkts (inbound) and total # pkts (outbound). By dividing this value by total uptime (secs), you can determine the average packets per second since the last reboot.

total # bits

Total number of bits handled by the BIG-IP system since the last reboot. This value should equal the sum of total # of bits (inbound) and total # bits (outbound). By dividing this value by total uptime (secs), you can determine the average bits per second since the last reboot.

total # pkts (inbound)

Total number of incoming packets handled by the BIG-IP system since the last reboot.

total # bits (inbound)

Total number of incoming bits handled by the BIG-IP system since the last reboot.

total # pkts (outbound)

Total number of outgoing packets handled by the BIG-IP system since the last reboot. Outgoing packets are packets that originated at the BIG-IP system.

total # bits (outbound)

Total number of outgoing bits handled by the BIG-IP system since the last reboot.

error no nodes available

The number of times the BIG-IP system tried to make a connection to a node, but no nodes were available. Because no nodes were available, the incoming packet was dropped. This is a serious error. If this number is non-zero, then one or more of the virtual servers is, or has been, unavailable.

For example, the following shows sample statistics for sytems A, B, and C.

System A: BIG-IP error no nodes available = 0

System B: BIG-IP error no nodes available = 11409162

System C: BIG-IP error no nodes available = 42

In this example, the statisitcs show that System A is healthy. System B, however, is unhealthy; in slightly over a month of up time, 11,000,000 instances of an unavailable server have occurred. System C is also unhealthy; although the number of times a virtual server has become unavailable is minimal, this averages to one such event per day of up time on this system. It should be possible to keep this number to zero.

tcp port deny

The number of times a client attempted to connect to an unauthorized TCP port on the BIG-IP system. This statistic indicates that a connection was attempted, but the TCP port requested was not open. Because the port was not open, the incoming packet was discarded. This applies only to administrative and alias addresses on the BIG-IP system, and not to virtual servers, NATs, or SNATs.

If the sysctl bigip.verbose_log_level is set to 2 or 15, the offending port and source IP address are logged in the file /var/log/bigip. Alternatively, the location of this log can be set in the Advanced Properties section of the browser interface.

The following shows sample statistics for systems A, B, and C:

System A: BIG-IP tcp port deny = 0

System B: BIG-IP tcp port deny = 16358

System C: BIG-IP tcp port deny = 58

In these examples, there is a wide disparity in port denials from system to system. System A is behind a firewall and has been available for a relatively short amount of time.

System B is not behind a firewall, and because of this, the system is intercepting many packets that would otherwise be filtered out by a firewall.

System C is behind a firewall, but a few packets appear not to have been discarded. In this case, the administrator should examine the BIG-IP system logs to determine the port and source address of these packets and then filter them out at the firewall.

udp port deny

The number of times a client attempted to connect to an unauthorized UDP port on the BIG-IP system. This statistic indicates that a connection was attempted, but the UDP port requested was not open. Because the port was not open, the incoming packet was discarded. This applies only to administrative and alias addresses on the BIG-IP system, and not to virtual servers, NATs, or SNATs.

If the sysctl bigip.verbose_log_level is set to 1 or 15, the offending port and source IP address are logged in the file /var/log/bigip. Alternatively, the location of this log can be set in the Advanced Properties section of the browser interface.

For example, the following shows sample statistics for systems A, B, and C:

System A: BIG-IP udp port deny = 0

System B: BIG-IP udp port deny = 16358

System C: BIG-IP udp port deny = 58

In these examples, there is a wide disparity in port denials from system to system. System A is behind a firewall and has been available for a relatively short amount of time.

System B is not behind a firewall, and because of this, the system is intercepting many packets that would otherwise be filtered out by a firewall.

System C is behind a firewall, but a few packets appear not to have been discarded. In this case, the administrator should examine the BIG-IP system logs to determine the port and source address of these packets and then filter them out at the firewall.

virtual tcp port deny

The number of times a client attempted to connect to an unauthorized TCP port on a virtual IP address. This statistic indicates that a connection was attempted to a virtual IP address, but used a TCP port that was not open. Because the port was not enabled for this virtual server, the incoming packet was discarded.

If the sysctl bigip.verbose_log_level is set to 8 or 15, the offending port and source IP address are logged in the file /var/log/bigip. Alternatively, the location of this log can be set in the Advanced Properties section of the browser interface.

For example, the following shows sample statistics for systems A, B, and C:

System A: BIG-IP virtual tcp port deny = 67

System B: BIG-IP virtual tcp port deny = 221313359

System C: BIG-IP virtual tcp port deny = 447

This is another statistic where a critical factor is whether or not the BIG-IP system is located behind a firewall. Systems A and C are placed behind a firewall, while System B is not.

Because System B is not behind a firewall, it has had to discard many more stray packets (over 221,000,000) than the systems protected by a firewall.

Although Systems A and C are located behind firewalls, some packets are still slipping through. This indicates that the firewall administrator has probably allowed all ports for each virtual IP address. By tightening security on the firewalls, it should be possible to reduce this statistic to zero. This example applies also to the next section.

virtual udp port deny

The number of times a client attempted to connect to an unauthorized UDP port on a virtual IP address. This statistic indicates that a connection was attempted to a virtual IP address, but used a TCP port that was not open. Because the port was not enabled for this virtual server, the incoming packet was discarded.

If the sysctl bigip.verbose_log_level is set to 4 or 15, the offending port and source IP address are logged in the file /var/log/bigip. Alternatively, the location of this log can be set in the Advanced Properties section of the browser interface.

For example, the following shows sample statistics for systems A, B, and C:

System A: BIG-IP virtual tcp port deny = 67

System B: BIG-IP virtual tcp port deny = 221313359

System C: BIG-IP virtual tcp port deny = 447

This is another statistic where a critical factor is whether or not the BIG-IP system is located behind a firewall. Systems A and C are placed behind a firewall, while System B is not.

Because System B is not behind a firewall, it has had to discard many more stray packets (over 221 million) than the systems protected by a firewall.

Although Systems A and C are located behind firewalls, some packets are still slipping through. This indicates that the firewall administrator has probably allowed all ports for each virtual IP address. By tightening security on the firewalls, it should be possible to reduce this statistic to zero.

max connections deny

The total number of connections denied because the maximum number of connections allowed was exceeded. This error indicates that the maximum number of connections was received on a port that has a connection limit configured. If port connection limits are configured, it is a good idea to monitor this statistic. The statistic indicates the exact amount of traffic being discarded by the port limit.

You can set port connection limits using the following bigpipe service syntax:

bigpipe service <port> limit <seconds>

virtual duplicate syn ssl

This error is obsolete and therefore should always be zero.

virtual duplicate syn wrong dest

The number of duplicate connection attempts from the same client (IP address and port combination) to a different virtual server. This error indicates that a connection arrived from a source port and IP address for which a connection already existed on the BIG-IP system; however, this connection requested a different destination. The existing connection was torn down and a new connection was created.

This is most likely to occur with packets coming from busy proxies where source ports are constantly being reused. These errors are common and should not be a cause for alarm.

For example, the following shows sample statistics for systems A, B, and C:

System A: BIG-IP virtual duplicate syn wrong dest = 0

System B: BIG-IP virtual duplicate syn wrong dest = 2673815

System C: BIG-IP virtual duplicate syn wrong dest = 324

In this example, System A has probably not encountered this error due to its limited up time.

System B has a very large value because the HTML contains links to another virtual server on the BIG-IP system. When these links are followed and coincide with reuse of a source port, the error is generated.

System C has a fairly average value. It is receiving some source port reuse, probably from large proxies such as AOL.

virtual duplicate syn node down

The number of duplicate connection attempts to a server that is unavailable when a connection to the server was made previously. This error indicates that a syn packet arrived and that a connection to a node was created. Later, another syn packet arrived but the node was unavailable. The existing connection was severed and a new connection to a different node was created to service the request.

This error is common when nodes are unreliable or over-burdened.

The seriousness of this error varies from site to site. In sites where there is a large number of low-capacity nodes, you see this error as nodes become over-burdened and then unavailable. This error is also more common with some load balancing modes, where certain nodes receive more connections than others.

For example, the following shows sample statistics for systems A, B, and C:

System A: BIG-IP virtual duplicate syn node down = 0

System B: BIG-IP virtual duplicate syn node down = 7442773

System C: BIG-IP virtual duplicate syn node down = 1

In this example, Systems A and C are healthy, while System B appears to have a serious problem. System B nodesappear to be frequently marked unavailable.

virtual maint mode deny

The number of times a connection to a virtual server was denied while the BIG-IP system was in maintenance mode. Current maintenance status can be determined by using the bigpipe maint command.

virtual addr max connections deny

The number of virtual IP address connections that were dropped because the maximum number of connections configured was exceeded.

A connection limit on a virtual IP address can be configured using the bigpipe virtual command, as shown in the following example:

bigpipe virtual 172.16.1.1 limit 100

virtual path max connections deny

The number of virtual path connections that were dropped because the maximum number of connections configured was exceeded.

A connection limit on a virtual server can be configured using the bigpipe virtual command, as shown in the following example:

bigpipe virtual 172.16.1.1:80 limit 100

virtual non syn

The number of packets received that are not connection requests, and are destined to a virtual IP address but not a valid virtual server (port). This error indicates that a packet arrived with a destination of a virtual server. However, this packet was not a syn and there was no existing connection. The packet was discarded because BIG-IP system only creates a new connection to a virtual server when it receives a syn packet.

This error is common and could occur for a variety of reasons.

It is typical for this number to grow very large. In most cases, this error occurs when packets arrive out of sequence or when packets are dropped before arriving at the BIG-IP system.

For example, the following shows sample statistics for systems A, B, and C:

System A: BIG-IP virtual non syn = 2

System B: BIG-IP virtual non syn = 1609400253

System C: BIG-IP virtual non syn = 10366

In this example, System A and System C show fairly typical values based on their up times.

System B shows a very large value which may indicate a problem. One possibility is that System B has a heavy traffic load and that a significant portion of this traffic must traverse a very long distance before arrival (European traffic to the US west coast, for example). Long physical distance seems to contribute to the kind of packet loss that results in this error. Another possibility is that a device on the local network is dropping packets. Large values in this statistic should be investigated at least enough to ensure that a local device is not the cause of the problem.

no handler deny

The number of packets from the middle of a flow that do not match any known virtual servers or entries in the connection table.

error virtual fragment no port

The number of IP fragments for which there is no port. This error indicates that a packet fragment arrived, but it was not the first fragment. Since the first fragment contains the port number and is required to set up a new connection, BIG-IP system discards the fragment.

This error is similar to virtual non syn, but refers to fragmented, rather than intact, packets. As with virtual non syn, this probably occurs because fragments arrive out of sequence or not at all. This is a common error and not usually a cause for concern.

error virtual fragment no conn

The number of IP fragments for which there is no connection. This error indicates that a packet fragment arrived, but it was not the first fragment. BIG-IP system previously received the first fragment, but it was not a syn packet and did not match an existing connection, causing it to be discarded.

This error is most likely to occur in conjunction with a virtual non syn. Thus, when BIG-IP system received the first packet, it found that the packet met the criteria for virtual non syn and dropped it; this error simply indicates that the BIG-IP system is dropping the following fragments of that packet. As with virtual non syn and virtual fragment no port, this error is relatively common and should not cause much concern.

error standby shared drop

The number of packets, destined to the shared IP address in a redundant system, that are received and ignored by the standby system. This error indicates that a packet arrived at the standby BIG-IP system with a destination of the shared alias. Because the BIG-IP system was in standby mode, this packet was dropped.

This is most likely to occur when a BIG-IP system has failed over, but the arp cache of another device has not yet been updated. Because that device is caching an invalid arp request, the device continues to send packets to the previously active BIG-IP system.

dropped inbound

The total number of inbound packets dropped by the BIG-IP system because the source IP address is other than a BIG-IP system address.

dropped outbound

The total number of outbound packets dropped by the BIG-IP system because the source IP address is the BIG-IP system address.

reaped

The total number of TCP connections that timed-out and were therefore deleted by the BIG-IP system.

ssl reaped

The total number of SSL persistence records based on SSL session IDs that timed-out and were therefore deleted by the BIG-IP system. The timeout for SSL persistence is configured when creating the virtual server.

persist reaped

The total number of non-SSL persistence records that timed-out and were therefore deleted by the BIG-IP system. Persistence timeouts are configured when creating the virtual server.

udp reaped

The total number of UDP connections that timed-out and were therefore deleted by the UDP timer of the BIG-IP system. UDP timers are configured with the bigpipe command, using the following syntax:

bigpipe udp <port> <timeout>

malloc errors

The number of times a connection could not be created due to insufficient memory. If this error is occuring, the BIG-IP system is overloaded and the configuration should either be streamlined, or the software and/or chassis should be upgraded.

mem pool total

The total amount of memory available in all combined memory pools.

mem pool used

The total amount of memory, in all combined memory pools, in use by the BIG-IP system.

mem percent used

The total percentage of memory in use by all combined memory pools.

 

Retaining current statistics during reboot

When you reboot the BIG-IP system, all existing summary statistics are deleted. If you need to reboot the BIG-IP system but want to save the existing summary statistics, you can a create shell script that saves the statistics and copies them to another file. The following shows an example of this script, named restart. Note that this script must reside in the /sbin directory.

Figure 17.2 Script for saving summary statistics


# restart script
bigpipe summary >/var/log/summary.`date +%d%m%y%H%M`
bigpipe ms >/var/log/ms.`date +%d%m%y%H%M`

echo "Reboot by /sbin/restart at `date +%d%m%y%H%M`" >/var/log/bigip
/bin/sync;/bin/sync
/sbin/reboot
 

Resetting statistics on the BIG-IP system

With the bigpipe commands, you can selectively reset any statistic on the BIG-IP system. The statistics you can reset selectively include:

  • Virtual address
  • Virtual server
  • Node address
  • Node server
  • Virtual port
  • Network address translations (NATs)
  • Secure network address translations (SNATs)
  • Global statistics

When you reset one of these items, the packets in, packets out, bytes in, and bytes out counters of the target item are reset to zero. The maximum connection count counter is also reset. The current connections counter is not reset, and the total connections counter is set equal to the number of current connections.

Note


The statistics are reset for the specified items only. Statistics for dependent items, such as node servers for a given virtual address, are not modified by these commands. The only exception is the global statistics reset option, which resets traffic statistics for all items. After an item-level reset, statistics for all other dependent items do not add up.

You can create an audit trail for reset events by setting an optional system control variable. You can set this variable to generate a syslog log entry. To set this variable, type the following command:

b global verbose_log_level 4

To reset statistics for virtual servers and virtual addresses

Use the following syntax to reset statistics for the virtual address specified by the IP address <virtual ip>.

b virtual <virtual_ip> stats reset

For example, if you want to reset statistics for the virtual address 172.20.1.100, type the following command:

b virtual 172.20.1.100 stats reset

If you want to reset statistics for a list of virtual addresses, type the command with a list of addresses separated by spaces:

b virtual 172.20.1.100 172.20.1.101 172.20.1.102 stats reset

If you want to reset statistics for all virtual servers, use the following command:

b virtual stats reset

Use the following syntax to reset statistics for the virtual server IP:port combination <virtual_ip>:<port>.

b virtual <virtual_ip>:<port> stats reset

For example, if you want to reset statistics for the virtual address/port combination 172.20.1.100:80, type the following command:

b virtual 172.20.1.100:80 stats reset

If you want to reset statistics for a list of virtual address/port combinations, type the command with the list of addresses separated by spaces:

b virtual 172.20.1.100:80 172.20.1.100:23 172.20.1.101:80 stats reset

To reset statistics for node servers and node addresses

The following command resets statistics for all node addresses and node servers:

b node stats reset

You can reset statistics for the node address specified by the IP address <node_ip>:

b node <node_ip> stats reset

For example, to reset the statistics for the node address 10.1.1.1, use the following command:

b node 10.1.1.1 stats reset

If you want to reset statistics for a list of node addresses, type the command with the list of addresses separated by spaces:

b node 10.1.1.1 10.1.1.2 10.1.1.3 stats reset

Use the following syntax to reset statistics for the node server specified by the IP:port combination <node_ip>:<port>:

b node <node_ip>:<port> stats reset

For example, to reset the statistics for the node server 10.1.1.1:80, use the following syntax:

b node 10.1.1.1:80 stats reset

If you want to reset statistics for a list of node server addresses, type the command with the list of addresses separated by spaces:

b node 10.1.1.1:80 10.1.1.2:23 stats reset

To reset statistics for virtual ports

Use the following command to reset statistics for all virtual ports:

b service stats reset

Use the following command syntax to reset statistics for the virtual port <port>. You can specify a list of virtual ports separated by spaces:

b service <port> stats reset

For example, to reset the statistics for the virtual port 80, use the following command:

b service 80 stats reset

To reset the statistics for virtual ports 23, 80, and 443, use the following command:

b service 23 80 443 stats reset

To reset statistics for network address translations (NATs)

Use the following command to reset statistics for all NATs:

b nat stats reset

Use the following syntax to reset statistics for the NAT for the IP address <orig_ip>.

b nat <orig_ip> stats reset

For example, to reset the statistics for the NAT 172.20.3.101, use the following command:

b nat 172.20.3.101 stats reset

To reset the statistics for origin IP addresses 172.20.3.101 and 172.20.3.102, use the following command where addresses are separated by spaces:

b nat 172.20.3.101 172.20.3.102 stats reset

To reset statistics for secure network address translations (SNATs)

Use the following command to reset statistics for all SNATs:

b snat stats reset

Use the following syntax to reset statistics for the SNAT for IP address <snat_ip>:

b snat <snat_ip> stats reset

For example, to reset the statistics for the SNAT 172.20.3.101, use the following command:

b snat 172.20.3.101 stats reset

To reset the statistics for SNAT origin addresses 172.20.3.101 and 172.20.3.102, use the following command where addresses are separated by spaces:

b snat 172.20.3.101 172.20.3.102 stats reset

To reset global statistics

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

b global stats reset

To reset any statistic using the Configuration utility

A Reset button is located in the Configuration utility in each of the following tables:

  • Virtual address
  • Virtual server
  • Node address
  • Node server
  • Virtual port
  • Network address translations (NATs)
  • Global statistics

To reset a statistic for a particular item, click the Reset button next to the item in one of these tables.


Printing the connection table

The bigpipe command line utility also offers a useful diagnostic tool that prints the list of current connections. Normally, the bigpipe conn command prints the client, virtual server, and node addresses.


Monitoring virtual servers, virtual addresses, and services

You can use different variations of the bigpipe virtual command, as well as the bigpipe port command, to monitor information about virtual servers, virtual addresses, and services managed by the BIG-IP system.


Displaying information about virtual servers and virtual addresses

The bigpipe virtual command displays the status of virtual servers (up, down, unchecked, or disabled), the current number of connections to each virtual server, and the status of the member nodes that are included in each virtual server mapping. The status for individual member nodes includes whether the node is up, down, unchecked, or disabled and also includes the cumulative count of packets and bits received and sent by the node on behalf of the virtual server. The BIG-IP system displays the statistics as shown in Figure 17.3 .



Figure 17.3 Virtual server statistics


virtual +------> 11.11.11.50 UNIT 1
| (cur, max, limit, tot) = (0, 8, 0, 370)
| (pckts,bits) in = (10704, 8744872), out = (21480, 230874016)
+---+--> PORT http UP
| (cur, max, limit, tot) = (0, 8, 0, 370)
| (pckts,bits) in = (10704, 8744872), out = (21480, 230874016)
POOL appgen_11.11.11.50.80
MEMBER 11.12.11.100:http UP
(cur, max, limit, tot) = (0, 8, 0, 370)
(pckts,bits) in = (10704, 8744872), out = (21480, 230874016)

virtual +------> 11.11.11.101 UNIT 1
| (cur, max, limit, tot) = (0, 2, 0, 4)
| (pckts,bits) in = (4532, 2090768), out = (6824, 82113984)
+---+--> PORT http UP
| (cur, max, limit, tot) = (0, 2, 0, 4)
| (pckts,bits) in = (4532, 2090768), out = (6824, 82113984)
POOL my_website_pool
MEMBER 11.12.11.100:http UP
(cur, max, limit, tot) = (0, 2, 0, 4)
(pckts,bits) in = (4532, 2090768), out = (6824, 82113984)
 

If you want to view statistical information about one or more specific virtual servers, simply include the virtual servers in the bigpipe virtual show command as shown below:

b virtual <virt addr>:<port> ... <virt addr>:<port> show

If you want to view statistical information about traffic going to one or more virtual addresses, specify only the virtual address information in the command:

b virtual <virt addr> ... <virt addr> show


Displaying information about services

The bigpipe port show command allows you to display information about specific virtual ports managed by the BIG-IP system. You can use the command to display information about all virtual services, or you can specify one or more particular virtual services.

To view information about all virtual services, use the following syntax:

b service show

To view statistical information about one or more specific virtual services, simply include the service names or port numbers as shown below:

b service <port> ... <port> show


Monitoring nodes and node addresses

The bigpipe node command displays the status of all nodes configured on the BIG-IP system. The information includes whether the specified node is up, down, disabled, or unchecked, and the number of cumulative packets and bits sent and received by each node on behalf of all virtual servers. The BIG-IP system displays the statistical information as shown in Figure 17.4 .

Figure 17.4 Node statistics screen


NODE 11.12.11.100 UP
| (cur, max, limit, tot) = (0, 8, 0, 374)
| (pckts,bits) in = (15236, 10835640), out = (28304, 312988000)
+- PORT http UP
(cur, max, limit, tot) = (0, 8, 0, 374)
(pckts,bits) in = (15236, 10835640), out = (28304, 312988000)
 

If you want to view statistical information about one or more specific nodes, simply include the nodes in the bigpipe node show command as shown below:

b node <node addr>:<port> ... <node addr>:<port> show

If you want to view statistical information about traffic going to one or more node addresses, specify only the node address information in the command:

b node <node addr> ... <node addr> show


Monitoring NATs

The bigpipe nat show command displays the status of the NATs configured on the BIG-IP system. The information includes the number of cumulative packets and bits sent and received by each NAT.

To display NAT status from the command line

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

b nat show

Use the following syntax to display the status of one or more selected NATs:

b nat <node addr> [...<node addr>] show

An example of the output for this command is shown in Figure 17.5 .

Figure 17.5 NAT statistics screen


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)
 

Monitoring SNATs

The bigpipe snat show command displays the status of the SNATs configured on the BIG-IP system. The information includes connections and global SNAT settings.

To show SNAT details from the command line

Use the following bigpipe command to show SNAT mappings:

b snat [<SNAT addr>] [...<SNAT addr>] show

b snat show

Use the following command to show the current SNAT connections:

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

b snat dump [ verbose ]

The optional verbose keyword provides more detailed output.

The following command prints the global SNAT settings:

b snat globals show


Viewing the status of the interface cards

The bigpipe interface command displays the current status and the settings for external and internal interface cards. You can also use the bigpipe interface command to view information for a specific interface card, using the following command syntax:

b interface <ifname> -show

Customizing the Configuration utility user interface

You can customize the appearance of the Configuration utility.

To customize the Configuration utility user interface
  1. In the navigation pane, click System Admin.
    The System Admin tabs appear.
  2. Click the Web UI Administration tab.
    The WEB UI Administration screen opens.
  3. Select the options you want to configure.
    For more information about the options available on this screen, click the Help button.

Working with the bigtop utility

The bigtopTM utility is a real-time statistics display utility. The display shows the date and time of the latest reboot, and lists activity in bits, bytes, or packets. The bigtop utility accepts options that allow you to customize the display of information. For example, you can set the interval at which the data is refreshed, and you can specify a sort order. The bigtop utility displays the statistics as shown in Figure 17.6 .

Figure 17.6 The bigtop screen display


| bits since | bits in prior | current
| Nov 28 18:47:50 | 3 seconds | time
BIG-IP ACTIVE |---In----Out---Conn-|---In----Out---Conn-| 00:31:59
227.19.162.82 1.1G 29.6G 145 1.6K 0 0

virtual ip:port |---In----Out---Conn-|---In----Out---Conn-|-Nodes Up--
217.87.185.5:80 1.0G 27.4G 139.6K 1.6K 0 0 2
217.87.185.5:20 47.5M 2.1G 3.1K 0 0 0 2
217.87.185.5:20 10.2M 11.5M 2.6K 0 0 0 2

NODE ip:port |---In----Out---Conn-|---In----Out---Conn-|--State----
129.186.40.17:80 960.6M 27.4G 69.8K 672 0 0 UP
129.186.40.17:20 47.4M 2.1G 3.1K 0 0 0 UP
129.186.40.18:80 105.3M 189.0K 69.8K 1.0K 0 0 UP
129.186.40.17.21 9.4M 11.1M 1.3K 0 0 0 UP
129.186.40.18:21 700.8K 414.7K 1.3K 0 0 0 UP
129.186.40.18:20 352 320 1 0 0 0 UP
 

Using bigtop command options

The syntax for the the bigtop command is as follows:

bigtop [options...]

Table 17.2 lists and describes the options you can use with the bigtop command.

 

Option

Description

-bytes

Displays counts in bytes (the default is bits).

-conn

Sorts by connection count (the default is to sort by byte count).

-delay <value>

Sets the interval at which data is refreshed (the default is four seconds).

-delta

Sorts by count since last sample (the default is to sort by total count).

-help

Displays bigtop help.

-nodes <value>

Sets the number of nodes to print (the default is to print all nodes).

-nosort

Disables sorting.

-once

Prints the information once and exits.

-pkts

Displays the counts in packets (the default is bits).

-scroll

Disables full-screen mode.

-virtuals <value>

Sets the number of virtual servers to print (the default is to print all virtual servers).

 

Using runtime commands in bigtop

Unless you specified the -once option, the bigtop utility continually updates the display at the rate indicated by the -delay option. You can also use the following runtime options at any time:

  • The u option cycles through the display modes: bits, bytes, and packets.
  • The q option quits the bigtop utility.

Working with the Syslog utility

The BIG-IP system supports logging using the Syslog utility. The logs are generated automatically, and saved in user-specified files. These logs contain all changes made to the BIG-IP system configuration, such as those made with the bigpipe virtual command, or other bigpipe commands, as well as all critical events that occur in the system.

Note


You can configure the Syslog utility to send email or activate pager notification based on the priority of the logged event.

The Syslog log files track system events based on information defined in the /etc/syslog.conf file. You can view the log files in a standard text editor, or with the less file page utility.


Sample log messages

Table 17.3 shows sample log messages to give you an idea of how the Syslog utility tracks events that are specific to the BIG-IP system.

 

Sample message

Description

bigd: allowing connections on port 20

A user specifically allowed connections on virtual port 20.

bigd: node 192.168.1.1 detected up

The 192.168.1.1 node address was successfully pinged by the BIG-IP system.

bigd: added service port 20 to node 192.168.1.1

A user defined a new node, 192.168.1.1:20.

kernel: security: port denial 207.17.112.254:4379 -> 192.168.1.1:23

A client was denied access to a specific port. The client is identified as coming from 207.17.112.254:4379, and the destination node is 192.168.1.1:23.

 

Powering down the BIG-IP system

If you want to power down, or turn off, the BIG-IP system, you need to complete two tasks. The first task is to shut down the BIG-IP system software. After you shut down the BIG-IP system software, you can turn the off the power to the system.

To shut down the BIG-IP software from the command line

To complete the first task to shut down the BIG-IP system software, type the following command:

halt

After the system halts, you can turn the power to the system off.

Removing and returning items to service

Once you have completed the initial configuration on the BIG-IP system, you may want to temporarily remove specific items from service for maintenance purposes. For example, if a specific network server needs to be upgraded, you may want to disable the nodes associated with that server, and then enable them once you finish installing the new hardware and bring the server back online.

If you specifically disable the nodes associated with the server, the BIG-IP system allows the node to go down only after all the current connections are complete. During this time, the BIG-IP system does not attempt to send new connections to the node. Although the BIG-IP system monitoring features would eventually determine that the nodes associated with the server are down, specifically removing the nodes from service can prevent interruptions on long duration client connections.

You can remove the entire BIG-IP system from service, or you can remove the following individual items from service:

  • Virtual servers
  • Virtual addresses
  • Virtual ports
  • Nodes
  • Node addresses

Removing the BIG-IP system from service

The BIG-IP system offers a Maintenance mode, which allows you to remove the BIG-IP system from network service. This is useful if you want to perform hardware maintenance, or make extensive configuration changes. When you activate Maintenance mode, the BIG-IP system no longer accepts connections to the virtual servers it manages. However, it allows the existing connections to finish processing so that current clients are not interrupted.

The bigpipe maint command toggles the BIG-IP system into or out of Maintenance mode. Use the following command to put the BIG-IP system in maintenance mode:

b maint

If the BIG-IP system runs in Maintenance mode for less than 20 minutes and you return the machine to the normal service, the BIG-IP system quickly begins accepting connections. However, if the BIG-IP system runs in Maintenance mode for more than 20 minutes, returning the unit to service involves updating all network ARP caches. This process can take a few seconds, but you can speed the process up by reloading the /config/bigip.conf file using the following command:

b -f /config/bigip.conf

To activate maintenance mode using the Configuration utility
  1. In the navigation pane, click System.
    The Network Map screen opens.
  2. Click the Properties tab.
    The Properties screen opens.
  3. Check the Maintenance Mode box.
  4. Click the Apply button.

Removing individual virtual servers, virtual addresses, and ports from service

The BIG-IP system also supports taking only selected virtual servers, addresses, or ports out of service, rather than removing the BIG-IP system itself from service. Each bigpipe command that defines virtual servers and their components supports enable and disable keywords, which allow you to remove or return the elements from service.

When you remove a virtual address or a virtual port from service, it affects all virtual servers associated with the virtual address or virtual port. Similarly, if you remove a node address from service, it affects all nodes associated with the node address.


Enabling and disabling virtual servers and virtual addresses

The bigpipe virtual command allows you to enable or disable individual virtual servers, as well as virtual addresses.

To enable or disable a virtual server from the command line

To enable or disable a virtual server, use the appropriate command syntax:

b virtual <virtual addr>:<virtual port> enable

b virtual <virtual addr>:<virtual port> disable

To enable or disable a virtual address, use the appropriate command syntax:

b virtual <virtual addr> enable

b virtual <virtual addr> disable


Enabling and disabling virtual ports

The bigpipe port command allows you to allow or deny traffic on a virtual port.

To allow or deny traffic on a virtual port from the command line

Use the following command syntax to allow or deny traffic on a virtual port:

b service <virtual port> enable

b service <virtual port> disable


Removing individual nodes and node addresses from service

You can enable or disable individual and node addresses from the command line.

To enable and disable nodes and node addresses from the command line

The bigpipe node command allows you to enable or disable individual nodes, as well as node addresses.

To enable or disable a node, use the appropriate command syntax:

b node <node addr>:<node port> enable

b node <node addr>:<node port> disable

To enable or disable a node address, use the appropriate command syntax:

b node <node addr> enable

b node <node addr> disable


Viewing the currently defined virtual servers and nodes

When used with the show parameter, bigpipe commands typically display currently configured elements. For example, the bigpipe virtual show command displays all currently defined virtual servers, and the bigpipe node command displays all nodes currently included in virtual server mappings. For more information about using bigpipe commands on the BIG-IP system, see Appendix A, bigpipe Command Reference .

Viewing system statistics and log files

The Configuration utility allows you to view a variety of system statistics and system log files. Note that from each statistics screen, you can access property settings for individual virtual servers, nodes, IP addresses, and ports by selecting the individual item in the statistics table.


Viewing system statistics

The Configuration utility allows you to view the following statistical information:

  • BIG-IP system statistics, including the elapsed time since the last system reboot, the number of packets and connections handled by the system, and the number of dropped connections
  • Virtual servers, including virtual servers, virtual address only, or virtual ports only
  • Nodes, including nodes, node addresses only, or node ports only
  • NAT statistics, such as the number of packets handled by each NAT
  • SNAT statistics, such as SNAT mappings
  • IP filter statistics, including the number of packets accepted and rejected by individual IP filters
  • Rate filter statistics, including the number of bits passed through, delayed, and dropped by individual rate filters
  • Information about illegal connection attempts, such as the source IP addresses from which the illegal connection is initiated

Statistics are displayed in real-time. You can specify the update frequency by setting an interval (in seconds), and then clicking Update.


Viewing log files

The Configuration utility allows you to display three different log files:

  • The BIG-IP system log, which displays standard UNIX system events
  • The BIG-IP log, which displays information specific to BIG-IP system events, such as defining a virtual server
  • The Pinger log, which displays status information determined by each node ping issued by the BIG-IP system

Managing user accounts

When you run the Setup utility for the first time to configure your base network, the BIG-IP system automatically creates two special user accounts--root and admin. As an option, you can also specify within the Setup utility that you want the BIG-IP system to create a third account, support, which gives F5 Networks support personnel access to your system. For information on using the Setup utility to create the root, admin, and support accounts, see Chapter 2, Using the Setup Utility .

Once the Setup utility has created these accounts, you will most likely want to create additional administrative accounts and assign various system access levels, or user roles, to them, on an ongoing basis.

The remainder of this chapter addresses the following topics:

  • Understanding user roles
  • Creating and authorizing local user accounts
  • Creating and authorizing remote user accounts
  • Managing passwords for local accounts
  • Managing system accounts

Understanding user roles

Users that have user roles assigned to them fall into one of two categories--fully-privileged users or restricted users. The following sections describe these user-role categories.


Fully-privileged users

Fully-privileged users are those who have full access to a BIG-IP system for administration purposes. When creating accounts for users to whom you want to grant full privileges, you can choose one of three different roles. The role you choose for a user depends on the type of interface that the user will use to administer the BIG-IP system. Because each role has full access to the BIG-IP system, users with these user roles have privileges to change their own roles or other users' roles.

The roles for fully-privileged users are:

  • Full Web Read/Write
    This access level provides the user with full access to all administrative tasks. Users with this access level can access the BIG-IP system through the Configuration utility and iControl, but not through the command line interface.
  • CLI + Full Web Read/Write
    This access level provides the user with full access to all administrative tasks. Users with this access level can access the BIG-IP system through all external interfaces--the Configuration utility, the command line interface, and the iControl interface.
  • CLI
    This access level provides the user with full access to all administrative tasks, using the command line interface.

The three roles for fully-privileged users all grant the same level of user access, that is, full access to the BIG-IP system. Thus, these roles are not intended as a way to restrict administative access; rather, they are provided strictly as a way to define the method of user access, for administrative convenience.


Restricted users

Restricted users are those whose administrative access to a BIG-IP system is limited. When creating accounts for users to which you want to restrict access, you can choose one of three different roles, where each role represents a different amount of access to the BIG-IP system. The role you choose depends on the amount of restricted access that you want to grant to the user. The roles for restricted users are:

  • Partial Web Read/Write
    This access level allows the user to view information and to change the status of node addresses to either enabled or disabled. Users with this access level can access the BIG-IP system through the Configuration utility only.
  • Web Read Only
    This access level allows the user to view information, using the Configuration utility only. Users with this access level do not have access to Add buttons, certain tab items, Apply buttons, or Remove buttons.
  • None
    This access level is the default access level, and prevents the user from accessing the BIG-IP system altogether.

The procedure that you use to create and manage user accounts depends on whether you have configured user authentication to use either the local LDAP database that resides on the BIG-IP system, or an external (remote) server. The following sections describe how to assign access levels based on these two different authentication scenarios.

Note


The root, admin, and support accounts require special consideration when managing them. For information on managing these accounts, see Managing system accounts .

Creating and authorizing local user accounts

When you are using the local LDAP database on the BIG-IP system to authenticate users, your BIG-IP administrative accounts (including user names and passwords) are created and stored in the local LDAP database on the BIG-IP system, using the Configuration utility. Then, you use the Configuration utility to assign a level of access, or user role, to each user account, and upon user authentication, the BIG-IP system checks the local LDAP database to determine the access level that is assigned to that user. An exception to this is the root account, which is stored in the UNIX /etc/passwd file, rather than in the local LDAP database.

You assign access levels to users at the time that you create their user accounts, or by changing the properties of an existing account.


Creating, changing, and deleting user accounts

You can use the Configuration utility to create new user accounts on the BIG-IP system. For each user account that you create, you can assign one level of access control.


To display a list of existing user accounts using the Configuration utility
  1. In the navigation pane, click System Admin.
  2. Click the User Administration tab.
    This displays a list of all existing local user accounts.

Note


The Configuration utility only displays those accounts that are stored in the local LDAP database. Thus, the root account does not appear in the list of user accounts, given that the account is stored elsewhere.
To create a user account using the Configuration utility
  1. In the navigation pane, click System Admin.
  2. Click the User Administration tab.
    This displays a list of all local user accounts, except for the root account.
  3. Click the Add button.
  4. In the Add User section, type the following information:

    • User ID
      Type the user ID you want to assign the user.
    • Password
      Type the password you want to assign the user.
    • Retype Password
      Retype the password you want to assign the user.
  5. Choose an access level for the user.
  6. Click Done.

To change the properties of a user account using the Configuration utility
  1. In the navigation pane, click System Admin.
  2. Click the User Administration tab.
    This displays a list of all local user accounts, except for the root account.
  3. Click a user account name.
    This displays the properties of that account.
  4. Change the password, or choose a new access level for the account.
  5. Click Apply.

Warning


If you have a redundant system configuration and you change the password on the admin account, you must also change the password on the redundant system, to ensure that the bigpipe config sync command operates correctly.
To delete a user account using the Configuration utility
  1. In the navigation pane, click System Admin.
  2. Click the User Administration tab.
    This lists the user roles currently assigned to remote user accounts.
  3. In the Local Users box, locate a user name for which you want to delete a user role and click the Delete button (trashcan icon). Note that you cannot delete the admin user account.

Creating and authorizing remote user accounts

When you are using a remote LDAP or RADIUS authentication server, you create and store your BIG-IP administrative accounts (including user names and passwords) on that remote server, using the mechanism supplied by that server's vendor.

To configure user authorization in this case, you use the Configuration utility and assign a specific access level, or user role, to each remote user account. This access information is then stored in the BIG-IP system's local LDAP database. When a user whose account information is stored remotely logs into the BIG-IP system and is granted authentication, the BIG-IP system then checks its local LDAP database to determine the access level that is assigned to that user.

If no user role is assigned to a remote user account, then the BIG-IP system assigns access based on a role called the Default Role. Using the Configuration utility, you can set the access level for the Default Role.

The following sections describe the procedures for assigning user roles to remote user accounts.


To display a list of user roles for remote accounts using the Configuration utility
  1. In the navigation pane, click System Admin.
  2. Click the User Administration tab.
    This displays the Remote User Roles box, which lists the remote user accounts to which you have assigned an access level, as well as the Default Role and its access level. Also displayed is the Local Users box, showing the admin account, which is always stored locally on the BIG-IP system.

Any user account that has not been assigned a remote user role automatically inherits the access level assigned to the Default Role.


To assign a user role for a remote account using the Configuration utility
  1. In the navigation pane, click System Admin.
  2. Click the User Administration tab.
  3. Click the Add User Role button.
  4. In the User ID box, type a user name that is stored on your remote authentication server.
  5. In the Access Level box, choose an access level to assign to that user.
  6. Click Done.

To change a user role for a remote account using the Configuration utility
  1. In the navigation pane, click System Admin.
  2. Click the User Administration tab.
    This lists the user roles currently assigned to remote user accounts.
  3. In the Remote User Roles box, click a user name.
    This displays the user role properties for that user account.
  4. In the Access Level box, select a different access level.
  5. Click Apply.

To delete a user role for a remote accounts using the Configuration utility
  1. In the navigation pane, click System Admin.
  2. Click the User Administration tab.
    This lists the user roles currently assigned to remote user accounts.
  3. In the Remote User Roles box, locate a user name for which you want to delete a user role and click the Delete button (trashcan icon).

Managing passwords for local user accounts

Sometimes, the users who have accounts stored in the local LDAP database might need to change their passwords. Users can change their passwords by accessing the User Administration screen of the Configuration utility, and then displaying the properties of their user accounts.

This method of changing a password applies not only to the user accounts you create from within the Configuration utility, but also to the admin and support accounts that the Setup utility created when you configured your base network.

For the procedure on changing passwords for locally-stored user accounts, see To change the properties of a user account using the Configuration utility .

Note


To change the password for the root account, you must re-run the Setup utility. For more information, see the following section.

Managing system accounts

As previously described, the Setup utility automatically creates three system accounts--root, admin, and support. Only the support account is optional.

These accounts must be managed in the following ways:

  • The root account
    The root account is defined in the /etc/passwd file on the BIG-IP system, and therefore does not reside in either the local LDAP database or a remote LDAP database. To initially create the root account and set its password, you run the Setup utility. To change its password later, you must re-run the Setup utility. Because the root account does not reside in the local or a remote LDAP database, it does not appear on the User Administration screens of the Configuration utility. The access level for this account is fixed during creation and cannot be changed.
  • The admin account
    The admin account is defined in the local LDAP database on the BIG-IP system. To initially create the admin account and set its password, you run the Setup utility. To change its password later, you use the Configuration utility's User Administration screens. Note, however, that due to redundant system considerations, you must change the password on both systems of the redundant system configuration, and you cannot delete the password for this account. The access level for this account is fixed during creation and cannot be changed, except when performing an upgrade.
  • The support account
    The support account is defined in the local LDAP database on the BIG-IP system. To initially create the support account and set its password, you run the Setup utility. Unlike the root and admin accounts, however, creation of the support account is optional. To change the password and access level for this account later, you use the Configuration utility's User Administration screens.

Working with the bigdb database

The bigdbTM database holds certain configuration information for the BIG-IP system. Most BIG-IP system utilities currently use the configuration stored in bigdb. The bigpipe db is provided for loading configuration information into bigdb. An additional default.txt file is included with the BIG-IP system which contains default information you can load into the bigdb database.


Using the bigpipe db command

The keys are viewed and set using the bigpipe db command.

b db get <key>

b db get <reg_exp>

b db set <key>

b db set <key> = <value>

b db unset <key>

b db unset <reg_exp>

b db dump [filename]


To display current setting of a bigdb configuration key

To display the value of a bigdb configuration key, use the following syntax:

b db get <key>

b db get <regular_exp>

For example, the following command displays the value of Local.Bigip.FTB.HostNumber:

b db get Local.Bigip.FTB.HostNumber

The following command displays the value of all local keys:

b db get Local.*


To set a bigdb configuration key

To create (set) a bigdb configuration key, use the following syntax:

b db set <key>

To set a bigdb configuration key and assign a value to it, use the following syntax

b db set <key> = <value>

For example, the following command sets Local.Bigip.FTB.HostNumber mode to on:

b db set Local.Bigip.FTB.HostNumber = 1


To unset a bigdb configuration key

To unset the bigdb configuration key, use the following syntax.

b db unset <key>

b db unset <regular_exp>

For example, the following command unsets Local.Bigip.FTB.HostNumber:

b db unset Local.Bigip.FTB.HostNumber

The following command unsets all local keys:

b db unset set Local.*


Working with the default.txt file

The default.txt file documents the keys that are valid in the BIG/store database. This file is located at /config/default.txt. It contains all the possible database keys, comments that document these keys, and the default values used by programs that run on the BIG-IP system.

Note


The values in the default.txt file are default values; several of the keys listed are not present in the bigdb database.

The default.txt file is intended to serve as documentation only. In order for the system to work, some of the records, such as those that represent IP addresses and port numbers, need to be set to values other than the default values for the system to work. Additionally, some of the key names listed are wildcard keys. These keys are not valid key names.

If you want to load default.txt into the bigdb database, we recommend that you dump the existing database to another text file. Make a copy of default.txt, and then edit the copy so that the records which are present in your dump file match the values contained in the default.txt file. After the values match, you can load the edited copy of default.txt.

For a complete list of the keys available in the bigdb, see Appendix B, bigdb Configuration Keys .