Cisco Cisco ASA 5555-X Adaptive Security Appliance Guía Para Resolver Problemas
The security appliance is preconfigured to autodetect the speed and duplex settings on an interface.
However, several situations exist that can cause the autonegotiation process to fail, which results in either
speed or duplex mismatches (and performance issues). For mission-critical network infrastructure, Cisco
manually hardcodes the speed and duplex on each interface so there is no chance for error. These
devices generally do not move around, so if you configure them properly, you should not need to change
them.
However, several situations exist that can cause the autonegotiation process to fail, which results in either
speed or duplex mismatches (and performance issues). For mission-critical network infrastructure, Cisco
manually hardcodes the speed and duplex on each interface so there is no chance for error. These
devices generally do not move around, so if you configure them properly, you should not need to change
them.
On any network device, link speed can be sensed, but duplex must be negotiated. If two network devices
are configured to autonegotiate speed and duplex, they exchange frames (called Fast Link Pulses, or
FLPs) that advertise their speed and duplex capabilities. In order to a link partner that is not aware, these
pulses are similar to regular 10 Mbps frames. In order to a link partner that can decode the pulses, the
FLPs contain all the speed and duplex settings that the link partner can provide. The station that receives
the FLPs acknowledges the frames, and the devices mutually agree on the highest speed and duplex
settings that each can achieve. If one device does not support autonegotiation, the other device receives
the FLPs and transitions to parallel detection mode. In order to sense the speed of the partner, the device
listens to the length of pulses, and then sets the speed accordingly. The problem arises with the duplex
setting. Since duplex must be negotiated, the device that is set to autonegotiate cannot determine the
settings on the other device, so it defaults to half-duplex, as stated in the IEEE 802.3u standard.
are configured to autonegotiate speed and duplex, they exchange frames (called Fast Link Pulses, or
FLPs) that advertise their speed and duplex capabilities. In order to a link partner that is not aware, these
pulses are similar to regular 10 Mbps frames. In order to a link partner that can decode the pulses, the
FLPs contain all the speed and duplex settings that the link partner can provide. The station that receives
the FLPs acknowledges the frames, and the devices mutually agree on the highest speed and duplex
settings that each can achieve. If one device does not support autonegotiation, the other device receives
the FLPs and transitions to parallel detection mode. In order to sense the speed of the partner, the device
listens to the length of pulses, and then sets the speed accordingly. The problem arises with the duplex
setting. Since duplex must be negotiated, the device that is set to autonegotiate cannot determine the
settings on the other device, so it defaults to half-duplex, as stated in the IEEE 802.3u standard.
For example, if you configure the PIX interface for autonegotiation and connect it to a switch that is
hardcoded for 100 Mbps and full-duplex, the PIX sends out FLPs. However, the switch does not respond
because it is hardcoded for speed and duplex and does not participate in autonegotiation. Because it
receives no response from the switch, the PIX transitions into parallel detecion mode and senses the
length of the pulses in the frames that the switch sends out. That is, the PIX senses that the switch is set
to 100 Mbps, so it sets the interface speed accordingly. However, because the switch does not exchange
FLPs, the PIX cannot detect if the switch can run full-duplex, so the PIX sets the interface duplex to half-
duplex, as stated in the IEEE 803.2u standard. Since the switch is hardcoded to 100 Mbps and full-duplex,
and the PIX has just autonegotiated to 100 Mbps and half-duplex (as it should), the result is a duplex
mismatch that can cause severe performance problems.
hardcoded for 100 Mbps and full-duplex, the PIX sends out FLPs. However, the switch does not respond
because it is hardcoded for speed and duplex and does not participate in autonegotiation. Because it
receives no response from the switch, the PIX transitions into parallel detecion mode and senses the
length of the pulses in the frames that the switch sends out. That is, the PIX senses that the switch is set
to 100 Mbps, so it sets the interface speed accordingly. However, because the switch does not exchange
FLPs, the PIX cannot detect if the switch can run full-duplex, so the PIX sets the interface duplex to half-
duplex, as stated in the IEEE 803.2u standard. Since the switch is hardcoded to 100 Mbps and full-duplex,
and the PIX has just autonegotiated to 100 Mbps and half-duplex (as it should), the result is a duplex
mismatch that can cause severe performance problems.
A speed or duplex mismatch is most frequently revealed when error counters on the interfaces in question
increase. The most common errors are frame, cyclic redundancy checks (CRCs), and runts. If these
values increment on your interface, either a speed/duplex mismatch or a cabling issue occurs. You must
resolve this issue before you continue.
increase. The most common errors are frame, cyclic redundancy checks (CRCs), and runts. If these
values increment on your interface, either a speed/duplex mismatch or a cabling issue occurs. You must
resolve this issue before you continue.
Example
interface ethernet0 "outside" is up, line protocol is up
Hardware is i82559 ethernet, address is 00d0.b78f.d579
IP address 192.168.1.1, subnet mask 255.255.255.0
MTU 1500 bytes, BW 100000 Kbit half duplex
7594 packets input, 2683406 bytes, 0 no buffer
Received 83 broadcasts, 153 runts, 0 giants
378 input errors, 106 CRC, 272 frame, 0 overrun, 0 ignored, 0 abort
2997 packets output, 817123 bytes, 0 underruns
0 output errors, 251 collisions, 0 interface resets
0 babbles, 150 late collisions, 110 deferred
Hardware is i82559 ethernet, address is 00d0.b78f.d579
IP address 192.168.1.1, subnet mask 255.255.255.0
MTU 1500 bytes, BW 100000 Kbit half duplex
7594 packets input, 2683406 bytes, 0 no buffer
Received 83 broadcasts, 153 runts, 0 giants
378 input errors, 106 CRC, 272 frame, 0 overrun, 0 ignored, 0 abort
2997 packets output, 817123 bytes, 0 underruns
0 output errors, 251 collisions, 0 interface resets
0 babbles, 150 late collisions, 110 deferred
CPU Utlilization
If you noticed the CPU utlization is high, follow these steps in order to troubleshoot:
1.
Verify that the connection count in show xlate count is low.
2.
Verify that the memory block is normal.
3.
Verify that the number of ACLs is higher.
4.
Issue the show memory detail command, and verify that the memory used by the PIX is normal
utilization.
utilization.
5.
Verify that the counts in show processes cpu-hog and show processes memory are normal.
6.
Any host present inside or outside the security appliance can generate the malicious or mass traffic
that can be a broadcast/multicast traffic and cause the high CPU utilization. In order to resolve this
issue, configure an access list to deny the traffic between the hosts (end to end) and check the
that can be a broadcast/multicast traffic and cause the high CPU utilization. In order to resolve this
issue, configure an access list to deny the traffic between the hosts (end to end) and check the
usage
.
7.
Check the duplex and speed settings in PIX interfaces. The mismatch setting with the remote
infterfaces can increase the CPU utilization.
infterfaces can increase the CPU utilization.
This example shows the higher number in input error and overruns due to the speed mismatch.
Use the show interface command in order to verify the errors:
Use the show interface command in order to verify the errors: