topic Re: TTL expired in transit at lan0:1 ip in Operating System - HP-UX

TTL expired in transit at lan0:1 ip

FaizirizaL — Mon, 22 Dec 2008 08:45:03 GMT

Hi friends,

I have a problem where oracle system cannot be access when the "TTL expired in transit" appears.

There are 2 server which is HP-UX 11.11 os. Running MC-Serviceguard.

1 server (node) running application and another server (node) running database. The ip configuration are as follows:

apps node - lan0 - 172.16.1.25
lan0:1 - 172.16.1.26

db node - lan0 - 172.16.1.23
lan0:1 - 172.16.1.24

default gateway - 172.16.1.14 and 172.16.1.2

The issue here is when system up and running, after a while, the lan0:1 ip come out with the "TTL expired in transit" result at ping and system cannot be accessed using the lan0:1 ip where it supposed to be but still can access using lan0 ip.

When tracert from windows pc which is on the same LAN (same switch), the result is like below:
1 <10 ms <10 ms <10 ms 172.16.1.14
2 2 ms 3 ms 3 ms 58.139.156.225
3 2 ms 3 ms 2 ms 58.139.156.226
4 7 ms 7 ms 5 ms 58.139.156.225
5 5 ms 5 ms 5 ms

There is sometimes it become back to normal where system can be accessed and can resolve ping without "TTL expired in transit".

Anybody here can help me because this problem really challenge me. Thanks in advance.

Re: TTL expired in transit at lan0:1 ip

Eric SAUBIGNAC — Mon, 22 Dec 2008 11:02:59 GMT

Bonjour FaizirizaL,

If the windows PC is "on the same LAN", I guess you mean "on the same IP subnet", right ? So, why a packet issued from the PC to the server has to go through the default gateway 172.16.1.14 ? It should not.

Second thing : the "TTL expired" error you see when you ping from the PC is clearly due to a loop between routers 58.139.156.225 and 58.139.156.226. Both of them don't know how to route the packet and "think" that each other knows how to. So they play ping-pong with the packet.

I also guess you have no trouble when pinging between app node and db node. Did you try ?

In conclusion I think you should carefully examine with the network admin your IP adressing and routing scheme. The problem is probably outside of HP-UX boxes.

Eric

Re: TTL expired in transit at lan0:1 ip

FaizirizaL — Mon, 22 Dec 2008 13:50:02 GMT

Hi Eric,

Thanks for the response,

Eric - If the windows PC is "on the same LAN", I guess you mean "on the same IP subnet", right ? So, why a packet issued from the PC to the server has to go through the default gateway 172.16.1.14 ? It should not.

Me - Yes, it is on the same IP subnet. I have no idea why the server should go through the default gateway 172.16.1.14 .By right, i think so it should not. What should it do?

Eric - Second thing : the "TTL expired" error you see when you ping from the PC is clearly due to a loop between routers 58.139.156.225 and 58.139.156.226. Both of them don't know how to route the packet and "think" that each other knows how to. So they play ping-pong with the packet.

Me - Is this because of the router/gateway 172.16.1.14 problem? There have no issue for the lan0 ip (can resolved ping)

Eric - I also guess you have no trouble when pinging between app node and db node. Did you try ?

Me - Sometimes got trouble ping from lan0 from node 1 to lan0:1 node 2 and vice versa

Eric - In conclusion I think you should carefully examine with the network admin your IP adressing and routing scheme. The problem is probably outside of HP-UX boxes.

Me - I'm also agreed with your conclusion which is probably outside of HP-UX boxes but still finding prove.

Re: TTL expired in transit at lan0:1 ip

Eric SAUBIGNAC — Mon, 22 Dec 2008 14:34:49 GMT

From both nodes, could you post results of :

ifconfig lan0
ifconfig lan0:1
netstat -rnv
netstat -in

From windows pc :

ipconfig /all
netstat -rn

Eric

Re: TTL expired in transit at lan0:1 ip

FaizirizaL — Mon, 22 Dec 2008 15:55:20 GMT

Eric,

Attached are the info you requested:

The lan0:2 also existed there is because of i'm running package for database also in the same box due to unable to resolve ping.

Thanks,

Re: TTL expired in transit at lan0:1 ip

Eric SAUBIGNAC — Mon, 22 Dec 2008 16:56:35 GMT

well, well ... :-( looking at the informations provided, I still can't understand why packets from the PC are transmitted to the server through a router : speksap1 and dmsserver are really in the same subnet (I was hoping an error on the subnetmask). Since the package has switched you could have sent "ifconfig lan0:2" but I guess it has the same netmask "ffff0000" ? Check please.

What I understand from your latest post, is that you can ping packages'IP (172.16.1.24 and 172.16.1.26) when there are on node speksap1 but not on the other node ? If true, then you should really post results of command (ifconfig, netstat, ...) from the second node. You did not.

An other thing that is comming straight from windows world : 2 or more default gateway. I can't figure out how it could work on an HP-UX box. I am not a network expert, but as far as I know, when a packet can't reach its destination, ip stack doesn't try an other route. I would tend to think that you should have one and only one default gateway, on hp-ux boxes and on windows boxes also. 172.16.1.2 or 172.16.1.14 but not both.

Last question today : do you have vLan in your network ?

Eric

Re: TTL expired in transit at lan0:1 ip

FaizirizaL — Tue, 23 Dec 2008 04:32:35 GMT

Eric,

Thanks for the response,

Eric - well, well ... :-( looking at the informations provided, I still can't understand why packets from the PC are transmitted to the server through a router : speksap1 and dmsserver are really in the same subnet (I was hoping an error on the subnetmask). Since the package has switched you could have sent "ifconfig lan0:2" but I guess it has the same netmask "ffff0000" ? Check please.

Me - i also don't understand why is that happened.Here is the result of ifconfig lan0:2
speksap1@root:>ifconfig lan0:2
lan0:2: flags=1843
inet 172.16.1.24 netmask ffff0000 broadcast 172.16.255.255
speksap1@root:>

Eric - What I understand from your latest post, is that you can ping packages'IP (172.16.1.24 and 172.16.1.26) when there are on node speksap1 but not on the other node ? If true, then you should really post results of command (ifconfig, netstat, ...) from the second node. You did not.

Me - Yes i can ping if those are on the same box no matter which node where i believe it just because of there is no route between that ip. I can't post it right now, will do later (i checked both node have same network config - so i leave it no change except gw).

Eric - An other thing that is comming straight from windows world : 2 or more default gateway. I can't figure out how it could work on an HP-UX box. I am not a network expert, but as far as I know, when a packet can't reach its destination, ip stack doesn't try an other route. I would tend to think that you should have one and only one default gateway, on hp-ux boxes and on windows boxes also. 172.16.1.2 or 172.16.1.14 but not both.

Me - Actually before this we only using 1 gateway ip which is 172.16.1.2 but also got the same result as using 2 gateway. Recently, during the problem occured, i have added 172.16.1.14 (thus became 2 gw), then about 2 hours later, the lan0:1 ip back to normal which is can normally ping and system can access thru that ip. It only can stand for 1 day, where the next day it back to the same problem.

Eric - Last question today : do you have vLan in your network ?

Me - I can't answer at this moment, i'll be back for this.