Re: Load balancing + NAT issue on BNT GBE 2-7 equipement

Oliver Adam <[email protected]> Thu, 22 Apr 2010 09:06:53 +0200
Newsgroups gmane.comp.programming.load-balancing.general
Message-ID <[email protected]>
--===============0433118017==
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<body>
Hi Javier,<br><br>
I do not agree here - Clement mentioned that the packet arriving at the
real server is coming from the virtual IP (VIP) and it is going to the
real IP (RIP). Most load balancer to use special NAT IPs to communication
with the real servers internally.<br><br>
Clement, <br><br>
do you have some more details related to the configuration? Are you using
so called proxy IPs? How is your configuration looking like? Do you mind
to share it?<br><br>
A standard source-NAT configuration would have pips configured<br><br>
/cfg/slb/pip/pip1 a.b.c.d<br>
/cfg/slb/pip/pip2 q.w.e.r<br><br>
These PIPs need to be reachable from the real server. Have a look at the
Application Guide to understand how the PIP selection is getting done.
You do not need both of them in case there is a single uplink port
only.<br><br>
On top of that it is necessary to have &quot;proxy enable&quot; at the
incoming port (the client facing external port of the L2-7
module):<br><br>
/cfg/slb/port EXT1/proxy ena<br><br>
Client processing is as well needed at this port:<br><br>
/cfg/slb/port EXT1/client ena<br><br>
This is pretty straight forward - does this fit to your
configuration?<br><br>
Best regards,<br><br>
<a name=3D"_MailAutoSig"></a>Oliver Adam<br>
Systems Engineer<br>
Blade Network Technologies<br>
<a href=3D"mailto:[email protected]">
[email protected]</a><br>
Cell: +49 173 993 2827 <br>
<a href=3D"http://www.bladenetwork.net">www.bladenetwork.net</a> <br><br>
<br><br>
At 00:23 20.04.2010, Javier Checa wrote:<br>
<blockquote type=3Dcite class=3Dcite cite=3D"">Hi Clement,<br><br>
NAT process for most load balancers use to work this way:<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Original packet at the outside
interface:<br>
Client IP (src) -&gt; External Interface Load Balancer VIP (dst)<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Translated packet at the
unside interface:<br>
Internal Load Balancer VIP (src) -&gt; Server (dst)<br><br>
However, if you can't fix this, try adding a host route like this
in&nbsp; <br>
the server:<br><br>
route add -host ExternalLoadBalancerIP gw InternalLoadBalancerIP<br><br>
Regards,<br>
-- <br>
Javier Checa<br>
Germinus XXI | Gesfor<br><br>
<br><br>
Cl=E9ment Gam=E9 &lt;[email protected]&gt; ha escrito:<br><br>
<blockquote type=3Dcite class=3Dcite cite=3D"">Hi guys,<br><br>
I've got troubles configuring an Hardware load-Balancer with NAT
functions.<br><br>
I have the following architecture:<br><br>
Internet =3D=3D=3D&gt; VIP (public) [Load Balancer] (private ip) =3D=3D=3D=
=3D&gt;
private<br>
addressed servers<br><br>
When a connection is initialised from the outside (internet) , the
LB<br>
correctly forwards the SYN packet to one of the private servers. But<br>
when these servers want to reply with a SYN/ACK there is a
problem.<br><br>
the SYN packet coming in the private servers has as ip header : VIP
=3D&gt;<br>
Private_server_Address<br><br>
The answer packet then logically has: Private_server_Address =3D&gt; VIP
,<br>
in its source =3D&gt; dest ip header<br><br>
But the private servers cannot reach VIP from their side (this is<br>
normal since it's nated), and then provide a correct reply.<br><br>
Have you guys any solution to correctly forward the packets back to
the<br>
LB, and make it process them correctly ?<br><br>
Note: The load balancer, which is the default gw for the servers,
also<br>
has a NAT rule for &quot;masquerading&quot; (actually more SNAT than
real<br>
masquerading)<br><br>
Regards,<br><br>
Cl=E9ment.<br><br>
_______________________________________________<br>
lb-l mailing list<br>
[email protected]<br>
<a href=3D"http://vegan.net/mailman/listinfo/lb-l" eudora=3D"autourl">
http://vegan.net/mailman/listinfo/lb-l</a><br>
Searchable Archive:
<a href=3D"http://vegan.net/lb/archive" eudora=3D"autourl">
http://vegan.net/lb/archive</a><br>
<a href=3D"http://lbdigest.com/" eudora=3D"autourl">http://lbdigest.com</a>
Load Balancing Digest<br>
<a href=3D"http://lbwiki.com/" eudora=3D"autourl">http://lbwiki.com</a> Load
Balancing Wiki</blockquote><br><br>
<br><br>
___________________________________________<br>
-Aviso legal-<br>
<a href=3D"http://webmail.grupogesfor.com/Aviso_legal" eudora=3D"autourl">
http://webmail.grupogesfor.com/Aviso_legal</a><br><br>
<br>
_______________________________________________<br>
lb-l mailing list<br>
[email protected]<br>
<a href=3D"http://vegan.net/mailman/listinfo/lb-l" eudora=3D"autourl">
http://vegan.net/mailman/listinfo/lb-l</a><br>
Searchable Archive:
<a href=3D"http://vegan.net/lb/archive" eudora=3D"autourl">
http://vegan.net/lb/archive</a><br>
<a href=3D"http://lbdigest.com/" eudora=3D"autourl">http://lbdigest.com</a>
Load Balancing Digest<br>
<a href=3D"http://lbwiki.com/" eudora=3D"autourl">http://lbwiki.com</a> Load
Balancing Wiki</blockquote></body>
<br>
</html>


--===============0433118017==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
lb-l mailing list
[email protected]
http://vegan.net/mailman/listinfo/lb-l
Searchable Archive: http://vegan.net/lb/archive
http://lbdigest.com Load Balancing Digest
http://lbwiki.com Load Balancing Wiki

--===============0433118017==--