Showing results for 
Search instead for 
Did you mean: 

ASA Doubled values in Interface Traffic Usage



Perhaps someone smarter than me would be able to shed some light on this situation:

ASA 5505, 9.1.4, BT Fibre 80/20, ECI modem, PPPoE dialout on the outside interface

Everything works fine (well, I've had to lower tcpmss to 1300 as I've been getting the PMTU-D errors when trying to browse thru VPN tunnel), except I've noticed that traffic usage per interface on the outside interface shows doubled values of what's really being pushed thru it.

clear interface outside, clear interface inside and :


        received (in 7.480 secs):

                25006 packets   1002424 bytes

                3343 pkts/sec   134013 bytes/sec

        transmitted (in 7.480 secs):

                51058 packets   66144398 bytes

                6825 pkts/sec   8842833 bytes/sec


        received (in 5.010 secs):

                67904 packets   88375838 bytes

                13553 pkts/sec  17639887 bytes/sec

        transmitted (in 5.010 secs):

                16756 packets   835423 bytes

                3344 pkts/sec   166751 bytes/sec

The figure on the outside interface shows 134.58 Mbps !

The inside interface shows correctly 67.46 Mbps.

Consequetnly the ASDM shows exactly the same thing on the graphs.

Previously ASA has been used with VM Cable modem on 120Mbps connection, and it was showing the correct values (also worked fine with default tcpmss of 1380)

Ideas, anyone ?

3 Replies 3

Maykol Rojas
Cisco Employee
Cisco Employee


Well this is just a guessing, may not be your situation, but here it goes. Some of the reasons could potentially be the Headers for VPN traffic. Remember that the ESP header is 20 bytes, when it goes to the inside, this header is ripped off and the Data is sent clear text without this header, this, and just this would cause the value not to be equal.

Second, the internet is full of garbage, DoS, script kiddies and what not. Someone might be sending a lot of traffic to your outside interface without (until now) you noticed.

Best way to verify this is to put a capture on the outside interface and validate the traffic you are seeing, or use Netflow to go through the flows and check what is the most traffic that is hitting the outside.

Firewall Dashboard does show some interesting stuff to troubleshoot with, but may not be the final answer.

Let me know.



Hola Maykol.

I wish it would be that easy

Let me elaborate then, to show you the full test environment. The figures you see are with no VPN tunnels estabilished, all incoming traffic being dropped on the outside interface (except the already estabilished, of course), and it's just a single huge file download using d/l manager with 8 threads to saturate the bandwidth. That's what bugs me, not to mention the fact that it's virtually impossible to get these figures on the fastethernet interface ....

That's why I've decided to drop everything and do this test with just a download, to be able to isolate the issue. The moment download stops, traffic stats are dropping to 0 on both interfaces. It's just the outside that shows the doubled values of what's really hitting the downloading machine in the inside network ...

How's that for a mystery, huh ?




But the outside is facing an internet link is that correct?

It would be really easy to receive 134Mbps on a fastethernet interface and not impossible at all. If it is running at 100Mbps with full duplex the bandwidth of that interface would be 200mbps, if at some point you are seeing going up more than 200, that would be impossible.

In regards to the traffic that is being dropped. It would be dropped, however, the counter will increment no matter if the traffic is being dropped or not.

Again, placing a capture I am pretty sure you will be able to see what is going on. If both captures inside and outside show a bandwidth of 60Mbps while analyzing it with Wireshark, then we would be talking about a Software bug that incorrectly shows and parses the "show traffic output".

PS: Forgot to mention that the ASA uses TCP proxy feature as well for TCP connection, that would also increse the load on that interface.


Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers