From: Brian McGahan (bmcgahan@internetworkexpert.com)
Date: Fri May 21 2004 - 20:27:56 GMT-3
I'm not sure what you mean by fragment delay, but in simpler
terms the fragment size is just the Bc expressed in bytes (Bc/8). You
can configure it to be larger or smaller, but by setting it to be Bc/8
you are ensuring that a fragment takes no longer than 1 Tc to send.
HTH,
Brian McGahan, CCIE #8593
bmcgahan@internetworkexpert.com
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
Toll Free: 877-224-8987 x 705
Outside US: 775-826-4344 x 705
> -----Original Message-----
> From: Mujica, Raul - (Per) [mailto:raul.mujica@telmex.com]
> Sent: Friday, May 21, 2004 6:18 PM
> To: Brian McGahan; Osterberg, Todd (EM, ITS); ccielab@groupstudy.com
> Subject: RE: Frame-Relay and QoS Questions
>
> Brian,
> I want to confirm if you use the formula "FS = BW * fragment delay /
8" to
> define fragment.
>
> FS = [512000 * (1/100)] / 8 = 640 bytes.
>
> Thank
> Raul
>
>
> -----Mensaje original-----
> De: Brian McGahan [mailto:bmcgahan@internetworkexpert.com]
> Enviado el: Viernes, 21 de Mayo de 2004 04:53 p.m.
> Para: Osterberg, Todd (EM, ITS); ccielab@groupstudy.com
> Asunto: RE: Frame-Relay and QoS Questions
>
> Hi Todd,
>
> Your Bc value for the class is WAY to high. The size of Bc
> determines the worst case delay for a packet as it waits to move from
> the output queue to the transmit ring. The larger the Bc the more
> possibility to have an unacceptable delay. You should use the
following
> calculation:
>
> Bc = CIR/100
>
> This results in the Tc interval of 10ms, which is the minimum
> configurable. You should also considering enabling fragmentation, as
> with a CIR of 512000 and a Bc of 5120 the maximum packet size you can
> send in a single interval is 640 bytes. You should set the fragment
> size to 640 bytes to ensure that a single packet does not need more
than
> one Tc to be transmitted. Your class should therefore read something
as
> follows:
>
> map-class frame-relay 256k-frts
> service-policy output QoS-Policy
> frame-relay mincir 256000
> frame-relay cir 512000
> frame-relay bc 5120
> frame-relay fragment 640
>
> If you are going to configure Be on the circuit you should
> determine at what rate the provider is policing you at. If your
> applications can endure possible packet loss in favor of bandwidth you
> may consider setting the Be to be the (AR - 512000)/100. This will
> allow you to burst up to the AR if you have enough credit.
>
> Next, inside your service policy you are matching af41 and then
> setting it to af41. Do you mean to do this for traffic that is
matched
> by the access-list but not already set to af41?
>
> For further reference see the following paper on FRTS:
>
> http://www.internetworkexpert.com/resources/01700368.htm
>
> HTH,
>
> Brian McGahan, CCIE #8593
> bmcgahan@internetworkexpert.com
>
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
> Toll Free: 877-224-8987 x 705
> Outside US: 775-826-4344 x 705
>
>
> > -----Original Message-----
> > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
> Of
> > Osterberg, Todd (EM, ITS)
> > Sent: Friday, May 21, 2004 4:39 PM
> > To: ccielab@groupstudy.com
> > Subject: Frame-Relay and QoS Questions
> >
> > I have some questions for the group...
> >
> > Remote site has a single frame-relay t1 with 2 pvcs. Primary PVC
has
> a
> > CIR of 256K but can burst to full AR. The backup PVC is 4K but can
> > burst to full AR. With the contact we have with the Telco, out
> packets
> > never get marked DE, we are not charged more if we send traffic at
> > double the CIR. We will be running video conferencing and multicast
> > audio (16K) and multicast video (56K) sessions across the WAN. Here
> is
> > the sample config for a remote site with a 256K CIR (see below). So
> > here are my questions:
> >
> > 1. What are the thoughts/comments on the CIR/MINCIR/Be/Bc values.
> > 2. What would you tweak these values to be if the CIR was 512K?
> > 3. Is there any interaction between the interface bandwidth command
> > and the FRTS map-class values?
> >
> > The configuration at the head end will be similar except that it
will
> be
> > ATM plus we will be providing a class-map for multicast traffic.
> >
> > Any other thoughts or comments would be appreciated.
> >
> > Thanks,
> >
> > Todd Allen Osterberg
> > GE IT Solutions
> > Cisco Content Networking Specialist
> >
> > class-map match-any video-conference
> > match access-group 102
> > match ip dscp af41
> >
> >
> > policy-map QoS-Policy
> > class video-conference
> > priority 450 30000
> > set ip dscp af41
> > class class-default
> > fair-queue
> > random-detect dscp-based
> >
> >
> > access-list 102 permit ip host x.x.x.x any << ip address of the
h.323
> > end point >>
> >
> >
> > interface serial0/0
> > encapsulation frame-relay
> > no ip address
> > desc physical interface <<<circuit id>>> etc
> > frame-relay traffic-shaping
> >
> > interface serial0/0.16
> > desc primary PVC CIR=256k, burst to 1500K
> > frame-relay interface-dlci 16
> > class 256k-frts
> > ip address 10.1.1.1 255.255.255.0
> > bandwidth 256
> >
> > interface serial0/0.26
> > desc backup pvc CIR=4K, burst to 1500K
> > frame-relay interface dlci 26
> > class 256k-frts
> > ip address 10.2.2.1 255.255.255.0
> > bandwidth 4
> >
> > map-class frame-relay 256k-frts
> > service-policy output QoS-Policy
> > frame-relay mincir 256000
> > frame-relay cir 512000
> > frame-relay bc 1000000
> > frame-relay be 30000
> >
> >
> > router eigrp 42
> > network 10.0.0.0
> >
> >
>
This archive was generated by hypermail 2.1.4 : Wed Jun 02 2004 - 11:12:14 GMT-3