QoS - Input queue question

Hi All,

I was going over QoS again and there is something that is bugging me. How can an input queue on an interface get congested using the following example out of the Vol 1 book? R6 pings R1 and the interface on R1 drops traffic on the input queue.

R1 ---R6

R6#ping repeat 1000000 timeout 0 size 1000

Sureley R6 can only transmit at the same speed as R1 can receieve so I dont see a scenario where R6 can overrun the interface? Traffic on R1 should be pulled off the Rx ring and transmitted to the backplane as fast as its sent when we use hardware switching. There should never be a need for the Rx-ring to use the input queue unless we are not using CEF and the routers CPU is busy. Am I correct?





  • In your example, all packets received by R1 are destined for the control-plane itself. Switching is not involved here. There are quite a few things going on on R1 after the ICMP echo packets are receieved, including pulling the packets from the RX ring, passing them to the upper layer processes, creating the echo reply and sending it back to R6. When packets are arriving faster than R1 can process them, input queue will fill up and drops start to occur.

  • Of course. Its so obvious now but I couldnt see it before so thanks for that. If a packet is traversing the router I believe my first statement should be true though. As long as its hardware switched. Correct?

  • Hi rmcewin. I do believe that's true. But if the egress interface is slower than the ingress interface, you might still see output drops at the egress interface.

  • peetypeety ✭✭✭

    Surely R6 can only transmit at the same speed as R1 can receieve so I dont see a scenario where R6 can overrun the interface?

    Back when routers were invented, traffic followed the 80/20 rule: 80% of the traffic was local, and 20% was remote.  The 80% would not bother the router as it'd be unicast to other MAC addresses, and 20% of line rate would flow into the router.

    Nowadays, Cisco's famous for routers that can't handle line rate, especially when features are applied.  Just because it's a GE port does NOT mean that the router can transit 1Gbps of traffic arriving on the port.  (Notable example: GSR/12008, which is 2.5Gbps per slot hardware forwarding.  8-port FastEthernet card, so 800Mbps of front-panel connectivity feeding 2500Mbps of backplane connection.  However, it's built on the oldest of the 2.5G/slot "engines", so no priority queueing support whatsoever, and lots of other limitations.  With only 1 port active (so 100Mbps of front-panel traffic feeding a 2500Mbps backplane connection), under a DOS attack we'd see input overruns and other input errors, and certainly less traffic flowing out of the box than we were seeing into the box.)

  • Thanks Peety. Some very interesting examples. I have seen 6500 line cards (48 port gig interfaces) that contain larger input capability than the backplane but I have never seen them actually have issues. Obviously its rare to have that many interfaces all inputting at full rate. I always wondered what I would see if the backplane was congested. I assume, if I use you example, that I would see the input queues fill up while they wait to transmit onto the backplane. Is that correct?

  • peetypeety ✭✭✭

    It's all platform-dependent, and that dictates where you'd look for issues.  Sometimes it's so early in the pipeline that it's hard to find.  A lot of times it's "microbursts", super-brief onslaughts of high-rate traffic that's enough to overrun the card's ability but not hit your ability to detect it.

    Take a look at the bps vs. pps specifications for a Cisco device sometime, and do the math for packets from 64B to 9000B.  Example: the Supervisor720 can operate a system capable of moving 720Gbps (which happens to be marketing math right away).  However, it can only process 15Mpps unless you take specific actions to boost that (DFCs can put up to 48Mpps of ingress processing on each card, and a modification to the packet header handling scheme can boost the Sup's capability to 30Mpps). But alas, we're off-topic a bit now.

Sign In or Register to comment.