Troubleshooting bizarre interface issue.

Answered Question
Apr 20th, 2010

Hi Guys I have an ASA 5510 running 8.0 code.

I was experiencing slower throughput then normal and decided to do some testing on the firewall.

I had a redundant interface for the inside of the firewall with ports e0/2 and e0/3. both configures to 100/FULL.

I configured the management interface and e0/1 ( e0/0 is being used on the outside interface) with seperate ip subnets and configured the required NAT'ing.

I then ran some speedtests via speedtest.net. I found that using e0/1(gig) or management(100mb) I was achieving speeds consistently(over many tests) at least 10 times faster then on the redundant 1 interface ( with e0/3 active).

I then removed the redundant interface and tested e0/2 and e0/3 seperately and discovered e0/2 gave consistent high speeds just like all of the other interfaces but e0/3 was still consistently showing very poor speeds.


The interface was up, didn't seem to be under any load and full duplex 100 ( the same as 0/2 and management interface).

So I think there is an issue with e0/3 but I'm not sure how to test. What should I look for, what sort of tests are at my desposal?

many thanks.

Correct Answer by David White about 6 years 8 months ago

Hi Marcos,

The reason this will cause a problem is if the ASA is hardcoded for 100/full-duplex, and then is connected to a device (laptop/switch) which is configured for Auto then the switch side will try to autonegotiate the settings.  Since the ASA is hard-coded, it will not participate in the negotiation process.  The switch side will then see that negotiation has failed, and will be able to sense the speed, so it will set itself to 100 Mbps.  However, for duplex it cannot be sensed, and therefore the side configured for Auto will default to half-duplex.  Thereby causing a duplex mis-match. 

