Operating System - HP-UX
1834106 Members
2320 Online
110063 Solutions
New Discussion

Re: A network problem of ignite server

 
SOLVED
Go to solution
Wang,MinJie
Super Advisor

A network problem of ignite server

Hi all
I have a problem
I've configured an ignite server which is based on HP-UX B2000 workstation by the way and it works well
Recently I inserted an extra lan card and gave it an IP address to make it work
Now the problem comes:
I can only boot my client to pull installation from Ignite Server through the newly added lan card.
In other words my original lan card cannot give client IP address
Can any one help me?
6 REPLIES 6
Wang,MinJie
Super Advisor

Re: A network problem of ignite server

Maybe I should make it clearer
My original lan card IP:192.168.20.151
My newly added lan card IP:192.168.20.152
When I run the following command in BCH:
******************************************
BCH Prompt>boot lan.192.168.20.151 install
******************************************
it doesn't work
instead "boot lan.192.168.20.152 install"
it works

I don't know why
Any advice
Matti_Kurkela
Honored Contributor
Solution

Re: A network problem of ignite server

Looks like you have connected two physical LAN cards of the same host to the same network segment. This is not supported by HP-UX.

(The IP routing code in HP-UX sees the two LAN cards are connected to the same network, and it uses whichever card comes first in the OS's internal tables. The result is that when your Ignite client sends a request to one interface, the answer may come out the other interface...)

If you need your server to have two IP addresses in the same network segment, use IP aliases instead.

If you need more bandwidth than one interface can provide, you need to install HP APA product and use it to configure a "trunk" of two LAN cards.

MK
MK
Patrice Le Guyader
Respected Contributor

Re: A network problem of ignite server

Hello,

What you can try is to force your server to respond by the lan interface it received the request. Whis this you can have multiple physical NICs on the same IP subnet.

Try to look after this ndd parameter ip_strong_es_model.

To get it's current value:
ndd -get /dev/ip ip_strong_es_model

To activate it :
ndd -set /dev/ip ip_strong_es_model 1

You can after if it's good for you put it in the file /etc/rc.config.d/nddconf.

TRANSPORT_NAME[X]=ip
NDD_NAME[X]=ip_strong_es_model
NDD_VALUE[X]=1

Hope this helps.
Pat

Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.
Wang,MinJie
Super Advisor

Re: A network problem of ignite server

Hey Patrice
When I telnet 192.168.20.151 and run
#ndd -set /dev/ip ip_strong_es_model 1
it seems like i can't use the NIC with 192.168.20.151 any more.
Then I have to telnet 192.168.20.152 and run
#ndd -set /dev/ip ip_strong_es_model 0
then the first NIC can work again
Can you tell me why
How can I consult the meaning of the "ndd" parameters?
Thx
Sandy Chen
Honored Contributor

Re: A network problem of ignite server

Hi,

Matt already answered for your last question. HPUX does not support 2 IP address on same subnet. You will have to configure your second LAN Card for a different subnet of IP

regards,
Sandy
I never think of the future. It comes soon enough.
Patrice Le Guyader
Respected Contributor

Re: A network problem of ignite server

Demat Wang,

You can have the signification of the ndd parameters with ndd -h :

ndd -h ip_strong_es_model.

Otherby according to the fact that is it possible to have more than one NIC on the same subnet ? It seems to be possible (TOUR2.4). Is it a good thing ? I don't know.

You should consider the following update on you system, the installation of TOUR2.4 wich will enable new feature on HPUX transport.

http://docs.hp.com/en/5991-0782/5991-0782.pdf

"By configuring a default gateway for each physical IPv4 interface, a system can now send an outbound packet through the interface for the address to which the socket (or communication endpoint) is bound. If the socket (or communication endpoint) is not bound to a specific address, the system sends the packet through the interface on which the inbound packet was received. Prior to this support, a system could receive inbound packets through multiple physical interfaces connected to the same subnet but all outbound packets were sent through a single interface."

It had a new value to ip_strong_es_model too :

"If ip_strong_es_model is set to 1, the strong end-system model is enabled on the system.
Starting with TOUR 2.4, the ip_strong_es_model parameter supports another value, that is 2. If you set ip_strong_es_model to 2, the system attempts to match the best gateway (discussed in Case 1) when multiple default gateways are set up on a single IPv4 subnet. Following are different instances that affect the routing decision:
Case 1 If the client application is bound to the IP source address, the default gateway
chosen is the one associated to that source address.
Case 2 If the client application is bound to INADDR_ANY, the default gateway chosen is the one associated to the source address the client application binds to.

For more information on configuring the default gateway for a physical IPv4 interface, refer to
the ndd help text."

And finally :

From ftp://ftp.cup.hp.com/dist/networking/briefs/annotated_ndd.txt

ip_strong_es_model:

Controls support for "Strong End-System Model" described in
RFC1122, Section 3.3.4.2. When enabled, packet source addresses
(and therefore interfaces on a multihomed host) affect selection
of a gateway for outbound packets. Set to 0 to disable; set to 1
to enable. [0,1] Default: 0 (disable)

Setting this value to one will have the beneficial effect of allowing
(should they be desired) per-interface default routes. It also means
that if a packet is received on a given interface, the reply to that
packet will be sent-out that interface. This can be useful if one is
in the rare situation of needing to have separate physical (in the
context of IP - see ip_ill_status) interfaces configured with IP
addresses in the same subnet. Generally though, using Auto Port
Aggregation (APA) to create one virtual interface with a logical
interface for each address is a more robust solution.

Also, when ip_strong_es_model is set to a value of one, IP datagrams
arriving on the "wrong" interface (one that does not have an IP
address which matches the IP datagrams' destination IP address) are
discarded. If one is using IP address aliases on the loopback (lo0)
interface in support of functionality such as hardware load balancer
triangle routing, setting ip_strong_es_model to a value of one may
result in loss of connectivity for the virtual IP address.

It's sure not as simpliest as configuring APA but if you don't want to buy a licence it should probably be interesting to spend some time to tune your routing table.

Perhaps someone as a good feedback about it ?
(Thinking to Mr Rick Jones)

Hope this helps
Kenavo
Pat
Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement.