[f-nsp] ServerIron XL not translating SLB response addresses?

[Clifton Royston]

  I recently picked up a ServerIron XL and put it onto a new network
I'm setting up, and then plugged in and configured a number of real
servers behind it and set up some virtual servers on it.

  When I try to connect to the virtual servers, it appears I'm seeing
quite different behavior in terms of packet rewriting than I see on my
other ServerIrons, which are essentially identically configured in what
I thought were the relevant respects.  Even though I have not
configured DSR, the responses from the real servers are not having
their source IP address rewritten as I think they should.

  The old ServerIrons and ServerIron XLs are running 7.1.21 or 7.1.08
(really old!) and the problem ServerIron XL was initially running
7.3.00, but I also booted it into 7.1.17 (from the secondary) and still
see the same behavior.

  Here's a config excerpt (names and addresses altered):

ver 07.3.00T12
no global-stp
!
!
!
!
server real real01 10.11.12.49
 port default disable
 port smtp
 port ssl
 port http
 port http url "HEAD /"
!
server real real02 10.11.12.50
 port default disable
 port http
 port http url "HEAD /"
 port ssl
 port smtp
!
...
server virtual virtual01 10.11.12.12
 sym-priority 100
 port default disable
 port smtp
 bind smtp real02 smtp real01 smtp
!
...

!
!
enable telnet password .....
enable super-user-password .....
enable port-config-password .....
enable read-only-password .....
hostname newxl
ip address 10.11.12.9 255.255.255.192
ip default-gateway 10.11.12.1
...

  As you can see, I've made the configuration as vanilla as possible.

  Here's a tcpdump from a client machine, again with names changed to
protect the innocent:

[client$ telnet virtual01.example.com smtp]

12:10:07.473353 client.example.net.49607 > virtual01.example.com.smtp:
S 3339122030:3339122030(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp 114
6543 0> (DF) [tos 0x10]
12:10:07.473356 real01.example.com.smtp > client.example.net.49607: S 3937
812647:3937812647(0) ack 3339122031 win 57344 <mss 1460,nop,wscale 0,nop,nop,tim
estamp 69348795 1146543> (DF)
12:10:07.473357 client.example.net.49607 > real01.example.com.smtp: R 3339
122031:3339122031(0) win 0
12:10:09.183449 client.example.net.49607 > virtual01.example.com.smtp:
S 3339122030:3339122030(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp 114
6546 0> (DF) [tos 0x10]
12:10:09.183450 real01.example.com.smtp > client.example.net.49607: S 4170
5827:41705827(0) ack 3339122031 win 57344 <mss 1460,nop,wscale 0,nop,nop,timesta
mp 69350505 1146546> (DF)
12:10:09.183451 client.example.net.49607 > real01.example.com.smtp: R 3339
122031:3339122031(0) win 0
12:10:13.183649 client.example.net.49607 > virtual01.example.com.smtp:
S 3339122030:3339122030(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp 114
6554 0> (DF) [tos 0x10]
12:10:13.183658 real02.example.com.smtp > client.example.net.49607: S 5
17189916:517189916(0) ack 3339122031 win 57344 <mss 1460,nop,wscale 0,nop,nop,ti
mestamp 71049339 1146554> (DF)
12:10:13.183659 client.example.net.49607 > real02.example.com.smtp: R 3
339122031:3339122031(0) win 0
12:10:21.184049 client.example.net.49607 > virtual01.example.com.smtp:
S 3339122030:3339122030(0) win 8192 <mss 1460,nop,wscale 0,nop,nop,timestamp 114
6570 0> (DF) [tos 0x10]
12:10:21.184051 real02.example.com.smtp > client.example.net.49607: S 2
177638732:2177638732(0) ack 3339122031 win 57344 <mss 1460,nop,wscale 0,nop,nop,
timestamp 71057341 1146570> (DF)
12:10:21.184052 client.example.net.49607 > real02.example.com.smtp: R 3
339122031:3339122031(0) win 0
 [etc.]

  You can see that the real server responses are not getting rewritten,
as if I'd specifically enabled DSR, but it's not enabled.  In fact, the
valid responses from the real server indicate that the initial
destination IP and MAC addresses are rewritten correctly by the
ServerIron to reach the real server.  The ethernet interfaces of the
real01 and real02 servers are physically plugged in directly to the
ServerIron, so there should be no possibility of their responses taking
an alternate path which does not pass through it for the standard SLB
address translation.  The problem occurs when connecting from clients
both within and outside the ServerIron and servers' subnets, both
directly connected to it and "upstream" of it as in this example.

  I'm baffled.  I've reread all the docs in the last couple days, and
those I have seem to say that it should absolutely be rewriting the
source IP address on these responses, as my past experience showed.  Am
I missing something obvious here?  My last resort is to enable the
virtual IP addresses on a loopback, explicitly turn on DSR, and hope
that works, but I am concerned that I've set up a network with a
critical piece of equipment which is behaving completely differently
from what the docs say and how I always thought it should work.

  Guru advice welcomed.
  -- Clifton

-- 
          Clifton Royston  --  cliftonr at tikitechnologies.com 
         Tiki Technologies Lead Programmer/Software Architect
Did you ever fly a kite in bed?  Did you ever walk with ten cats on your head?
  Did you ever milk this kind of cow?  Well we can do it.  We know how.
If you never did, you should.  These things are fun, and fun is good.
                                                                 -- Dr. Seuss