I have a Cisco 3845 running IOS 15.3(3)XB12 which is accepting synchronous MLPPP calls from ISDN lines via a PRI. I want to reduce the size of the output queue on the router's PPP interfaces, but the command I am using to try to do that does not appear to be having any effect.
When the router is forwarding data to a client at the full line rate, packets going across the link experience a lot (multiple seconds) of latency. The cause of this appears to be that the router has a default output queue size of 40 packets on the Virtual-Access interfaces which get created for each MLPPP session. I want to attempt to reduce this latency by reducing the number of packets the router will queue to send to each client.
The Virtual-Access interfaces are cloned from the Dialer interface associated with the D channel of my PRI, so I added the following commands to my Dialer interface:
hold-queue 5 in hold-queue 5 out
(Note that the "hold-queue 5 in" is just there for comparison; I don't actually need to alter the size of the input queue.)
After making these changes and starting a new client dial-in session, it appears that the input queue size change took effect but the output queue size change did not:
#show int virtual-access 3 Virtual-Access3 is up, line protocol is up Hardware is Virtual Access interface MTU 1500 bytes, BW 128 Kbit/sec, DLY 20000 usec, reliability 255/255, txload 21/255, rxload 5/255 Encapsulation PPP, LCP Open, multilink Open Open: IPCP MLP Bundle vaccess, cloned from Dialer10 Vaccess status 0x44, loopback not set Keepalive set (10 sec) DTR is pulsed for 5 seconds on reset Last input 00:00:00, output never, output hang never Last clearing of "show interface" counters 00:48:39 Input queue: 0/5/0/0 (size/max/drops/flushes); Total output drops: 3 Queueing strategy: fifo Output queue: 35/40 (size/max) 5 minute input rate 3000 bits/sec, 7 packets/sec 5 minute output rate 124000 bits/sec, 10 packets/sec
Starting a download on the connected client then pinging across the link results in 3+ seconds of latency, which is about what you would expect from a 40-packet output queue on the router interface (40 packets in the queue * 1500 bytes per packet * 8 bits per byte / 128000 bits per second = 3.75 seconds max queue time).
For reference, here are the complete configurations of the Dialer and D-channel interfaces:
interface Dialer10 ip unnumbered Loopback3 encapsulation ppp no ip route-cache cef dialer in-band dialer idle-timeout 0 dialer-group 5 peer default ip address pool isdn no cdp enable hold-queue 5 in hold-queue 5 out interface Serial3/0:23 no ip address encapsulation ppp no ip route-cache cef dialer rotary-group 10 dialer-group 5 autodetect encapsulation ppp v120 isdn switch-type primary-ni isdn incoming-voice modem ppp authentication chap ppp multilink no cdp enable
Does anyone have any idea why this change seems to be taking effect for the interface input queue but not the output queue, or what the correct way is to alter the output queue size?
Note 1: This question is different than the one here, which this was marked as a duplicate of. That question is about trying to get a router to generate ICMP Source Quench messages, which I am not trying to do. The document linked to as an answer to that question discusses how to adjust a router's strategy for allocating shared buffer resources between busy interfaces, which is also not what I am trying to do. I am trying to reduce the output queue length of a single interface.
Note 2: Through further experimentation, I have found that my
hold-queue 5 out
directive on the Dialer actually does take effect, just not on the first time a given cloned Virtual-access interface comes up. Once a Virtual-access interface has come up, then been torn down due to a hangup, it will come up with an output queue size of 5 on all subsequent connections. If anyone knows why this is or what to do about it, I would still be very interested to know.
Otherwise, I will pursue one of the suggested alternate approaches (QoS queue-limits and/or RED).