Applies To:

Show Versions Show Versions

Archived Manual Chapter: BIG-IP Link Controller Reference Guide v4.3: Monitoring and Administration
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

This article has been archived, and is no longer maintained.



6

Monitoring and Administration



Monitoring and administration utilities

The Link Controller platform provides several utilities for monitoring and administration of the Link Controller. You can monitor system statistics, as well as statistics specific to virtual servers and nodes, such as the number of current connections, and the number of packets processed since the last reboot.

The Link Controller platform provides the following monitoring and configuration and administration utilities:

  • 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 Link Controller.
  • The Configuration utility
    You can use the Configuration utility to configure any feature on the Link Controller. You can reset any statistic, or all statistics, for virtual servers, nodes, NATs, and SNATs in the Configuration utility.
  • BIG/stat
    This utility is provided specifically for statistical monitoring of virtual servers, nodes, NATs, SNATs, and services. One benefit of using BIG/stat is that you can customize the display of statistical information.
  • Syslog
    Syslog is the standard UNIX system logging utility, which monitors critical system events, as well as configuration changes made on the Link Controller.

Using the bigpipe utility as a monitoring tool

Using the bigpipe utility, you can view information about the Link Controller 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 Link Controller

The bigpipe summary command displays performance statistics for the Link Controller itself. You can use these statistics to monitor and troubleshoot your Link Controller.

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

b summary

If you need to reboot the Link Controller 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, on page 6-8 .

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

Figure 6.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 = 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 6.1 contains descriptions of each individual statistic included in the bigpipe summary display screen.

bigpipe monitoring statistics

Statistic

Description

total uptime

Total time elapsed since the Link Controller 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 Link Controller 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 treaper or UDP timer. This is important to note, because a Link Controller with short time-outs is likely to show more connections than a Link Controller with long time-outs.

total # pkts

Total number of packets handled by the Link Controller 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 Link Controller 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 Link Controller since the last reboot.

total # bits (inbound)

Total number of incoming bits handled by the Link Controller since the last reboot.

total # pkts (outbound)

Total number of outgoing packets handled by the Link Controller since the last reboot. Outgoing packets are packets that originated at the Link Controller.

total # bits (outbound)

Total number of outgoing bits handled by the Link Controller since the last reboot.

error no nodes available

The number of times the Link Controller 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 systems 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 statistics 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 Link Controller. 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 Link Controller, and not 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 GUI.

For example, 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 Link Controller 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 Link Controller. 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 Link Controller, and not 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 GUI.

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 Link Controller 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 GUI.

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 Link Controller 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 GUI.

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 Link Controller 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 Link Controller; 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 Link Controller. 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 are 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 nodes frequently appear to be marked unavailable.

virtual maint mode deny

The number of times a connection to a virtual server was denied while the Link Controller 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 Link Controller 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 Link Controller.

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.

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, Link Controller 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. Link Controller 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 Link Controller 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 Link Controller 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 Link Controller with a destination of the shared alias. Because the Link Controller was in standby mode, this packet was dropped.

This is most likely to occur when a Link Controller 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 Link Controller.

dropped inbound

The total number of inbound packets dropped by the Link Controller because the source IP address is other than a Link Controller address.

dropped outbound

The total number of outbound packets dropped by the Link Controller because the source IP address is the Link Controller address.

reaped

The total number of TCP connections that timed-out and were therefore deleted by the Link Controller.

ssl reaped

The total number of SSL persistence records based on SSL session IDs that timed-out and were therefore deleted by the Link Controller. 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 Link Controller. 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 Link Controller. 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 occurring, the Link Controller 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 Link Controller.

mem percent used

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

Retaining current statistics during reboot

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

 # 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

Figure 6.2 Script for saving summary statistics

Resetting statistics on the Link Controller

The bigpipe commands allow you to selectively reset any statistic on the Link Controller. 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 internal set 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

Use the following syntax to reset 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 command:

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 syntax to reset statistics for all virtual ports:

b service stats reset

Use the following 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 a list of virtual ports, use the following command:

b service 23 80 443 stats reset

To reset statistics for network address translations (NATs)

Use the following syntax 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 a list of origin IPs, 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 syntax 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 a list of SNAT origin addresses, 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 in 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.

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 Link Controller.

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 Link Controller displays the statistics as shown in Figure 6.3 .

Figure 6.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 Link Controller. 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 Link Controller. 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 Link Controller displays the statistical information as shown in Figure 6.4 .

Figure 6.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 Link Controller. 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 6.5.

Figure 6.5 NAT statistics

 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 Link Controller. 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

