×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

Frame relay

Unanswered Question
Jan 17th, 2001
User Badges:

I am new to frame relay, how would i check to see what is causing packets to drop occassionally.

Also i am running an accounting program that goes over the frame relay connection and it is rather slow. Would traffic shaping help solve that problem?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
dagreer Thu, 01/18/2001 - 13:47
User Badges:

The first thing you need to do is login to all routers under enable mode and do a "SHOW INT S" followed by the appropriate sub-interfaces.

You should also do a "SHOW FRAME PVC". Post those to the list, I would bet that your frame-relay is overloaded.


Also, it may not hurt to do a SHOW FRAME LMI command and make sure that your Enq Sent and Msgs Recvd are in close agreement otherwise you have big problems.


Trafficshaping will help if your frame is marginal but if you are really overloaded you need to look at your configs and at possibly increasing your PVC's.

You may want to check on your CIR (Committed Information Rate)from your frame provider. Some providers like to sell 0 CIR insisting their network is over engineered. You should have some fraction of your line speed as your CIR. Anything above your CIR is tagged as eligble for dropping should their frame network become congested. Your link may look fine but theirs upstream may not and if you have a 0 CIR every one of your packets could be dropped. Issue show frame-relay pvc and you will see if you are getting FECN or BECN packets which are congestion controll packets which may give you some insight. Hope that helps.

Tom

hie

If you dropping packects you need to check on you serial interface of the router by doing a SH INT S0 for instance.Check for load which is normally given as :load 255/255 if the link is fully or overloaded hence anything between 0/255 to 220/255 is acceptable.still on that check for input errors by the same command several times,see if they are building by repeating the command and lastly check for carrier transitions ,this is the number of times you loosing carrier between your local router and remote.


You can also check for congestion by veryfing the BENC and FENC :do a SH FRAME-RELAY PVC


I am sure this will be a starting point for you we had similar problems when we were trying to set up our frame-relay network here as well.


Chris,Harare.Zimbabwe.


shaundr Tue, 02/20/2001 - 20:19
User Badges:

Here are a couple of suggestions.

Need to determine what kind of traffic your accounting program is producing. For example SNA traffic is very time sensitive.

I'm assuming this is a point to point circuit.

First, ping across the WAN to your server or some other machine during a low traffic time period.

Use -t with ping and watch the reply...they will be bursty, but that is the nature of Frame. This will help verify 1)how long it takes for a packet to transverse the Frame cloud and 2)if any packets are being dropped.

Be aware that carrier's do over sell their ports..so if your getting crazy ping times like 110ms, 220ms, 300ms the carrier has issues.

It would be a good idea to open a maintance ticket with your carrier...they won't charge for it and they can tell you things like 1)How many times you hit your CIR, 2)How many BECN, FECN were issued 3)Did LMI drop...4)How many packets were dropped, ect.

You could also increase the TTL on your packets, but this could have adverse effects.

This kind of problem usually goes back to who provisioned your PVC. If you are getting time outs from your application then it is taking too long for your traffic to traverse your PVC and your carrier should be able to help with this. If you are constantly hitting your CIR then there is too much traffic (Need a bigger pipe!!!)

Hope this is of help to you...Good Luck!!


Actions

This Discussion