Release Notes : BIG-IP Controller Release Note, version 1.8.2

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 1.8.2
Release Notes
Original Publication Date: 05/15/1998 Updated Date: 04/18/2019

Summary:

This release note documents version 1.8.2 of the BIG-IP Controller software.

Contents:

What's New In Version 1.8.2

  • Fine-Grain Extended Content Verification

    Extended Content Verification (ECV), also known as Active Service Ping, may now be configured with different send and receive strings for each IP and port combination, where before, it could only be configured for each port.

    Previous /etc/bigd.conf syntax:

    active <port> [ <send_string> [ <recv_string> ] ]

    New etc/bigd.conf syntax:

    active [<ip>:]<port> [ <send_string> [ <recv_string> ] ]

    Where <port> can be a port number or service name, and <ip> can be an IP number in nnn.nnn.nnn.nnn notation, or a hostname.

    When BIG/ip is deciding how to service-ping a certain ip:port, it looks for a matching ip:port in the configuration file. If it cannot find one, it looks for a line that specified port only that has a matching port. If it can't find that, then it just does simple service ping.

    Example:

    active node0:80 "GET /" "I am node0" active 11.0.0.101:www "GET /" "I am node1" active www "GET /" "I am"

    If bigdnode tried to ping node2:www, it would try to match "I am", but if it tried to ping node0:www, it would try to match "I am node0".

  • Enhancements For Very Large Configurations

    • 512MB Memory Configuration

      Our new BIG/ip3 model can handle up to 512MB of memory for very large configurations. Please contact F5 Networks for more details.

    • Pinging Node Aliases

      A new command, "bigpipe alias", provides for increased control over how nodes are pinged. See SOL942: Reducing the impact of ICMP health checks by configuring node aliases for complete information.

      A slight change to the BIG/ip startup sequence is required in conjunction with the "alias" command. This change is now standard on new BIG/ip, but may need to be made manually when upgrading from a previous version.

    • VIP-NoArp Mode

      This new operating mode optimizes communication between BIG/ip and the external router. See Solution 270: VIP-NoArp Mode Technical Note for complete information.

    • Bigtop Fixes and Enhancements

      bigtop is no longer disabled for very large configurations. When a very large configuration is loaded into BIG/ip, bigtop will display the message "QUERYING..." in the upper-left corner of the window while it is reading statistics.

  • Manual Pages

    Online manual pages are now provided for the BIG/ip utilities. These are available by typing one of the following commands:

    man bigpipe
    man bigtop
    man bigstat
    man bigd
    man sod

    For detailed information, please consult the full BIG/ip manual.

  • Optional Forwarding Of Source-Routed Packets

    This is an alternative way to get access to servers behind BIG/ip. See Solution 203: How can I get access to my servers behind BIG-IP without using NAT? for complete information.

  • Priority Load Balancing Mode

    This new load balancing mode augments the existing 6 modes. Set it with the command:

    bigpipe lb priority

    It uses the ratios set for each node with the "bigpipe ratio" command, but it uses them in a different way than the ratio load balancing mode. The ratios are treated as priorities.

    The algorithm is: pick nodes in a round-robin way out of the the nodes that have the highest priority.

    Example:

    bigpipe lb priority
    bigpipe ratio n1 4
    bigpipe ratio n2 3
    bigpipe ratio n3 3
    bigpipe ratio n4 2
    bigpipe ratio n5 2
    bigpipe ratio n6 2
    bigpipe vip v1:80 define n1:80 n2:80 n3:80 n4:80 n5:80 n6:80

    If n1:80 is up, then all requests for v1:80 go to n1:80.

    If n1:80 is down but n2:80 and n3:80 are up, then alternating requests go to either n2:80 or n3:80.

    If n1:80 and n2:80 are down, then all requests go to n3:80.

    If n1:80, n2:80, and n3:80 are down, and n4:80, n5:80, and n6:80 are up, then the latter three nodes each get 1/3 of the requests.

    Refer to the manual for more information on the "bigpipe ratio" command for setting priorities, and the "bigpipe lb" command for setting load balancing modes.

  • Graphical User Interface

    The new GUI for BIG/ip, xbigpipe, is an X Windows client that displays on any X server through an SSH tunnel.

  • IP Source Check Disabled

    IP source checking is used for added security in environments that are prone to denial-of-service attacks. Unfortunately, IP source checking impacts BIG/ip performance far more than it really protects against such attacks. IP source checking is now disabled by default but can be enabled at the user's discretion using the "sysctl" command. Here's how:

    To enable:

    sysctl -w net.inet.ip.sourcecheck=1

    To disable:

    sysctl -w net.inet.ip.sourcecheck=0

    To display the current setting:

    sysctl net.inet.ip.sourcecheck

    To permanently alter the setting, edit the "/etc/rc.sysctl" file, and modify the appropriate sysctl command line.

  • Intra-Server Array Load Balancing Capability

    This feature, also known as "NAT Bounceback" makes it possible for a node behind BIG/ip to send a request to a VIP or a NAT address. The chief advantage of this capability is that servers may make load balanced requests of servers who are behind the same BIG/ip. To use this capability, it is necessary to define a NAT for the node which will be making intra-server array requests. A possible use of NAT bounceback is described below:

    In this example, there are two servers resolving names and three servers providing web content behind the same BIG/ip. The HTTP servers may resolve a name using a VIP that load balances the requests across both name servers. The configuration might look like this:

    vip 10.0.0.10:80 define 11.0.0.50:80 11.0.0.51:80 11.0.0.52:80
    vip 10.0.0.10:53 define 11.0.0.53:53 11.0.0.54:53
    nat 11.0.0.50 to 10.0.0.50
    nat 11.0.0.51 to 10.0.0.51
    nat 11.0.0.52 to 10.0.0.52

    The addresses of the HTTP servers within the server array are 11.0.0.50, 11.0.0.51 and 11.0.0.52. With this configuration, the HTTP servers may send packets to any externally visible address/port combination. In particular, the HTTP servers may send name resolution requests to 10.0.0.10:53. These requests will be load balanced across the two defined name servers.

  • Historical Maximum Connection Count

    BIG/ip now keeps track of an additional statistic: the historical maximum connection count. This is the highest value that the connection count ever attained since the last counter reset. This statistic is available through the bigpipe and bigstat commands for BIG/ip overall, for each VIP, for each Node, and for each port.

    In conjunction with this, the format of output of the bigpipe and bigstat commands is changed slightly to reduce confusion.

    Previously, connection counts were printed in this format:

    (cur, max, tot) = (0, 0, 0)
      cur
      Current connection count
      max
      Connection count limit (set with "bigpipe" command)
      tot
      Cumulative total connections since last reset

    Now, connection counts are printed in this format:

    (cur, max, limit, tot) = (0, 0, 0, 0)
      cur
      Current connection count (same as before)
      max
      Historical maximum connection count since last reset
      limit
      Connection count limit (set with "bigpipe" command)
      tot
      Cumulative total connections since last reset (same as before)

    To reduce confusion in the bigpipe command, the max keyword is being replaced by limit. For backward compatibility, both max and limit will be accepted for an indefinite time. Thus, limits may now be set with the following bigpipe commands:

    vip [ vip_ip[:port] vip_ip[:port] vip_ip[:port]... [limit <limit>] ]
    node [ <node_ip>[:<port>] <node_ip>[:<port>]... [ limit <limit> ] ]
    port [ <port> <port> <port>... [allow | deny] [ limit <limit> ] ]


    Note: bigpipe vip ... limit commands must always follow bigpipe vip define ... commands in configuration files. This is because:
    1. It is not possible to set a limit on a VIP which has not yet been defined.
    2. The limit is lost when a VIP is redefined.

  • Performance Improvement

    Data throughput has been increased 7 to 10%. For greater-than-T3 speeds, contact F5 Networks about our new BIG/ip3 model.

  • Syslog Changes

    • Additional active ping warnings: In active ping mode, when the data received from a node does not match the regular expression in /etc/bigd.conf, a warning is now issued through the syslog mechanism.

    • Reduced babble when no traffic is observed on an armed interface: With interfaces "armed", BIG/ip no longer logs messages just because there is no traffic. When there is no traffic, it does an ARP and then if there is no response, logs a warning message.

  • Minor Fixes and Improvements

    • persist and ssl are now separate and distinct commands: Previously, these commands were synonyms. Now there are two separate settings for each port: persist timeout and ssl timeout.

    • Bigtop Fix: Running bigtop before defining VIP's will no longer hang the bigtop process.

    • ping Command for Broadcast Address on BIG/ip Internal Net: On BIG/ip, the ping command can now be used to ping the broadcast address on the internal network.


