Ping Response from Cisco router
Page 1 of 3 123 LastLast
Results 1 to 10 of 22

Thread: Ping Response from Cisco router

  1. #1
    Senior Member
    Join Date
    Feb 2003
    Location
    Memphis, TN
    Posts
    3,747

    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
    =

  2. #2
    Member
    Join Date
    May 2005
    Posts
    92
    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

  3. #3
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    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

  4. #4
    Junior Member
    Join Date
    Feb 2006
    Posts
    12
    have you ran any debug commands?
    are you using static routes?

    try debug ip packet and see what you get

  5. #5
    Senior Member
    Join Date
    Feb 2003
    Location
    Memphis, TN
    Posts
    3,747
    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.
    =

  6. #6
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    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.

  7. #7
    AO Ancient: Team Leader
    Join Date
    Oct 2002
    Posts
    5,197
    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

  8. #8
    Jaded Network Admin nebulus200's Avatar
    Join Date
    Jun 2002
    Posts
    1,356
    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)

  9. #9
    Junior Member
    Join Date
    Oct 2001
    Posts
    20
    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.

  10. #10
    Senior Member
    Join Date
    Mar 2004
    Posts
    119
    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
  •