Subject: RE: Frame relay fragement and llq The answer depends on what delay you will accept on that interface before a voice packet can be transmitted. The higher the speed on the interface (which is what I always use to calculate how fast the packet is clocked on to the wire, rather than the DLCI speed) and the smaller the fragment size, the lower the delay any PQ packet has to wait before it can be transmitted if a non-PQ fragment has been sent to the interface Tx-ring ahead of it. The fragment value is in bytes, so I do it by dividing the access rate by 8, so if there is a 256K access rate for example, this equates to 32000 bytes per second. If I only want to allow 10 milliseconds delay for queueing in my design, I'd set fragment to 320. There are no right answers, just how much of your delay budget you can llocate to queueing delays at that point in the network. ---- Subject: RE: frame fragmentation and the many methods... Thanks for the reply Chris. So what I"m understanding is that the best way to set this up is to make sure that my fragmentation is set on all affected frame interfaces in the cloud. And, that fragmentation value should be a reflection of the local access rate. So if a spoke has access rate of 256k, and fragmentation is 10milliseconds, we set fragmentation to 320 bytes. Fair enough. My concern is when it comes to the hub site that aggregates the spokes. After reading your post, it makes sense that the fragmentation values are locally significant depending upon the access rate regardless of hub or spoke or what specific DLCI we're using. The only "hole" this leaves in my thoughts is the option to configure the fragmentation on a per-DLCI basis within a map-class frame-relay command. I'm trying to think of the value to changing the fragmentation values on a per-DLCI basis when multiple DLCI's could exist on the interface. Doing so could actually impair your traffic flow by blowing out your PQ delay budget on one DLCI in favor of another... why I couldn't say. ---- Hi Simon, I think you have it right and make a good point about the bandwidth statement. For anyone that does not want to memorize this sort of stuff for the exam, I'd strongly recommend familiarity with the show policy-map interface command, it verifies what pecentage has been applied. Taking the config supplied and applying it to an interface with multiple DLCIs on it shows the policy applied to all DLCIs and the percentage calculated, an example is at the end of this response. Regards adaptive shaping, this is my understanding. Adaptive shaping using the older BECN awareness means that should the interface see BECNs, it will start to throttle the rate it transmits at down from CIR to mincir, but no lower. I believe the congestion awareness option does the same thing, but uses interface congestion rahter than BECNs as the trigger for shaping and thorttling back of output. The throttling algorithm for interface congestion awareness is given in the documentation as following: When the congestion level exceeds a configured value called queue depth, the sending rate of all PVCs is reduced to the minimum committed information rate (minCIR). As soon as interface congestion drops below the queue depth, the traffic-shaping mechanism changes the sending rate of the PVCs back to the committed information rate (CIR). So, if there is no congestion, there will be no shaping. However set statements are not conditional upon bandwidth or priority statements being active in order for them to mark. The class-map identifies traffic and the policy map applies the set commands, if there is no congestion, the bandwidth commands will not be active but the plain set commands will be, just as if no bandwidth command was configured. Chris Router2(config-if)#do sh policy-map int Serial1/0: DLCI 221 - Service-policy output: QOS Class-map: QOS-1 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 5 Queueing Strict Priority Output Queue: Conversation 24 Bandwidth 30 (%) Bandwidth 9 (kbps) Burst 225 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 QoS Set dscp ef Packets marked 0 Class-map: QOS-3 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 1 Queueing Output Queue: Conversation 25 Bandwidth 20 (%) Bandwidth 6 (kbps) Max Threshold 64 (packets) (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 QoS Set dscp af33 Packets marked 0 fr-de Packets marked 0 Class-map: QOS-2 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 3 Queueing Output Queue: Conversation 26 Bandwidth 30 (%) <------------------------------------------------------percent calculation Bandwidth 9 (kbps) Max Threshold 64 (packets) <------------- (pkts matched/bytes matched) 0/0 (depth/total drops/no-buffer drops) 0/0/0 QoS Set dscp af31 Packets marked 0 Class-map: class-default (match-any) 1 packets, 88 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: any Queueing Flow Based Fair Queueing Maximum Number of Hashed Queues 16 (total queued/total drops/no-buffer drops) 0/0/0 QoS Set dscp default Packets marked 1 Serial1/0: DLCI 244 - Service-policy output: QOS Class-map: QOS-1 (match-all) 0 packets, 0 bytes 5 minute offered rate 0 bps, drop rate 0 bps Match: ip precedence 5 Queueing Strict Priority Output Queue: Conversation 24 Bandwidth 30 (%) Bandwidth 9 (kbps) Burst 225 (Bytes) (pkts matched/bytes matched) 0/0 (total drops/bytes drops) 0/0 QoS Set dscp ef Packets marked 0 --- Subject: RE: MQC bandwidth Yes and no. The feature described in that link is fragmentation at the interface level without FRTS enabled. When FRTS is disabled all VCs share the same output queue, whether they're on the main or subinterface. Specifically it says: "This new feature simplifies the configuration of low-latency, low-jitter quality of service (QoS) by enabling the queueing policy and fragmentation configured on the main interface to apply to all permanent virtual circuits (PVCs) and subinterfaces under that interface." The reason why it applies to all VCs is because all VCs share the same output queue when FRTS is disabled, onto which the fragmentation is applied. "Before the introduction of this feature, queueing and fragmentation had to be configured on each individual PVC." This is true because previously fragmentation could only be applied through FRTS, which implies per VC queueing. "For interleaving to work, both fragmentation and the low-latency queueing policy must be configured with shaping disabled" This is also true because interface level fragmentation requires the usage of a single output queue for all VCs, which FRTS does not have. For fragmentation to be supported in conjunction with shaping the fragmentation parameters need to be defined inside a "frame-relay map-class" in which legacy or MQC based FRTS is applied. --- Subject: Re: MQC-Based FRTS Thomwin, No, do not configure the command "frame-relay traffic-shaping" when doing MQC-based shaping. When doing MQC-based shaping remember that the "shape average" command automatically sets Be equal to Bc, so set Be explictly to 0 if the task does not require an excess burst. Also remember that if you want to shape at the DLCI level, using a map-class frame-relay, then you must shape class class-default. HTH, Bob Sinclair CCIE #10427, CCSI 30427, CISSP www.netmasterclass.net ---- The "frame-relay tc" command is not used in FRTS from the client side. See http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_ guide09186a00800e955b.html for more detail. As for the calculations for this solution they are as follows: frame-relay cir 256000 This says to average 256000 bits per second. The question states to use the lowest interval, which is 10ms. If you are sending 256000 bits every second, this means that you're sending 2560 bits every 10ms: 256000 bits | 1 second | 10 ms Bc = -------------------------------- = 2560 bits 1 second | 1000 ms | If you can only send 2560 bits in a single interval this means that your largest packet fragment should be 2560 bits, or 320 bytes: 2560 bits | 1 byte Fragment = -------------------- = 320 bytes | 8 bits 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 24/7 Support: http://forum.internetworkexpert.com Live Chat: http://www.internetworkexpert.com/chat/ > -----Original Message----- > From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On Behalf Of > Roberto Fernandez > Sent: Wednesday, October 26, 2005 8:37 PM > To: Cisco certification > Subject: On Frame Relay fragmentation answer, IE lab 10 > > Friends, > > In Lab #10, 9.1 to 9.4 from IE, frame relay fragmentation is required; > after knowing the CIR (256K) and requiring the lowest Tc possible. > > The solution then uses > > map-class frame-relay DLCI_503 > frame-relay cir 256000 > frame-relay bc 2560 > frame-relay fragment 320 > > > I have the following questions, > > 1- Why specify Bc instead of Tc? (given the words "lowest shaping > interval") > 2- Why is fragment size 320 and not the Bc size? > --- You can set the DE bit on the CE side (assuming that is a Cisco router) by DE-list, a set command in MQC or as an exceed action in policing. The frame-relay switches within the provide network are not Cisco routers and the configuration will be dependant upon what devices they are :) Not all frame relay providers use the DE bit for congestion management. Chris ---