F5 Logo MyF5
Search
  1. MyF5 Home
  2. End-of-Life Products
  3. BIG-IP 1.x - 4.x
  4. BIG-IP Controller Release Note, version 1.8.3
Release Notes : BIG-IP Controller Release Note, version 1.8.3

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 1.8.3
Release Notes
Original Publication Date: 06/15/1998 Updated Date: 04/18/2019

Summary:

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

Contents:

Who Should Upgrade To 1.8.3?

    This release is recommended for all customers. It contains important bug fixes, several useful features, and a security fix for SSH.

Special Configuration Note For Customers With Nodes On Different Logical Networks From BIG/ip

    Customers that currently configure non-shared IP aliases on BIG/ip to provide for nodes that are on a different logical network than BIG/ip, must now use the following alternative configuration in the /etc/rc.local file:

    1. Remove all ifconfig commands configuriong IP aliases

    2. Add interface routes for each logical network other than the one that BIG/ip is on:

      route add -net <network> -interface <interface_name>

      For example:

      route add -net 17 -interface exp1

Installation Instructions

    These installation instructions apply to customers upgrading from previous versions of BIG/ip software, including 1.6 through beta versions of 1.8.2.4, and the latest 1.8.3 version. Users upgrading from 1.6.x versions should note that once you download the upgrade software, you need to apply the 1.6.x. patch (included in the upgrade software) before you install the 1.8.3 upgrade software.

  • Downloading the upgrade software and preparing for installation

    1. Click here and follow the instructions for using the F5 Networks FTP site.
    2. Download the dom-upgradev1.8.3.tgz
      file to the /var/tmp/183 directory on the target BIG/ip controller.
    3. Using the commands shown below, backup the existing configuration files on the BIG/ip controller. Users upgrading from version 1.6.x note that you cannot reuse your configuration files, and you do not need to complete this step.

      cp /etc/bigip.conf /etc/bigip.conf.mmddyy cp /etc/bigip.interfaces/etc/bigip.interfaces.mmddyy cp /etc/ethers /etc/ethers.mmddyy cp /etc/hosts /etc/hosts.mmddyy cp /etc/rc.sysctl /etc/rc.sysctl.mmddyy cp /etc/rc.local /etc/rc.local.mmddyy cp /etc/netstart /etc/netstart.mmddyy cp /etc/ssh_config /etc/ssh_config.mmddyy
    4. Extract the dom-upgradev1.8.3.tgz file in the /var/tmp/183 directory:

      cd /var/tmp/183
      /usr/contrib/bin/gtar -zxvpUf /var/tmp/183/dom-upgrade-1.8.3.tgz

    The following files are extracted:

    File Name Description
    README Description of upgrade software contents
    README-v1.8.3.update.txt Installation instructions
    Patch_Files_from_1.6 Patch for customers who are upgrading from v. 1.6.x
    bsdfs-v1.8.3.tgz File system tar ball
    bigip-v1.8.3_980818.tar BIG/ip tar ball
    bigip_ssh.1.3.5.tgz SSH software update
    ssl_v_1_8_3b16.tgz SSL pinger

     

    Installing the 1.6 software patch (v1.6 users only)

    1. Retrieve the patch files:
      cd/
      /usr/contrib/bin/patch -c < /var/tmp/183 Patch_Files_from_1.6
    2. Remove the following files which is do not apply to a 1.8 or higher installation:
      rm /usr/local/bin/bigman
      rm /sbin/bigman


    Note that if the patch fails, it creates files with a .rej suffix. Check for these files in the /etc directory and in /usr/share/misc. If the patch fails repeatedly, you can change the files manually. To do this, you simply need to move the sod startup lines from the /etc/rc file to the /rc.local file. The /rc.local file should look something like this:

    # BIG/ip service and node monitoring daemon
    # BIG/ip failover daemon
    if [-x /usr/sbin/sod];then
    echo "sod (and bigd)."; /usr/sbin/sod -- bigd ${bigdflags} 2> /dev/null
    fi

  • Installing the 1.8.3 update

    1. Extract the file system files using the command below: cd /
      /urs/contrib/bin/gtar -xvpUf /var/tmp/183/bsdfs-v1.8.3.tgz
    2. Install the BIG/ip software changes:
      cd /
      /urs/contrib/bin/gtar -xvpUf /var/tmp/bigip-v1.8.3_980818.tar
    3. Users that run BIG/ip software on a Compaq device need to issue the following command:
      cp file /etc/fstab.sd /etc/fstab
    4. International users who do not use the SSH client should edit the /etc/changelist file and remove the following 2 lines:
      ssh_config
      sshd_config
    5. Next, recreate your configuration. You can do this either by reapplying the configuration files that you backed up, or by rebooting the machine and reconfiguring the software using the First-Boot utility. If you do not reapply your configuration files, the BIG/ip controller does not find an /etc/hosts file when it reboots, which in turn prompts the system to run the First-Boot utility automatically. Users upgrading from 1.6.x note that you must reconfigure using the First-Boot utilities because 1.6.x configuration files do not use the syntax required by BIG/ip software versions 1.8 and higher.
    6. Verify the new installation. Enter the following commands and check for the appropriate version number.
