Mailing List Archive

Hi.

You don't always have to use source-nat just because the
real server is remote. You only need to do that if the
default traffic path from the remote server back to the
client does not pass through the serveriron. Source
natting just ensures that the return traffic from the
real server will pass back via the serveriron (where
it's un-natted - if there is such a word :)

If you can default route from the real server to the
serveriron via the intermediate router, or use PBR
or similar on the intermediate router, then you can
use remote server configuration and still allow the
client's IP address to be presented to the real server.


David
...


On 14/10/2004, at 11:44 PM, John Willingham wrote:

> Greetings,
>
> I am new to this list and have a few questions regarding
> foundry's ServerIronXL , specifically dealing with the SLB portion
> with regards to source-nat and remote servers. Basically the question
> is and I am already certain I have the answer, but am looking for
> confirmation from outside sources: "In a remote server environment
> (non-local to the SLB) with source-nat enabled, the requests and log
> entries are from the SLB, not the clients, in this setup is it
> possible to pass the client address to the servers NOT local to the
> SLB, and continue to work in a remote configuration.

[Cc'ed back to the list where this conversation started]

OK. The problem is that Vlan xyz's default (or learned) path
from the servers back to the clients obviously doesn't pass
back through the serveriron. The return packets must go back
via the SI or things just aren't going to work. The return
packet will have a source addr of the real server even though
the client sent the packet to the VIP.

Other than source natting, the only option is to force all
traffic from the reals (or the entire vlan xyz) to go back
via the serveriron. You could do one of the following :-

1. Route that vlan via the serveriron.

2. PBR traffic from that vlan and next-hop it to the serveriron.

3. If the router connecting to Vlan xyz is a Cisco you could put
the vlan xyz interface into a different VRF and define a default
route pointing to the serveriron.

In short, get the return packets to traverse the serveriron or
learn to live with source-nat. Not much else you can do.


David
...


On 15/10/2004, at 1:05 AM, John Willingham wrote:

> Here is a more accurate description of what I am attempting to
> accomplish.
>
>
> Vlan XXX has several ip addresses assigned to it:
> 10.18.99.1/25 (used for virtual servers)
> 10.18.100.0/24 (real)
> 10.18.102.0/25 (real)
>
> These work fine plugged in and acting as "real" servers or virtual.
>
>
> My problem is I have a vlan xyz that is not local to the Server Iron
> on addresses,
> 10.18.102.128/27 that are setup as "remote with source-nat" on the
> ServerIron, my problem is that because of the source-nat it appears in
> the log files to the web server as coming from the ServerIron's
> source-nat address. I need to get it so that it comes from the client
> without causing issues in the SLB, and preserve health checks if that
> is possible.
>
>
> If you need clarification I can send config snippets as well,
>
> Thanks,
> JW
>
>