Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

Frame Relay Broadcast queue


I'm trying to understand frame relay broadcast queue. Cisco's defaults for a serial interface are:

size: 64 packets

byte-rate: 256000 bytes per second

packet-rate: 36 packets per second

Now if I take the byte-rate / packet-rate I should get the average packet size. In this example

256 000 Bps / 36 pps = 7 111 Byte per packets.

Since the default MTU is set to 1500 why would you have such a default configuration for broadcast queues? Am I missing something?

Thank you,

Cisco Employee

Re: Frame Relay Broadcast queue

The only time I have seen this low value cause trouble is in a point-to-multipoint network where the customer is running OSPF or some other routing protocol that uses link local multicast for neighbor discovery. In this case, I usually tell customers to increase the values by a factor of 10.

Community Member

Re: Frame Relay Broadcast queue

Thank you for your response.

I guess what I wanted to verify is that my logic (and math) was correct and that the default values are not set correctly. These values should be calculated for 1500 packets not 7111 bytes. Would you agree?

Hall of Fame Super Silver

Re: Frame Relay Broadcast queue

Hello Tomasz,

I think here there is a combination of a specialized queue to hold multicast frames and a rate limiter expressed in two ways: up to 256 kbps and up to 36 frames per second.

This two-ways rate limiter controls how frames are placed into the broadcast queue waiting for tramsmission or how they are taken from it to send to VCs.

not being FR really multicast capable each frame has to be replicated over each PVC.

max size of single frame is still governed by interface MTU.

for me 256000 bps / 36 fps / 8 bit/bytes would give an average size of 889 bytes / frame

but I think we should see the rate limiter as a combination of a traffic volume rate and of a pps limit.

like up to 36 multicast frames per second can be sent out the FR interface over the multiple VCs.

this can imply a multiplication effect because each frame needs to be sent on each VC belonging to the same IP subnet/multipoint interface.


OSPF hellos are small packets so increasing the pps threshold may help.

Hope to help


Community Member

Re: Frame Relay Broadcast queue

Hi, Giuseppe

I am stay  reading of "frame-relay broadcast-queue" and find this topic.

You say

"for me 256000 bps / 36 fps / 8 bit/bytes would give an average size of 889 bytes / frame

but I think we should see the rate limiter as a combination of a traffic volume rate and of a pps limit."

But it is not 256000bps, is 256000 Bytes per second that is 2048000 bps.

I am tried to see the math logic's to this but I am so confuse.

the Cisco's Default bandwidth in serial interface is 1544kbits (T1) and not 2048kbps (E1), then why the Cisco technical Documentation take E1 as default as reference value?, it may not make sense "logic".

The brodcast-queue command is:

frame-relay broadcast-queue

The formula for calculate the byte rate is:

take a byte-rate less than both of the following

N/4 (times the minimum remote access /  bytes per second) - N number of DLCI


1/4 the local access rate / bytes per second

this calculate may make sense given by default IOS reserve the 25% of bandwith for control's traffic on all interface (as analogic).

then when a interface use "encapsulation frame relay" the "frame relay broadcast queue" another queue is create it; where the broadcast traffic of routing protocols pass for it and has priority while the traffic do not exceed    or parameters. (the  broadcast traffic of routing protocols do not flow any more over the normal queue).

About, assuming 250-byte packets is possible that Cisco take  RIP as reference routing protocol, the maximum routes per packet on RIP packet is 25 and each entry need 10 Bytes. (25 routes * 10 Bytes/entry = 250 Bytes).

but it analysis per parameter is not useful, the question about the command still stay active.

Who can I calculate or know the better parameters to used, when I use the command "frame-realy broadcast-queue" in another case as "Frame Relay traffic shaping" the IOS calculate other parameter (Be and Bc / with Tc=125ms) with only 1 o more explicit value. Or when I need to calculate the bandwidth for priority bandwith on LLQ for voice traffic are a formula based on codec and sample interval.

I hope you can help me.

Hall of Fame Super Silver

Re: Frame Relay Broadcast queue

Hello David,

you are right: I had misunderstood the command reference pages in my answer in this thread!

the rate is given in bytes/sec instead of bps as I had written.

About why the default settings is 256000 byte/sec and not another value is difficult to say.

The product bulletin that you have attached (published in 1995) suggests a possible explanation on pag. 6:

>>The I/O memory on the 2500 with standard RAM configuration of 2 Mbytes is 1 MByte. Hence, it is recommended that the broadcast

queue buffer be kept to less than 300 Kbyte so that buffering for user data is not unreasonably depleted. Hence, a limit of 15 DLCIs is

recommended for a 2500 with standard memory. This would be suitable for a 64 Kbit/s access link.

So the default settings may reflect this fact that is looking at memory requirements to hold packets before sending them rather then at 1/4 of access link.

Even if I agree 256000 bytes are 100% of an E1 link and the recommendation is to stay at 20% of access link speed as you cannot use more then the access link speed for all traffic.

I would say this byte is more a storage specification (memory) then a rate value.

>> from appendix 1

Broadcast Replication: When sending, the router must replicate the packet on each DLCI and this causes congestion on the access link.

The Broadcast Queue reduces this problem. In general, the network should designed to keep the routing update load to below 20% of the

access lines speed. It is also important that memory requirements for the Broadcast Queue be considered. A good technique to reduce

this restriction is the use of default route or extending the update timers.

Broadcast Receipt: When receiving, the router must receive updates from the network. The issue here is that the upstream switch can

be overloaded and drop packets. When routing updates are dropped, routing instability occurs. Again, the receiving routing update load

should be kept to less than 20% of the access link speed and preferably lower. Where very high speed links are used, a limit of 128 Kbit/s

worth of routing updates is recommended.

General note:

this is a very specific feature that hasn't wide application. Again I may be wrong, but let's consider the following:

First, you need to have multiple DLCIs terminated on a rather slow access link to hub

Second, you should be using an old routing protocol like RIP that at each update interval needs to send out all the table.

With modern routing protocols only small hello packets every N seconds need to be sent.

So, if you attempting to solve an issue on a FR network on the job, your time is spent well on this.

If you are in your own learning process towards CCIE lab, this might be a case where you just need to know the existence of the feature.

I think a very important aspect of FR is reported in last page of the bulletin in Appendix 1:

that is the max number of DLCIs given a type of LMI in use and the MTU of the access link.

This kind of information is valuable even if standards may change over time and these limitations may have been moved upwards.

Hope to help


CreatePlease to create content