Command Version Displayed
sod -v sod: version 1.8.3_980818
bigd -v bigd: 1.8.3_980818
bigpipe -v bigpipe: version 1.8.3_980818
bigpipe version BIG/ip: version 1.8.3_980818

What's New In Version 1.8.3

  • New persistence mode: resets timer on each packet

    This mode is disabled by default. Enable it by setting the sysctl variable "bigip.persist_time_used_as_limit" to 0>.

    When enabled, this mode causes the persistence timer to be reset on each packet. Normally, the persistence timer starts when a connection is first made, and subsequent connections go to the same node until the timer times out. With this mode, the timer does not time out as long as there is traffic. This mode applies to the simple persistence time for TCP as well as the special persistence timer for SSL.

    Example:

    Suppose we configure:

       bigpipe vip v1:http define n1:http n2:http
       bigpipe persist http 60

    Now suppose a client connects to v1:http and the BIG/ip controller's load balancing mechanism chooses n1:http as the node. Because persistence is enabled, the persistence timer for this client/VIP combination starts. Then, 45 seconds later, the same client reconnects to v1:http. Because the persistence timer has not yet expired, the BIG/ip controller directs the client to n1:http, as it did with the original connection. Then 45 seconds later, (90 seconds after the initial connection), the same client connects to v1:http for the third time. Normally, the BIG/ip controller would choose a new node for this connection because more than 60 seconds elapsed since the initial connection.

    However, if bigip.persist_time_used_as_limit=0, then the third connection is sent to the original node, n1:http, because it has been less than 60 seconds since the last packet.

    F5 Networks believes that this new mode will be more appropriate than the default mode for those applications which require persistence.

  • New persistence mode: persist across multiple VIPs

    This mode is disabled by default. Enable it by setting the sysctl variable "bigip.persist_on_any_vip" to 1>.

    Normally, persistence keeps the same client's requests for the same VIP going to the same node until the timer expires. When this new mode is enabled, the BIG/ip controller attempts to keep all requests from the same client going to the same node, even if those requests are for different VIPs.

    Example:

    Suppose we configure:

       bigpipe vip v1:http define n1:http n2:http
       bigpipe vip v1:ssl  define n1:ssl  n2:ssl
       bigpipe persist http ssl 60

    Now suppose a client connects to v1:http and the BIG/ip controller's load balancing mechanism chooses n1:http as the node. Then, the same client connects to v1:ssl. Normally, the BIG/ip controller would use its normal load balancing mechanism to pick a new node for that request; it might go to n1:ssl or n2:ssl.

    However, if bigip.persist_on_any_vip=1, then the second connection would still go to the same node IP as the first connection, but to the correct port. In this example, the second connection would go to n1:ssl.

    Suppose we change the configuration:

       bigpipe vip v1:http define n1:http n2:http
       bigpipe vip v1:ssl  define n3:ssl  n4:ssl
       bigpipe persist http ssl 60

    Now, it is not possible to pick the same node IP for the second connection, because n1 is not part of the v1:ssl VIP. Therefore, the BIG/ip controller would use its normal load balancing mechanism to pick a new node for that request.

  • New commands for graceful node or VIP takedown

    The syntax is:

       vip <vip_ip>[:<port>]
    <vip_ip>[:<port>] <vip_ip>[:<port>]... enable
       vip <vip_ip>[:<port>] <vip_ip>[:<port>]
    <vip_ip>[:<port>]... disable
       node <node_ip>[:<port>] <node_ip>[:<port>]... enable
       node <node_ip>[:<port>] <node_ip>[:<port>]...
    disable

    "bigpipe -s" will generate vip-disable and node-disable commands if any are disabled. It will not ever generate vip-enable or node-enable commands.

    The bigpipe and bigstat displays DISABLED to the right of the UP or DOWN or INVALID status. However, these do not display ENABLED. Note that bigtop displays a node as down if it is really down or if it is DISABLED. When counting how many nodes are up for a given VIP, bigtop does not count nodes that are down or DISABLED.

    When a vip or node is disabled, existing connections are allowed to complete, but no new connections are sent to it. An exception is made for persistent connections (TCP and UDP): new connections will be allowed to go to the vip or node until the persistence times out.

    Everything is always enabled by default. Reloading a configuration file, resets BIG/ip, and thus enables everything, except what is explicitly disabled in the configuration file.

    You can enable/disable a vip_ip, vip_ip:port, node_ip, or node_ip:port. For example, a node will not get new connections unless the node_ip is enabled and the node_ip:port is enabled.

  • Extended content verification for SSL

    Note: This feature is currently only available within the U.S.

    In the /etc/bigd.conf file, if the keyword ssl is used instead of active, then the BIG/ip controller uses SSL protocol when checking content for the specified service.

    Example:

       active n1:80 "GET /" "html"
       ssl n1:443 "GET /" "html"

    In the example above, the BIG/ip controller uses plain HTTP to check port 80, but uses HTTP over SSL to check port 443.

    Just like popular web browsers, the BIG/ip controller uses SSL version 3 but automatically falls back to version 2 for checking web servers that support only that version.

    It is possible to install a client certificate on a BIG/ip controller for secure web servers that require client authentication. Please contact F5 Customer Support for details.

    As always, it is still possible to do simple service ping (connect-only) on an SSL server without actually using SSL protocol. This is configured by not having an entry for the service in the /etc/bigd.conf file.

    Due to the computational load of SSL's public-key cryptography, pinging very large numbers of nodes in SSL mode may impact performance. We recommend longer tping_svc settings (and correspondingly long timeout_svc settings) with SSL.

  • Inverted regular expressions for extended content verification

    In the /etc/bigd.conf file, if the keyword "reverse" is used instead of "active", then the regular expression matching will be inverted. This means that if the regular expression matches, then the service will be considered to be down; if the regular expression does not match, then the service will be considered to be up.

    Example:

       active n1:80 "GET /" "html"
       reverse n2:80 "GET /" "error"

    In the example above, if n2:80 delivers any content containing the word error, then n2:80 will be considered down.

  • System log can now generate email and traps

    Note: This new version of the system logging facility is stricter about syntax in the syslog.conf file. Specifically, the fields on each line of the file must be separated by one or more TAB characters.

    Refer to the new manual pages:

       man syslogd
       man syslog.conf
       man log2mail

  • New command to force failover

    In a BIG/ip redundant system, you can force the active BIG/ip controller to instantly become the standby unit, which also, simultaneously, causes the other BIG/ip controller to transition from the standby unit to the active unit. The command is:

       bigpipe fo slave

    Note: This command is provided for use in special situations; it is not intended for normal operation. Each BIG/ip controller automatically switches between active and standby mode, without operator intervention, and it does not usually matter which BIG/ip controller is in running in active mode.

    To check whether a BIG/ip controller is currently running in active or standby mode, use the following command:

       bigpipe fo

    WARNING:

    Do not issue the command to switch an active machine to a standby machine (bigpipe fo master). This puts both BIG/ip units into a confused state!

  • New feature to designate a BIG/ip controller as the preferred active machine

    In a BIG/ip redundant system, you can force a particular BIG/ip controller to be the preferred active unit. When ever this unit is operational, it runs as the active machine.

      Edit the /etc/rc.local file on the BIG/ip controller that you want to be the active machine. Find the line that starts "sod" and add the -force_master command line argument. Example:

      Change the line:

         echo " sod.";    /usr/sbin/sod 2> /dev/null

      to read:

         echo " sod.";    /usr/sbin/sod -force_master 2> /dev/null

      Edit the /etc/rc.local file on the BIG/ip controller you want to be the standby machine. Find the line that starts "sod" and add the -force_slave command line argument. Example:

      Change the line:

         echo " sod.";    /usr/sbin/sod 2> /dev/null

      to read:

         echo " sod.";    /usr/sbin/sod -force_slave 2> /dev/null

      Reboot both BIG/ip controllers.

    Note: This change only applies at startup. Therefore, "bigpipe fo slave" on a forced active machine causes the expected revertion to standby state.

