From: Brian Dennis (bdennis@internetworkexpert.com)
Date: Tue Sep 23 2003 - 17:08:47 GMT-3
The Frame-Relay service provider's CIR and Cisco's CIR are not always
the same value. Just because you configure a CIR value on a router it
does not mean it is the same as the provider's CIR.
Cisco assumes that most providers allow for sending data at twice the
agreed upon CIR. This is why Cisco has min-CIR set to half of the CIR
value by default. In the event of congestion, the router will start to
throttle down to min-CIR assuming that adaptive shaping is enabled. The
min-CIR should be set to the provider's CIR when using adaptive shaping.
Any data above this min-CIR rate will have the DE bit set since min-CIR
is set to the provider's CIR.
If you do not want to send data above the agreed upon CIR, CIR should be
configured on the router to equal the provider's CIR. In this case you
will never exceed CIR and the DE should never be set by the provider.
You could configure CIR to equal the provider's CIR and have a 'Be'
value. This 'Be' value could theoretically cause you to exceed the
provider's CIR and in turn cause the DE bit to be set on the 'excess'
data. But this could be a little more complicated because you would
really need to know how your CIR value is measured by the provider. Most
providers measure CIR over a period of a full second but it is not
unheard of for a provider to measure CIR over 1/40th of a second.
Lastly Cisco should change the "frame-relay cir" command to "frame-relay
target-rate" because the "frame-relay cir" command is just that the
"target-rate" at which data should be sent and not necessarily the CIR.
Then change "frame-relay mincir" to "frame-relay cir". This would create
a lot less confusion.
Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
bdennis@internetworkexpert.com
Toll Free: 877-224-8987
Direct: 775-745-6404 (Outside the US and Canada)
Internetwork Expert, Inc.
http://www.InternetworkExpert.com
-----Original Message-----
From: Ram Shummoogum [mailto:rshummoo@ca.ibm.com]
Sent: Tuesday, September 23, 2003 12:17 PM
To: bdennis@internetworkexpert.com; ccielab@groupstudy.com
Subject: Re: RE: FRTS scenario
Brian:
Reading from the presentation, you mentioned that "Theoretically" the DE
bit is set to 1 above MinCIR.
Reading from Cisco, the DE bit is set above CIR.
Can you shed some light please.
Thanks
Ram
<navaid@rogers.com>@groupstudy.com on 09/19/2003 09:57:11 PM
Please respond to <navaid@rogers.com>
Sent by: nobody@groupstudy.com
To: "Brian Dennis" <bdennis@internetworkexpert.com>,
<Danny.Andaluz@triaton-na.com>
cc: <ccielab@groupstudy.com>
Subject: Re: RE: FRTS scenario
Brian,
FRTS presentation is excellent. Specially the examples are very helpful.
Navaid
>
> From: "Brian Dennis" <bdennis@internetworkexpert.com>
> Date: 2003/09/19 Fri PM 01:21:17 EDT
> To: <Danny.Andaluz@triaton-na.com>
> CC: <ccielab@groupstudy.com>
> Subject: RE: FRTS scenario
>
> Let me first say that if this was a real world FRTS scenario you would
have problems with serialization delay causing latency. Even if you
fragment the voice DLCI both DCLIs share the same physical interface so
the
data DLCI could cause latency when large packets are sent on it.
>
> Now back to the scenario.
>
> "Assume voice traffic is will be passing over dlci 101, which has 64k
link speed. Configure Frame Relay such that there is no latency and
packets are not dropped. DLCI 102 has 50% BW of port speed. Configure
CIR, Bc and Be accordingly by maintaining Tc's default value and
interface
queueing default mechanism. Port speed Between r1 and r2 is 256k."
>
> The values given in the solution do not look correct. The scenario
said
to use the default Tc but they changed the Tc value on the DLCI used for
voice. We know that voice should have the smallest Tc value possible
(10ms)
but it said use the default. The default Tc value is 1/8 of a second for
speeds below 640kbps.
>
> The scenario said to give the data DLCI 50% of the port's bandwidth
but a
DCLI with 64000 CIR and 8000 Be is not correct if you are trying to give
the DLCI 128kbps. The values will allow the DLCI to burst up to 128kbps
but
only if credits are built up. To truly give the DLCI 50% of the ports
bandwidth you would need to set the CIR to 128000 with no Be. Also not
trying to sound negative but setting min-CIR to equal CIR when adaptive
shaping is not turned on tells me whoever came up with the solution
doesn't
really understand FRTS.
>
> Now the queuing part of this scenario is good. When traffic shaping is
enabled on an interface with Frame-Relay encapsulation the default
queuing
method changes from fair-queue to FIFO.
>
> Rack4R3#sho int s1/0 | in strate
> Queueing strategy: weighted fair
> Rack4R3#conf t
> Enter configuration commands, one per line. End with CNTL/Z.
> Rack4R3(config)#int s1/0
> Rack4R3(config-if)#frame traffic-shaping
> Rack4R3(config-if)#^Z
> Rack4R3#sho int s1/0 | in strate
> Queueing strategy: fifo
> Rack4R3#
>
> Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> bdennis@internetworkexpert.com Toll Free: 877-224-8987
> Direct: 775-745-6404 (Outside the US and Canada)
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
Danny.Andaluz@triaton-na.com
> Sent: Friday, September 19, 2003 8:45 AM
> To: bdennis@internetworkexpert.com
> Cc: ccielab@groupstudy.com
> Subject: RE: FRTS scenario
>
> Brian,
>
> Those are my solutions. I just wanted to get an idea what might be
wrong
with it. Below are the configs for the actual solution, which I just
don't
understand. I would definitely be interested in the vSeminar.
>
> Thanks,
> Danny
>
>
> map-class frame-relay voice
> frame-relay cir 32000
> frame-relay bc 320
> frame-relay mincir 32000
> no frame-relay adaptive-shaping
> !
> map-class frame-relay data
> frame-relay cir 64000
> frame-relay bc 8000
> frame-relay be 8000
> no frame-relay adaptive-shaping
> frame-relay fair-queue
>
> -----Original Message-----
> From: Brian Dennis [mailto:bdennis@internetworkexpert.com]
> Sent: Friday, September 19, 2003 3:15 AM
> To: Andaluz, Danilo, Triaton/NA
> Cc: ccielab@groupstudy.com
> Subject: RE: FRTS scenario
>
>
> Danny,
> Are those your solutions to the scenario? The solutions are allowing
the
router to send data at 64kbps for DLCI 101 and 256kbps for DLCI 102. The
router will overwhelm the interface since the AR (aka port speed) is
256kbps. Also configuring min-CIR does not do anything if adaptive
shaping
is not enabled.
>
> Below is a link to a Frame-Relay traffic shaping presentation I
developed. Read it over and let me know if you have any questions. It
should help clarify FRTS.
>
> http://www.internetworkexpert.com/resources/01700368.htm
>
> If we can get a few people to sign up I'm willing to do a free
Frame-Relay traffic shaping vSeminar next week.
>
> Brian Dennis, CCIE #2210 (R&S/ISP-Dial/Security)
> bdennis@internetworkexpert.com
> Toll Free: 877-224-8987
> Direct: 775-745-6404 (Outside the US and Canada)
> Internetwork Expert, Inc.
> http://www.InternetworkExpert.com
>
> -----Original Message-----
> From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf
Of
Danny.Andaluz@triaton-na.com
> Sent: Thursday, September 18, 2003 9:03 PM
> To: ccielab@groupstudy.com
> Subject: FRTS scenario
>
> Hello Group,
>
> A scenario for FRTS on a lab that I'm doing states:
>
> "Assume voice traffic is will be passing over dlci 101, which has 64k
link speed. Configure Frame Relay such that there is no latency and
packets are not dropped. DLCI 102 has 50% BW of port speed. Configure
CIR, Bc and Be accordingly by maintaining Tc's default value and
interface
queueing default mechanism. Port speed Between r1 and r2 is 256k."
>
> R1
> |
> | |
> dlci 101 | | dlci 102
> | |
> |
> R2
>
> Here's what I have as far as configs. I get all sorts of different
answers for what this should be. Hopefully I can get this cleared up.
You
think you understand something, and then you get punched in the mouth.
>
> Thanks,
> Danny
>
> R1
>
> interface Serial0.8 point-to-point
> ip address 172.16.78.1 255.255.255.252
> frame-relay interface-dlci 101
> class Voice
> !
> interface Serial0.9 point-to-point
> ip address 172.16.78.5 255.255.255.252
> frame-relay interface-dlci 102
> class Data
>
> map-class frame-relay Voice
> frame-relay cir 64000
> frame-relay bc 640
> frame-relay be 0
> frame-relay mincir 64000
> no frame-relay adaptive-shaping
> frame-relay fair-queue
> frame-relay fragment 80
> !
> map-class frame-relay Data
> frame-relay cir 256000
> frame-relay bc 32000
> frame-relay be 0
> frame-relay mincir 128000
> no frame-relay adaptive-shaping
> frame-relay fair-queue
>
> R2
>
> interface Serial0.2 point-to-point
> ip address 172.16.78.2 255.255.255.252
> frame-relay interface-dlci 101
> class voice
> !
> interface Serial0.3 point-to-point
> ip address 172.16.78.6 255.255.255.252
> frame-relay interface-dlci 102
> class data
>
> map-class frame-relay voice
> frame-relay cir 64000
> frame-relay bc 640
> frame-relay be 0
> no frame-relay adaptive-shaping
> frame-relay fair-queue
> frame-relay fragment 80
> !
> map-class frame-relay data
> frame-relay cir 256000
> frame-relay bc 32000
> frame-relay be 0
> no frame-relay adaptive-shaping
> frame-relay fair-queue
>
> ***Get your CCIE and a FREE vacation: Shop.GroupStudy.com***
This archive was generated by hypermail 2.1.4 : Wed Oct 01 2003 - 07:24:34 GMT-3