sFlow: Sampling rates

From http://blog.sflow.com/2009/06/sampling-rates.html:

Sampling rates

A previous posting discussed the scalability and accuracy of packet sampling and the advantages of packet sampling for network-wide visibility.

Selecting a suitable packet sampling rate is an important part of configuring sFlow on a switch. The table gives suggested values that should work well for general traffic monitoring in most networks. However, if traffic levels are unusually high the sampling rate may be decreased (e.g. use 1 in 5000 instead of 1 in 2000 for 10Gb/s links).

Configure sFlow monitoring on all interfaces on the switch for full visibility. Packet sampling is implemented in hardware so all the interfaces can be monitored with very little overhead.

Finally, select a suitable counter polling interval so that link utilizations can be accurately tracked. Generally the polling interval should be set to export counters at least twice as often as the data will be reported (see Nyquist-Shannon sampling theory for an explanation). For example, to trend utilization with minute granularity, select a polling interval of between 20 and 30 seconds. Don't be concerned about setting relatively short polling intervals; counter polling with sFlow is very efficient, allowing more frequent polling with less overhead than is possible with SNMP.

IronPort WCCP Redirection and Proxy Bypass List

I came across a trap for the unwary today. It seems that the IronPort WSA products Proxy Bypass List for transparent mode redirection actually operates on sources as well as destinations.



From the Administrators Guide (note the "or from"):

You can configure the Web Security appliance so client requests to or from particular addresses bypass all processing by the Web Proxy.



Therefore, putting your internal address space in the list to prevent the caching engine from performing access checks and caching upon your intranet and other internal web content will actually prevent transparent redirection from working at all !!



Rather than do this, set up your access lists for WCCP redirection on your router or switch to prevent the requests with an internal destination from being redirected to your caching engine in the first place.



Ip access-list standard wccp-devices
Remark Only WCCP devices should be listed here
permit 10.200.10.10
permit 10.200.10.20

Ip access-list extended wccp-80
Remark Deny redirection of web traffic to internal services, then permit all http
Remark Internal Devices may be listed as deny (source) here to prevent them using transparent proxy
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
deny ip host 10.100.1.50 any
permit ip any any eq www

Ip access-list extended wccp-443
Remark Deny redirection of web traffic to internal services, then permit all https
Remark Internal Devices may be listed as deny (source) here to prevent them using transparent proxy
deny ip any 10.0.0.0 0.255.255.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
deny ip host 10.100.1.50 any
permit ip any any eq 443

ip wccp web-cache redirect-list wccp-80 group-list wccp-devices password password
ip wccp 120 redirect-list wccp-443 group-list wccp-devices password password

Interface [outbound network]
ip address 10.1.1.x
ip wccp web-cache redirect out
ip wccp 120 redirect out



Note that you can avoid the overhead associated with CEF forwarding for outbound traffic on your switches by using redirection on input traffic instead of output traffic, and this will provide faster redirection of packets, but this will often mean a much more complex configuration. If you're not approaching the performance limits of your switches and it's not going to impact VOIP call quality, it's probably going to be simpler to configure redirection on the outbound port to your firewall and measure during peak usage periods (usually lunch time for web usage) for any performance impact.



Cheers,
Sean

How to use ROMON to recover from a bad boot image on a Cisco ASA

Note that this can be applied to other Cisco devices, but commands will vary from device to device. The specific commands here apply to the Cisco ASA 5500 series.
Connect a computer to the console port of the device using a Cisco console cable. Use a terminal emulator such as Putty set for 9600 baud, 8 data bits, no parity, 1 stop bit, no flow control.
Power cycle the device.
During startup, press the Escape key when you see the prompt to enter ROMMON mode.
It is always a good idea to retain the previous boot image on the device during an upgrade, if space permits. If there is an alternative image available on the flash memory you can issue the boot command as follows:
rommon #1> boot asa821-k8.bin
Launching BootLoader...
Boot configuration file contains 1 entry.

Loading disk0:/asa821-k8.bin... Booting...
Platform ASA5505
Loading...

If you don't have a local copy of an alternative boot image and need to copy an image from a network location, define the interface settings as follows:

rommon #1> ADDRESS=172.31.255.1rommon #2> SERVER=10.200.4.29rommon #3> GATEWAY=172.31.255.4rommon #4> IMAGE=asa821-k8.binrommon #5> PORT=GigabitEthernet0/1GigabitEthernet0/1 Link is UP
MAC Address: 0021.a09a.bf89
Test connectivity using the ping server command.
rommon #6> ping serverSending 20, 100-byte ICMP Echoes to server 10.200.4.29, timeout is 4 seconds:

Success rate is 100 percent (20/20)
Load the software image using the tftp command. This assumes that you have a TFTP server running on the target address and a copy of the required image in the target directory.
rommon #7> tftpROMMON Variable Settings:
ADDRESS=172.31.255.1
SERVER=10.200.4.29
GATEWAY=172.31.255.4
PORT=GigabitEthernet0/1
VLAN=untagged
IMAGE=asa821-k8.bin
CONFIG=
LINKTIMEOUT=20
PKTTIMEOUT=4
RETRY=20

tftp asa821-k8.bin@10.200.4.29 via 172.31.255.4
Received 16275456 bytes
Launching TFTP Image...
After the image is loaded the device automatically exits ROMMON.

RSA Server IP Address Change

A gotcha discovered while changing the IP address of an RSA Authentication server.

To change the address of the server, you need to use the rsautil command from the command line:

rsautil update-instance-node --old-host Current_IP_Address --new-host New_IP_Address --instance primary

where:
• Current_IP_Address is the current IP address of the instance, for example,192.168.1.1.
• New_IP_Address is the new IP address of the instance, for example,192.168.200.245.

That's all well and good and is in the administrative guide. Of course, you'll need to reconfigure any devices that are pointing to the IP address of the server as well, such as an authentication agent on your Aventail or ASA.

However, you may see failed authentications and start noticing this in your logs:
Node secret mismatch. Cleared on agent but not on server.

In order to fix this, you'll have to get CLI access to your Aventail or ASA and delete the node secret files from the device. On an Aventail, these will be ststatus.12, securid ( delete them from /var/ace then restart the policy server using /etc/init.d/policyserver restart ). On the ASA it will be 192-168-111-123.sdi. Then connect to your RSA Security Console and manage the existing Authentication agents. You should then be able to select "Manage Node Secret" from the drop-down menu and clear the node secret. The secret will then be renegotiated on first use.

Cheers,
Sean

Cisco: Password Recovery

Ever lost the password to a Cisco device? I've had to do this about 4 times so far during my career (Not because I lost the password personally!). The steps are similar for many Cisco devices. These are the steps to reset the enable password on an ASA5505 Security Appliance.

The following steps were designed using a Cisco ASA 5505 Security Appliance. They are not appropriate for a Cisco PIX Firewall appliance.

1. Power-cycle your security appliance by removing and re-inserting the power plug at the power strip.
2. When prompted, press Esc to interrupt the boot process and enter ROM Monitor mode. You should immediately see a rommon prompt (rommon #0>).
3. At the rommon prompt, enter the confreg command to view the current configuration register setting: rommon #0>confreg
4. The current configuration register should be the default of 0x01 (it will actually display as 0x00000001). The security appliance will ask if you want to make changes to the configuration register. Answer no when prompted.
5. You must change the configuration register to 0x41, which tells the appliance to ignore its saved (startup) configuration upon boot: rommon #1>confreg 0x41
6. Reset the appliance with the boot command: rommon #2>boot
7. Notice that the security appliance ignores its startup configuration during the boot process. When it finishes booting, you should see a generic User Mode prompt: ciscoasa>
8. Enter the enable command to enter Privileged Mode. When the appliance prompts you for a password, simply press (at this point, the password is blank): ciscoasa>enable Password: ciscoasa#
9. Copy the startup configuration file into the running configuration with the following command: ciscoasa#copy startup-config running-config Destination filename [running-config]?
10. The previously saved configuration is now the active configuration, but since the security appliance is already in Privileged Mode, privileged access is not disabled. Next, in configuration mode, enter the following command to change the Privileged Mode password to a known value (in this case, we'll use the password system): asa#conf t asa(config)#enable password system
11. While still in Configuration Mode, reset the configuration register to the default of 0x01 to force the security appliance to read its startup configuration on boot: asa(config)#config-register 0x01
12. Use the following commands to view the configuration register setting: asa(config)#exit asa#show version
13. At bottom of the output of the show version command, you should see the following statement: Configuration register is 0x41 (will be 0x1 at next reload)
14. Save the current configuration with the copy run start command to make the above changes persistent: asa#copy run start Source filename [running-config]
15. Reload the security appliance: asa# reload System config has been modified. Save? [Y]es/[N]o:yes
Cryptochecksum: e5f81433 5493266b 4e24072 d71d5cbf
2157 bytes copied in 1.490 secs (2157 bytes/sec) Proceed with reload? [confirm]
When your security appliance reloads, you should be able to use your newly reset password to enter privileged mode.