8.1 FRTS


In the SG I’m
missing traffic shaping on R1 and R5. I think it is needed because we are
fragmenting on DLCI 401 and 405. So without it, packets larger than 640B are
dropped…

Martin

Comments

  • I always get confused with this kind of questions,  should we apply FRTS on the main interface for all DLCIs or apply to individual DLCI as specific as possible? 

    For example on R2, per SG, FRTS is applied to main interface, then all DLCIs will get CIR 512k, which does not sound right to me. or am i missing something?

    Rack1R2#sh traffic-shape
    Interface   Se0/0
           Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
    VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
    203           512000    640    5120      0         10        640       -  
    204           512000    640    5120      0         10        640       -  
    205           512000    640    5120      0         10        640       -  
    213           512000    640    5120      0         10        640       -  
    201           512000    640    5120      0         10        640       -  

    For my solution, I applied FRTS to DLCI 204 only.  Will this be acceptable?  Comments?

    Rack1R2#sh traffic-shape
    Interface   Se0/0
           Access Target    Byte   Sustain   Excess    Interval  Increment Adapt
    VC     List   Rate      Limit  bits/int  bits/int  (ms)      (bytes)   Active
    203           56000     875    7000      0         125       875       -  
    204           512000    640    5120      0         10        640       -  
    205           56000     875    7000      0         125       875       -  
    213           56000     875    7000      0         125       875       -  
    201           56000     875    7000      0         125       875       -  

  • This is a typical question - should I be as specific as possible or not? In general, being specific and adding the least amount of changes is the best strategy. However, in some cases being specific makes little sense: like if say those other PVCs are not being used, we dont care about their effective CIR. Apply principle of the minimum changes only to the elements that are actually being used in the lab.

    HTH

  • Thanks Petr!!!  It helps.  I will use this strategy to address the lab questions from now on.  Thanks again.  Good advise.

  • Friends,

    I feel very strange on this question. Let's recall from task list:

    circuit between R2 and R4 has been provisioned ad 512kbps

    interface speed is T1 (=1536Kbit/s)

    maximum time it takes to transmit a packet across the frame-relay network is 10ms.

    1) there is no "bandwidth 1536" issued at serial interface. Isn't it needed at all?

    2) if interface speed is 1536kbit/s it means, that interface can serialise 1 536 000 bits per second, so it can serialise 15 360 bits per 10ms.

    Going further, it means, that it can serialise 1920 bytes per 10ms

    MTU is 1500, so we do not need any fragmentation on this interface, because there is no packet that would take more than 10ms to put in the wire. I don't get why SG used DLCI's bandwidth to caluculate fragment size, as far as i remember packets are serialized always with physical speed of the interface.

    Correct, or do I miss someting?

     

    P.S. R1 and R5 configuration is missing anyway, doesn't it?

  • I second that.  The Physical rate 1536000.  So 15360 bits per 10ms interval / 8 = 1920 bytes per interval at clock rate.  

    Can someone explain why the fragment 640 bytes was added ?? 

     

     

  •  

    May be this doc may help us (I am stll confused)...this task need an interpretation from the proctor at the exam.

    If I'm right every single pvc should be set to bandwidth 512 and the serial 0/0 to 1536 because the question ask to share the rest of the bandwidth.In this case we need frame-relay fragment 640 .

     

     

    http://www.cisco.com/en/US/tech/tk652/tk698/technologies_tech_note09186a00800d6788.shtml

     

    Relevant FRTS Commands

    frame-relay fragment bytes —Use this command to enable fragmentation of Frame Relay frames for a Frame Relay map class. For more information refer to: Frame Relay Fragmentation for Voice.
    Be aware that every PVC that shares an interface with a voice PVC will
    need fragmentation depending on the lowest link speed between the two
    routers
    , even if the PVC is data only. Since the voice PVC may share the
    same physical interface as other PVCs, large datagrams going out on
    these other PVCs may cause delay for voice packets trying to go out the
    same physical interface on a voice PVC.

  • This is a tough question. I think interpreting it is the biggest difficulty. I am not giving the definite answer, I not even claiming to be right, and I still struggle to interpret it.  But there are two delays involved - shaping and serialization delay.

    Using shaping delay the fragmentation has been calculated as ( ( 512000 bps / 1000 ms ) *10 ms ) / 8 bits =  640 Bytes per 10ms interval.

  • Hi Tommey,

     This is correct!

    Good luck with your studies!

  • correction.....BW T1 = 1544kbs....

     

    Just had to through it out there!

     

  • Can anyone tell me why the BE is set to 0.....

     

    I've seen other solutions where this value is neglected..... why set it specificly to 0 ?

     

    If this is a dumb question , please bare with me....haven't spent that much time on QOS yet.....(I wonder why?).....

     

    Planning to spent more time on it soon!

     

     

  • Hi JJ,

       You need to set the Be to zero, whenever you want to send no more than the Bc on every interval, so you have nu burst capabilities. This requirement is implied by task statement: "ensure that neither of these devices send traffic beyond this rate on the circuit".

    Good luck with your studies!

  • thanks Cristian.... so obvious and yet I've missed it....

     

    Man, there should be rule that after 4 hours of studying one shouldtake 4 hours off!

    Yes, setting BE to 0 ensuring no burst happening...got it!

     

  • Hi JJ,

       The rule is not good as lab is 8 hours long :) You should prepare for 4 hours of hell, 30 minutes break, 4hours of hell :). Just joking there is no hell, only fun.

    Good luck with your studies!

  • Below is from the solution guide.  “Lowering Tc value doesn’t help when MTU of the packet exceeds the Bc value. If MTU is set for 1500 bytes, 512000 CIR and 5120 BC (10ms) configuration makes each TC for FRTS to 5120 bits so it would take three intervals (30 ms) in order to clock this packet onto the interface.  This delay would even high priority packet to wait in the interface.  Frame relay fragmentation helps to make out the queue into one single TC”.

     

     I’m trying to understand why it takes 30 ms to clock the  5120 bits packet? Pls help me to understand.

  • aselva,

    The Bc is set to 5120, which roughly equals 640 bytes. So if you want to serialize a 1500 bytes packet it will take you 3 Tcs in order to get the packet serialized into the wire.

     

    Packet lenght: 1500 bytes

    First Tc = 640 bytes

    Sec Tc = 640 bytes

    Third Tc = 220 bytes

     

    Each Tc allows you to send only up to the Bc on this case.

    HTH

  • If each Tc is 10 ms, then 3xTcs will be 30 ms total.

  • Agree, if it is 1500 bytes packet it would take 3 ms when Bc is set to 5120. But my eyes were reading and mind was interpreting "in order to clock this packet onto the interface" in SG as 640 bytes (5120 bits) packet not as 1500 bytes hence I raised the question. I guess SG trying to explain about 1500 bytes not the 640 bytes. Clear now, thanks.

  • Understood.

    Yes, the SG is referring to a 1500-byte packet. Glad it is clear.

    Happy studies.

  • In the SG I’m
    missing traffic shaping on R1 and R5. I think it is needed because we are
    fragmenting on DLCI 401 and 405. So without it, packets larger than 640B are
    dropped…

     

    I agree with you. With this inconsistent FRF configuration the FR network is broken.

    regards,

    Gabor

  • The wording on this task throws me off.  Bullet point three, states that the remaining VC on R4 should share the remaining bandwidth.  I read it that some how we would need to make the remaining two VC share the same pool of 1024Kb?

  •  

    The task asked to share the remaining bandwidth "equally" between the remaining VCs. Hence the 1024Kbps was divided between VCs 401 and 405 resulting in 512Kbps for each.

  • I don't think fragment is needed if you specify the tc

     


    map-class frame-relay DLCI402

     frame-relay tc 10

     frame-relay cir 512000

     frame-relay bc 5120

    !

  • Hi,

    T1 = 1.544 Mbps - .512 = 1032/2 = .516 M or 516kbps and that should be the rate of each of the other two DLCIs CIRs.

    I have a question though, if you set the ip mtu on the interface to 640B then it means all packets meet the 10ms requirement or doesn't this work with FRTS?

    Thanks.

Sign In or Register to comment.