with Tags: ipv6 X
When uLB is configured in high availability mode and a takeover is issued at any point in time,
then all present running connections will be lost. Why!!!
Because the uLB secondary server which took over does not know the state of connections which were handle by the other partner uLB.
From uLB 80 release record replication feature is introduced. This feature when enabled allows both primary and secondary uLB servers to exchange connection and affinity records.
It works in following modes:
1) none -Do not replicate
2) connection -Replicate connections (Should use with connection selection algo)
3) affinity -Replicate affinity (Should use with affinity selection algo)
4) both -Replicate connections and affinity (Should use with conn+affin selection algo)
This feature is network intensive. Use only when desired. Recommended only for long running connection. Does not have any advantage for short term connections.
Disclaimer: "The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions."
One of the basic limitation in MAC forwarding is that uLB and back-end servers should be in same subnet.
What should be done when you have a requirement to place back-end servers in another subnet.
Well recue is Tunneling!!!
Tunneling in required when you want uLB machine and back-end servers to be in different network.
This is equivalent to NAT/NATP forwaring method in Legacy Websphere Load Balancer.
Types of tunneling supported:
uLB support two types of tunneling.
1) IPIP ( IP in IP )
2) GRE ( Generic Routing Encapsulation )
Supported on AIX,Linux,HP-UX,Solaris but Windows.
You can follow configuration steps for tunneling under section "Use encapsulation forwarding to forward traffic across network
segments" in uLB admin guide
One of the most important thing to remember while configuration of uLB with tunneling is to disable reverse path filtering on back-end servers (ONLY).
Reverse path filter was introduced to support Strong Send and Receive. Which now most of the OSes have
as default setting. In Strong Send and Receive OS transmits outgoing packet only from the same interface from which
it has received it. In tunneling packets are received on tunnel interface but they go out from different
interface. Hence if RPF is enabled on back-end servers response will not be delivered to clients.
uLB logs,reports will be normal because it had handled the packet correctly.
Hence RPF disabling is the key to make uLB work with tunneling.
Disclaimer: ""The postings on this site are my own and don't necessarily represent IBM's positions, strategies or opinions.""