I have a Cisco ASA 5510 connecting our office via 2Mbit/s Internet. When Internet link fills up, latency to a well-connected host on Internet goes from 5-8 ms to 500-800 ms. With ping, it may look something like this (TCP performance seems to match this):

64 bytes from X: icmp_req=242 ttl=59 time=450 ms
64 bytes from X: icmp_req=243 ttl=59 time=458 ms
64 bytes from X: icmp_req=244 ttl=59 time=495 ms
64 bytes from X: icmp_req=245 ttl=59 time=186 ms
64 bytes from X: icmp_req=246 ttl=59 time=103 ms
64 bytes from X: icmp_req=247 ttl=59 time=5.18 ms
64 bytes from X: icmp_req=248 ttl=59 time=4.94 ms
64 bytes from X: icmp_req=249 ttl=59 time=4.65 ms
64 bytes from X: icmp_req=250 ttl=59 time=4.85 ms

I assume this is because large send queues on the 2 Mbit link. Since this is mainly office IT (from < 20 ppl), lateny is more important than throughput.

How can I measure how this latency is divided between outbound and inbound leg? If it turns out to be generated equally or mostly on inbound traffic, can I affect that (i.e. ingress throttling) or do I have to contact my ISP? How best to achieve this on ASA 8.2?

UPDATE: Short topolgy:

Ping node -[gbit]->
  ProCurve dist -[gbit]->
    ProCurve core -[gbit]->
      ASA -[100 mbit]->
        DSL -[copper]->

ASA interface upstream:

asa# show interface Ethernet 0/3
Interface Ethernet0/3 "outside", is up, line protocol is up
Hardware is i82546GB rev03, BW 100 Mbps, DLY 100 usec
    Auto-Duplex(Full-duplex), Auto-Speed(100 Mbps)
    Input flow control is unsupported, output flow control is off
    Description: ### Upstream ###
    MAC address X, MTU 1500
    IP address X, subnet mask
    3480433364 packets input, 2625479988848 bytes, 0 no buffer
    Received 1010728 broadcasts, 0 runts, 11 giants
    11 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
    0 pause input, 0 resume input
    0 L2 decode drops
    3160567056 packets output, 1537515646562 bytes, 0 underruns
    0 pause output, 0 resume output
    0 output errors, 0 collisions, 15 interface resets
    0 late collisions, 0 deferred
    6 input reset drops, 0 output reset drops, 0 tx hangs
    input queue (blocks free curr/low): hardware (255/240)
    output queue (blocks free curr/low): hardware (255/109)
Traffic Statistics for "outside":
    3487933998 packets input, 2561681053821 bytes
    3160334264 packets output, 1477359288037 bytes
    57746233 packets dropped
  1 minute input rate 193 pkts/sec,  209755 bytes/sec
  1 minute output rate 122 pkts/sec,  12734 bytes/sec
  1 minute drop rate, 1 pkts/sec
  5 minute input rate 177 pkts/sec,  174578 bytes/sec
  5 minute output rate 131 pkts/sec,  17600 bytes/sec
  5 minute drop rate, 2 pkts/sec
  • Could you give us more information about the how you're connected to the 2Mbps link and the infrastructure the ASA is connected to? FYI, the ASA does not support CBWFQ with per class shaping (which would be optimal in this case). If you have any devices capable of this inline with the ASA, it would help to know that. Dec 2, 2013 at 13:02
  • Updated with topology and if info. In theory, I could insert a Linux-box somewhere, but would rather not.
    – Bittrance
    Dec 2, 2013 at 14:33
  • @MikePennington I suppose I need to talk to my ISP and/or set up a Linux box. If you post a reply to this effect, I'll accept it.
    – Bittrance
    Dec 2, 2013 at 20:44
  • I can add a reply before tomorrow AM. I am traveling today with spotty Internet access, which is limited to my phone Dec 2, 2013 at 21:12

2 Answers 2


How can I measure how this latency is divided between outbound and inbound leg?

You can find the congested ping direction with hping on linux / cygwin.

If it turns out to be generated equally or mostly on inbound traffic, can I affect that (i.e. ingress throttling) or do I have to contact my ISP?

You can do it either way, but the ISP method is better since it won't transmit across the DSL before controlling the traffic. However, there is nothing fundamentally wrong with controlling both directions on the ASA (as long as you implement it correctly). I agree with you that linux is not a good enterprise qos solution, since there are non-trivial supportability issues with anyone who has to maintain the iptables policies.

