Routing issue on HACMP

Implement a set of preferences for the placement of service labels on IPAT via IP aliasing networks.
Options include:

1) Anti-collocation - this is the default - all labels are distributed across all boot labels using a least loaded selection process.
2) Collocation - all labels will be mapped to the same interface.
3) Anti-Collocation with persistent - Service labels will be mapped across all interfaces NOT holding the persistent label
4) Collocation with persistent - Service labels will be mapped to the same interface as the persistent label..
Note that these preferences will not affect availability - if there are not adequate interfaces to satisfy the preference, service and persistent labels will still be mapped to an active interface. if "Collocation with persistent" is selected, then the persistent address will always be the source IP address. . With "Anticollocation" or "Anti-Collocation with persistent" aliases my be distributed over several interfaces. There are multiple routing entries which are used in Round-Robin Mode by AIX. So the Source IP Address will not always be the same. . In a Single Adapter Network this APAR (with setting: "Collocation with persistent") is not necessary. In a Single Adapter Network the persistent IP Address should always be the source IP address. . The service IP Address will only be used as source IP, if there is no persistent address or if persistent address and service address are on diffrent interfaces....

If that is not an option, the only possibility is, that the application gets modified to bind to a specific IP as described by :

It seems to be the reason the questions are being asked is the statement by the customer : "The client is connected at IP1 ( 172.18.32.3 ) of the AIX lpar. The way back on the AIX lpar is possible over DG1 ( 172.18.32.30 ) and ( 10.40.139.254 ) DG2. The Multipath Routing default attitude is Weighted Round Robin. If the way back is made now by DG2 and not by DG1, the Firewall a IP recognizes Spoofing and communication is not possible." .

The core if the statement is just the words: "the Firewall a IP recognizes Spoofing and communication is not possible." . The source IP address of a packet being different is the real issue here. .

This is caused by applications making the wrong choice: (They have 2 choices in this regard) .

Choice #1: (antiquated, but still in use by legacy apps). this choice lets the routing table decide the source IP address of a reply packet. -Back when the internet was young (very young by todays standards) - then this did not cause too much trouble because it was a fact of those days that the only hosts with more than one interface were routers, and routers of those days were "dedicated" to being routers.. they generally did not also function as application servers. Application servers usually only had ONE route to any remote hosts, and so applications were coded to not even care which local address the query was sent to, they just let the OS`s routing table find the interface and put the IP on it as per the very simple (by todays` standards) routing table, because, like I said above - back then, there was only one route usually out of the machine, and it always led to the same interface, and it was pretty well guaranteed that it would be the same IP and same interface that any traffic came in on, - and then those replies were always going to be coming from the same address that they were sent to. . NOTE: Choice #1 (above) - is a bad choice in today`s multipath network environment. .

Choice #2: Server applications coded to "do it properly" in a multipath, asymmetric routing world we have today. (Asymmetric routing = the route there, is not always the route back). Such applications pay proper attention to the inbound packet (the call is "getpeername") and through such a series of API calls they can find out exactly which local IP address they were contacted on - so that when they send replies to such contact, they bind() the socket they are about to reply on TO that exact IP address before they send() the reply. This in no way affects how the packet will actually leave the machine (by the way) it can still follow the routing table to the destination - even leaving a different interface than the one which address is bound to. What`s important is that it will go out with the exact same source address that the packet it is an answer to came in on as a destination address. This is what is supposed to prevent "firewall troubles" . . It`s not just firewalls either - most new applications will not even accept (for security reasons) a packet coming form a different address than the one they sent a query to. A prime example is: the DNS server application "named" USED to have such a problem. (Not in the client - but in the server) - The DNS server would fail to follow choice #2 in it`s coding, and instead use choice #1. ---This worked for the early internet days where asymmetric routing (often caused by equal cost multipath) was not common at all. But - this had to be "fixed" in the named code at one point - because as people started to use asymmetric routes, it started to fail. . SO: The upshot is this: If you use a lot of legacy apps which are still using choice #1 in thier code.. (they will all soon die if they do not make coding corrections like the named daemon did) - then you are going to be restricted from using asymmetric routes along with these as these will not work. There has been an intermittent solution though, (instead of waiting for programmers to re-program all those legacy apps) that STILL lets you use asymmetric routes along with such apps: The VIPA interface. The AIX VIPA interface has the unique property of making applications which try to do a wildcard bind() bind only to it`s address. The VIPA can also be directed to use ANY interface to send traffic on - even though such traffic will always carry the IP of the VIPA instead of the one on whichever external interface it leaves the machine on. . The only thing you need is to give the routers any host-specific routes back to the VIPA using the hosts own external interface addresses as the gateways for such routes. . The routing policies then are only of concern to load balancing, or for higher availability, or for other traffic load control purposes. - But they are not effective against the issue brough up by "IP spoofing" as even without multipath routing, asymmetric routes can and do still exist. .