We have a site that is having slow response issues. Our central router is a mc3810 because one of the remost sites is using voice over frame-relay. The strange thing about this problem is that the a show interface doesn't show any errors or drops. mrtg and the show interface (i've change the load interval to 30) show that the link is under CIR. I'm wondering if frame-relay traffic shaping could have any affect on this site? The site in question does not require voice over frame relay. The telco has pinged there passort switches and tell us that the response time there is fine 3ms. We get a great variation in the response time, anything from 70ms to 2000ms.. Any ideas?
I have faced this problem, in my case the issue was looping of the traffic on the link , which chokes up the bandwidth , is it one dlci or multiple dlci , if one check the bandwidth ultiztion on the serial interface, also traffic shaping sould work in ur case ,if the physical bandwidth of the leased line is 64 kbps, try with cir of 48k, burst of 8 kbps.check with these options.
i've tried various frame-relay class settings, ie setting the different bc, be, cir to see what difference it makes and i've noticed that it doesn't make much difference! i've put the settings back to the telco settings and response times are still very bad. Turning off traffic shaping on the dlci without voice over frame makes it worse. This problem is across multiple dlci's. How did u find out that the traffic was being looped?
You can check the line reliability by looking on the frame-relay-interface
'reliability 255/255'. This means 'execellent'-reliability, could not be better.
When you see f.i. reliability 200/255 or 128/255 the reliability is getting wors.
This all has to do with the quality of your connection. In most cases your provider is credit.
You can also look at the CRC's on that interface, many CRC's means bad line.
An other cause can be bad cables connected to the router.
In all of the mentioned examples the router is constantly trying to correct errors, this takes time and therefor the performance goes down.
You can also check the CPU-perfomance of your router with the 'show proc cpu'. A high CPU-performance (should not be more than 75%) takes also the overhaul performance down.
Edwin van Wijk
Yes, it sounds like a hard problem.
How big size packet did you ping?
Have you ever excute traceroute for destination?
But we will find the way to solve this problem. I had managed frame-relay network for years. But there was not the problem couldn't solved. Can you provide your network diagram to me at firstname.lastname@example.org. If I can get the diagram, I will discuss with our members with it.
The interface i'm pinging is the Ethernet interface, unforutately i can't ping the serial interface because of ip unnumbered being configured.
The show interface serial 0 show's 255/255 reliability. We use mrtg to monitor the links and i see that it is constantly pumping out 52k to a frame relay access speed of 128k and a cir of 96k. I've checked with the telco and the link is running under cir but when i do the ping response times are still terrible. What i've done is also reload the router incase there is a memory problem. A sho mem shows about 80% free memory and a sho proc shows that the cpu is running at around 52%. Because of ip unnumbered i've put an access list on the subinterface to only permit traffic to the remote subnet incase the router is sending traffic that is not destined for that location out the interface.. All this and still no good.. I've notice that when i do a show frame relay pvc that i get dropped packets. The telco assures me that they are not dropping any packets. Could this be a hardware fault? or a fault with eigrp or routing?
If you have your ethernet interface on the router connected to a switch you could possible have a duplex or speed mismatch problem. If the switch port is set to auto, manually set the ethernet interface on the router to full or half duplex and to 10 or 100.
If your line speed on the frame is fine, you may see dropped packets if you have never cleared your interface counters. Clear the counters and then investigate for dropped packets.
Have you checked out your telco circuits?
Give this a try, it'll prove something: check router i/f's for crc's at both ends.
Ping using packet size of at least 2000 bytes, first using all zero's 0x0000,
next using all 1's (0xffff). If any drops, it's often likely a "bit pattern sensitive" circuit. Take it to the telco, and don't get off the phone till they fix it.
Thanks everyone for all your help.
I found that it was a rouge server causing the problem! Which unfortunately still worries me as to why it caused this issue. I initially thought that the interface was sending traffic destined for other subnets out to the site so i applied an access-list to this interface to only permit the correct networks through. Doing a few ip accounting lists i noticed a server was always appearing on the list even after hours. The interface stats afterhours (assuming no one works afterhours) showed the the util was 28k of a 96k cir and 128k access, this however still was causing the slow response. Since i've had the server switched off and the network is back to normal.. Very strange.