host route question

[chad_c]

hello

am trying to ping (icmp) a device with a dedicated host (static) route

however the ping (icmp) takes a different route (see example below)

txnnm2# traceroute 10.10.10.32
traceroute to 10.10.10.32 (10.10.10.32), 30 hops max, 40 byte packets
1 TXCecPLUS1-2 (10.5.25.109) 3.521 ms 1.595 ms 1.587 ms
2 HA1-AUS (10.5.25.103) 3.053 ms 3.075 ms 3.035 ms
txnnm2# netstat -rnv | grep 10.10.10
10.10.10.32/255.255.255.255 10.5.25.104 UGH 0 lan0 1500
10.10.10.0/255.255.255.0 10.5.25.109 UG 0 lan0 1500

can anyone shed some light as to why the route taken is through the 10.5.25.109 instead of using the dedicated host route 10.5.25.104?

gracias,
chad

[chad_c]

here is a clearer snapshot:

txnnm2# traceroute 10.10.10.32
traceroute to 10.10.10.32 (10.10.10.32), 30 hops max, 40 byte packets
1 TXCecPLUS1-2 (10.5.25.109) 1.773 ms 5.051 ms 3.478 ms
2 HA1-AUS (10.5.25.103) 3.225 ms 3.279 ms 3.146 ms

txnnm2# traceroute 10.5.25.104
traceroute to 10.5.25.104 (10.5.25.104), 30 hops max, 40 byte packets
1 HA2-AUS (10.5.25.104) 3.024 ms 4.416 ms 3.439 ms

txnnm2# traceroute 10.5.25.109
traceroute to 10.5.25.109 (10.5.25.109), 30 hops max, 40 byte packets
1 TXCecPLUS1-2 (10.5.25.109) 1.816 ms 2.954 ms 1.821 ms

txnnm2# netstat -rnv | grep 10.10.10
10.10.10.32/255.255.255.255 10.5.25.104 UGH 0 lan0 1500
10.10.10.0/255.255.255.0 10.5.25.109 UG 0 lan0 1500

can anyone shed some light as to why the route taken is through the 10.5.25.109 instead of using the dedicated host route 10.5.25.104?

[Jim Keeble]

Give us the following:

The command you used to add the route, or the netconf entry.

Netstat -in

netstat -rvn

... without the grep :-)

Also, try :

ping -o 10.10.10.32 -n 4

[Mel Burslan]

Unfortunately you can not control the behavior of ping as in which route it should take. On the other hand, you can do it by traceroute, by specifying the gateway to use using -g switch. I know traceroute is not ping but close enough in my opinion.

[Roland Piette]

Hello Chad

You have to control also the routing table on the other side.

I see that the address you try to reach belongs to two rules.

A rule for a subnet 10.0.0.x (255 nodes) through a remote gateway defined on your lan0. Note that the adress 10.10.10.32 is include in this subnet !
A second rule for a remote host through a gateway also define on your lan0.

As lan0 is used for both rules, you have also to see on the gateway witch rules are applied.

I cannot tell you witch is the order traceroute will used to define the patch to reach the remote host. Maybe it will choice first network rule and then host rule ?!

Regards

[chad_c]

hi

thanks for the responses

the route is on entered as a temporary route at the moment ... aka not in the netconf file (routing table)

entered the route via:

add host 10.10.10.32: gateway 10.5.25.104

[chad_c]

further more ... it is my impression that if a host route is entered with 32 bit mask ... then that is the static route for that one host

[Jim Keeble]

Try removing the route and adding it back with the metric of 1. I think it assumes 0 if you leave it off:


route add host 10.10.10.32 10.5.25.104 1

[Mel Burslan]

Chad,

The right syntax for the route command for this purpose should be

route add 10.10.10.32 10.5.25.104 1

in the command the word host is implied and yes the netmask in the case of a host route is 32 bits by default. But I can see that it somehow worked with the syntax you used. Again, if something funky happened when you were adding that route, it might look like it is there but it may not be routing traffic. Please try to traceroute to this host with

traceroute -g hostname_or_ipaddress

and see if it is working. When it comes to ping taking that route, as I said previously, uncontrollable behavior. Maybe network expert extraordinaire Rick Jones can shed some light on "why ping does that" when he drops by, but it is beyond me unfortunately.

[chad_c]

thanks for the resoonse jim

that is how the route was entered ... just got left out on my copy and paste to the forum ... :)

[Jim Keeble]

Ping uses the routing table, same as any other IP packet. Some versions of traceroute do not, and may need the -i and/or -g switches to steer the outbound packet the way you want.

So, maybe your route is ok, and traceroute syntax is your problem.

netstat -in and netstat -rvn would help.

[chad_c]

txnnm2# route add host 10.10.10.32 10.5.25.104 1
add host 10.10.10.32: gateway 10.5.25.104

txnnm2# traceroute -g 10.5.25.104 10.10.10.32
traceroute to 10.10.10.32 (10.10.10.32), 30 hops max, 52 byte packets
1 HA2-AUS (10.5.25.104) 4.644 ms 2.949 ms 2.991 ms
2 * * *
3 *

