Common CISCO Firewall commands and details

 

1. show cpu usage

The PIX only has one CPU to complete all the work, from the processing package to writing debug information to the console. The process that consumes the most CPU resources is encrypted. Therefore, if you want to encrypt data packets in the PIX, you 'd better use the accelerator card or dedicated VPN Concentrator. The log function is another process that consumes a large amount of system resources. Therefore, we recommend that you disable log writing from the PIX to the console, monitor, and buffer normally.

Pixfirewall # show cpu usage

CPU utilization for 5 seconds = 1%; 1 minute: 2%; 5 minutes: 1%

 

 

2. show traffic

This command shows how much traffic flows through the PIX at a specific time. The specific time is the interval from the last command execution to the current command execution. We can see the data traffic of each interface.

 

ZJ-WAP-FW-2 # show traffic

Inside:

Received (in 1506074.635 secs ):

277725221288 packets 143521417050444 bytes (total input throughput since FW boot)

184001 pkts/sec 95295000 bytes/sec (average input value since FW boot)

Transmitted (in 1506074.635 secs ):

287523217939 packets 151292879605153 bytes (total output throughput since FW boot)

190002 pkts/sec 100455001 bytes/sec (average output since FW boot)

1 minute input rate 19597 pkts/sec, 11294493 bytes/sec (average input throughput within 1 minute)

1 minute output rate 20063 pkts/sec, 11294468 bytes/sec (average output throughput within 1 minute)

1 minute drop rate, 34 pkts/sec

5 minute input rate 19102 pkts/sec, 9905358 bytes/sec (average input throughput within 5 minutes)

5 minute output rate 20159 pkts/sec, 11419208 bytes/sec (average ioutput throughput in 5 minutes)

5 minute drop rate, 36 pkts/sec

 

 

3. show perfmon

 

This command monitors the traffic and type of the data checked by the PIX. It can determine the transformation (xlates) and number of connections (conn) performed on the PIX per second ).

 

Perfmon stats Current Average

Xlates 18/s 19/s

Connections 75/s 79/s

TCP Conns 44/s 49/s

UDP Conns 31/s 30/s

URL Access 27/s 30/s

URL Server Req 0/s 0/s

TCP Fixup 1323 per second 1413/s

TCPIntercept 0/s 0/s

HTTP Fixup 923/s 935/s

FTP Fixup 4/s 2/s

AAA Authen 0/s 0/s

AAA Author 0/s 0/s

AAA Account 0/s 0/s

 

Among them, the most important thing is that Xlates is the number of changes generated per second; Connections is the number of established Connections; TCP Fixup is the number of TCP packets forwarded by the PIX per second; TCPIntercept indicates how many SYN packets per second have exceeded the initial value.

 

 

4. show blocks

 

When used together with show cpu usage, you can determine whether the PIX is overloaded.

When a data packet enters the firewall interface, it is first placed in the input interface queue and divided into different blocks according to the data frame size. For Ethernet frames, use a 1550-byte block. If the data comes in from a gigabit port, a 16384-byte block is used. The PIX then determines whether to pass the package based on the ASA algorithm. If the PIX is overloaded, the corresponding block will be dropped to or close to 0 (depending on the CNT column ). When this value is reduced to 0, the PIX will try to apply for more blocks, up to 8192. If no block is available, the package is discarded.

The 256-byte block is stateful failover information. The primary PIX sends these packages to and from the PIX to update the xlates and connection information. If a large number of connections are established and removed in a certain period of time, the 256-byte block may be reduced to 0, that is, the sub-PIX may not be synchronized with the master PIX. It is acceptable if this time is not long, but if it remains at 0 for a long time, you need to consider upgrading to a higher-speed PIX.

 

In addition, the log information is also sent to the external through a 256-byte block. Note that you do not need to set the log level to debug.

 

Pixfirewall # show blocks

SIZE MAX LOW CNT

4 1600 1597 1600

80 400 399 400

256 500 495 499

1550 1444 1170 1188

16384 2048 1532 1538

 

 

5. show memory

 

We can see the memory of the PIX and the available memory. Under normal circumstances, the available memory of the PIX should not change too much. If the memory is suddenly exhausted, check whether an attack is used. You can run the show conn count command to check the number of connections in the current PIX. If the PIX memory is exhausted, crash will eventually occur.

 

Pixfirewall # show memory