Bug Fixes In Version 1.8.3

  • Update to F-Secure SSH 1.3.5

    This update fixes the "SSH Insertion Attack" security hole.

  • Gateway routes are now allowed for nodes

    Nodes no longer need to be on the same logical network as a BIG/ip controller's internal interface.

  • Route refcount bugfix and optimization

    Fixes a problem that could cause kernel panic under heavy load.

  • VIPs with certain subnet masks are no longer rejected

    Fixes a problem that caused errors when defining VIPs with certain combinations of VIP and node network numbers and subnet masks.

  • Failsafe mode always ARPs correct router

    Fixes a problem that caused BIG/ip to attempt to ARP the wrong router when the external interface failsafe was armed and no traffic was seen during the timeout period. This problem occurred when there were gateway routes other than the default route.

What Was 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> ] ]

    In the new syntax, <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 a BIG/ip controller determines 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 controller startup sequence is required in conjunction with the "alias" command. This change is now standard on new BIG/ip controllers, but may need to be made manually when upgrading from a previous version. igip/solutions/nodeport/sol943.html">Solution 943: Startup Sequence For Large Number Of Nodes for instructions.

    • VIP-NoArp mode

      This new operating mode optimizes communication between a BIG/ip controller 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 a BIG/ip controller, bigtop displays 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 BIG/ip Installation and User's Manual.

  • Optional forwarding of source-routed packets

    This is an alternative way to get access to servers behind the BIG/ip controller. 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 a BIG/ip controller's 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.

    Enable it by setting the sysctl variable net.inet.ip.sourcecheck to 1.

  • Intra-server array load balancing capability

    This feature, also known as "NAT Bounceback" makes it possible for a node behind a BIG/ip controller 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 controller. To use this capability, you must 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 controller. 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

    A BIG/ip controller 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", a BIG/ip controller 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 a BIG/ip controller, you can now use the ping command to ping the broadcast address on the internal network.

