[f-nsp] SLB ServerIron XL Question

[David J. Hughes]

[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
>
>