Slowness in Frame Relay link

[Chaker BCHIR]

I have a frame relay link between two locals.

The problem is that the bandwidth of the traffic is very low when it traverse the frame relay link.

Any idea or trick to resolve this problem ??

[Edison Ortiz]

There isn't any trick to make a connection faster other than buying more bandwidth.

You can configured QoS on the circuit to guarantee a % of the bandwidth for critical traffic BUT if the amount of traffic is greater than the %, you will have the same issue.

What's the committed information rate for this link?

Can you post the configuration along with the 'show interface' output?

Regards,

Edison

[Chaker BCHIR]

#sh interfaces serial 0/0/0         

Serial0/0/0 is up, line protocol is up

  Hardware is GT96K Serial

  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

     reliability 255/255, txload 3/255, rxload 3/255

  Encapsulation FRAME-RELAY IETF, loopback not set

  Keepalive set (10 sec)

  LMI enq sent  1414663, LMI stat recvd 1414642, LMI upd recvd 0, DTE LMI up

  LMI enq recvd 0, LMI stat sent  0, LMI upd sent  0

  LMI DLCI 0  LMI type is ANSI Annex D  frame relay DTE

  Broadcast queue 0/64, broadcasts sent/dropped 2374925/0, interface broadcasts 22

  Last input 00:00:05, output 00:00:07, output hang never

  Last clearing of "show interface" counters 23w2d

  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0

  Queueing strategy: weighted fair

  Output queue: 0/1000/64/0 (size/max total/threshold/drops)

     Conversations  0/6/256 (active/max active/max total)

     Reserved Conversations 0/0 (allocated/max allocated)

     Available Bandwidth 1158 kilobits/sec

  5 minute input rate 21000 bits/sec, 20 packets/sec

  5 minute output rate 20000 bits/sec, 19 packets/sec

     53286569 packets input, 3225125119 bytes, 0 no buffer

     Received 0 broadcasts, 0 runts, 2 giants, 0 throttles

     3772 input errors, 3762 CRC, 3145 frame, 2762 overrun, 0 ignored, 2452 abort

     49605217 packets output, 3763762049 bytes, 0 underruns

     0 output errors, 0 collisions, 28 interface resets

     0 output buffer failures, 0 output buffers swapped out

     0 carrier transitions

     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up

#sh interfaces serial 0/0/0.1

Serial0/0/0.1 is down, line protocol is down

  Hardware is GT96K Serial

  Internet address is 192.168.1.30/24

  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,

     reliability 255/255, txload 1/255, rxload 1/255

  Encapsulation FRAME-RELAY IETF

  Last clearing of "show interface" counters never

[vmiller]

Just to establish a baseline, clear your counters at a given time (say 8:00 am local).

do another show int in 4 hours. This will give a very crude rendition of the amount of traffic flowing, and we can see

if the input,CRC errors are transient or on going.

[Joseph W. Doherty]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

There could be lots of causes, and unfortunately, you've provided no specific details.

Some things to be aware of:

Edison asks about CIR.  This is a contracted bandwidth, often less than circuit bandwidth.  If you exceed it, FR vendor might drops your packets.  If they do, only solution is to either "buy" larger CIR or find another vendor that doesn't seem to drop at the same rate.  (If FR vendor drops traffic within your CIR, you should have recourse.)

FR might have end points with different physical bandwidths.  If you do, faster side can congest upon FR cloud egress and FR vendor does ???  I.e., shape to lower bandwidth so you know it's happening and you can control what happens.

With FR, you can have mulitple logical circuits share the same physical port.  Often easy to congest FR cloud egress without realizing it.

[paolo bevilacqua]

'Very slow' is not a technical definition. Ot, it was faster 'before'?