FRTS exceeding CIR

Discussion in 'Cisco' started by Jim Kirby, Oct 30, 2003.

  1. Jim Kirby

    Jim Kirby Guest

    Hi All. Our setup: Local hub router (7200) with T1 port and multiple
    PVCs; remote spoke router (2610) with 256k port and 256k CIR (yes, CIR
    = Port speed). Priority queueing is in force for VoIP bearer, CBWFQ
    for the rest; everything configured according to AVVID guidelines.

    Here's the problem: In the frame-relay map-class (copied below), cir
    and mincir are both set to 256000. However, when we drive this PVC to
    its limits (from hub to spoke), the 7200 actually sends more than
    256000kbps. In fact, our frame provider (MCI) says as much as 108%.
    (actually, they have claimed up to 116% but have only shown us
    evidence of 108%). Outgoing counters in the subint/dlci seems to
    confirm this. This is causing packets to get marked DE and often
    dropped somewhere in the cloud which of course impacts voice quality.

    Ok, I know because of the T1 it is physically possible to send more
    than 256k at once. However, I thought with FRTS in force, that
    otugoing packets would buffer and the rate would not exceed 256k.
    Isn't this the whole purpose of Traffic Shaping in the first place?

    TAC is claiming this is standard and well-understood behavior but that
    you only really notice it with real-time traffic. It took us 2 weeks
    and multiple engineers before they found an one who could explain
    these observations. No one we've spoken to since can confirm what he
    says. He is telling us that FRTS does not account for the frame-relay
    layer 2 header (4 byte FCS and flags) which explains what MCI saw in
    their cloud. He said the interface counters do not account for RTP
    compression which explains the why the interface counters exceeded
    256kbps. It's been about 4 weeks and he is yet to provide any
    documentation of this "standard" behavior.

    Frankly, I'm having a hard time buying any of it. I've been doing
    FRTS for 5 years and this is the first I've heard that. If it is
    true, it means you can never really get 256bps out of out of a 256bps
    circuit because of the frame header. But if the frame header's always
    there, why wouldn't Cisco account for it in their FRTS calulations?

    Or are we just too stoopid and looking right past the forest? Any
    pointers to documentation explaining this would be great.

    ps. Here's the f-r class-map I promised.

    map-class frame-relay FRTS-256K
    frame-relay cir 256000
    frame-relay bc 2560
    frame-relay be 0
    frame-relay mincir 256000
    service-policy output VoIP
    frame-relay fragment 320
    Jim Kirby, Oct 30, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.