I agree as far as the traffic source. However I think queue- 
thresholding is relevant only for incoming traffic. So what we are  
talking about is what happens between the control-plane and the tx- 
ring. Packets generated by the cp for IGP traffic has internal tag of  
pak_priority. This should go into a special queue and has the most  
direct access to the tx-ring.



On May 14, 2010, at 2:52 PM, Adrian Brayton <[email protected]> wrote:

> I think the direction that you want to head in is "Control Plane"...
>
>
> On May 14, 2010, at 12:16 PM, Paul Stewart wrote:
>
>> Maybe priority queue is a misuse of the term. But my understanding  
>> is that in IOS, there is a special queue for packets tagged  
>> internally as pak_priority (all routing protocols except bgp). This  
>> shields them from going to class-default and effectively gives them  
>> access to the 100% - max reservable bandwidth. Therefore they get  
>> priority to the tx-ring(but not necessarily cassified in the  
>> priority queue I suppose?). I'm not sure how different the ASA is  
>> in this regard.
>>
>>
>>
>> On May 14, 2010, at 11:41 AM, Brandon Carroll  
>> <[email protected]> wrote:
>>
>>> I'd have to revisit this, because it's been some time since I've  
>>> done anything with it, but I recall something from the old QOS  
>>> class about the max-reservable bandwidth is defaulted to 75% of  
>>> the link bandwidth so that routing protocols and other traffic can  
>>> have a little breathing room.  Like I said, I'll have to revisit  
>>> this, but I think this may be the case.  I don't think routing  
>>> protocol traffic actually uses the "priority" queue on Cisco  
>>> routers, unless you classify the traffic and put it there.
>>>
>>> Sorry if I'm off base here, just thinking out loud.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Brandon Carroll - CCIE #23837
>>> Senior Technical Instructor - IPexpert
>>> Mailto: [email protected]
>>> Telephone: +1.810.326.1444
>>> Live Assistance, Please visit: www.ipexpert.com/chat
>>> eFax: +1.810.454.0130
>>>
>>> IPexpert is a premier provider of Self-Study Workbooks, Video on  
>>> Demand, Audio Tools, Online Hardware Rental and Classroom Training  
>>> for the Cisco CCIE (R&S, Voice, Security & Service Provider)  
>>> certification(s) with training locations throughout the United  
>>> States, Europe, South Asia and Australia. Be sure to visit our  
>>> online communities at www.ipexpert.com/communities and our public  
>>> website at www.ipexpert.com
>>>
>>> Platinum Solutions Group (PSG) provides high-end consulting  
>>> services with a primary emphasis on Cisco's Data Center Solutions,  
>>> Service Provider Solutions, Unified Communications and Security- 
>>> enabled infrastructures. Be sure to visit www.platinumsolutionsgroup.com 
>>> .
>>>
>>>
>>>
>>> On May 14, 2010, at 5:37 PM, Paul Stewart wrote:
>>>
>>>> I think this is not just an ASA thing. It seems that routing  
>>>> protocol
>>>> traffic is always handled by the priority queue on a router as  
>>>> well.
>>>>
>>>>
>>>>
>>>> On May 14, 2010, at 3:06 AM, Anantha Subramanian Natarajan 
>>>> <[email protected]
>>>>> wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Was reading through Chapter 11(QOS) on the Cisco ASA:All-in-One
>>>>> Firewall,IPS,Anti-X, and VPN Adaptive security appliance" book and
>>>>> inferring
>>>>> the below sentence from that
>>>>>
>>>>> "Certain critical keep-alive packets such as EIGRP hello packets  
>>>>> are
>>>>> never
>>>>> dropped even if they are not prioritized in the shaped traffic"
>>>>>
>>>>> Have a question on that,
>>>>>
>>>>> 1) Is all protocols hello packets treated that way in Cisco ASA  
>>>>> and
>>>>> if so,
>>>>> how Cisco ASA keeps track of that to have this exception.
>>>>>
>>>>> Thanks for the help
>>>>>
>>>>> Regards
>>>>> Anantha Subramanian Natarajan
>>>>>
>>>> _______________________________________________
>>>> For more information regarding industry leading CCIE Lab  
>>>> training, please visit www.ipexpert.com
>>
>
_______________________________________________
For more information regarding industry leading CCIE Lab training, please visit 
www.ipexpert.com

Reply via email to