From: Joseph Brunner (joe@affirmedsystems.com)
Date: Sun Nov 18 2007 - 16:06:12 ART
You would think, but look at Brian's question on that... in the real world I
would divide up the interface and see what is reserved and free.
The IE question on that specifically said "full T-1"
The logic here is any Priority will be done at levels we guarantee with
MINCIR settings, which the DLCI 502 wont have, and using service policy
which gets things into the tx ring ahead of general traffic without
priority/bandwidth statements used in policy-maps which we apply to the
"slower" dlci.
Per odom's qos book and my own research there are 2 queues on frame-relay
interfaces, "high and low". Each of these feeds into the tx ring for
hardware transmission. DlciB's traffic is still trying to get into one of
these two queues. If both DLCI A & B has a service-policy output with
priority in a class, or is using ip rtp priority for frame-relay priority
queuing the packets will flow round robin into the high queue as they are
serviced (sort of like priority fifo, if you will into the high queue)
So no, DLCI B is still going to wait... the scheduler is not per-dlci its
per frame-relay MAIN interface
Each dlci (and sub interface) has no inherent queue's they use the interface
hardware queues.
Check this doc...
http://www.cisco.com/warp/public/105/queuing_fr_interfaces.html
and while your reading it, remember we have control of what gets into the
high queue at all times, whether we configure ip rtp priority,
service-policy POLICY1 output with "priority" in the classes, etc.
-Joe
-----Original Message-----
From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
Gregory Gombas
Sent: Sunday, November 18, 2007 1:57 PM
To: Cisco certification
Subject: RE: Frame-Relay Traffic Shaping
Thanks Joe. Now when you shape DLCI 502 to 1536kbps, aren't you
essentialy giving DLCI 502 free reign over the entire circuit, thus
nullifying the QOS policies you configured on DLCI 501?
Which leads me to my follow up question:
When applying a QOS policy to one DLCI (lets call it DLCI A) but not
the other DLCI (call it DLCI B), wouldn't DLCI B's traffic impact DLCI
A's traffic?
Taking voice traffic for an example:
1. Configure DLCI A with miniumum bc and fragment size and prioritize
voice traffic.
2. Configure nothing on DLCI B.
Wouldn't a large file transfer on DLCI B with its 1500 byte packets
overwhelm the entire frame relay circuit and thus destroy the QOS
policy on DLCI A?
On Nov 18, 2007 1:31 PM, Joseph Brunner <joe@affirmedsystems.com> wrote:
> When you enable traffic shaping on the main interface, does it
automatically
> shape all DLCI's to 56k?
>
> >YES, and IE labs have another lab where this affected a dlci
inadvertently
> and you need to create a second map-class to apply it to the dlci you
don't
> want at 56k by default.
>
> So if you're requirement is to shape one DLCI but not impact the other
> DLCI's, would you need to manually configure the CIR for the other
> DLCI's?
>
> >anytime you have more than one dlci on an interface you have to worry
about
> the effect of "frame-relay traffic-shaping". If you are ONLY going to
> perform shaping for one dlci, and using sub-interfaces you can not use
> frame-relay traffic-shaping and use nested policy-map's, where the parent
> policy-map has something like "shape average 512000" in the class
> class-default.
>
> If you are going to shape per dlci with physical interface frame-relay you
> should make sure you don't slow down the other dlci's. so I would go as
far
> making a second map class just to guarantee cir is working as planned.
>
> (with physical interface)
> Int s0/0
> Frame-relay traffic-shaping
> Frame-relay interface dlci 501
> Class DLCI_501
> Frame-relay interface dlci 502
> Class DLCI_502
>
> If so what value do you set them to if you don't know their
> CIR?
>
> >1536kbps! Better safe then sorry
>
> > Again this is from IE Lab 13 Task 6.3 where the solution guide shows
> DLCI 502 configured with a CIR 512k which is the access rate and I am
> wondering why would you shape at the access rate?
>
> This is the stated limit of the line's cir. This does relate back to
> traditional telecom where the cir is a contracted amount and enforced by
the
> frame-relay switch. So I guess this lab teaches us we have some work to do
> in order to prevent to many discards.
>
> -Joe
>
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of
> Gregory Gombas
> Sent: Sunday, November 18, 2007 1:19 PM
> To: Cisco certification
> Subject: Frame-Relay Traffic Shaping
>
>
> I noticed when you apply a map-class to a frame-relay subinterface you
> still need to enable traffic shaping on the main interface.
> When you enable traffic shaping on the main interface, does it
> automatically shape all DLCI's to 56k?
>
> So if you're requirement is to shape one DLCI but not impact the other
> DLCI's, would you need to manually configure the CIR for the other
> DLCI's? If so what value do you set them to if you don't know their
> CIR?
>
> Again this is from IE Lab 13 Task 6.3 where the solution guide shows
> DLCI 502 configured with a CIR 512k which is the access rate and I am
> wondering why would you shape at the access rate?
>
> Thanks,
> Greg
>
>
> _______________________________________________________________________
> 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 : Sat Dec 01 2007 - 06:37:30 ART