Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Problem with frame Frame Relay

Status
Not open for further replies.

oshill

MIS
Dec 4, 2003
9
US
I am fairly new with Frame Relay and Cisco so please go easy if I do not say something right. Our company has 4 branches with the main system (Karmak) at branch 1 and a frame relay from the other locations to use. The other locations uses Telnet thru Kea to access the Karmak sever. The other locations also use the frame relay to access our T-1 for HTTP and the E-mail. Here is what bandwidth the other branches have.

Branch 1 Main = 768 and CIR of 768 Cisco 2620 ver 12.2 with Adtran IQ-710

Branch 2 = 256 and CIR of 256 Cisco 1720 ver 12.1 with Adtran IQ-710

Branch 3 = 56 and CIR of 56 Cisco 1720 ver. 12.1 with Adtran IQ-710

Branch 4 = 256 and CIR of 256 Cisco 1721 ver. 12.2 with Adtran IQ-710


The problem we are having is that branch 4 all of a sudden is having a real bad delay time talking to the Karmak server. I ping from the 1721 at Branch 4 to the Karmak server and get the following:

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.16.21.3, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 80/84/88 ms
Washington#


When I ping from branch 3 to the Karmak server I get higher numbers and they do not have near the amount of delay that branch 4 does and they only have a 56k line.

Also I use Real VNC to control the other PCs to help with setups and problems and I cannot do this to any PC at branch 4. I can do this to all the other locations.

Where should I start looking? Our frame relay is with SBC, and they say that there is nothing wrong to branch 4. If anyone can help and need more info I can post it.

Thank you for reading.
 
I would begin by looking at the MTU at branch 4. It should be the same as the other end of the link, probably 1500. I would also look for dropped packets. Clear your counters and then watch them. Another thing to try would be to replace the cabling between your demark and CSU and CSU and router. If you are having physical problems you should see it in your counters.

-Don
 
does branch 4 have lots of traffic coming out of it. copy and paste the show interface serial ? replacing ? with the serial interface that connects to your frame relay.

you are looking for traffic above the cir rate like 256K plus. if its higher you will get more delay.

also do a

show frame-relay pvc command and look at the corresponding dlci info for the circuit you are having issues with.

if you are seeing alot of fecn,becn,or de packets then you could just be experiencing traffic problems. check to make sure that you don't have a lot of traffic bogging down the line.


errors on frame lines can be seen from the show interface serial command and looking for

carrier transitions ( how many times you have lost carrier signal)

CRC errors packets arriving with errors <1% per million bytes is normal anything higher is a problem.

 
i think sbc is right.
your ping times are within the sla's. what kind of ping times are you looking for? one thing that sbc can do for you is to "optimize the path" often this doesnt work, as all they do in the alcatel swiches is hit the "optimize" button which makes the circuit take an alternate route (usually something less desirable)...
depending on the location of these circuits (the sites that you have)the path that sbc is giving you might be going through their Long Distance trunks (has to take more hops, thus more delay)...

but remember, SBC (or any other provider) is only responsible for the PIPE (wan link) not what happens after that...try pinging from WAN TO WAN (SERIAL TO SERIAL) and see what kind of ping times you get.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top