Source Ip Selection

[Ilninno]

Hello,

We have detected some network problems in one server (HP-UX 11.31). This problem was due a physical link failure.

Now everything is working fine, but we have detected that the server is sending packets with a secondary IP (One of the ServiceGuard Packages Ip - 172.17.2.30).

Name Network Address errs
lo0 127.0.0.0 127.0.0.1 0
lan900 172.17.2.0 172.17.2.166 2
lan900:1 172.17.2.0 172.17.2.30 0
lan900:2 172.17.2.0 172.17.2.16 0

Destination Gateway Interface
172.17.2.30 172.17.2.30 lan900:1
172.17.2.16 172.17.2.16 lan900:2
127.0.0.1 127.0.0.1 lo0
10.0.0.10 10.0.0.10 lan21
172.17.2.166 172.17.2.166 lan900
255.255.255.0 172.17.2.166 lan900
10.0.0.0 10.0.0.10 lan21
127.0.0.0 127.0.0.1 lo0
default 172.17.2.111 lan900

I don't know how the source selection is done, but we have to force it to the main Ip address lan900 (172.16.14.166).

Do you know how to solve this problem with the less impact in the users?

Thank you!

[Laurent Menase]

Hi,

in fact as soon as the addressed are in the same subnet, there is no way to be sure which local address will be taken except that the applications bind explicitely to that address.


There is an other heavy way; use ipfilter to nat all the other addresses to the one expected.

but again, the only real way is that the application bind explicitely to the desired local address.

[Ilninno]

Hello Laurent,

Don't you know what criterion uses hpux for choosing the source Ip?

I mean that it should be always the same, something like: first of the if list, first of the routes.


Thank you!

[Laurent Menase]

>Don't you know what criterion uses hpux for
>choosing the source Ip?
yes I know them.

>I mean that it should be always the same,
>something like: first of the if list, first
>of the routes.
In fact it is none deterministic because external traffic may have an influence.

Most often, it is the first local in the same subnet as the gateway or the target in the ire hash table which is taken, but, if for instance
an inbound tcp packet come from a destination B to a local IP A , there will be an ire created from A to B so next packet sent to B will use address A, even if it is not the first one in the ire table.
- it is an example, some other cases exist too.
So you can't rely on that.


The only way currently to be able to choose a local address is to bind explicitely.

There is an other one, but may be more difficult to put in place as it needs more configuration:
using SRPv3, you can define a workload containment in which you put your applications, then the address assigned to that containment will be the one used by the application.

[Ilninno]

Perfect,

That was the kind of answer that I was looking for :)

About these tables, is there any way to clear it? We have never had this problem before and we think that is related with some physical network problems.

So just for solving our current problems we would like to know if it is possible to reset this assignments.

Thank you!

[Laurent Menase]

hi,
the only way is to lower ip_ire_flush_interval and ip_ire_cleanup_interval to their minimum
- be sure that cleanupthen be sure that there is no connection to the target from that source for that interval
- if any connection stay between the 2 side when the flush arrives, the ire will be recreated.


you can try also to create a little program which create a socket, bind to the address you want to use, and connect to the target on a opened port. it will create the valid ire, then it will depend on its position in the ire hash.
Then if it is not enough, you need to be sure there is no pending connection from the bad local to the destination.

you may also try to change the local ip to flush the ires from it ( if no application connected through that address).- did not try but may work-


But all this are tweaks without any guaranty of working nor side effects.
The only really supported way is to have application binding on the desired address.