From: Joseph Brunner (joe@affirmedsystems.com)
Date: Sun Nov 18 2007 - 22:05:01 ART
If you notice on that link the picture near the top -
Wfq is enough to get into the high queue.
So if DLCI_A has a service policy with a "bandwidth 384" statement in a
class, then that will be prioritized above "best efford" from DLCI A & B,
both riding the low queue.
Regarding Brian's lab where we set a DLCI that was inadvertently set to
56kbps after enable traffic-shaping for another dlci-
Both the DLCI with traffic shaping and the one that given "full T-1" traffic
shaping are going to be sharing the low queue with contention.
Its is just a fact of frame relay... so regardless of dlci # we can always
put traffic into the interface high queue, as outlined in the doc
-Joe
-----Original Message-----
From: Gregory Gombas [mailto:ggombas@gmail.com]
Sent: Sunday, November 18, 2007 7:56 PM
To: Joseph Brunner
Cc: Cisco certification
Subject: Re: Frame-Relay Traffic Shaping
That DOC clears up a lot of confusion - thanks.
One thing I'm still not clear on is why they shaped DLCI B to line
rate? According to that doc :
"Without any shaping, a VC can consume all interface bandwidth and
starve other VCs. "
So while the voice traffic is protected in the high queue, how is the
bandwidth reservation for HTTP traffic on DLCI A affected?
On Nov 18, 2007 2:06 PM, Joseph Brunner <joe@affirmedsystems.com> wrote:
> 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
>
> _______________________________________________________________________
> 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