Manual Chapter : BIG-IP Installation guide v3.3: Additional Setup Options

Applies To:

Show Versions Show Versions

BIG-IP versions 1.x - 4.x

  • 3.3.1 PTF-06, 3.3.1 PTF-05, 3.3.1 PTF-04, 3.3.1 PTF-03, 3.3.1 PTF-02, 3.3.1 PTF-01, 3.3.1, 3.3.0
Manual Chapter


4

Additional Setup Options



Introduction to additional setup options

This chapter contains details about additional setup options you may want to configure for the controller. The options described in this chapter include:

  • Defining additional host names
  • Preparing workstations for command line access
  • Addressing general networking issues
  • Using a serial terminal with the BIG-IP Controller
  • Configuring RADIUS authentication

Defining additional host names

Once you complete the First-Time Boot utility, you may want to insert additional host names and IP addresses for network devices into the /etc/hosts file to allow for more user-friendly system administration. In particular, you may want to create host names for the IP addresses that you will assign to virtual servers. You may also want to define host names for standard devices such as your routers, network interface cards, and the servers or other equipment that you are load balancing.

The /etc/hosts file, as created by the First-Time Boot utility, is similar to the example shown in Figure 4.1.

Figure 4.1 The /etc/hosts file created by the First-Time Boot utility

 # localhost entry    
127.1 localhost

# default gateway entry
11.11.11.10 router


# Local name
11.11.11.2 bigip controller name

#
# Physical Interfaces Tue Oct 19 18:14:44 1999
#

# ext interface
11.11.11.2 exp0

# int interface
11.12.11.2 exp1

#
# VIPS and NODES ( add below - do not delete this line )
#

This sample hosts file lists the IP addresses for the default router, the internal network interface, and the external network interface, and it contains place holders for both the virtual servers and the content servers that the BIG-IP Controller will manage.

Warning: If you have modified the /etc/hosts file with something other than the First-Time Boot utility, such as vi or pico, be aware that your changes may be lost when you run the First-Time Boot utility (config file). This utility overwrites the /etc/hosts file, and several other files, but it does warn you before doing so.

Preparing workstations for command line access

You may want to configure a workstation for command line access to the BIG-IP Controller. You can use a workstation configured for command line access to configure the BIG-IP Controller remotely.

The type of system you have determines the options you have for remote command line administration:

  • Most BIG-IP Controllers support secure shell command line access using the F-Secure SSH client.
  • If your BIG-IP Controllers does not support SSH client, you will use command line access using a standard Telnet shell.

    If SSH came with your BIG-IP Controller, you probably want to install the F-Secure SSH client on your workstation. The BIG-IP Controller includes a version of the F-Secure SSH client for each of the following platforms: Windows, UNIX, and Macintosh. You can download the F-Secure client using your web browser, or you can download the client using an FTP server on the administrative workstation.

    Note that the F-Secure license agreement allows you to download two copies of the F-Secure SSH client. If you require additional licenses, you need to contact Data Fellows. For information about contacting Data Fellows, as well as information about working with the SSH client, refer to the F-Secure manual included with your BIG-IP Controller.

    Note: You can also use the F-Secure SSH suite for file transfer to and from the BIG-IP Controller, as well as for remote backups. An F-Secure SSH client is pre-installed on the BIG-IP Controller to assist with file transfer activities. Please refer to the F-Secure User's Manual for more information.

Downloading the F-Secure SSH client from the BIG-IP web server