1073741824 bytes total, 1022992384 bytes free

 

 

6. show xlate count

 

Displays the number of changes currently passed through the PIX and the maximum number of changes. An internal address is transformed into an external legal address. A machine may establish a connection with multiple external targets, but there is only one transformation. If the displayed Number of transformations is much greater than the number of internal machines, it may be a network attack.

 

Pixfirewall # show xlate count

84 in use, 218 most used

 

 

7. show conn count

 

You can see the maximum number of connections of the current PIX. A connection is a ing between an internal layer-4 Information and an external address. When the PIX receives a SYN packet, a connection is established. if the number of connections is too high, it means that it is under attack. If the show memory command is used, although the number of connections is high, it does not consume excessive memory resources in the PIX.

 

Pixfirewall # show conn count

2289 in use, 44729 most used

 

 

8. show interface

 

This command is used to determine the duplex matching problem and the cable fault. It can also be seen whether the interface is overloaded. If the CPU resources of the PIX are exhausted, the block size in 1550 bytes is close to 0. If it is a gigabit port, the block size in 16384 bytes is close to 0. Another signal is that the value of "no buffers" is constantly increasing. It indicates that the interface receives packets too quickly and the PIX cannot process the packets, and there is not enough block to carry the packets, packet loss occurs. If "no buffer" is accompanied by an increase in CPU usage, it indicates that you should upgrade to a firewall with better performance.

 

When a data packet enters the interface, it is placed in the input hardware queue. If the queue is full, it is placed in the input software queue. The package is then put into the block from the input queue and waits for the processing of the pix OS. The PIX decides which exit the package is put, that is, the output hardware queue. If the queue is full, put it in the output software queue. If the max blocks in each soft queue is large, it is called "overrun ". The common situation is that the data transmission rate between the entry and exit does not match, and overrun occurs. In this case, you should consider upgrading the interface.

 

Pixfirewall # show interface

Interface ethernet0 "inside" is up, line protocol is up

Hardware is i82559 ethernet, address is 0002. b31b. 99ff

IP address 9.9.1, subnet mask 255.255.255.0

MTU 1500 bytes, BW 100000 Kbit full duplex

4630 packets input, 803174 bytes, 0 no buffer

Received 2 broadcasts, 0 runts, 0 giants

0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort

4535 packets output, 445424 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets

0 babbles, 0 late collisions, 0 deferred

0 lost carrier, 0 no carrier

Input queue (curr/max blocks): hardware (128/128) software (0/1)

Output queue (curr/max blocks): hardware (0/2) software (0/1)

 

If runts, input errors, CRCs or frame errors are increasing, it may be caused by mismatch of duplex mode or cable failure.

 

 

9. show process

 

Displays the active processes in the current PIX. In this way, we can see which processes use too much CPU resources and which processes fail to use CPU resources. To obtain this information, we execute the show process command for two consecutive times, with an interval of 1 minute. For suspicious processes, the two Runtime values are subtracted. The time difference (in milliseconds) is the CPU resources occupied by the process in one minute. The 557poll process is usually the most time-consuming process. It is responsible for querying the Ethernet interface to see if there are packets to be processed.

 

 

Summary

 

Run the show cpu usage command to check the load of the PIX.

Generally, if the CPU usage exceeds 30%, it is regarded as high, but it generally does not exceed 50%. When the CPU usage reaches 80%, the performance will be affected. If the CPU usage exceeds 90%, packet loss may occur.

At this time, we can run the show process command to see what processes are consuming CPU resources,

Find the process and find a solution.

If the CPU usage is not high but packet loss occurs,

Run the show interface command to check whether there is a wrong package, that is, whether there is a duplex matching problem or a cable problem;

If "no buffer" increases and the CPU usage is not high, the interface capability cannot meet the traffic requirements;

If the buffer condition is good, check the block. If the block size of 1550 bytes or 16384 bytes is close to 0,

This indicates that the PIX is too busy to start packet loss, and the CPU will also be very high.

If it is difficult to create a new connection in the PIX, run the show conn count command to check the current number of connections:

If the memory usage is high, run the show memory command to check the memory usage,

If the memory is small, run the show conn command or the show local-host command.

Check the reason for the large number of connections, which may be DoS attacks.

In addition, the show traffic command displays the number of packages and number of nodes processed by each interface;

The show perfmon command further divides traffic into different types.