<div>Yeah, from what you are describing, the problem is not the config.  In your case, what is happening is the real servers are responding back to each other directly.  To better illustrate, here is a quick packet walkthru. 

</div>

<div> </div>

<div>Original packet for flow setup</div>

<div>SourceIP (SIP)=RealServer1</div>

<div>DestIP (DIP)=VIP</div>

<div> </div>

<div>SI gets this, and changes to </div>

<div>SIP=RealServer1</div>

<div>DIP=RealServer2</div>

<div> </div>

<div>RealServer2 gets this, and responds appropriately, since its on the same vlan/L2 domain:<br>SIP=RealServer2</div>

<div>DIP=RealServer1</div>

<div> </div>

<div>If you have a L2 switch path that bypasses the ServerIron, it never sees this packet to do the reverse translation.  This in turn gets dropped by RealServer1, since it is expecting a reply from the VIP ip, not RS2.  Your options are to use DSR, Source-nat, or attach directly to the SI (or somehow ensure the SI is in both incoming and return path for traffic.)   One other option (though a little more complicated) is to use NAT for the real servers.

</div><span class="sg">

<div> </div>

<div>Mike<br><br> </div></span><br><br>

<div><span class="gmail_quote">On 1/22/07, <b class="gmail_sendername">Ryan DeBerry</b> <<a href="mailto:rdeberry@gmail.com">rdeberry@gmail.com</a>> wrote:</span>

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">What is the vlan configuration like?  You only have one VE? 

<div><span class="e" id="q_1104b2f4e3c69423_1"><br><br>

<div><span class="gmail_quote">On 1/22/07, <b class="gmail_sendername"><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://news.gmane.org/" target="_blank">news.gmane.org</a></b> <<a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:matthew.kirkland@uk.clara.net" target="_blank">

 matthew.kirkland@uk.clara.net</a>> wrote:</span> 

<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Hello I am having an issue with a load balancer config whereby the real  servers (smtp servers) cannot access the VIP that they are part of.

<br><br>The servers are able to ping the VIP but any connections to port 25 are<br>timed out.<br><br>The load balancer is running ip forwarding, with the VIP range and real <br>server range on the same VE.<br><br>Enabling "server source-nat" resolves this , but makes all the

connections on the servers appear to come from the load balancer alone. I need the real servers to be able to contact the VIP without  translation taking place. Does anyone know a solution to this problem ?

<br><br>Thanks<br>Matthew Kirkland<br>Claranet Network Engineering<br><br>_______________________________________________<br>foundry-nsp mailing list <br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:foundry-nsp@puck.nether.net" target="_blank">

foundry-nsp@puck.nether.net</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a>

<br></blockquote></div><br></span></div><br>_______________________________________________<br>foundry-nsp mailing list<br><a onclick="return top.js.OpenExtLink(window,event,this)" href="mailto:foundry-nsp@puck.nether.net">

foundry-nsp@puck.nether.net</a><br><a onclick="return top.js.OpenExtLink(window,event,this)" href="http://puck.nether.net/mailman/listinfo/foundry-nsp" target="_blank">http://puck.nether.net/mailman/listinfo/foundry-nsp</a>

<br><br><br></blockquote></div><br>