Using the Configuration utility for administration and monitoring

You can use the Configuration utility System Admin screen to add users, customize the user interface, configure SNMP, and save and restore a current configuration.

You can use the Configuration utility to allow access to the SNMP agent and to set SNMP properties. For more information on configuring SNMP, refer to Chapter 9, Configuring SNMP .

Adding a user

You can add a user to the Link Controller using the Configuration utility.

To add a user to the Link Controller using the Configuration utility

  1. In the navigation pane, click System Admin.
    The System Admin tabs appear.
  2. Click the User Administration tab.
    The Add User screen opens. This screen contains a list of current users.
  3. In the appropriate field, type the User ID, password, and access level for the user.
    For more information on the Add User screen, click the Help button.

Customizing the Configuration utility

You can customize the appearance of the Configuration utility.

To customize the Configuration utility

  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.

Configuring SNMP

For information on configuring SNMP, refer to Chapter 9, Configuring SNMP .

Working with the Syslog utility

The Link Controller 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 Link Controller 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 6.2 shows sample log messages to give you an idea of how the Syslog utility tracks events that are specific to the Link Controller.

Sample Syslog messages

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 Link Controller.

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 Link Controller

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

To shut down the Link Controller software from the command line

To complete the first task to shut down the Link Controller software, type the following command:

halt

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

Removing and returning items to service

Once you have completed the initial configuration on the Link Controller, 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 Link Controller allows the node to go down only after all the current connections are complete. During this time, the Link Controller does not attempt to send new connections to the node. Although the Link Controller monitoring features do 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 Link Controller from service, or you can remove the following individual items from service:

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

Removing the Link Controller from service

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

The bigpipe maint command toggles the Link Controller into or out of Maintenance mode. Use the following command to put the Link Controller in maintenance mode:

b maint

If the Link Controller runs in Maintenance mode for less than 20 minutes and you return the machine to the normal service, the Link Controller quickly begins accepting connections. However, if the Link Controller 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 Link Controller also supports taking only selected virtual servers, addresses, or ports out of service, rather than removing the Link Controller 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, type the appropriate command:

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

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

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

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 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, type the appropriate command:

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

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

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

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 additional information about using bigpipe commands on the Link Controller, 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:

  • Link Controller 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 Link Controller system log, which displays standard UNIX system events
  • The Link Controller log, which displays information specific to Link Controller events, such as defining a virtual server
  • The Pinger log, which displays status information determined by each node ping issued by the Link Controller

Printing the connection table

The bigpipe command line utility 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.

Changing passwords

When you run the Setup utility, you define a password that allows remote access to the Link Controller, and you also define a password for the Link Controller web server. You can change these passwords at any time.

To change the Link Controller password

  1. At the Link Controller command line prompt, log on as the root user and use the passwd command.
  2. At the password prompt, enter the password you want to use for the Link Controller and press Enter.
  3. To confirm the password, retype it and press Enter.

Changing passwords and adding users for the Configuration utility

You can create new users for the Link Controller web server by using the Configuration utility.

The user accounts you create in the Configuration utility can have full, partial, or read-only access to the Link Controller.

To create user accounts using the Configuration utility

  1. In the navigation pane, click User Admin.
    The User Administration screen opens.
  2. 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.
  3. In the Current Users list, select the access level for the user. The access levels available are:

    • Read Only
      This access level allows the user only to view information in the Configuration utility. Users with this access level do not have access to Add buttons, certain tab items, Apply buttons, or Remove buttons.
    • Partial Read/Write
      In addition to allowing the user to view information, a Partial Read/Write user can also change the status of node addresses to either enabled or disabled.
    • Full Read/Write
      This access level provides the user with full access to all administrative tasks.
  4. After you select the access level for the user, click the Add button.

The Current User list on the User Administration screen contains all users configured to access the Configuration utility. You can delete any user added through the Configuration utility by clicking the Remove button next to the user in the list. The Link Controller web server administrator account you created with the Setup utility shows up in this list. However, you cannot edit or delete this account from the Configuration utility. To edit this account, you must run the Setup utility and choose the Configure Web servers menu option. For more information about this utility, see Chapter 2, Using the Setup Utility, in the BIG-IP Link Controller Solutions Guide.

Working with the BIG/stat utility

BIG/statTM is a utility that allows you to quickly view the status of the following elements:

  • Virtual servers
  • Services (cur, max, limit, tot) (pckts,bits) in out
  • Nodes (cur, max, limit, tot) (pckts,bits) in out
  • Ports
  • Network address translations (NATs)

