Ping works but traceroute doesnt

[chocyman]

Hi folks

Just before I start, I have posted this in the TCP/IP section as well..just to try to get as much info as I can. Its really causing some grief for what seems like a so so simple problem.

Brief description

2 x 1720 routers connected via a frame.

Router A config :
F/E 0 = 192.0.0.1/24
Serial 0 = 192.168.200.2/30
F/E 0 connected to Cisco 2924 switch
Router A default gateway = 192.168.200.1
Router has RIP version 2 enabled with networks 192.0.0.0 and 192.168.200.0 being broadcast.

Router B config:-
F/E 0 = 192.168.1.1/24
Serial 0 = 192.168.200.1/30
F/E 0 connected to hub
Router default gateway = 192.168.200.2
Router has RIP version 2 enabled with networks 192.168.1.0 and 192.168.200.0 being broadcast.

Switch Config (located behind router A):-
Switch has IP address = 192.0.0.141
Switch default gateway = 192.0.0.1

Router A (via switch) workstation(s) config:-
default gateway = 192.0.0.141 (to the switch)

Router B workstation config:-
Default gateways set to 192.168.1.1 (have tried 192.168.200.1 as well)

OK (apologies for the lengthy detail)

From Router B I can ping router A and workstations beyond Router A
From Router B I can traceroute to workstations behind router A and the switch, which is good. To my thinking there is a route to and from Router B through Router A, through the switch, to the workstation and then back again.

Problem is from Router A..(and anything behind router A)
I can ping workstations beyond Router B (via the hub), but I cannot traceroute to any devices behind Router B.

Im struggling to see what the reason is. I understand ping is different to traceroute, but I can FTP to the devices I am trying to traceroute to..weird...
Its causing some problems with an application we are running where comms are OK between Router B to A...but fail from Router A to B ( well, the devices behind router B ).
I can traceroute to each one of the routers..the problems happen when I try to get to devices beyond router B.

Confused!!?? I am just reading this, but hopefully someone will be able to help.

BTW, the workstations in question (behind router B) are running DOS and TCP/IP (PCTCP)

Any ideas folks???

Really appreciate any assistance...

Andrew

**Update...I have narrowed it down to router B. I cannot traceroute from router B to any workstations behind it. There is a netgear hub (EN104) connecting a few workstations together to the router F/E 0. I can still ping though.

AGain..really really apprecite any help.

Andrew

 

[KSM]

Any network device including switch must point default gateway to local router ip address. Your switch does not perform routing or layer 3 forwarding.
Please correct it first and see what is change on your problem.

 

[tschouten]

Uhhmmmm, my question would be are you attempting to perform a traceroute from the RouterB Console itself? Because if that's the case you won't see much as there is no hop for it to trace to you would see a reply something like this if it was directly off of the ether port which is connected to a switch (or hub of some kind).


Type escape sequence to abort.
Tracing the route to 10.3.1.11

1 10.3.1.11 4 msec 4 msec 4 msec


However, if you are trying it from RouterB and see:

Type escape sequence to abort.
Tracing the route to 10.3.1.11

1 10.3.1.11 * * *

You know that it's being blocked.And Iwould say look at any access-lists you may have and you have narrowed it down to a problem going out that ethernet port.

 

[tschouten]

Ooops, submitted a post with information missing.

Say that IP address 10.3.1.11 is a workstation located off of the HUB or SWITCH that is connected to the ether port of RouterB.

Totaly forgot to mention that.

 

[chocyman]

Many thanks for the replys folks..

Righty...

Umm..firstly to answer the first reply. Ummm my switch`s default gateway IS pointing to the local routers IP address (192.0.0.1). So not quite understanding what you mean, can you just expand on this a bit more..

Now...

Your right...Im telnetted onto router B so yes I have a tty session open on it (to get to the console means a 4 hour drive!!).
From the "console" I cannot traceroute to any of the workstations behind it. Ive tried initiating the trace from the local (to the router) FE0 port and the serial 0 port. Both come back with the response * * *.
You mentioned acl`s....also been down that route, no acls configured and tried the IP allow any any as well (just in case there was anything freaky going on the implicit deny). But all no good.

So...This is where I am at. In my opinion the network is fine and working. Gateways are correct and the message is getting to the workstation. Lets face it I can FTP and ping to the device so theres no logical reason why I should be able to trace to it.
Ive done a little reasearch into how trace works and its intersting stuff. (apologies if if get a little bit wrong but the idea is:- trace sends 3 UDP packets to the destination, along with a TTL of 1. The first hop reduces this to 0 and gets bounced back to the source with its IP address as the source of the refusal. This is your first hop. Now the source sends again out 3 UDP packets this time with a TTL of 2. The first router or hop reduces this by one, and routes it to the next router or hop..which again reduces the TTL to 0 etc etc...
BUT the important part. When it finally reaches its destination (ie the device you pinged in the first place) the 3 UDP packets reach it, but on a high port number (think its 33000) which most systems will refuse. Therfore, they get bounced back to the source with a connection refused. This is how trace knows that its reached its destination and what IP address it is etc etc)
Ok..after that long winded explanation....
I use an OLD OLD version of DOS and PCTCP with a TCP module resident in memory. Theres no doco, but I think..that the TCP module is ACCEPTING these final UDP requests, rather than rejecting them. This may explain why FTP and ping works, but trace doesnt...
UNFORTUNATLY this doesnt solve my problem of why comms work one way and not the other as far as the application we use goes. Id give you more info on the app if I had it, but all I know is that the app uses the OS TCP stack to deal with comms. It has no knowledge of TCP/IP itself, and just "sends" info down to the OS to handle routing and other stuff.

So...I`ll have a closer look, and may even go and hang I dunno another switch or something off the hub (maybe a NT box or something) and try to trace to it. My guess is that it`ll work and its down to the age of the TCP module Im using.

Lengthy explanation I know, but still be greatful of any suggestions to get me out of the poop...

Cheers

Andrew

 

[jeter]

Problem is from Router A..(and anything behind router A)
I can ping workstations beyond Router B (via the hub), but I cannot traceroute to any devices behind Router B.

Odd, when you do trace route do you recieve any information at all? Have you tried other tracert parameters such as,

-d does not resolve address to computer names
-h specifies max number of hops
-j specifies loose source route along computer-list
-target_name specifies target computer

“Reserve your right to think, for even to think wrongly is better than not to think at all”

Fisher CCNA

 

[ChicagoJim]

KSM's point is valid. Why do you have the default gateway of the workstations behind router A pointing to the switch? This will cause end-to-end connectivity problems for the hosts behind router A.

The switch will never forward the frames sent from the hosts on to your router. Therefore, the default gateway for the hosts behind router A should point router A's FastEthernet port (192.0.0.1), not the address of your switch (192.0.0.141).

This doesn't directly answer your trace route issue. Nevertheless, it is a configuration problem that should to be corrected before addressing your traceroute issue.

 

[chocyman]

Ahhh..Ok I understand the original remark now.
I`ll give it a go, and change the default gateway of the workstation to the router rather than the switch...but my thinking is that the switch (a layer 2 device) fair enough wont do routing, but surely I am not routing as its all on the same network (the 192.0.0.x network).I would HAVE to route if the IP address was a different network, and therefore wouldnt be able to use the switch.
Like I say, I`ll give it a go, but dont see as there will be much if any difference.
ANyway...really appreciate your help guys.
Ive done some further digging and going on a trip to the local router to rig up a packet sniffer to see whats going on. I think the traceroute issue is clouding the real problem (see my explanation (maybe) above)

Once again...thanks..

Andrew