What Was New In Version 1.8.1

  • Multiport Configurability

    BIG/ip now offers finer-grain control over VIPs and nodes. Each invocation of "bigpipe vip" now defines a virtual path for a single virtual IP address and port combination to a set of node IP address and port combinations. This is best described by example:

    bigpipe vip 192.168.101.10:80 define node1:80 node1:8001 node2:80 bigpipe vip 192.168.101.10:443 define node3:443 node4:443

    This configuration would send 1/3 of the HTTP traffic to a second web server on node1 that is attached to port 8001. It would route all of the SSL traffic (port 443) to node3 and node4 instead of node1 and node2.

  • NAT (Network Address Translation)

    NAT is a very powerful feature that gives nodes behind BIG/ip transparent access to the network in front of BIG/ip. This is particularly useful when nodes need access to database servers that are located somewhere else on the intranet or Internet. For example, if you previously configured a static route or ran the routing daemon on BIG/ip, or ran a DNS proxy on BIG/ip to allow your web servers to make DNS queries, you may find it more convenient and secure to just set up a NAT and allow your web servers direct access to the servers they need to talk to. Use the bigpipe nat command to define NAT paths through BIG/ip.

  • SSL

    BIG/ip now load balances SSL (Secure Sockets Layer), the WWW standard for secure web servers and web browsers. A special command, bigpipe ssl, is required to enable SSL on specific ports since BIG/ip must keep multiple connections in a single SSL session going to the same node.

  • Passive FTP

    Passive FTP is the file transfer mode used by FTP clients which are built into current versions of the popular web browsers. When BIG/ip is configured for FTP, it now supports traditional (active) FTP and passive FTP.

  • UDP

    BIG/ip now load balances UDP (User Datagram Protocol) for connectionless services such as DNS servers. Use the bigpipe udp command to enable UDP on specific ports and set persistence for those ports.

  • New Load Balancing Modes

    BIG/ip now features 6 different load balancing algorithms:

    • Round Robin
    • Ratio
    • Least Connection
    • Fastest
    • Observed
    • Predictive

    The bigpipe lb command selects which algorithm is used. The default is round_robin, which is the same as prior versions of BIG/ip. An additional command, bigpipe ratio is used in conjunction with ratio mode.

  • Configurable Connection Limits

    Users may now set maximum number of concurrent connections by port, VIP, VIP/port, node, or node/port. The default is unlimited. Refer to the bigpipe vip, bigpipe node, and bigpipe port commands in the Command Reference.

  • Active Service Ping

    Previously, BIG/ip "pinged" services by connecting to the specified port on a server and then immediately disconnecting. That mode is still the default, but now users may configure BIG/ip to do "Active Service Ping", in which an actual request is written to a server and then a response is read back from the server. The request is user configurable and the response is matched against a user-defined regular expression. Refer to the manual section on Controlling Pings for information on configuring this feature.

  • Configuration Synchronization

    The new command bigpipe configsync simplifies propagating configuration changes to the other BIG/ip in a BIG/ip HA configuration. This command is called after one or more bigpipe commands have changed the kernel configuration. The command writes the current configuration to the file, /etc/bigip.conf, and then if SSH RSA Authentication is properly configured between the two BIG/ip, the command also copies /etc/bigip.conf on the local BIG/ip to /etc/bigip.conf on the remote BIG/ip and then loads the the new configuration file to the kernel on the remote BIG/ip.

    The bigpipe configsync command is a shortcut for the following commands:

    bigpipe -s /etc/bigip.conf
    scp /etc/bigip.conf root@<ip-address>:/etc/bigip.conf
    ssh -l root <ip-address> /sbin/bigpipe -f /etc/bigip.conf

    To use the bigpipe configsync command, it is necessary to make the following configuration changes on each BIG/ip Controller:

    1. Create a /etc/bigip.failover file, containing the real IP address of the internal interface of the other BIG/ip. The file should contain one line in the following format:

          FailoverIp <ip-address>

    2. In the /etc/sshd_config file, verify that the "AllowHosts" line includes the IP address of the other BIG/ip.

    3. Run the following command to generate the /root/.ssh/identity and /root/.ssh/identity.pub files that incorporate NULL passphrases. Respond to all questions by pressing the <return> key as show below:

      # ssh-keygen <return>
      Enter file in which to save the key(/root/.ssh/identity): <return>
      Enter passphrase: <return>
      Enter the same passphrase again: <return>

    4. Append the contents of the /root/.ssh/identity.pub file to the remote BIG/ip's /root/.ssh/authorized_keys file, using the following command:

          cat /root/.ssh/identity.pub | ssh -l root \
              <ip-address-of-remote-BIGip> 'cat >> /root/.ssh/authorized_keys'

     

  • IP Filtering and Rate Shaping

    This feature allows you to control and/or prioritize access and bandwidth for each VIP by client IP, port, IP/port combo. Refer to the manual section on IP Filtering and Rate Shaping for information on configuring this feature.

  • New bigtop Utility

    A new utility, bigtop is now included with BIG/ip. It is a convenient way to monitor VIP and node statistics using a terminal or SSH session. Simply log in to BIG/ip and type bigtop.

  • Support For Very Large Configurations

    BIG/ip is now capable of handling up to 10,000 VIPs. If you have more than a few thousand VIPs or nodes, please contact F5 Networks Technical Support to discuss your configuration. In some of these cases, a memory upgrade may be required.