How best to achieve this on ASA 8.2?

First be sure you know how much bandwidth you have in the Tx / Rx direction. Note that DSL uses ATM, which can be a little tricky due to the ATM cell tax.

Then, use hierarchical priority queueing (aka hierarchical QoS, or HQoS) on the ASA; this is a sample policy:

class-map CLASS_VOICE
 match dscp ef
 match dscp af31
 ! Give VOICE and VOICE SIGNAL priority
 class class-default
 ! Shape all traffic to slightly less than the DSL modem's ingress bandwidth
 ! I assume you have 2Mbps here, but please measure what you have
 class class-default
  shape average 2000000 16000
 ! Shape all traffic to slightly less than the DSL modem's egress bandwidth
 ! I assume you have 512Kbps here, but please measure what you have
 class class-default
  shape average 512000

This example assumes you implement both Tx and Rx HQoS on the ASA (and that you only use two interfaces on your ASA). It also assumes you have already marked your traffic correctly. However, by the time you finish trying to mark traffic on your powerconnects, you might think it's easier to put a real Cisco router in-line to do the marking for you. If you put a router inline, it's usually better to do the qos on the router.

  • Great answer Mike, but one note: DSL does not always use ATM. I've personally worked on replacing hundreds of ATM DSLAMs with Ethernet fed ones. DSL is no different than most carrier services these days with a rush to Ethernet based transit. With that said, depending on the carrier/where you are in the world, ATM could still be the uplink technology from the DSLAM. Dec 3, 2013 at 12:44
  • @Brett, thank you. I have seen DSLAMs that use ethernet uplinks after aggregating a bunch of ATM PVCs, but I don't recall seeing one that was ethernet all the way to the CPE. It would seem to me that it's no longer DSL if the CPE uplink is ethernet... at that point it would be something like an epon solution to an ethernet switch, no? Dec 3, 2013 at 12:48
  • It isn't technically Ethernet all the way to the CPE. The DSLAMs use one of the ADSL standards (ADSL2, ADSL2+, etc) to bridge Ethernet across the 2-wire pair (between DLSAM and modem) to the CPE. If my memory serves, ATM never factors into the service at all, I didn't have to build new PVC's etc. Take a look at the Adtran TA series of boxes, we specifically used the TA1248. Dec 3, 2013 at 14:52
  • I'm marking this correct, because it at least the hping bit works fine. I haven't tried the ASA stuff yet, but it looks promising. Thank you very much for this comprehensive answer!
    – Bittrance
    Dec 4, 2013 at 13:42
  • 1
    @Bittrance, You're most welcome; I am curious, was the egress from DSL congested or was it ingress to the modem? DSL modems tend to have huge packet buffers, so my guess was that it was the egress direction Dec 4, 2013 at 13:48

Judging from your ASA statistics, it does appear that the majority of traffic is on the inbound path. If you intend to do some sort of policing or shaping, you will have to do it on the far end (i.e., the output of the other side of the WAN). The ASA has no scheduling controls on the input queue, but even if it did, the queue would never fill up because the bottleneck is the WAN link, not your input queue.

  • 1
    Temporary traffic bursts will not loom so large in traffic stats; it's not a good idea to make these kind of broad assumptions about suitable solutions from a simple stats screen cap Dec 2, 2013 at 15:22
  • Perhaps not, but a one minute average showing almost 18x more traffic on inbound than outbound is a strong hint, especially if it's consistent with the 5 minute average. If the traffic was real bursty, he wouldn't get the kind of ping response (several pings in a row with high response times) he posted.
    – Ron Trunk
    Dec 2, 2013 at 16:20
  • Generally speaking, this being an office net, it is likely that inbound is busier than outbound. However, there are some "large upload" use cases, so I was curious if there is some method whereby one could verify.
    – Bittrance
    Dec 2, 2013 at 18:52
  • If you use the ASDM, you can graph interface statistics over time. If you're willing to watch it over some period of time, you should be able to figure out what is using up your bandwidth.
    – Ron Trunk
    Dec 2, 2013 at 19:10
  • Oh, I got port monitoring and rrd graphs galore. I know precisely who is doing the talking. It is just that I am looking for a method to improve the user experience that does not include wholesale throttling or repeated head-bashing.
    – Bittrance
    Dec 2, 2013 at 20:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.