txnnm2# traceroute 10.10.10.32
traceroute to 10.10.10.32 (10.10.10.32), 30 hops max, 40 byte packets
1 TXCecPLUS1-2 (10.5.25.109) 1.705 ms 1.624 ms 1.586 ms
2 HA1-AUS (10.5.25.103) 4.256 ms 3.117 ms 4.893 ms
3 *

txnnm2# netstat -rvn | grep 10.10.10
10.10.10.32/255.255.255.255 10.5.25.104 UGH 0 lan0 1500
10.10.10.0/255.255.255.0 10.5.25.109 UG 0 lan0 1500
txnnm2#

makes a little more sense ... that this is not working even when tracing through the appropriate GW

[chad_c]

txnnm2# netstat -in
Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll
lan3 1500 192.168.1.0 192.168.1.53 171198348 0 72245434 0 0
lan0 1500 10.5.25.0 10.5.25.53 536774256 0 544720240 0 0
lo0 4136 127.0.0.0 127.0.0.1 158355368 0 158355369 0 0
lan5 1500 192.168.4.0 192.168.4.53 96291973 0 59205460 0 0
lan4 1500 192.168.3.0 192.168.3.53 136841428 0 105385666 0 0

txnnm2# netstat -rvn
Routing tables
Dest/Netmask Gateway Flags Refs Interface Pmtu
127.0.0.1/255.255.255.255 127.0.0.1 UH 0 lo0 4136
10.5.25.53/255.255.255.255 10.5.25.53 UH 0 lan0 4136
192.168.4.53/255.255.255.255 192.168.4.53 UH 0 lan5 4136
192.168.1.53/255.255.255.255 192.168.1.53 UH 0 lan3 4136
192.168.3.53/255.255.255.255 192.168.3.53 UH 0 lan4 4136
10.10.10.32/255.255.255.255 10.5.25.104 UGH 0 lan0 1500
10.5.25.0/255.255.255.0 10.5.25.53 U 2 lan0 1500
192.168.1.0/255.255.255.0 192.168.1.53 U 2 lan3 1500
192.168.3.0/255.255.255.0 192.168.3.53 U 2 lan4 1500
192.168.4.0/255.255.255.0 192.168.4.53 U 2 lan5 1500
192.168.2.176/255.255.255.240 192.168.4.1 UG 0 lan5 1500
192.168.2.192/255.255.255.240 192.168.4.1 UG 0 lan5 1500
192.168.2.208/255.255.255.240 192.168.3.1 UG 0 lan4 1500
192.168.2.224/255.255.255.240 192.168.3.1 UG 0 lan4 1500
192.168.2.0/255.255.255.240 192.168.1.1 UG 0 lan3 1500
192.168.2.128/255.255.255.240 192.168.1.1 UG 0 lan3 1500
10.160.184.0/255.255.255.0 192.168.3.1 UG 0 lan4 1500
10.160.194.0/255.255.255.0 192.168.3.1 UG 0 lan4 1500
10.160.63.0/255.255.255.0 192.168.4.1 UG 0 lan5 1500
10.160.73.0/255.255.255.0 192.168.4.1 UG 0 lan5 1500
10.160.152.0/255.255.255.0 192.168.3.1 UG 0 lan4 1500
10.160.162.0/255.255.255.0 192.168.3.1 UG 0 lan4 1500
10.3.74.0/255.255.255.0 192.168.1.1 UG 0 lan3 1500
10.3.84.0/255.255.255.0 192.168.1.1 UG 0 lan3 1500
10.10.10.0/255.255.255.0 10.5.25.109 UG 0 lan0 1500
10.120.0.0/255.255.0.0 192.168.3.1 UG 0 lan4 1500
10.100.0.0/255.255.0.0 192.168.1.1 UG 0 lan3 1500
10.101.0.0/255.255.0.0 192.168.1.1 UG 0 lan3 1500
10.119.0.0/255.255.0.0 192.168.1.1 UG 0 lan3 1500
10.115.0.0/255.255.0.0 192.168.4.1 UG 0 lan5 1500
10.114.0.0/255.255.0.0 192.168.1.1 UG 0 lan3 1500
192.168.6.0/255.255.255.0 192.168.3.1 UG 0 lan4 1500
127.0.0.0/255.0.0.0 127.0.0.1 U 0 lo0 4136
default/0.0.0.0 10.5.25.1 UG 0 lan0 1500

[Jim Keeble]

Try:

traceroute -i lan0 10.10.10.32

I think traceroute might be choosing lan3 as the return (ie, the source)address on it's outbound packets, and maybe the router doesn't know how to reach that IP.

The routing table looks right. You may need a nettl trace to figure out what's happening if that doesn't work. There are knowledge tree articles on that, not trivial to decode.

[chad_c]

traceroute -i lan0 10.10.10.32
traceroute to 10.10.10.32 (10.10.10.32), 30 hops max, 40 byte packets
1 TXCecPLUS1-2 (10.5.25.109) 1.789 ms 4.230 ms 1.684 ms
2 HA1-AUS (10.5.25.103) 3.204 ms 3.423 ms 3.232 ms
3 * * *
4 *

**continuing research**

[chad_c]

traceroute -g 10.5.25.104 -i lan0 10.10.10.32
traceroute to 10.10.10.32 (10.10.10.32), 30 hops max, 52 byte packets
1 HA2-AUS (10.5.25.104) 4.306 ms 2.991 ms 2.885 ms
2 * * *

[chad_c]

.