Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Users might experience few discrepancies in Search results. We are working on this on our side. We apologize for the inconvenience it may have caused.
New Member

ASA and PIX interfaces going down and up

I have 2 ASA5520s in failover mode, connected to a 3750 switch. The logs on the 3750 show the uplink interfaces to both ASAs going down/up occationally for 2 to 30 seconds. I didn't have logging on on the ASA at the time.

Are there any known issues with the ASAs losing connectivity or rebooting itself.

Cisco Adaptive Security Appliance Software Version 7.0(1)

Device Manager Version 5.0(1)

Compiled on Thu 31-Mar-05 14:37 by builders

System image file is "disk0:/asa701-k8.bin"



Re: ASA and PIX interfaces going down and up

Have you checked you intrface for ERRORS and have you verified that your Switch and ASA/PIX have the same Duplex and Link Speed settings.

Do a < show interface > to see if you have CRC, Short packages ....

Speed and Duplex Settings

The PIX is preconfigured to autodetect the speed and duplex settings on an interface. However, there are several things that can cause the autonegotiation process to fail, resulting in either speed or duplex mismatches (and performance issues). For mission-critical network infrastructure, it is Cisco's overall policy to manually hard-code the speed and duplex on each interface so there is no chance for error. These devices generally do not move around, so if you set them up properly to begin with, you should not have to change them.

On any network device, link speed can be sensed, whereas duplex must be negotiated. If two network devices are configured to autonegotiate speed/duplex, they will exchange a couple of frames (called Fast Link Pulses, or FLPs) that advertise their speed and duplex capabilities. These pulses look like regular 10 Mbps frames to an unaware link partner. But to link partners that can decode the pulses, the FLPs contain all the speed and duplex settings that the link partner can provide. The receiving station then acknowledges the frames, and the devices mutually agree on the highest speed and duplex settings that each can achieve. If one side does not support autonegotiation, the other side will not receive the FLPs and will go into Parallel Detection mode, sensing the speed of the partner by listening to the length of pulses and then setting speed accordingly. The problem arises with the duplex setting. Since duplex must be negotiated, the side that is set to autonegotiate has no way of determining the settings on the other side, so it defaults to half-duplex per the IEEE 802.3u standard.

As an example, say your switch is hard-coded for 100 Mbps and full-dupex, and you connect your PIX into it, with the PIX's interface set to autonegotiation. The PIX sends out FLPs, but the switch doesn't respond because it is hard-coded for speed/duplex and doesn't participate in autonegotiation. Receiving no response from the switch, the PIX goes into Parallel Detection mode and senses the length of the pulses in the frames the switch is sending out. Thus the PIX can sense that the switch is set to 100 Mbps, so it sets its interface speed accordingly. However, because the switch will not exchange FLPs, the PIX has no way of knowing if the switch is capable of running full-duplex, so the PIX sets its interface duplex to half-duplex, per the standard. But the switch is hard-coded 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 will cause severe performance problems.

A duplex mismatch is most frequently revealed by increasing error counters on the interfaces in question. The most common errors are Frame, CRC, and Runts. If these values are incrementing on your interface, you either have a duplex mismatch or a cabling issue. Resolve this issue before you do anything else.


interface ethernet0 "outside" is up, line protocol is up

Hardware is i82559 ethernet, address is 00d0.b78f.d579

IP address, subnet mask

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



CreatePlease to create content