Known Problems In This Release

  • GUI Bug

    The process of building and editing a VIP tree in the Network View Tab can possibly cause a graphical representation of network components which doesn't reflect the actual BIG/ip configuration. These states generally follow component additions or deletions (VIP Port, Node, and/or Node Port) that leave incomplete VIP branches in the network tree, followed by the selection of "Apply". The results are benign; what is viewed as a reappearing, incomplete branch in the network tree or a false "deletion" command sent to BIG/ip do not reflect a true system state. The way to avoid this problem is to press "Apply" only when the network tree is composed of complete VIP->VIP Port->Node->Node Port branches.

    This potentially confusing state can be remedied by reloading the current configuration. Changes up to the last "Apply" issued by the user will be restored.

  • Serial port TERM environment variable is fixed to "ibmpc3"

    For 'dumb' terminals this causes problems when using the serial port of a BIG/ip for the first time boot and configuration script.


Manual Errata

  • bigpipe interface Command Syntax

    The BIG/ip manual shows incorrect syntax for the bigpipe interface command. The correct syntax is:

    interface [ <ifname> [ timeout [<seconds>] ] ]
    interface [ <ifname> [ mac_masq [<mac_addr>] ] ]

  • bigpipe persist Explanation

    The BIG/ip manual incorrectly describes the operation of persistence. The correct description is:

    Enables persistence on one or more ports for TCP traffic. Persistence forces new connections that have the same source address as a prior connection to use the sam enode and port as used by the prior connection for the specified period.
  • bigpipe udp Explanation

    The BIG/ip manual incorrectly describes the operation of UDP persistence. The last paragraph of the description should read:

    Persistence forces UDP packets that have the same source address as a prior UDP packet to use the same node and port as used by the prior UDP packets for the specified period.

Things You Must Know If Upgrading From A Version Prior To 1.8

In order to support the many new features in this version, the syntax of some bigpipe commands has changed. This means that any configuration files (particularly, the default configuration file, /etc/bigip.conf) must be modified.

  • The bigpipe vip command syntax has changed. Please refer to the Command Reference in the BIG/ip Installation and User's Guide for complete information.

    Previously you defined VIPs by doing:

    bigpipe vip <vip> define <node_ip> <node_ip> ...

    Now the syntax is:

    bigpipe vip <vip:port> define <node_ip:port> <node_ip:port> ...

    Separate bigpipe vip commands must be issued for each service name or port number. Other variations of this command are used to set connection limits (see New Features above.)

  • The bigpipe node command syntax has changed. Previously, it was necessary to define nodes. Now nodes are implicitly defined when they are specified in a VIP definition. The svc_on, svc_off, and svc_read options are now obsolete. The node command is now used to read information about nodes and to set connection limits (see New Features above.)

  • Manual configuration changes are required to support the new Configuration Synchronization command. (See New Features - Configuration Synchronization above.)


Special Note For International Customers

    SSH is required to remotely administer BIG/ip. This approach uses public-key cryptography to provide the highest level of security. Unfortunately, such a product is not exportable under the laws of the United States. Domestic versions of BIG/ip are provided with copies of a commercial version of SSH for Windows and Unix, called F-Secure SSH. International customers should obtain their own copies of SSH.

    F-Secure for Windows, Macintosh, and Unix is available commercially from:

      Data Fellows

      USA:   Europe:

      Data Fellows Inc.
      F-Secure SSH Sales
      675 N. First Street, Suite 605
      San Jose, CA 95112
      USA
      tel (408) 938 6700

      Data Fellows Ltd.
      F-Secure SSH Sales
      Paivantaite 8
      FIN-02210 Espoo
      FINLAND
      tel +358-9-478 444

    A free version of SSH for Unix is available from:


Upgrade Installation Instructions

    Please contact F5 Technical Support to arrange upgrades.


Where To Find More Info

  • New Manual

    The thoroughly revised and updated manual for version 1.8 describes all of the new commands and features. Please contact F5 Networks Technical Support to obtain a copy if you don't already have one.

  • New Technical Support Center Web Site at tech.f5.com. This site is exclusively for F5 customers. Please contact Technical Support to obtain the current password. This site contains these Release Notes, as well as our new Frequently Asked Questions file, and assorted additional information.

  • Check Out Our Corporate Web Site at www.f5.com