Tuesday, July 29, 2008

BIG-IP v4 - Common bigstart commands

The bigstart is the command used for controlling the F5 BIGIP daemons/services. For Windows users, this is synonymous to Control Panel -> Admin Tools -> Services. Here is BIG-IP v4.x bigstart command syntax dissected:


bigstart [-d] action [id]

  • -d
    Lists the execution order of the services for the specified action command.

  • action
    Performs whatever action is specified. Values are startup, shutdown, active, standby, status, reinit and restart.

  • id
    The specific service on which the specified action would be acted upon. That is, for example, bigstart shutdown named will shutdown the service named.

  • startup
    The target program commences. Bigstart startup is called from /etc/rc before rc.local is executed.

  • shutdown
    The target program should shut down gracefully.

  • active
    The target program takes any action necessary whenits host BIG-IP becomes the active unit. Bigstart active is called when the BIG-IP becomes the active

  • standby
    The target program takes any action necessary when its host BIG-IP becomes the standby unit.

  • reinit
    The target program initializes itself from its configuration data.

  • restart
    The target program is to be restarted. Typically this means the program will be stopped then started.

  • status
    The target program responds by providing some status information.


The scripts for each of the services are in the /etc/bigstart/scripts directory.

Each of the actions have their own individual action directories in /etc/bigstart/action. Files in the action directories are actually symbolic links pointing to the actual scripts in the /etc/bigstart/scripts directory.


Each symbolic link in the action directories follow this naming convention:


NN - two digit number that determines the execution order of the services.

String - name of the service

The contents of, say, /etc/bigstart/startup will correspond to the output of the command bigstart -d startup.


Scenario: In our setup, the name service named of the BIG-IP is not being used. Hence, it was decided to be not started during device startup.

  1. Verify the status of the named service:

    bigip:# bigstart status named
    bigstart: status named
    status named: (pid=1130) is running

  2. Shutdown the service:

    bigip:# bigstart shutdown named

  3. Remove the named symbolic link in the startup action directory:

    bigip:# cd /etc/bigstart/startup
    bigip:/etc/bigstart/startup# ls *named*
    bigip:/etc/bigstart/startup# rm S10named
    remove S10named? y

  • Verify that the service is not in the execution order for the startup action.

    bigip:# bigstart -d startup
    <output omitted>

  • Verify status of the current running status of the service:

    bigip:# bigstart status named
    bigstart: status named
    status named: is not running

Friday, July 25, 2008

NetApp C6200: Configuring HTTP Acceleration

The NetCache NetApp C6200 appliance can be configured for web acceleration, aka reverse proxy. The following are the bare minimum steps to configure HTTP acceleration on this device.

Below are the details about the web server that will be proxied by the NetApp C6200.
  • Hostname : myWebServer01

  • IpAddress :

  • Public URL: www.xyz.com

  • Public IP :

  • DNS - Ensure that the DNS server resolves the URL to the NetCache appliance IP address (see below)

  • Accelerator IP Address - either the assigned IP address OR the aliased IP address of the NetCache appliance

  • Actual Server IP address

Note: In each page, ensure to click "Commit Changes" button in order to apply the changes.
  1. In Setup -> Network -> Interfaces, verify that the public IP address to use is configured as either the primary (Appliance Manager Primary IP address) or the alias(Appliance Manager Aliases) IP address.

  2. In Setup -> HTTP -> General, configure the following:
    • Check Enable HTTP services option.

    • Under the HTTP ACL, ensure that the server IP address is permitted:

      allow server-ip

    • HTTP Proxy PortsUsually, this is configured to port 80, the default HTTP port.

  3. In Setup -> HTTP -> Web Server Acceleration, General tab, configure the following:

    • Check Enables the Web accelerator function of the appliance option.

    • Under the Web Server Accelerator ACL, ensure that the server IP address is permitted:

      allow server-ip

  4. Configure a new accelerator rule in Setup -> HTTP -> Web Server Acceleration -> Acceleration Rules, New Rule button.

    For this scenario, you would have the following:
    AcceleratorWeb Server

    Alternate Rule: You can use wildcards / asterisk, in case the webserver has multiple URLs.
    AcceleratorWeb Server

Thursday, July 17, 2008

SSH Connection Fails, Missing Key

One of the requirements to enable remote management via SSH on a device is the configured crypto RSA key. Hence, it is imperative that the RSA key be defined first before disabling other connections such as console and telnet.

Problem/Error Encountered:
So how do you know if your device doesn't have a crypto key enabled? Check the SSH attempt below:

-bash-3.00$ ssh -1
ssh_exchange_identification: Connection closed by remote host

To further confirm, check the SSH port via telnet:

-bash-3.00$ telnet 22
Connected to
Escape character is '^]'.
Could not load host key. Closing connection...Connection closed by foreign host.

The output from the telnet 22 should be enough to confirm that the device has a missing (or possibly a corrupt) RSA key.

Simply put, configure the RSA key.

However, here is a possible problem scenario: the device can only be accessed via SSH (console and telnet were disabled) AND the crypto key was (accidentally) erased. In this case, the only way to access the device is effectively disabled as well.

The "quickest" solution for this one is to recover the password recovery via console. Password recovery usually involves rebooting the device.


Best way is, of course, to ssh to the device.

If testing via telnet 22, the should see something like this:

