-
March 3rd, 2006, 02:36 AM
#1
Ping Response from Cisco router
I'm configuting a PtP T1 connection with two Cisco 1841 modular routers.
Been having a lot of CRC erros, Telco says its not their problem, but I have cisco, and a buddy of mine that works for another ISP saying that my equipment is fine and its a hardware problem with the T1.
Phone company doesn't even know how to work the test equipment. THey get errors when they do a test a certain way, but don't know if its valid or not cause they've never used the equipment before.
Anyway, I can ping and what not across the T1, just I lose a lot of packets, and get a lot of CRC errors as stated above..The other day I got Alarms on both sides of the T1 and couldn't do anything. Came in today to attempt to troubleshoot it, and the errors gone on one side, but still on the other. I'm about to go the other side of the T1 and see what I can do, however I have one question.
When I do a ping from the router with no alarms to the other router I get the following.
grouter#ping 10.20.1.2
Sending 5, 100-byte ICMP echos to 10.20.1.2, timeout is 2 seconds:
.U.U.
Success rate 0 percent.
What does the u mean? I've never seen that before...tried some google searches but didn't come up with much.
Thanks in advance
-
March 3rd, 2006, 03:30 AM
#2
U stands for a destination unreachable pdu was received. Take a look here for more answers http://www.cisco.com/warp/public/63/...raceroute.html
Early symptoms, from my experience, are that this problem is actually in the network between your devices. Meaning... blame the telco company.
"Experience is the hardest teacher, it gives the test first and the lesson after." Anonymous
-
March 3rd, 2006, 03:46 AM
#3
Ahhh.... You've reached the point of no return...
The telco doesn't know how to troubleshoot it so they will pass it back to you as your problem and you don't know what to tell them because you don't know what they don't know... been here...
First... Get on the line with their tech, (not the clerk you report the issue to), and have him describe the circuit to you. Draw it and annotate the drawing with the same names/designations he uses... then you can talk his language... The have him indicate which of the pieces of equipment he has described to you are available test points - this becomes important later when you realize that he doesn't know how to properly troubleshoot. Then have him confirm error free connectivity from the furthest test point to it's opposite end - the smartjack... stress the "error free... Have him run all zero's and then run all ones if his test suite can do it because these are the most stressful on the equipment. I'm blocking on the name of the standard test they do right now but it often sucks... It'll almost certainly be the first one he tries and it is a "battery" of tests... sort of... It really doesn't _test_ the line and the pieces of equipment. Make sure that he is thorough in his troubleshooting technique. They will often go through a pre-rehearsed set of actions with no thought to the symptoms themselves...
That should start you off... Yell if you need more help... In fact, make notes of everything he says and does and post back if it is unresolvbed and I'll see if we can't find the issue from here... Unfortunately, I learned what I know about this through several weeks of different issues... It's very frustrating because they always want to put it back on you.
Don\'t SYN us.... We\'ll SYN you.....
\"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides
-
March 3rd, 2006, 03:47 AM
#4
Junior Member
have you ran any debug commands?
are you using static routes?
try debug ip packet and see what you get
-
March 3rd, 2006, 08:17 AM
#5
Heres the way its setup at the moment.
Router --------------------- Router
^T1 line
I have static routes setup between the routers for my different networks at each end. I am able to ping from both routers to each other on both the T1 interfaces and LAN interfaces.
I do a ping from each end while logged into the router pinging to the other router. I ping 1000 times, and get about 93% success rate.
when I do a show interface serial0/0/0 I see about 90-120 input errors and the exact same number of CRC erros.
However, I only get CRC erros on one side of the T1, not on the other.
I've swapped out CSU/DSU cards in the router, changed clock settings, but it doesn't work
The test equipment the telco used was T-bird equipment. They run 0's 1's and a mix of it...if they set it to Terminate they got all kinds of errors, but they said they're not sure if thats right due to the fac that T-bird isn't meant to terminate.
So I talked with the Supervisor over the Technicians, and they manage to bring in some Frame Relay equipment so they can actually terminate the link.(this is the stuff they don't know anything about). Running certain tests they get abotu 20 CRC errors after 15 minutes. Running another kind of test they get about 25errors a sec on the T1.
But once again they're not really sure if its valid caue they've never used this equipment.
They told me straight up they don't really know what else to do. I showed them my errors on the Routers.
I'm frustrated beyond all belief.
They're talking to Techs at the NOC now trying to see if they know anything about this.
Just in case your wondering what I want to do with this T1, this is it:
We can't get DSL at one of our offices, so we have DSL where we can get it then the PTP T1 from the DSL to the Office.....my plan is to route the Office internet over the T1 to the DSL.
I've talked to cisco and they say its a everyday solution for a lot of companys. The telco thinks its crazy idea and that it would never work.
I would like to add that it does work, I can ping from the officer, over the T1 and out to any websites, its just the connection doesn't last long, pings are good about 60ms, but if I try to open any connections with websites they just timeout....Downloading files from file servers download at <2.2KB/s before they time out.
But I dont' know, I just think they don't know what eht F**$ they're doing and maybe trying to blame it on that? But I told them "look, I can't even get a clean ping across your line to the other side."
So they're still looking into it, but I'm about to go explode I think.
I guess this is more of a rant than anything. I've tried everything I know, and cisco says its telco problem, as we did numerous tests. I can show you router configs if you want.
-
March 3rd, 2006, 10:05 AM
#6
Originally posted here by patrande1
try debug ip packet and see what you get
Carefull with this one... I've managed to flood myself off routers this way.. If there's lot's of traffic you'll get sh*tloads of data.. enough to kill your remote connection...
Cheyenne: Not really a solution but I'd be looking for a different telco right about now.. One that does have enough technical knowledge..
Oliver's Law:
Experience is something you don't get until just after you need it.
-
March 3rd, 2006, 11:40 AM
#7
Ok... Number One... Your solution is perfect... I run all my offices over PTP T1's and route them out to the internet via one of two other T1's. So tell them to hush... They are throwing things like that in to muddy the waters.
The T'Birds are the best test box they have... The newer ones suck because they can only run preset tests... T'birds can run anything they like, (user patterns)... The issue is most likely with a piece of equipment, (repeater or whatever), on the line itself. The trouble is that they don't know what they are doing from what you say... You need to keep on them... Every time they try to close the ticket don't let them... You've changed all your stuff on the routers etc so you know it's not you. Plus, they are testing smartjack to smartjack I hope, looped too... Thus, _none_ of your equipment is involved yet they still see errors... It's their problem... The only trouble is _you_ have to make them fix it. Have them loop up each piece of equipment one at a time and run the tests then go to the other end and do the same. This will tell them the segment of the circuit that is causing the errors and they can have it investigated.
One final thing... When they do fix it they will run a final test... Then the silly bastards will leave a piece of equipment looped... Your Cisco facing the loop with tell you the circuit is looped... I have managed to down the loop using the Cisco itself once but the command to do so eludes me right now - it's under the int serX/X IIRC and it's a remote loopback command. It works sometimes but not all the time but it may save you a few hours waiting for them to fix it themselves.
Good luck... I know how frustrating this can be - It took me 7 weeks... Yes seven... to get one circuit right once because they didn't have T'birds and they didn't know what they were doing. I used the cisco to send a certain pattern and showed them the issue... You'll never guess what one tech said.....
"Maybe that a pattern the circuit isn't supposed to pass"
I blew up... "It's Fsking ONES and ZEROS for christs sake once you get past two of them then the minimum pattern is set"... I threw him out and asked for another tech...
Don\'t SYN us.... We\'ll SYN you.....
\"A nation that draws too broad a difference between its scholars and its warriors will have its thinking done by cowards, and its fighting done by fools.\" - Thucydides
-
March 3rd, 2006, 04:46 PM
#8
Just wanted to mention one thing (TS is right on), just type ping at the prompt and you'll get alot more options, one you should use is to change the size of the packet. Set it >> than the MTU so that it forces fragmentation. Doing this is usually a pretty good way to 'stress' the circuit and point out any lingering issues and give you a clear indication if the circuit really is running clean... (this would explain why your pings might look ok but HTTP bombs since the responses over HTTP are much larger than the typical 56 byte ping packet )...
There is only one constant, one universal, it is the only real truth: causality. Action. Reaction. Cause and effect...There is no escape from it, we are forever slaves to it. Our only hope, our only peace is to understand it, to understand the 'why'. 'Why' is what separates us from them, you from me. 'Why' is the only real social power, without it you are powerless.
(Merovingian - Matrix Reloaded)
-
March 3rd, 2006, 07:05 PM
#9
Junior Member
One thing stood out in a previous message...
The test equipment the telco used was T-bird equipment. They run 0's 1's and a mix of it...if they set it to Terminate they got all kinds of errors, but they said they're not sure if thats right due to the fac that T-bird isn't meant to terminate.
The Tberd can terminate a circuit - seen this many times - the reason it gets higher errors is possibly a timing setting mixup in the provider csu or in the segments along the way - the circuit should/must provide timing to the cpe (router) equipment
One other possibility to investigate are the T1 settings in the smart jacks at both ends - maybe one is set for T1 B8ZS coding an another AMI coding - search the web for the manufactorer and model - most used by US providers are adtran - they have a 9 pin dte connection for terminal access - ps - providers don'tlike you connecting to their equipment.
As far as stress testing a T1 - the tberd should have a setting (depending on model) for a 3 in 24 test (3 ones in 24 bits, ones are used by the circuit to pass and keep clock)
Basically - if you cant get a tberd to run clean on the circuit end to end or thru a loop the circuits bad.
-
March 4th, 2006, 05:14 AM
#10
Perhaps if you post your configuration as it will help. In addition if its a true point-to-point T1 and not a frame-relay T1 then the errors are coming from your gear. If its a P-to-P you can insert a loopback plug in the smartjack at one end and see the loop on the other CSU. Are you sure your subnet masks are correct on each end?
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
|