From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Sun Dec 16 2007 - 14:09:39 ART
Technically you don't have to do this because RIP will be queued
separately as pak_priority by default. This is an internal marking the
router's CPU uses for layer 2 and layer 3 control packets, such as RIP
and OSPF. Check this document on routing queueing for more information:
http://www.cisco.com/en/US/tech/tk543/tk544/technologies_tech_note09186a0080094612.shtml#undqu
HTH,
Brian McGahan, CCIE #8593 (R&S/SP/Security)
bmcgahan@internetworkexpert.com <mailto:bmcgahan@internetworkexpert.com>
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
24/7 Support: http://forum.internetworkexpert.com
Live Chat: http://www.internetworkexpert.com/chat/
Godswill Oletu wrote:
> If you re-read the question again, you will see why matching &
> excluding RIP might not work....
>
> Two keywords in the question is...RIP should not be a candidate to be
> 'shaped' or 'dropped'
>
> Though in the grand scheme of things, I do not know how this could
> happen because by default RIP along with the other routing protocols &
> other "essential services" traffic have given a priority and assigned
> 25% of your bandwidth. This is done for your by the router so that
> these traffics will not contend for available bandwidth with the other
> traffic, you can give increase/decrease the bandwidth allocated to
> these control traffic.
>
> One read of the question indicates that one should ignore what the
> router is doing by default to protect RIP and assume that RIP is not
> been protected at all.
>
> Now, the question said, ...."RIP must not be a candidate to be
> ....dropped......", your solution excluded RIP from been matched,
> which means if we ignore the default allocated 25% priority queue
> assigned to control traffic and in the event of a congestion RIP can
> be dropped or if the allocated 25% priority queue is full, RIP can be
> dropped.
>
> My read into the question is that RIP need to be protected or RIP need
> additional protection beyond what the Router is doing by default.
>
> To achive this, RIP has to be assigned to a class that will prevent it
> from being dropped, the only way to do this is to assign RIP to a
> priority queue, allocate a bandwidth value or percent to this queue
> and call the priority queue in your FRTS subsection.
>
> Now, you might asked? We are calling RIP priority queue under a FRTS,
> are we not shaping RIP then? The answer is no, the queue will not
> loose its priority just because you called it under the FRTS subsection.
>
> Look at this as the skin of an Onion that have many layers, within the
> core we have RIP and we are giving RIP a strict priority, but at the
> outer skin we are shaping all the traffic.
>
>
>
> Godswill Oletu
> CCIE #16464 (R&S)
>
>
> ----- Original Message ----- From: "Joseph Saad"
> <joseph.samir.saad@gmail.com>
> To: "Cisco certification" <ccielab@groupstudy.com>
> Sent: Sunday, December 16, 2007 12:40 AM
> Subject: Re: How do I exclude RIP traffic in FRTS?
>
>
>> Neither do I know how to exclude specific traffic type on FRTS alone,
>> hence
>> I'd be using MQC myself.
>>
>> Here's how I do it.
>>
>> TermServ(config-map-class)#do sh runn | s class-map|map-class|ip ce
>>
>> ip cef
>>
>> class-map match-all NOT_RIP
>> match not protocol rip
>>
>> map-class frame-relay FRTS
>> service-policy output NOT_RIP
>>
>> int s0/0
>> enc frame
>> frame-relay traffic-s
>> frame-relay class FRTS
>>
>>
>> On Dec 16, 2007 6:54 AM, PANDI MOORTHY <moorthypandi@gmail.com> wrote:
>>
>>> Hi Group
>>>
>>>
>>>
>>> My task is to configure the frame-relay traffic shaping on the WAN
>>> interface
>>> to 512K, make sure RIP traffic are not candidate to be shaped or
>>> dropped.
>>> How do I exclude this RIP traffic in FRTS?
>>>
>>>
>>>
>>> I know we can achieve this by MQC based traffic shaping.
>>>
>>>
>>>
>>>
>>>
>>> I don't see any options are available under map-class to exclude some
>>> traffic alone
>>>
>>>
>>>
>>>
>>>
>>> Thanks
>>>
>>> Regards
>>> Pandi
>>>
>>> _______________________________________________________________________
>>> Subscription information may be found at:
>>> http://www.groupstudy.com/list/CCIELab.html
>>
>> _______________________________________________________________________
>> Subscription information may be found at:
>> http://www.groupstudy.com/list/CCIELab.html
>
> _______________________________________________________________________
> Subscription information may be found at:
> http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Tue Jan 01 2008 - 12:04:30 ARST