Multilink with QoS - 'packets late drop'

Unanswered Question
Apr 29th, 2008
User Badges:

Hi experts,


I have a multilink (2*E1s) running across a CE to PE - running QoS on it. It is reporting loads of Packets Late Drops and hence output drops on the interface. I would really appreciate if someone can help me with this please.


I have attached some very essential outputs in the txt file for troubleshooting purposes.


Many Thanks

Arav



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
guruprasadr Tue, 04/29/2008 - 06:50
User Badges:
  • Gold, 750 points or more

HI Arvindh, [Pls Rate if HELPS]


Thanks for the Logs Shared. The Configuration of QOS all looks OK.


Add, the configuration to the MultiLink Interface on both sides:


load-interval 30

hold-queue 500 out


>> Observe to see if the drops continue to increase.


In addition, Can you please execute the command and see whether both the E1's are bundled very well under Multilink Interface:


#sh ppp multilink interface multilink 8


Also, can you check whether any CRC, Overrun, Errors increasing on the "E1 Links" that are bundled with the Multilink Interface which could cause such problem too.


Hope I am Informative.


Pls Rate if HELPS


Best Regards,


Guru Prasad R

Joseph W. Doherty Tue, 04/29/2008 - 07:19
User Badges:
  • Super Bronze, 10000 points or more

I haven't seen packets late drop before, but I wonder about max-reserved-bandwidth 100 usage on the PE. This leaves none for overhead, and although your StandardMQC class matches any and the stats for class-default show no packet matches, I still wonder if this, in this instance, might be an issue.


I also note the same policy is working as expected on the CE router, but I further see a VRF is being used on the PE router. Additionally, from the policy stats, I would guess that the PE and CE are different platforms and/or IOS revs. The PE stats are what I might expect on a 7500 or some 6500/7600 WAN cards, those on the CE are more in line with a software router. Perhaps you have bumped into either a bug or an implementation difference because of platform or IOS rev.


On your PE, you might try removing StandardMQC and using max-reserved-bandwidth 91 and see if the drop behavior changes at all.

aravindhs Tue, 04/29/2008 - 07:44
User Badges:

Hi Guru, Joseph,


Thank you both for your replies. I realise that increasing the hold queue will extend the FIFO software queue on the multilink and cause delays to the priority traffic. They will get scheduled in priority before the other CBWFQ queues but will undergo a 'head-of-line' blocking and sit on the hold-FIFO Q.


I was thinking in line with Joseph though- that I would remove the standard class and reduce the max-reserved-bandwidth to 80 or may be even 90. And let the unmarked traffic take the class-default and use fair-queue servicing that it offers by default.


I was wondering why the standard class in my config won't rob bandwidth from the Biz Critical class when it exceeded its BW limit. But I reckon that it is actually the queue that is filling up and not the bandwidth that is getting exceeded. The late drops might just imply that the queue is filling up and there is tail drop. So, for example if the queue limit for strd traffic is 10 and if there are ten 64 byte packets in the strd queue, the bandwidth would only be 640 bytes in the standard queue but the 11th packet would get dropped as 'late packet drop' which is effectively a tail drop.


I would really appreciate any more opinions on this.


Many thanks !


Cheers

Arav

Joseph W. Doherty Tue, 04/29/2008 - 08:07
User Badges:
  • Super Bronze, 10000 points or more

You certainly could use different values for max-reserved-bandwidth, I suggested 91 to preserve the 9% you're now using for standard.


On most Cisco software routers, something to note about using FQ within class-default, every flow grabs bandwidth. I.e. all flows within that class don't seem to limit themselves to what should be the class percentage. (7500s and 6500/7600s with some WAN cards do restrict all class-default flows to the overall percentage.)


As to your concern of standard class robbing bandwidth from critical, it shouldn't, the non-LLQ bandwidth percentages provide a floor. I.e. such classes can use more bandwidth if it's available. If, for instance Video wasn't using any (and both your stats show zero matches, so it's possible), that bandwidth would be available to other classes. If both critical and standard wanted all the available bandwidth, the excess is proportioned in the same ratio, in your case 65:9.


With regard to you idea about tail drops showing as "late packet drops", they should be counted as drops within the class, like the 417 drops seen on the PE's StandardMQC class.


What you might also check is your PE's buffers stats, looking for buffer failures. If this was happening, I would expect counts against "no buffer drops" or "other drops" within the class, but I have seen drops against the interface which I haven't been able to account for, although I suspect, in the instance I have in mind, they're tail drops off the back end of a shaper within a class.

aravindhs Wed, 04/30/2008 - 12:03
User Badges:

Hi Joseph,


Thanks for your reply again. My concern was actually the opposite of what you wrote. I was thinking why it did not rob the bandwidth from the other classes when it had free unused bandwidth in the other classes. I think it is a case of tail-drops rather than anything else. I am planning to use a lesser max-res-bw to 91 like you suggested and not specify a standard class and just leave it to the class-default to handle the rest of traffic. I will let you know once I have done the change.


Cheers

Arav

Actions

This Discussion