That is why the general recommendation is to leave all ports at 'auto'.  (In the old days - 1990s; the auto-negotiation process had some bugs between different vendor's equipment, and thus the general recommendation back then was to hard-code everything.  However, those issues have long been since addressed, and configuring the devices for autonegotiation is a much better option, as it avoids the more common case of misconfigurations - where one side is hard-coded, but the other is not).

I hope it helps explain it.

Sincerely,

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
David White Thu, 04/29/2010 - 06:39

Please send the output of show interface both before running the speed test as well as after.  Is the interface receiving any errors?  Also, what peer device are the interfaces plugged into?  If you swap e2 and e3 connections on the peer device, does that make a difference?

Thanks,


David.

marcosgeorgopoulos Fri, 06/04/2010 - 02:36

Hi,

Sorry its taken so long to get back with this information.Something came up and I wasn't able to get to the devices over the last month.

I have tried plugging E0/3 into different ports of the switch but I get the same result. I don't think its an issue with the switch.

Here are the before and after interface stats. I can't see much obvious.There are some errors, but not sure if its enough to be concerned?

BEFORE - Note, it is down as I hadn't plugged my laptop in yet. There are still some previous stats from the last tests.

Interface Ethernet0/3 "faulty", is down, line protocol is down
  Hardware is i82546GB rev03, BW 100 Mbps, DLY 100 usec
    Full-Duplex, 100 Mbps
    MAC address 0026.0b31.1249, MTU 1500
    IP address 172.16.1.1, subnet mask 255.255.255.0
    9549 packets input, 3377943 bytes, 0 no buffer
    Received 140 broadcasts, 0 runts, 0 giants
    337 input errors, 337 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    76 L2 decode drops
    14233 packets output, 15641611 bytes, 0 underruns
    0 output errors, 0 collisions, 3 interface resets
    0 babbles, 0 late collisions, 0 deferred
    0 lost carrier, 0 no carrier
    input queue (curr/max packets): hardware (0/9) software (0/0)
    output queue (curr/max packets): hardware (0/0) software (0/0)
  Traffic Statistics for "faulty":
    0 packets input, 0 bytes
    0 packets output, 0 bytes
    0 packets dropped
      1 minute input rate 0 pkts/sec,  0 bytes/sec
      1 minute output rate 0 pkts/sec,  0 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 0 pkts/sec,  0 bytes/sec
      5 minute output rate 0 pkts/sec,  0 bytes/sec
      5 minute drop rate, 0 pkts/sec
  Control Point Interface States:
    Interface number is 5
    Interface config status is active
    Interface state is not active

asa01(config)#


AFTER
-----
show interface e0/3 detail
Interface Ethernet0/3 "faulty", is up, line protocol is up
  Hardware is i82546GB rev03, BW 100 Mbps, DLY 100 usec
    Full-Duplex(Full-duplex), 100 Mbps(100 Mbps)
    MAC address 0026.0b31.1249, MTU 1500
    IP address 172.16.1.1, subnet mask 255.255.255.0
    18335 packets input, 6920327 bytes, 0 no buffer
    Received 233 broadcasts, 0 runts, 0 giants
    720 input errors, 720 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    76 L2 decode drops
    28761 packets output, 33414940 bytes, 0 underruns
    0 output errors, 0 collisions, 3 interface resets
    0 babbles, 0 late collisions, 0 deferred
    0 lost carrier, 0 no carrier
    input queue (curr/max packets): hardware (0/20) software (0/0)
    output queue (curr/max packets): hardware (0/5) software (0/0)
  Traffic Statistics for "faulty":
    8778 packets input, 3345614 bytes
    14528 packets output, 17505640 bytes
    133 packets dropped
      1 minute input rate 109 pkts/sec,  8359 bytes/sec
      1 minute output rate 208 pkts/sec,  289404 bytes/sec
      1 minute drop rate, 0 pkts/sec
      5 minute input rate 0 pkts/sec,  0 bytes/sec
      5 minute output rate 0 pkts/sec,  0 bytes/sec
      5 minute drop rate, 0 pkts/sec
  Control Point Interface States:
    Interface number is 5
    Interface config status is active
    Interface state is active

Panos Kampanakis Fri, 06/04/2010 - 10:15

I see CRC errors on the e0/3. That could relate to the issue.

I would suggest checking speed/duplex negotiation with the connected device.

I hope it helps a little.

PK

David White Fri, 06/04/2010 - 14:39

Hi Marcos,

I was looking for the show interface output from both interfaces.  But, as Panos says, you are getting a number of CRC errors, and since you hard-coded the interface speed/duplex on the ASA, there is the possibility that you are getting a duplex mis-match.  I would suggest removing the hard-coding of the speed/duplex on both sides, and verify they auto negotiate to 100/full and then do the test again (after issuing clear interface to clear the packet/error counters).


Sincerely,

David.

marcosgeorgopoulos Sat, 06/05/2010 - 00:29

Thanks Guys,

The other interface is no longer plugged into my switch that is why I didn't provide the show interface of my switch.  I plugged my laptop directly into the firewall on e0/3 and then e0/2  and e0/3 is dramatically slower then when using e0/2.

However I think you may be onto something. e0/3 on the firewall is Hardcoded to FULL/100 whilst e0/2 is AUTO. on the switch all ports are AUTO.

excusse my lack of understanding in this area, but why would this cause this problem?

I will need to go into the datacentre and repatch the port, I will do this next week, switch them both to auto and try again.

I will report back.

Many thanks.

Correct Answer
David White Sat, 06/05/2010 - 08:09

Hi Marcos,

The reason this will cause a problem is if the ASA is hardcoded for 100/full-duplex, and then is connected to a device (laptop/switch) which is configured for Auto then the switch side will try to autonegotiate the settings.  Since the ASA is hard-coded, it will not participate in the negotiation process.  The switch side will then see that negotiation has failed, and will be able to sense the speed, so it will set itself to 100 Mbps.  However, for duplex it cannot be sensed, and therefore the side configured for Auto will default to half-duplex.  Thereby causing a duplex mis-match. 

That is why the general recommendation is to leave all ports at 'auto'.  (In the old days - 1990s; the auto-negotiation process had some bugs between different vendor's equipment, and thus the general recommendation back then was to hard-code everything.  However, those issues have long been since addressed, and configuring the devices for autonegotiation is a much better option, as it avoids the more common case of misconfigurations - where one side is hard-coded, but the other is not).

I hope it helps explain it.

Sincerely,

David.

marcosgeorgopoulos Sun, 06/06/2010 - 15:55

Thanks David,

That explanation was very clear and concise.

I will be heading into my data center in a couple of days and will test then and let you know if that was the issue or not.

Many thanks.

marcosgeorgopoulos Mon, 06/14/2010 - 17:23

Hi David,

I have set both sides of the connection to Auto and the link is up as Full/100.

I don't seem to be seeing an increase in CRC errors anymore and things seem faster. So it looks like the issue could be resolved.

However what is odd to me is before I set the firewall to auto. both side were still Full/100.  I understand why a duplex mismatch would have casued issues but if they were both full and 100 I'm not sure why.

cheers.

David White Mon, 06/14/2010 - 20:02

Hi Marcos,

I agree, that does sound odd, if both sides were hard-coded with the same speed/duplex settings.  Especially since the ASA was receiving CRC errors (which is indicatitive of a duplex mis-match when it is at full-duplex).  We can try to chase it down further if you wish, but it will probably require a maintenance window where we would have access to both devices, and have you switch ports as we collect additional data.  If you want to persue that route, I would suggest opening a TAC case, so that we can be sure to have someone ready during your maintenance window.

Sincerely,

David.

marcosgeorgopoulos Tue, 06/15/2010 - 02:55

Hi David,

Sorry I don't think I made myself clear. The switch was set to Auto and the FW was hardcoded. But the switch had negotiated to (Auto) 100/Full and the firewall was (Hardcoded) 100/Full.

I figured because they were both "Full" there shouldn't be any issues.

I've been monitoring the interface and it doesn't seem to be causing any more CRC errors.

Actions

This Discussion