in QoS INE Products (Entire Site)

# IEOC - INE's Online Community

Welcome to INE's Online Community - IEOC - a place for CCIE and CCENT candidates to connect, share, and learn. Our Online Community features CCIE forums and discussions for all tracks including Routing & Switching, Voice, Security, Service Provider, Wireless,, and Storage. Through these online communities you can discuss your questions with thousands of your peers, hundreds of CCIE's and INE's own team of world renowned CCIE instructors and authors, Brian Dennis - Quintuple CCIE #2210, Brian McGahan – Triple CCIE #8593, Petr Lapukhov - Quad CCIE #16379, and Mark Snow - Dual CCIE #14073.
Latest post 12-31-2013 11:14 AM by diya_1426. 4 replies.
 Page 1 of 1 (5 items) Sort Posts: Oldest to newest Newest to oldest Previous Next
• #### 02-02-2012 9:26 AM

• BLP
• Joined on 03-05-2009
• Expert
• Points 3,170

#### 10.19 Legacy GTS for Frame-Relay

 I don't know if agree with the answer key setting the "be" value to zero..  The solutions guide states the following In this particular task the service provider instructs the customer that the guaranted rate (mincir) is 96k and the desired average rate is CIR(128k).   Using the formula to get bc we do Cir*tc/1000 or 3840 and then for burst we do air-cir*tc/1000 whic gives us  960 so we have bc=3840 be= 960 we set mincir to adapt to becn and reducing sending rate to 96000 okay so if you run through the math under those circumstances be+be will never exceed cir over the second if we allow bursting or don't allow for bursting over the second we still never send more than the cir and traffic can still get marked with DE regardless so i'm confused as to how setting be to zero would affect the traffic drop in the cloud if the cloud is signaling DE on everything above 96 Anyone have anyone thoughts on this.
• Post Points: 50

#### Re: 10.19 Legacy GTS for Frame-Relay

 BLP - I can put might thoughts on it and maybe we can both come to the same conclusion. "and then for burst we do air-cir*tc/1000 whic gives us 960" - I don't know how you came up with this formula for Be. And you got Bc/4=960. If I would do Be it would be 1 or 1,5s. "okay so if you run through the math under those circumstances be+be will never exceed cir over the second" - When there is Be involved we technically can use more BW over second that CIR. "if we allow bursting or don't allow for bursting over the second we still never send more than the cir and traffic can still get marked with DE regardless" - I think minCIR (96k)=CIR and CIR(128k)=PIR in this case. "so i'm confused as to how setting be to zero would affect the traffic drop in the cloud if the cloud is signaling DE on everything above 96" - #1 I think that DE bit might not automatically result in a drop. It's more like lower preference, i.e. DSCP 11 vs 12. - #2. If traffic is over PIR (128k) that should result in FECN and BECN and in traffic to be limited to CIR (96k). The Be of zero in this case does not allow for bust in a traffic. I.E. if application sends 0 traffic in first 30ms, but 3841 bits in next 30s, that would be constituted as violation resulting in FECN/BECN. Value other than zero would be more application/burst friendly. Andrius
• Post Points: 20
• #### 02-11-2012 5:33 AM In reply to

• BLP
• Joined on 03-05-2009
• Expert
• Points 3,170

#### Re: 10.19 Legacy GTS for Frame-Relay

 Thanks for your response andrius, I don't know how you came up with this formula for Be. And you gotBc/4=960. If I would do Be it would be 1 or 1,5s.I assumed air = 128 in this case was used for air and 96 was used for cir with a 30ms interval  which 128-96*30 = 960 ( which was purely an assumption becuase there was no indication of what the access rate was, so i know could've been off) As a follow up, Brian Dennis basically told me "be" in this case was set to zero simply because the question never requested it.   - When there is Be involved we technically can use more BW oversecond that CIR. from my understanding / interpretation of shaping from the instructors was regardless of what you set your be to you still never send more than cir over the second  #1 I think that DE bit might not automatically result in a drop.It's more like lower preference, i.e. DSCP 11 vs 12. I agree with you on that.
• Post Points: 5

#### Re: 10.19 Legacy GTS for Frame-Relay

 BLP:I don't know if agree with the answer key setting the "be" value to zero.. In this task configures cir at customer router is actually the pir for the SP . Any traffic above cir in the form of Be sending from customer to SP will simply drop. So there is no point of setting Be above 0
• Post Points: 5

#### Re: 10.19 Legacy GTS for Frame-Relay

 The task asks that the traffic exceeds 96kps and lower than 128kps should be marked with DE, Does the SG satisfy that?I don't think so.. does the adptive shaping of 96000 mark traffic higher than that? no, it is by definition that the adatpive shaping lowers the rate to the minCIR and doesn't allow higher than that. I think the CIR should be 96000 and the Be 960
• Post Points: 5
Page 1 of 1 (5 items)