You can customize the BIG/stat utility statistics display. For example, you can customize your output to display statistics for a single element, or for selected elements. You can set the display to automatically update at time intervals you specify.

The bigstat command accepts one or more options, which allow you to customize the statistical display. When you use the bigstat command without specifying any options, the BIG/stat utility displays the list of virtual servers, services, nodes, NATs, and SNATs only one time. The basic command syntax is:

bigstat [ options...]

Table 6.3 describes the options that you can use in the bigstat command.

The bigstat command options

Option

Description

-bigip

Displays totals for the Link Controller overall.

-c <count>

Sets the interval at which new information is displayed.

-h and -help

Displays the help options.

-n

Displays data in numeric format.

-nat

Displays network address table (NAT) entries only.

-no_virtualtot

Removes virtual server totals from the display.

-no_nodetot

Removes node totals from the display.

-node

Displays nodes only.

-port

Displays ports only.

-v

Displays version information.

-virtual

Displays virtual servers only.

Figure 6.6 contains an example of the output from the bigstat command. Table 6.4 contains descriptions of each of the items in this example.

Figure 6.6 Sample output of the bigstat command

 bigip springbank          
(cur, max, tot) = (0, 8, 374)
(pckts,bits) in = (15310, 10860064), out = (28363, 313009048)
virtual 11.11.11.50
(cur, max, limit, tot) = (0, 8, 370, 370)
(pckts,bits) in = (10704, 8744872), out = (21480, 230874016)
virtual 11.11.11.50:http UP
(cur, max, limit, tot) = (0, 8, 370, 370)
(pckts,bits) in = (10704, 8744872), out = (21480, 230874016)
virtual 11.11.11.101
(cur, max, limit, tot) = (0, 2, 4, 4)
(pckts,bits) in = (4532, 2090768), out = (6824, 82113984)
virtual 11.11.11.101:http UP
(cur, max, limit, tot) = (0, 2, 4, 4)
(pckts,bits) in = (4532, 2090768), out = (6824, 82113984)
node 11.12.11.100 UP
(cur, max, limit, tot) = (0, 8, 374, 374)
(pckts,bits) in = (15236, 10835640), out = (28304, 312988000)
node 11.12.11.100:http UP
(cur, max, limit, tot) = (0, 8, 374, 374)
(pckts,bits) in = (15236, 10835640), out = (28304, 312988000)
port WILDCARD PORT
(cur, max, limit, tot, reaped) = (0, 0, 0, 0, 0)
(pckts,bits) in = (0, 0), out = (0, 0)
port 80:http
(cur, max, limit, tot, reaped) = (0, 8, 374, 374, 6)
(pckts,bits) in = (15236, 10835640), out = (28304, 312988000)

The following table contains descriptions of each of the metrics collected for the Link Controller.

Data displayed by the bigstat utility

BIG/stat Item

Description

BIG-IP

cur - Shows the number of current connections handled by the Link Controller

max - Shows the maximum number of connections handled by the Link Controller

tot - Shows the total number of connections handled by the Link Controller

pckts,bits in - Shows the total number of packets and bits coming into the Link Controller

pckts,bits out - Shows the total number of packets and bits going out of the Link Controller

virtual server

cur - Shows the number of current connections handled by the virtual server

max - Shows the maximum number of connections handled by the virtual server

limit - Shows the connection limit reached by the virtual server

tot - Shows the total number of connections handled by the virtual server

pckts,bits in - Shows the total number of packets and bits coming into the virtual server

pckts,bits out - Shows the total number of packets and bits going out of the virtual server

service

cur - Shows the number of current connections handled by the service

max - Shows the maximum number of connections handled by the service

limit - Shows the connection limit reached by the service

tot - Shows the total number of connections handled by the Link Controller service

pckts,bits in - Shows the total number of packets and bits coming into the service

pckts,bits out - Shows the total number of packets and bits going out of the service

nodes

cur - Shows the number of current connections handled by the node

max - Shows the maximum number of connections handled by the node

limit - Shows the connection limit reached by the node

tot - Shows the total number of connections handled by the Link Controller node

pckts,bits in - Shows the total number of packets and bits coming into the node

pckts,bits out - Shows the total number of packets and bits going out of the node

ports

cur - Shows the number of current connections handled by the port

max - Shows the maximum number of connections handled by the port

limit - Shows the connection limit reached by the port

tot - Shows the total number of connections handled by the Link Controller port

reaped - Shows the number of connections reaped on the port

pckts,bits in - Shows the total number of packets and bits coming into the port

pckts,bits out - Shows the total number of packets and bits going out of the port

Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)