4 NIC's - outbound traffic all going out one NIC

[Ratzie]

I have 4 NIC's all inbound traffic is being evenly distributed throughout the 4 NIC's through DNS round robin.

I have just read an article in sun on IP network Multipathing, that you can stipulate how the outbound traffic is being distributed.

Is there something in HP that is similar
I have 2 NIC's on one subnet
2 NIC's on another subnet

[Slawomir Gora]

Hi,

you can try with Auto Port Aggregation but you have to purchase license for this software.
http://docs.hp.com/en/netcom.html#Auto%20Port%20Aggregation%20(APA)

without APA outboud trafic always goes by first lan interface is subnet.

[Craig Gilmore]

Hi!

HP only supports 1 NIC per subnet, unless you are using APA as the previous responder suggested. APA or Auto Port Aggregation allows you to team several NIC's into one big logical pipe. (aka bonding in Linux)

However, it seems that what you really want to do is load sharing. This is where IP routing comes into play. The IP stack will allow you one default route. That default is usually assigned to NIC with IP address that is on the same network as the gateway. It's the IP stack that makes the decision where to send the packet. With 2 NIC's on the same subnet, I'm guessing that the one with the lowest instance number would get the route. However, I cannot say for sure as I don't believe that this has been tested in all cases.

You could write a streams driver for DLPI to round-robin packets after the IP Stack passes off the data... but ...

Regards

[JJ Urich]

You might changing the parameter below via ndd:

# ndd -h ip_strong_es_model

TOUR 2.4 allows you to configure a default gateway for each IPv4 interface. This feature is by default disabled in the HP-UX 11i v1 Transport software. When this feature is disabled, TOUR 2.4 behaves similar to TOUR 1.0 on the HP-UX 11i v1 operating system and the base HP-UX 11i v1 Transport software.

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. This feature is already supported for IPv6 interfaces.

You can use the ndd parameter ip_strong_es_model to enable the default gateway for a physical IPv4 interface. The ip_strong_es_model parameter controls support for the strong end-system model. When this parameter is enabled, packet source addresses (and therefore interfaces on a multihomed host) affect selection of a gateway for outbound packets. Previously, ip_strong_es_model supported two values, namely 0 and 1. These values affect the routing decision made by a client application. If ip_strong_es_model is set to 0, the strong end-system model is disabled.



Note: A value of 0 for ip_strong_es_model is also the default option in TOUR 2.4 when the default gateway is disabled for a physical IPv4 interface.


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.

JJ

[rick jones]

Oh goody - they have shipped the "firm_es_model" change I was pestering them for :)

Indeed, when multiple NICs are in the same subnet, traffic is received on all, but only goes out one of them unless strong_es_model is set.

Strong_es_model causes the source IP address to be part of the route lookup. It also makes it such that packets to a given IP are only accepted on the interface with the matching IP.

Hence the desire for "firm_es_model" or strongs_es_model of two - do the route selection including the source IP, but still accept traffic for any IP of the system on any interface on the system.

With that, the outbound traffic will be distributed based on how the clients connect - the DNS round-robin will determine your traffic distribution.

If you want some other distribution - say by MAC or destination IP or TCP port number - then the OP should obtain and install APA, which will have the added benefit of transparant failover

[Ratzie]

I just want ot make sure before I make this change I will not break anything.
Right now I have:
# ndd -get /dev/ip ip_strong_es_model
0

Now if I change it to 1, will it break any routing??!!!!

# ifconfig lan0
lan0: flags=843
inet 192.168.165.106 netmask ffffff00 broadcast 192.168.165.255
# ifconfig lan1
lan1: flags=843
inet 192.168.165.107 netmask ffffff00 broadcast 192.168.165.255
# ifconfig lan2
lan2: flags=843
inet 192.168.160.243 netmask ffffff00 broadcast 192.168.160.255
# ifconfig lan3
lan3: flags=843
inet 192.168.160.244 netmask ffffff00 broadcast 192.168.160.255


# netstat -rn
Routing tables
Dest/Netmask Gateway Flags Refs Use Interface Pmtu
127.0.0.1 127.0.0.1 UH 0 73120313 lo0 4136
192.168.165.107 192.168.165.107 UH 0 0 lan1 4136
192.168.165.106 192.168.165.106 UH 0 302074 lan0 4136
192.168.160.243 192.168.160.243 UH 0 0 lan2 4136
192.168.160.244 192.168.160.244 UH 0 0 lan3 4136
192.168.165.0 192.168.165.107 U 2 0 lan1 1500
192.168.165.0 192.168.165.106 U 2 0 lan0 1500
192.168.160.0 192.168.160.244 U 2 0 lan3 1500
192.168.160.0 192.168.160.243 U 2 0 lan2 1500
127.0.0.0 127.0.0.1 U 0 0 lo0 4136
default 192.168.165.10 UG 0 0 lan1 1500

[rick jones · Accepted solution]

it will only "break" your routing if at present you are receiving traffic for one of your IPs on an interface other than the one on which that IP is configured.

having said that, it would be best to make that change when you can satisfy both of these conditions:

1) you are at the actual system console, not remotely logged-in to the system

and

2) if something does go wrong it will not cause you too much distress for the small number of moments it would take to set ip_strong_es_model back to zero