The F-Secure SSH client is available in the Downloads section of the BIG-IP web server. For US products, you connect to the BIG-IP web server via SSL on port 443 (use https:// rather than http:// in the URL). Once you connect to the BIG-IP web server, go to the Additional Software Downloads section and click the SSH Clients link. From the SSH Clients page, you can select the SSH Client.

Downloading the F-Secure SSH client using FTP

The BIG-IP Controller has an FTP client installed, which allows you to transfer the F-Secure SSH Client using FTP (note that your destination workstation must also have an FTP server installed). After you transfer the installation file, you simply decompress the file and run the F-Secure installation program.

Note: You can allow FTP and Telnet access to the BIG-IP Controller by running the config_ftpd script from the command line. This script allows specific clients FTP or Telnet access to the BIG-IP Controller. However, we do not recommend this method. For more information about this script, refer to the BIG-IP Controller Reference Guide.

You can initiate the FTP transfer from the BIG-IP Controller using the attached monitor and keyboard.

To transfer the SSH client using FTP

  1. Locate the SSH client that is appropriate for the operating system that runs on the administrative workstation:

    · Change directories to the /usr/contrib/fsecure directory where the F-secure SSH clients are stored.

    · List the directory, noting the file name that corresponds to the operating system of your administration workstation.

  2. To start FTP, type the following command:
      ftp
  3. To open a connection to the remote workstation, type the following command (where IP address is the IP address of the remote workstation itself):
      open <IP address>

    Once you connect to the administrative workstation, the FTP server on the administrative workstation prompts you for a password.

  4. Enter the appropriate user name and password to complete the connection.
  5. To switch to passive FTP mode, type the following command:
      passive
  6. To switch the transfer mode to binary, type the following command:
      bin
  7. Go to the directory on the administrative workstation where you want to install the F-Secure SSH client.
  8. To start the transfer process, type the following command (where filename is the name of the F-Secure file that is specific to the operating system running on the administrative workstation):
      put <filename>
  9. Once the transfer is done, type the following command:
      quit

Setting up the F-Secure SSH client on a Windows 95 or Windows NT workstation

The F-Secure SSH client installation file for Windows platforms is compressed in ZIP format. You can use standard ZIP tools, such as PKZip or WinZip to extract the file.

To unzip and install the SSH client

  1. Log on to the Windows workstation.
  2. Go to the directory to which you transferred the F-Secure installation file. Run PKZip or WinZip to extract the files.
  3. The set of files extracted includes a Setup program. Run the Setup program to install the client.
  4. Start the F-Secure SSH client.
  5. In the SSH Client window, from the Edit menu choose Properties.
    The Properties dialog box opens.
  6. In the Connection tab, in the Remote Host section, type the following items:

    · In the Host Name box, type the BIG-IP Controller IP address or host name.

    · In the User Name box, type the root user name.

  7. In the Options section, check Compression and set the Cipher option to Blowfish.
  8. Click the OK button.

Setting up the F-Secure SSH client on a UNIX workstation

The F-Secure installation file for UNIX platforms is compressed in TAR/Gzip format.

To untar and install the SSH client

  1. Log on to the workstation and go to the directory into which you transferred the F-Secure SSH client tar file.
  2. Untar the file and follow the instructions in the install file to build the F-Secure SSH client for your workstation.
  3. Start the SSH client.
  4. Open a connection to the BIG-IP Controller:
      ssh -l root [BIG-IP IP address]
  5. Type the root password and press the Enter key.

Addressing general networking issues

You must address several network issues when you place a BIG-IP Controller in your network. These networking issues include routing, DNS configuration, and special e-mail considerations. You need to address these issues based on the type of hardware and software in your network. This section describes the following networking issues:

  • Addressing routing issues
    There are a variety of routing configuration issues that you need to address. If you did not create a default route with the First-Time Boot utility, you must configure a default route for the BIG-IP Controller. You also must set up routes for the nodes that the BIG-IP Controller manages. You may also want to configure GateD, which allows dynamic routing information to automatically be updated on the BIG-IP Controller.
  • Configuring DNS on the BIG-IP Controller
    You may need to configure the BIG-IP Controller for DNS resolution or for DNS proxy, and you may even need to convert from rotary or round robin DNS.
  • Configuring email on the BIG-IP Controller
    There are some special requirements that you need to take into account when configuring email on the BIG-IP Controller.

Addressing routing issues

The BIG-IP Controller must communicate properly with network routers, as well as the servers, firewalls, and other routers that it manages. Because there is a variety of router configurations, and varying levels of direct control an administrator has over each router, you need to carefully review the router configurations in your own network. You may need to change some routing configurations before you put the BIG-IP Controller into production.

The BIG-IP Controller supports static route configurations, dynamic routing (via BGP4, RIP1, RIP2, and OSPF), and subnetting. However, the BIG-IP Controller is also designed to eliminate the need for you to modify routing tables on a router that routes to a BIG-IP Controller. Instead, the BIG-IP Controller uses Address Resolution Protocol (ARP) to notify routers of the IP addresses that it uses on each interface, as well as on its virtual servers.

The following sections address these common routing issues:

  • Routing from a BIG-IP Controller to a gateway to the external network
  • Routing from content servers to the BIG-IP Controller
  • Routing from a BIG-IP Controller to content servers that are on different logical networks
  • Setting up dynamic routing with GateD

Routing from a BIG-IP Controller to a gateway to the external net

The BIG-IP Controller needs a route to the external network. For most configurations, this should be configured as the default route on the BIG-IP Controller.

Note: For multiple gateways to the external network, you can configure a last hop pool. For more information, see the Reference Guide.

During installation, you were prompted to configure a default route for the BIG-IP Controller. If you need to change the default route at this time, you can set a new default route by editing the /etc/netstart file.

To change the default route

  1. Open the /etc/netstart file in a text editor, such as vi or pico.
  2. Change the default route entry using the following syntax:
      defroute="<router IP>"
  3. Save and close the file.
  4. Reboot the BIG-IP Controller.

Routing from content servers to the BIG-IP Controller

The content servers being load balanced by the BIG-IP Controller need to have a default route set to the internal IP alias (source processing) of the BIG-IP Controller. For most configurations, this should be configured as the default route on the content server.

For information about setting the default route for your content servers, refer to the product documentation for your server.

Routing between a BIG-IP Controller and content servers on different logical networks

If you need to configure the BIG-IP Controller to use one or more nodes that actually sit on a different logical network from the BIG-IP Controller, you need to assign one or more additional routes to get to those nodes. Set each node's default route in such a way that traffic goes back through the BIG-IP Controller internal interface.

In the following examples, the nodes are on 192.168.6/24 and the BIG-IP Controller internal interface is on 192.168.5/24. There are two possible situations which you may have to address:

  • 192.168.5/24 and 192.168.6/24 are on the same LAN (either sharing media or with a switch or hub between them).
  • 192.168.5/24 and 192.168.6/24 are on two different LANs with a router between them.

Case 1: Same LAN

If the nodes are on the same LAN as the BIG-IP Controller, you simply need to add an interface route for 192.168.6/24 to the BIG-IP Controller's internal interface. You can add this route to the bottom of the /etc/rc.local file using the following syntax:

  route add -net 192.168.6 -interface exp1

Note: You must have the interface defined correctly in the /etc/hosts file in order to use this syntax.

Case 2: Different LANs

If you have nodes on different LANs from the BIG-IP Controller, you need to add a static gateway route on the BIG-IP Controller itself. For example:

  route add -net 192.168.6.0 -gateway 192.168.5.254

You also need to set the default route on the nodes to point to the router between the LANs. For example:

  route add default -gateway 192.168.6.254

Finally, you need to set the default route on the router between the LANs to the BIG-IP Controller's shared alias. For example, type the command:

  route add default -gateway 192.168.5.200

Note: These examples assume you are using a UNIX-based router. The exact syntax for your router may be different.

It is not necessary to set the default route for nodes directly to the BIG-IP Controller, as long as the default path eventually routes through the BIG-IP Controller.

Setting up dynamic routing with GateD

The GateD daemon allows the BIG-IP Controller to exchange dynamic routing updates with your routers. Setting up the GateD daemon is a three-part task:

  • You need to create the GateD configuration file, /etc/gated.conf.
  • You need to start the GateD daemon.
  • You need to edit the /etc/netstart file.

Tip: You are not required to configure GateD on the BIG-IP Controller. The BIG-IP Controller can meet most routing requirements without using GateD.

Note: Additional documentation for GateD is available through the web server on the BIG-IP Controller.

To create the GateD configuration file

GateD relies on a configuration file, typically named /etc/gated.conf, which can be relatively simple, or can be very complex, depending on the routing needs of your network. The BIG-IP web server includes the GateD online documentation (in the Configuration utility home page, under Online Documentation section, click GateD). Note that the GateD configuration guide details the process of creating the GateD configuration file, and also provides samples of common protocol configurations.

To immediately start the GateD daemon on the BIG-IP Controller

Once you create the GateD configuration file, you need to start the GateD daemon on the command line using the following command:

  bigip# gated

To enable starting GateD each time the BIG-IP Controller starts

To start GateD each time the BIG-IP Controller starts, change the gated variable in the /etc/netstart file as shown below:

  gated=YES

Configuring DNS on the BIG-IP Controller

If you plan to use DNS in your network, you can configure DNS on the BIG-IP Controller. There are three different DNS issues that you may need to address when setting up the BIG-IP Controller:

  • Configuring DNS resolution on the BIG-IP Controller
  • Configuring DNS proxy
  • Converting from rotary or round robin DNS

Configuring DNS resolution

When entering virtual addresses, node addresses, or any other addresses on the BIG-IP Controller, you can use the address, host name, or fully qualified domain name (FQDN).

The BIG-IP Controller looks up host names and FQDNs in the /etc/hosts file. If it does not find an entry in that file, then it uses DNS to look up the address. In order for this to work, you need to create an /etc/resolv.conf file. The file should have the following format:

  nameserver <DNS_SERVER_1>
  search <DOMAIN_NAME_1> <DOMAIN_NAME_2>

In place of the <DNS_SERVER_1> parameter, use the IP address of a properly configured name server that has access to the Internet. You can specify additional name servers as backups by inserting an additional nameserver line for each backup name server.

If you configure the BIG-IP Controller itself as a DNS proxy server, then we suggest that you choose its loopback address (127.0.0.1) as the first name server in the /etc/resolv.conf file.

Replace the <DOMAIN_NAME_1> and <DOMAIN_NAME_2> parameters with a list of domain names to use as defaults. The DNS uses this list to resolve hosts when the connection uses only a host name, and not an FQDN. When you enter domain names in this file, separate each domain name with a space, as shown.

A sample configuration file is shown in Figure 4.2.

Figure 4.2 Sample /etc/resolv.conf file

  ; example /etc/resolv.conf   

nameserver 127.0.0.1

nameserver 127.16.112.2 ;ip address of main DNS server

search mysite.com store.mysite.com

You can also configure the order in which name resolution checks are made by configuring the /etc/irs.conf file. You should set this file so that it checks the /etc/hosts file first, and then checks for DNS entries. See Figure 4.3, for an example of how to make the entry in the /etc/irs.conf file.

Figure 4.3 Sample entry for the /etc/irs.conf file

 hosts           local   continue    
hosts dns

Configuring DNS proxy

The BIG-IP Controller is automatically configured as a DNS proxy or forwarder. This is useful for providing DNS resolution for servers and other equipment load balanced by the BIG-IP Controller.

To re-configure DNS proxy, you simply edit the /etc/named.boot file that contains these two lines:

  forwarders <DNS_SERVERS> 
  options forward-only

In place of the <DNS_SERVER> parameter, use the IP addresses of one or more properly configured name servers that have access to the Internet.

You can also configure the BIG-IP Controller to be an authoritative name server for one or more domains. This is useful when DNS is needed in conjunction with internal domain names and network addresses for the servers and other equipment behind the BIG-IP Controller. Refer to the BIND documentation for more details.

Converting from rotary or round robin DNS

If your network is currently configured to use rotary DNS, your node configuration may not need modification. However, you need to modify your DNS zone tables to map to a single IP address instead of to multiple IP addresses.

For example, if you had two Web sites with domain names of www.SiteOne.com and www.SiteTwo.com, and used rotary DNS to cycle between two servers for each Web site, your zone table might look like the one in Figure 4.4.

Figure 4.4 Sample zone table with two Web sites and four servers

 www.SiteOne.com  IN A 192.168.1.1    
IN A 192.168.1.2
www.SiteTwo.com IN A 192.168.1.3
IN A 192.168.1.4

In the BIG-IP Controller configuration, the IP address of each individual node used in the original zone table becomes hidden from the Internet. We recommend that you use the Internet reserved address range as specified by RFC 1918 for your nodes. In place of multiple addresses, simply use a single virtual server associated with your site's domain name.

Using the above example, the DNS zone table might look like the zone table shown in Figure 4.5.

Figure 4.5 Sample zone table with two Web sites and two servers.

 www.SiteOne.com  IN A 192.168.100.231    
www.SiteTwo.com IN A 192.168.100.232

Configuring Email

Another optional feature you can set up when you configure the BIG-IP Controller is email. You can configure the BIG-IP Controller to send email notifications to you, or to other administrators. The BIG-IP Controller uses Sendmail as its mail transfer agent. The BIG-IP Controller includes a sample Sendmail configuration file that you can use to start with, but you will have to customize the Sendmail setup for your network environment before you can use it.

Before you begin setting up Sendmail, you may need to look up the name of the mail exchanger for your domain. If you already know the name of the mail exchanger, skip to Setting up Sendmail on page 4-16.

Finding the mail exchanger for your domain

You can use the nslookup command on the BIG-IP Controller or any workstation that is configured for DNS lookup. Once you find the primary IP address for your domain, you can find the mail exchanger for your domain.

To find the mail exchanger

  1. First you need to identify the default server name for your domain. From a workstation capable of name resolution, type the following on the command line:
      nslookup
  2. The command returns a default server name and corresponding IP address:
    Default Server: <server name>
    Address: <server addr>
  3. Next, use the domain name to query for the mail exchanger:
      set q=mx
    <domain name>

    The information returned includes the name of the mail exchanger. For example, the sample information shown in Figure 4.6 lists bigip.net as the preferred mail exchanger.

    Figure 4.6 Sample mail exchanger information

     bigip.net   preference = 10, mail exchanger = mail.SiteOne.com    
    bigip.net nameserver = ns1.bigip.net
    bigip.net nameserver = ns2.bigip.net
    bigip.net internet address = 192.17.112.1
    ns1.bigip.net internet address = 192.17.112.2
    ns2.bigip.net internet address = 192.17.112.3

    Setting up Sendmail

    When you actually set up Sendmail, you need to open and edit a couple of configuration files. Note that the BIG-IP Controller does not accept email messages, and that you can use the crontab utility to purge unsent or returned messages, and that you can send those messages to yourself or another administrator.

    To set up and start Sendmail

    1. Copy /etc/sendmail.cf.off to /etc/sendmail.cf.
    2. To set the name of your mail exchange server, open the /etc/sendmail.cf and set the DS variable to the name of your mail exchanger. The syntax for this entry is:
        DS<MAILHUB_OR_RELAY>
    3. Save and close the /etc/sendmail.cf file.
    4. To allow Sendmail to flush outgoing messages from the queue for mail that cannot be delivered immediately, open the /etc/crontab file, and change the last line of the file to read:
        0,15,30,45 * * * *   root /usr/sbin/sendmail -q > /dev/null 2>&1
    5. Save and close the /etc/crontab file.
    6. To prevent returned or undelivered email from going unnoticed, open the /etc/aliases file and create an entry for root to point to you or another administrator at your site.
        root: networkadmin@SiteOne.com
    7. Save and close the /etc/aliases file.
    8. You now need to run the newaliases command to generate a new aliases database that incorporates the information you added to the /etc/aliases file.
    9. To turn Sendmail on, either reboot the system or type the following command:
        /usr/sbin/sendmail -bd -q30m

    Using a serial terminal with the BIG-IP Controller

    There are several different ways to add a serial terminal to the BIG-IP Controller. You can add a serial terminal in addition to the console, or you can add a serial terminal as the console. The difference between the two is:

    • A serial terminal configured as a terminal displays a simple login. You can log in and run commands and edit files. In this case, you can use the serial terminal in addition to the keyboard and monitor.
    • A serial terminal configured as the console displays system messages and warnings in addition to providing a login prompt. In this case, the serial terminal replaces the keyboard and monitor.

      Connect a serial line cable between the terminal device and the BIG-IP Controller. Note: On the back of BIG-IP is a male, 9-Pin RS232C connector labeled "Terminal". (Be sure not to confuse this with the failover connection which is also a male, 9-pin connector.) The connector is wired as a DTE device, and uses the signals described in Table 4.1.

      Serial line cable signals
      Pin Source Usage
      1 External Carrier detect
      2 External Received data
      3 Internal Transmitted data
      4 Internal Data terminal ready
      5 Both Signal ground
      7 Internal Request to send
      8 External Clear to send

      The connector is wired for direct connection to a modem, with receipt of a Carrier Detect signal generating transmission of a login prompt by BIG-IP. If you are planning to connect to a terminal or to connect a PC and utilize a terminal emulation program such as HyperTerminalTM, you will need a null modem cable with the wiring to generate the signals shown in Table 4.1.

      Note: You can achieve acceptable operation by wiring pins 7 to 8 and pins 1 to 4 at the back of BIG-IP Controller (and turning hardware flow control off in your terminal or terminal emulator).

    To configure a serial terminal in addition to the console

    If you want to configure a serial terminal for the BIG-IP Controller in addition to the standard console, use the following procedure.

    1. Configure the serial terminal settings in your terminal or terminal emulator or modem as follows:
      - 9600 baud
      - 8 bits
      - 1 stop bit
      - No parity
    2. Open the /etc/ttys file and find the line that reads tty00 off. Modify it as shown here:
        # PC COM ports (tty00 is DOS COM1) 
        tty00 "/usr/libexec/getty default" vt100 in secure
    3. Save the /etc/ttys file and close it.
    4. Reboot the BIG-IP Controller.

    To configure a serial terminal as the console

    In order to configure the serial terminal as the console, follow these steps:

    1. Disconnect the keyboard from the BIG-IP Controller
    2. Connect the serial terminal to the BIG-IP Controller. When there is no keyboard connected to the BIG-IP Controller, the BIG-IP Controller defaults to using the serial port for the console.
    3. Reboot the controller

    To force a serial terminal to be the console

    In the case where you have not connected the serial terminal or it is not active when the BIG-IP Controller is booted, as it might be if you are using a terminal server or dial-up modem, you can force the controller to use the serial terminal as a console. To do this, follow this procedure:

    1. Edit the /etc/boot.default file.
      Find the entry -console auto. Change this entry to -console com.
    2. Save the /etc/boot.default file and exit the editor.
    3. Plug the serial terminal into the serial port on the BIG-IP Controller.
    4. Turn on the serial terminal.
    5. Reboot the controller.

    Warning: You can only access the BIG-IP Controller through the serial port or the network if you perform this procedure.

    1) Once the serial line has been configured as the console, keyboard/monitor access is disabled. Once this occurs, logins are only possible via Secure Telnet (SSH), if configured, or the serial line.

    2) Be careful when editing boot.default. If this file is corrupted, the system will not boot at all. Save a backup copy of the original file and be prepared with a bootable CD-ROM.

    3) Be sure that boot.default contains either the line: "-console com" or the line: "-console auto".

    Note: You do not need to disconnect the keyboard if you use this procedure to force the serial line to be the console.

    Configuring RADIUS authentication

    You can configure the BIG-IP Controller to use a RADIUS server on your network to authenticate users attempting to access the controller with SSH. This allows you to use the RADIUS server as a central repository of users that can access the BIG-IP Controller for administrative purposes.

    To do this, configure the BIG-IP Controller to act as a Network Access Server (NAS) for a RADIUS server in your network. When you set up this feature, client connections received by the BIG-IP Controller for users not listed in the local account database are routed to the RADIUS server to be authenticated. If the user is authenticated, the user is logged in as the BIG-IP Controller user that you specify in the RADIUS user setting.

    Note: RADIUS authentication through the BIG-IP Controller is based on the username/password only. Challenge-response authentication methods are not supported.

    You can configure the BIG-IP Controller to use either version 1.3.7 or version 2.0.12.1, or both, of the sshd for SSH authentication.

    Note: If you want to support only SSH version 1.x clients, configure sshd version 1.3.7. Do not configure sshd version 2.0.12.1. However, if you want to support version 1.x and version 2.x clients, configure sshd version 2.0.12.1.

    RADIUS ports on the BIG-IP Controller

    The BIG-IP Controller uses the ports 1645/udp for communicating with the RADIUS server. If your RADIUS server uses different ports, such as 1812/udp, you must change the ports used by the BIG-IP Controller to these ports. To do this, use a text editor such as vi or pico to change the existing RADIUS port entry in the /etc/services file on each BIG-IP Controller:

    Figure 4.7 Alternative ports on the BIG-IP Controller for the RADIUS server

     radius          1812/tcp                      # Radius               
    radacct 1813/udp # Radius Accounting

    Configuring sshd version 1.3.7

    You can configure version 1.3.7 of the sshd by editing the /etc/sshd_config on the BIG-IP Controller with pico or vi. The following entries must be in the sshd_config file:

    • RadiusServer
      This entry is the host name or IP address of the RADIUS server.
    • RadiusKey
      This entry is the shared secret key of the RADIUS server. This key should be at least 16 characters long.
    • RadiusNasIP
      This is the host name or IP address of the interface on the BIG-IP Controller connected to the network that hosts the RADIUS server. Note that you can only use interfaces set to admin port open for RADIUS authentication.
    • RadiusUser
      This entry is the user name of the local BIG-IP Controller user, such as root. When the RADIUS user is authenticated, the user is logged into the controller as this user.

      Note: The most secure method for using RADIUS with the BIG-IP Controller is to create a RadiusUser entry that has a low level of privileges. After you are authenticated and you log in to the BIG-IP Controller as the low privilege user, use the su command to gain root privileges.

    Warning: For security reasons, we recommend that you use IP addresses instead of host names for the entries in this file. If you specify a host name for an entry, we recommend that you add the host name to the /etc/hosts file.

    For example, Figure 4.8 is an example of the entries you might make in the sshd_config file on the BIG-IP Controller:

    Figure 4.8 Example entries from the sshd_config file

     RadiusServer 12.34.56.78    
    RadiusKey my_radius_server.key
    RadiusNasIP 172.16.42.200
    RadiusUser radius_user

    Configuring sshd version 2.0.12.1

    You can configure version 2.0.12.1 of the sshd by editing the /etc/ssh2/sshd2_config on the BIG-IP Controller with pico or vi. The following entries must be in the sshd2_config file:

    • RadiusServer
      This entry is the host name or IP address of the RADIUS server.
    • RadiusKey
      This entry is the shared secret key of the RADIUS server. This key should be at least 16 characters long.
    • RadiusNasIP
      This is the host name or IP address of the interface on the BIG-IP Controller connected to the network that hosts the RADIUS server. Note that you can only use interfaces set to admin port open for RADIUS authentication.
    • RadiusUser
      This entry is the user name of the local BIG-IP Controller user, such as root. When the RADIUS user is authenticated, the user is logged into the controller as this user.

      Note: The most secure method for using RADIUS with the BIG-IP Controller is to create a RadiusUser entry that has a low level of privileges. After you are authenticated and you log in to the
      BIG-IP Controller as the low privilege user, use the su command to gain root privileges.

      To support SSH version 1.x clients, you must add the following entries to the /etc/ssh2/sshd2_config file.

    • Ssh1Compatibility
      This parameter must be set to yes.
    • Sshd1Path
      This entry is the path to sshd version 1. In this case, the path is /usr/local/sbin/sshd1.

      For example, Figure 4.9 is an example of the entries you might make in the sshd2_config file on the BIG-IP Controller:

      Figure 4.9 Example entries from the sshd2_config file

       RadiusServer 12.34.56.78    
      RadiusKey my_radius_server.key
      RadiusNasIP 172.16.42.200
      RadiusUser radius_user

      Sshd1Compatibility yes
      Sshd1Path /usr/local/bin/sshd1