Cisco 1600/1750 can ping serial, but not ethernet

I have a PTP T-1 between my office and a client.  I can ping the ethernet address on their side and they have internet traffic, but I can not ping directly from their router to the outside world.  I am also seeing several time out's when pinging their ethernet address.

The config on my side (1600 router):

interface Ethernet0
 description Local ethernet interface
 ip address 192.168.100.5 255.255.255.0
 no ip directed-broadcast
!
interface Serial1
 description point-to-point T
 ip address 192.168.255.1 255.255.255.252
 no ip directed-broadcast
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.100.1
ip route 199.224.122.104 255.255.255.248 192.168.255.2

On their side (Cisco 1750 router):

interface Serial0
 ip address 192.168.255.2 255.255.255.252
!
interface FastEthernet0
 ip address 199.224.122.105 255.255.255.248
 speed 100
!
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.255.1

All my traffic then passes to a 2600 series to the internet, in which
I have this statement:

ip route 199.224.122.104 255.255.255.248 192.168.100.5


When I telnet to their router I can not ping any address on my network.  I believe this might explain the delay they are seeing when trying to resolve any destination on their network.

Thank you!

scottparksAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

lrmooreCommented:
Post result of "show interface serial0" on the 1750
I suspect it may be a timing issue on the circuit. You might have to provide clocking for the T1 on one end.
You could also have a duplex mismatch on the LAN side of the 1750. You hard set the speed to 100 and that turns off the autonegotiation with the switch. If the switch that it is connected to is not managed, then suggest it be left on auto..
0
lrmooreCommented:
Also, add this to the 2600:
   ip route 192.168.255.0 255.255.255.0 192.168.100.5

That would take care of pinging from the router and to/from the serial ip..

0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
scottparksAuthor Commented:
Here is the result of :  show interface serial0:

Serial0 is up, line protocol is up
  Hardware is PQUICC with Fractional T1 CSU/DSU
  Internet address is 192.168.255.2/30
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 3
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/13/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 1000 bits/sec, 2 packets/sec
     791888 packets input, 587066085 bytes, 0 no buffer
     Received 12759 broadcasts, 0 runts, 0 giants, 0 throttles
     1780 input errors, 606 CRC, 1120 frame, 0 overrun, 0 ignored, 53 abort
     714762 packets output, 206578507 bytes, 0 underruns
     0 output errors, 0 collisions, 2 interface resets
     0 output buffer failures, 0 output buffers swapped out
     3 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

lrmooreCommented:
> 1780 input errors, 606 CRC, 1120 frame, 0 overrun, 0 ignored, 53 abort

Appears to be a lot of errors. These do indicated, as I suspected, a potential timeing issue.
on your end, assuming you are using the same WIC-T1 DSU:

interface serial 1
  service-module t1 clock source internal
  clock rate 2000000

Then clear the counters on both ends and see if the errors go away.

Clear counters:  rotuer#clear counters interface serial0


0
epylkoCommented:
Something needs to be doing NAT for 192.168.100.0/24. Who is doing that? Are you sure it's working correctly?

-Eric
0
scottparksAuthor Commented:
Cleared the counters after setting up the clock source on the serial interface and the errors have stopped, I will not know for sure until people in the office start using it again tomorrow, but here is the last 5 minute snap shot:

Serial1 is up, line protocol is up
  Hardware is QUICC Serial (with FT1 CSU/DSU WIC)
  Description: point-to-point Berkshire SGI
  Internet address is 192.168.255.1/30
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation HDLC, loopback not set, keepalive set (10 sec)
  Last input 00:00:03, output 00:00:01, output hang never
  Last clearing of "show interface" counters 00:05:59
  Input queue: 0/75/0 (size/max/drops); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/16/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     282 packets input, 30635 bytes, 0 no buffer
     Received 48 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     267 packets output, 15471 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
0
AutoSpongeCommented:
ip classless
ip route 0.0.0.0 0.0.0.0 192.168.100.1
ip route 199.224.122.104 255.255.255.248 192.168.255.2

Change this last statement to
ip route 199.224.122.104 255.255.255.248 Serial1

and see if performance increases.  I don't like using another router's address (even when connected) in a static route statement.
0
scottparksAuthor Commented:
Darn it, the errors are back......

Serial1 is up, line protocol is up
  Hardware is QUICC Serial (with FT1 CSU/DSU WIC)
  Description: point-to-point Berkshire SGI
  Internet address is 192.168.255.1/30
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec, rely 255/255, load 1/255
  Encapsulation HDLC, loopback not set, keepalive set (10 sec)
  Last input 00:00:00, output 00:00:07, output hang never
  Last clearing of "show interface" counters 02:47:04
  Input queue: 3/75/0 (size/max/drops); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/16/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
     2511 packets input, 225224 bytes, 0 no buffer
     Received 1327 broadcasts, 0 runts, 0 giants, 0 throttles
     238 input errors, 232 CRC, 6 frame, 0 overrun, 0 ignored, 0 abort
     2252 packets output, 199419 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
0
scottparksAuthor Commented:
This is the remote side (serial on the clients router):

Serial0 is up, line protocol is up
  Hardware is PQUICC with Fractional T1 CSU/DSU
  Internet address is 192.168.255.2/30
  MTU 1500 bytes, BW 1544 Kbit, DLY 20000 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation HDLC, loopback not set
  Keepalive set (10 sec)
  Last input 00:00:00, output 00:00:00, output hang never
  Last clearing of "show interface" counters 02:48:09
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: weighted fair
  Output queue: 0/1000/64/0 (size/max total/threshold/drops)
     Conversations  0/13/256 (active/max active/max total)
     Reserved Conversations 0/0 (allocated/max allocated)
  5 minute input rate 0 bits/sec, 1 packets/sec
  5 minute output rate 1000 bits/sec, 1 packets/sec
     2288 packets input, 202148 bytes, 0 no buffer
     Received 1186 broadcasts, 0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
     2545 packets output, 229861 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out
     0 carrier transitions
     DCD=up  DSR=up  DTR=up  RTS=up  CTS=up
0
AutoSpongeCommented:
First, call your provider to check PMs (performance monitors) in the direction of the site taking errors.  If you have an external CSU or a T1 controller card, check the error counts to see what type of errors you're seeing at the line level or frame level.  This can help troubleshoot them.

Next, have your provider perform a stress test (at least 2 hours of patterns) to your CSU and SJ from the furthest point they have test access.  This may help isolate where the errors are coming from.  If the test shows that they took errors to the CSU but none to the smartjack, have them test again and this time put a T1 loopback plug at the dmarc instead of your equipment.  If they test with no errors, the problem is in your wiring or the CSU itself--otherwise it will force a dispatch and further troubleshooting or the SJ replacement.
0
PennGwynCommented:
You've got two routers on your local LAN which go to different places.  Odds are good that your clients are pointing at one as their default gateway, and it's redirecting to the other as necessary.  Make sure to set "no ip redirects" on the LAN interfaces -- most clients will ignore redirects, but they'll chew up some bandwidth, and clients who *do* listen may get confused.

0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Routers

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.