in
IEOC CCIE Forums

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: Previous Next
  • 02-02-2012 9:26 AM

    • BLP
    • Top 150 Contributor
    • 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
  • 02-11-2012 1:13 AM In reply to

    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
    • Top 150 Contributor
    • 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 got
    Bc/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 over
    second 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
  • 03-05-2012 5:45 AM In reply to

    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
  • 12-31-2013 11:14 AM In reply to

    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)
IEOC CCIE Forums Internetwork Expert CCIE Training
About IEOC | Terms of Use | RSS | Privacy Policy
© 2010 Internetwork Expert, Inc. All Rights Reserved