traceroute trying to use backup lan instead of primary

[Ron Kinner]

I believe I read somewhere that traceroute was broken in 11.? and higher and that you had to use the -i option to get it to work reliably (Otherwise it seemed to randomly pick the interface to use instead of using the routing table like it should.)

I see there is a patch to traceroute:

PHNE_29887


They don't mention your exact problem but the notes say that you will get at least get a man page for traceroute even if it doesn't fix your problem. Perhaps there will be something in the man page.

Ron

PS I don't see how the broadcast address is going to cause traceroute to use the wrong path. If the address fits in the mask then it is considered a local address and we arp for its MAC out the interface where we expect to find it. If not we should look at the routing table (netstat -rn) and decide what to do from that. Usually that means we should use the default gateway so we arp for his address if we don't have it and send it on to him. I think the Broadcast address is mostly just used to remember what to listen for. Note that mask 255.255.248.0 is the same as xfffff800.

[Vicki Selover]

Mel,

We do have devices with 0 as the 3rd octet on the network. I tried to delete the route but was only able to delete the following line:

192.168.0.0/255.255.255.0 192.168.0.52 U 2 lan1 1500
The 192.168.0.52/255.255.255.255 would not delete.

Ron, I checked for the patch and I do have it installed and configured.

[Vicki Selover]

This may not mean anything but I thought it was interesting. I did a ping -o to a host because according to the ping man page, if hte -i option is not specified,packets are sent from the "default" interface, which is determined by the "route configuration". Can't I determine from the summary at the end, that it did take the 170 route out of hostB? Like Ron is thinking, wouldn't this point to a problem with traceroute possibly?


hpauto:/usr/contrib/bin :ping -o hostA
PING hostA.com: 64 byte packets
64 bytes from 170.126.4.43: icmp_seq=0. time=0. ms
64 bytes from 170.126.4.43: icmp_seq=1. time=0. ms
64 bytes from 170.126.4.43: icmp_seq=2. time=0. ms
64 bytes from 170.126.4.43: icmp_seq=3. time=0. ms

----hostA.com PING Statistics----
4 packets transmitted, 4 packets received, 0% packet loss
round-trip (ms) min/avg/max = 0/0/0
4 packets sent via:
170.126.4.43 - hostA.com
170.126.4.47 - hostB.com

[Sanjay_6]

Hi,

Maybe your default route is set to the same subnet as your backup lan.

Hope this helps.

Regds

[Vicki Selover]

Well, I've continued to dig into this problem and it really sounds like traceroute has some kind of issue (maybe by design???) I found the statement below in this post.

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=535404

Traceroute uses the first interface it finds, independent of routes. That's why you have this problem. As Peter mentions, ping -o is a way to know the real 'route'.

Thanks for everyone's help. Any other thoughts, let me know.

Vicki