11-02-2009 01:48 PM - edited 03-04-2019 06:35 AM
Hello
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,
11-02-2009 04:33 PM
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.
11-03-2009 08:04 AM
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?
11-06-2009 02:42 AM
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.
see
http://www.cisco.com/en/US/docs/ios/wan/command/reference/wan_f1.html#wp1012293
OSPF hellos are small packets so increasing the pps threshold may help.
Hope to help
Giuseppe
09-09-2010 07:29 AM
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
and
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
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.
09-11-2010 11:33 AM
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
Giuseppe
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: