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:


SYNTAX

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.

ACTIONS

• 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
  BIG-IP.


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

SCRIPT AND ACTION DIRECTORIES

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.


SYMBOLIC LINK FORMAT

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

SNNString

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.


CASE STUDY: PREVENT A SERVICE FROM RUNNING ON 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.

Procedure:

1. Verify the status of the named service:
   
   bigip:# bigstart status named
   bigstart: status named
   status named: (pid=1130) is running
   bigip:#



2. Shutdown the service:
   
   bigip:# bigstart shutdown named
   bigip:#



3. Remove the named symbolic link in the startup action directory:
   
   bigip:# cd /etc/bigstart/startup
   bigip:/etc/bigstart/startup# ls *named*
   S10named
   bigip:/etc/bigstart/startup# rm S10named
   remove S10named? y
   bigip:/etc/bigstart/startup#

Verification

• 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
  bigip:#

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.

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

• Hostname : myWebServer01


• IpAddress : 192.168.1.50


• Public URL: www.xyz.com


• Public IP : 10.20.1.50

Requirements:

• 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

Procedure:
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 192.168.1.50
     
   
   
   • 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 192.168.1.50


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:
   

   Accelerator				Web Server
   IP	Port	Host	Path	IP	Port	Host	Path
   10.20.1.50	80	www.xyz.com	*	192.168.1.50	80	myWebServer01	*

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

   Accelerator				Web Server
   IP	Port	Host	Path	IP	Port	Host	Path
   10.20.1.50	80	*	*	192.168.1.50	80	*	*

   
   
   

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 10.10.20.20 -1
ssh_exchange_identification: Connection closed by remote host
-bash-3.00$

To further confirm, check the SSH port via telnet:

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

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

Solution:
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.

Verification:

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 10.10.20.20 22
Trying 10.10.20.20...
Connected to 10.10.20.20.
Escape character is '^]'.
SSH-2.0-Cisco-1.25

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

REQUIRED INFORMATION:
- 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-defaults:auth=radius,bploc,passwd:\
       :radius-server=10.10.10.10:\
       :radius-port=1812:\
       :radius-server-alt=10.10.20.10:\
       :radius-port-alt=1812:
  
  
• RADIUS server IP address and secret key is configured in /etc/raddb/servers.
  
    MyBIGIP:~# cat /etc/raddb/servers
    10.10.10.10 myKey123
    10.10.20.10 myKey123
    MyBIGIP:~#

BIG-IPv9 Checklist:

• RADIUS server IP address, port, and secret key are in /etc/raddb/server.
  
    MyBIGIPv9:~# cat /etc/raddb/server
    10.10.10.10:1812 myKey123 3
    10.10.20.10:1812 myKey123 3
    MyBIGIPv9:~#
  
  
• 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 "10.10.10.10"
     secret "myKey123"
  }
  radius server system_auth_name2 {
     server "10.10.20.10"
     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.

SNMP ifIndex persistence

Your Ad Here

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.

Configuration:

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.

Verification

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)
MyDevice#


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.

References:
Interface Index (ifIndex) Persistence

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 53	DNS queries
UDP 88	Kerberos
UDP/TCP 3074	XBox live
UDP 6500	Peer queries
UDP 13139	Peer ping
UDP 22042	Server queries
TCP/UDP 22043-22050	Voice chat

Incoming ports:	Description
UDP/TCP 3074	Xbox 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 10.10.180.0/25:

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

...

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

...

interface Vlan180
 description "XBOX360 Subnet"
 ip address 10.10.180.254 255.255.255.128
 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.