Frame Relay Broadcast Queue

The broadcast queue for frame relay has 3 limitations, the queue size, the bandwidth, and the packets per second. Once the bandwidth or packets per second threshold is reached, the packets are queued. If the queue hits its limit, the subsequent packets are dropped. It works as a rate-limiting for frame-relay broadcast packets; since the broadcast queue has priority over other traffic, it limits the impact it can have on the interface. The default sizes are 64 queue size, 256,000 bytes per second (2,048,000 bps), and 36 pps. In situations with many individual sub-interfaces, and routing flowing across each sub-interface, the most impacting limitation is packets per second, which when met, starts to fill the queue and cause subsequent drops.

EIGRP as an example uses multicast hellos for neighbor discovery and management. With timers on the interfaces at 5 seconds for hellos, and 3 times that for the hold-interval of 15 seconds, there is a garaunteed packet matching the rates detailed above every 5 seconds minimum. This will begin to limit the numbers of EIGRP neighbors across the frame-relay circuit upon which the sub-interfaces are configured.

This example shows a quick way to look at the frame-relay interfaces on the router and then show the numbers of PVCs. Assuming you have a neighbor on each PVC can give you a quick number to reference.
Router1#sh frame-re pvc | inc Statistics
PVC Statistics for interface Serial1/1:1 (Frame Relay DTE)
PVC Statistics for interface Serial1/1:2 (Frame Relay DTE)
PVC Statistics for interface Serial1/1:4 (Frame Relay DTE)
PVC Statistics for interface Serial1/1:5 (Frame Relay DTE)
PVC Statistics for interface Serial1/1:6 (Frame Relay DTE)

Router1#sh frame-re pvc | inc Local
Local 47 2 1 0
Local 64 1 1 0
Local 37 1 0 0
Local 213 10 9 0
Local 109 3 2 0

The below example shows the interface above the default 36 packets per second, filling up the broadcast queue, and subsequently dropping broadcasts.
Router1#sh int serial1/1:6
Serial1/1:6 is up, line protocol is up

Broadcast queue 52/64, broadcasts sent/dropped 2029709/37737, interface broadcasts 1908875

Anywhere we see drops or a queue filling up, we should look at implementing the broadcast-queue changes to alleviate lost hellos and potential adjacency changes.

interface Serial1/1:5
frame-relay broadcast-queue

The numbers used can vary. You want to increase the packets per second enough to compensate for increased hellos, but keep the bandwidth conservative enough to keep that usage low.

Here is the output of Router1 s1/1:5. About twice as many neighbors and a small fraction of the drops of s1/1:6
Router1#sh int s1/1:5
Serial1/1:5 is up, line protocol is up

Broadcast queue 1/100, broadcasts sent/dropped 4223817/33, interface broadcasts 3920140

An example of the log messages generated when a neighbor goes down and comes back up, due to this issue.
Jan 14 00:45:41.038 PST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 10.1.1.1 (Serial1/1:6.144) is down: holding time expired
Jan 14 00:45:49.238 PST: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 200: Neighbor 10.1.1.1 (Serial1/1:6.144) is up: new adjacency