Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Cisco > FRTS exceeding CIR

Thread Tools

FRTS exceeding CIR

Jim Kirby
Posts: n/a
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
Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
Using Prime Time To Find All The Paths Of A Seq. Cir., Not Only the Critical Ones VHDL 0 03-16-2006 09:46 PM
Query regarding frame relay CIR Sparky Cisco 5 05-13-2005 04:07 AM
Cisco 1721 Series Router - CIR Rate Paul Cisco 1 09-21-2004 10:55 AM
FRTS Jonathan Cisco 0 08-29-2004 05:30 PM
is there a difference between CIR and CIR+end to end clear channel connection? ike lozada Cisco 0 05-27-2004 02:34 AM