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.
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.
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!!!)
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...