From: Sean C (Upp_and_Upp@xxxxxxxxxxx)
Date: Tue Mar 05 2002 - 12:57:42 GMT-3
Hi Dean,
While I praise the Solie text, after much frustration, I gave up on the
book's explanation of FRTS. I started a thread on this last month and the
general consensus was this:
1) The book's logic is wrong. I'm guessing it's typos.
2) CCO has a much better explanation of FRTS. I saw from earlier posts
that the best CCO link for FRTS was sent already sent out.
Have fun with FRTS - it's a beast.
Sean
----- Original Message -----
From: "Giblin Dean L." <dlgiblin@VASC.com>
To: "'Mason, Robert'" <romason@cisco.com>; <ccielab@groupstudy.com>
Sent: Tuesday, March 05, 2002 9:36 AM
Subject: Frame Relay Configuration - Traffic Shaping
> Robert,
>
> I thought the command below was designed to apply the FRTS to the
appropriate DLCI and not to the physical interface. The Solie text
indicated the parameters should be listed for the T1 interface. However the
lab indicated that this interface should throttle communication so as not to
overrun the 64K circuit on the other end. My impression was that by setting
these parameters it would configure the interface to transmit packets at
64K. Packets transmitted above the 32K rate would have the DE bit set. I
thought the BE was a bit that set during transmission to indicate congestion
along the path. Once configured, I streamed 1,000 1K packets to see if it
would increment the BE/DE counters. Nada. If the BE/DE bits must be sent
by the slow link I don't understand the point of this configuration. Would
the circuit still transmit data to the slow link at T1 rates? I would think
this could quickly overfill the buffers, result in excess packet loss, and
these packets despite t!
> heir settings would be dropped. I thought the point was to prevent this
from happening?? I feel like my head is in a vise!
>
> frame-relay interface-dlci 130
> class 64k
>
> Dean
>
> -----Original Message-----
> From: Mason, Robert [mailto:romason@cisco.com]
> Sent: Monday, March 04, 2002 10:55 PM
> To: Giblin Dean L.; ccielab@groupstudy.com
> Subject: RE: Frame Relay Configuration
>
> Dean,
> Like the others said the shaping is not always active, but I
> don't see where you applied the class to the interface. You
> created the map-class called 64k. You need to apply that to
> the interface with "frame-relay class 64k" command. At least
> that is how I understand it.
> HTH,
> Chuck
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com]On
> Behalf Of
> Giblin Dean L.
> Sent: Tuesday, March 05, 2002 11:00 AM
> To: ccielab@groupstudy.com
> Subject: RE: Frame Relay Configuration
>
>
> Thanks Nick. 'Preciate the feedback.
>
> I have forged ahead with traffic shaping and read a few
> additional articles from Cisco's web site. Still having a
> bit of a hard time with Bc, Be, CIR, and CIRMin. To me they
> appear redundant. None-the-less while trying to configure
> and test a configuration on a 2500 router traffic shaping
> does not activate. I have tried the configuration under a
> multipoint interface and a physical interface; neither
> worked. From what I can tell the following is a text book
> configuration based on Caslow's book. However, under the
> 'show frame-relay pvc 130" command it states that traffic
> shaping is not enabled. When streaming packets the counters
> for BE and DE never increment. I have also tried restarting
> the router. Below is the IOS version, fragment of the
> configuration and the output of the show command. Any
> thoughts?
>
> version 11.2(26a)
> hostname jpl
> !
> interface Serial0
> ip address 128.10.10.1 255.255.255.248
> encapsulation frame-relay
> frame-relay traffic-shaping
> frame-relay map ip 128.10.10.5 120 broadcast
> frame-relay map ip 128.10.10.6 130 broadcast
> frame-relay interface-dlci 130
> class 64k
> frame-relay lmi-type ansi
> !
> map-class frame-relay 64k
> frame-relay cir 64000
> frame-relay bc 8000
> frame-relay be 16000
> frame-relay mincir 32000
> !
> jpl#sh frame pvc 130
>
> PVC Statistics for interface Serial0 (Frame Relay DTE)
>
> DLCI = 130, DLCI USAGE = LOCAL, PVC STATUS = ACTIVE,
> INTERFACE = Serial0
>
> input pkts 33 output pkts 27 in bytes
> 3168
> out bytes 2304 dropped pkts 0 in FECN
> pkts 0
> in BECN pkts 0 out FECN pkts 0 out BECN
> pkts 0
> in DE pkts 0 out DE pkts 0
> out bcast pkts 0 out bcast bytes 0
> pvc create time 00:01:10, last time pvc status changed
> 00:01:10
> cir 64000 bc 8000 be 16000 limit 3000
> interval 125
> mincir 32000 byte increment 1000 BECN response yes
> pkts 27 bytes 2304 pkts delayed 0
> bytes delayed 0
> **shaping inactive <=
> *****************************************************
> Serial0 dlci 130 is first come first serve default
> queueing
>
> Output queue 0/40, 0 drop, 0 dequeued
> jpl#sh traffic
> Access Target Byte Sustain Excess Interval
> Increment Adapt
> I/F List Rate Limit bits/int bits/int (ms)
> (bytes) Active
> Se0 64000 3000 8000 16000 125
> 1000 BECN
> Se0 56000 7875 56000 56000 125
> 875 BECN
This archive was generated by hypermail 2.1.4 : Thu Jun 13 2002 - 10:56:53 GMT-3