-bash-3.00$ telnet 22
Connected to
Escape character is '^]'.

Friday, July 11, 2008

BIG-IP RADIUS Login Authentication Checklist

Our network BIG-IP suddenly had login problems after a firmware upgrade. I'd confirm at a later date (i.e., after upgrade of another F5 BIG-IP) if an upgrade indeed causes a authentication problems. The good thing is that the local root password was not affected. Anyway, here are some points to consider when troubleshooting remote RADIUS login authentication on BIG-IP via CLI (and some UNIX/Linux servers).

- RADIUS server IP address(es)
- RADIUS server port (default is TCP 1812)
- RADIUS server secret key

BIG-IPv4 Checklist:
  • RADIUS server IP address and TCP port is configured in /etc/login.conf.


  • RADIUS server IP address and secret key is configured in /etc/raddb/servers.

      MyBIGIP:~# cat /etc/raddb/servers myKey123 myKey123

BIG-IPv9 Checklist:
  • RADIUS server IP address, port, and secret key are in /etc/raddb/server.

      MyBIGIPv9:~# cat /etc/raddb/server myKey123 3 myKey123 3

  • RADIUS server IP address and secret key are defined in the /config/bigip.conf under the radius server sections.

    radius server system_auth_name1 {
       server ""
       secret "myKey123"
    radius server system_auth_name2 {
       server ""
       secret "myKey123"
    auth radius system-auth {
       server system_auth_name1 system_auth_name2

    You can opt to modify this file via the GUI, in System > Users > Authentication.

Thursday, July 10, 2008

SNMP ifIndex persistence

Your network monitoring application, such as MRTG, is configured to monitor a specific interface. Since there are more than one interface on a device, monitoring will be based on the specific interface's assigned ifIndex.

However, after a hard device reboot, the ifIndex has changed, causing problems with MRTG reporting. This may occur intermittently; sometimes, ifIndex are the same after a reboot, sometimes they change (especially after adding logical interfaces and/or FastEthernet or GigabitEthernet modules).

This has been addressed in RFC2863 (updatint the ifIndex definition under RFC1213). As such, Cisco introduced SNMP ifIndex persistence; simply put, the current ifIndex assigned to the interface will be the permanent.


SNMP ifIndex persistence can be applied globally to all interfaces, or only to specific ones. The syntax are as follows:

 MyDevice(config)# snmp-server ifindex persist
 MyDevice(config-if)# snmp ifindex persist

Note: The actual syntax may vary depending on the IOS version; older versions use snmp-server ifindex persist instead of just snmp ifindex persist.

After that, you need to save the configuration via write mem or copy run start.


To retain the ifIndex values, like the configuration and vlan information in some older devices, it will be saved in the nvram. Check the NVRAM for a file called ifIndex-table.

MyDevice#dir nvram:ifIndex-table
Directory of nvram:/ifIndex-table

   3 -rw- 6712 <no date> ifIndex-table

1964024 bytes total (1752173 bytes free)

Once that is configured, the changing ifIndex problem should be resolved and reporting tools such as MRTG will have no problems monitoring the correct interface.

Interface Index (ifIndex) Persistence

Monday, July 7, 2008

TCP/UDP Ports for XBOX360

As you know, XBOX360 is one of the latest console gaming platforms available with network capability. Suppose you are network security consultant and you want restrict the ports used in the subnet used by your XBOX360 devices, which ports are you going to open?

Here are the required ports for the XBOX360 to properly connect to the network/Internet:

Outgoing ports:Description
UDP 53DNS queries
UDP 88Kerberos
UDP/TCP 3074XBox live
UDP 6500Peer queries
UDP 13139Peer ping
UDP 22042Server queries
TCP/UDP 22043-22050Voice chat

Incoming ports:Description
UDP/TCP 3074Xbox live

Given the above information, you can then create the access-lists as necessary.

EXAMPLE with Cat6000 as the gateway:
Below is a snippet of an actual access-list configured on a real-live Cat6000 device serving as the gateway for subnet

ip access-list extended SUBNET_XBOX_IN
 remark <<Permit outbound XBOX360 ports>>
 permit udp any eq 88
 permit tcp any eq 3074
 permit udp any eq 3074
 permit udp any eq 6500
 permit udp any eq 13139
 permit udp any range 22042 22050
 permit tcp any range 22043 22050
 deny ip any any


ip access-list extended SUBNET_XBOX_OUT
 remark <<Permit inbound XBOX360 ports>>
 permit tcp any eq 3074
 permit udp any eq 3074
 deny ip any any


interface Vlan180
 description "XBOX360 Subnet"
 ip address
 ip access-group SUBNET_XBOX_IN in
 ip access-group SUBNET_XBOX_OUT out

Note that in the above examples, outbound XBOX ports are in the inbound switch access-list; likewise, inbound XBOX ports are in the outbound switch access-list. This is with respect to the point of view of the Cat6000 where the ACLs are defined. The XBox "outbound" ports go out from the Xbox into the switch, hence we use the inbound access-list. Similarly, Xbox inbound ports come from the switch out to the XBox subnet.

Of course, the access-lists would be slightly different if the subnet's default gateway is, say, a PIX/ASA, or a checkpoint firewall, or a CatOS switch. Regardless, the same requirements apply; the above listed ports should be permitted.