What Was New In Version 1.8.1

  • Multiport configurability

    The BIG/ip platform 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 a BIG/ip controller transparent access to the network in front of the BIG/ip controller. 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 a BIG/ip controller, or ran a DNS proxy on a BIG/ip controller 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 the BIG/ip controller.

  • SSL

    BIG/ip software 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 a BIG/ip controller 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 a BIG/ip controller is configured for FTP, it now supports traditional (active) FTP and passive FTP.

    UDP

    BIG/ip software 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

    The BIG/ip platform 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 a 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.

  • Extended content verification (aka Active Service Ping)

    Previously, a BIG/ip controller 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 a BIG/ip controller to do Extended Content Verification (ECV), 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 second BIG/ip controller in a BIG/ip redundant system. 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 controllers, the command also copies /etc/bigip.conf on the local BIG/ip controller to /etc/bigip.conf on the remote BIG/ip controller and then loads the new configuration file to the kernel on the remote BIG/ip controller.

    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:

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

          FailoverIp <ip-address>

      In the /etc/sshd_config file, verify that the AllowHosts line includes the IP address of the second BIG/ip controller.

      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>

      Append

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

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

  • 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

    The BIG/ip platform new includes the BIGtop utility. BIGtop is a convenient way to monitor VIP and node statistics using a terminal or SSH session. To access the utility, simply log in to a BIG/ip controller and type bigtop.

  • Support for very large configurations

    BIG/ip software 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 bugs

    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 software 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 the BIG/ip controller, does 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.

    XBigPipe may crash if a user presses the middle mouse button in a help screen.

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

    For 'dumb' terminals this causes problems when using the serial port of a BIG/ip controller 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 and VIP as a prior connection to use the same node 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 and VIP 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 configuration files (particularly, the default configuration file, /etc/bigip.conf) must be modified.

  • The bigpipe vip command syntax has changed.

    Previously you defined VIPs using the following command:

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

    Now you define VIPs using this command:

        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.)

    Please refer to the Command Reference in the BIG/ip Installation and User's Guide for complete information.

  • 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

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

Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information