|
Problem(Abstract) |
Client requests that result in large responses timeout if
the maximum transmit unit (MTU) is not set properly on the Load Balancer
machine. This can occur because Load Balancer defaults the MTU, rather
than negotiate it, for Dispatcher component's CBR and NAT forwarding
methods. |
|
|
|
Cause |
The MTU is set on each operating system based on the
communication media used; for example, Ethernet or Token-Ring. Routers
from the local segment might have a smaller MTU set if they connect to a
different type of communication media. Under normal TCP traffic, an MTU
negotiation occurs during the connection setup, and the smallest MTU is
used to send data between the machines.
Load Balancer does not support MTU negotiation for Dispatcher's CBR or NAT
forwarding method because it is actively involved as an endpoint for TCP
connections. For CBR and NAT forwarding, Load Balancer defaults the MTU
value to 1500. This is the typical MTU size for standard Ethernet, so most
customers do not need to adjust this setting. |
|
|
Resolving the
problem |
When using Dispatcher's CBR or NAT forwarding method, if
you have a router to the local segment that has a lower MTU, you must set
the MTU on the Load Balancer machine to match the lower MTU.
Use the following command to set the MTU value:
dscontrol e xm 32 <new_value>
For example:
dscontrol e xm 32 1400
You do not need to modify the MTU for Dispatcher's mac forwarding
method or any non-Dispatcher component of Load Balancer. |
|
|
|
|
Cross Reference information |
Segment |
Product |
Component |
Platform |
Version |
Edition |
Application Servers |
WebSphere Edge Server |
Load Balancer |
Multi-Platform |
Edge Server 2.0 GA, Edge Server 2.0 NLV, Edge Server 2.0.x |
|
Application Servers |
Runtimes for Java Technology |
Java SDK |
|
|
|
|
|
|