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

Hi Oliver,

Today my issue is partially fixed.
I finally switched to DSR mode, by enabling direct access mode in the =

global SLB options, enabling NO-NAT in the virtual service options and =

adding the LB VIP to the loopback if on my balanced servers.

I Also had to make a very dirty trick to make it work: Since my balanced =

servers need a NAT rule for outgoing internet traffic and that this rule =

is incompatible with balanced return packets having VIP=3D>Client_IP as ip =

headers, i had to produce a first filter rule stating:

If source ip =3D=3D VIP , then goto dummy Rule with filter id 3 ( Filter =

Rule 2 being the outgoing traffic NAT rule , it is then bypassed if the =

packets coming back from the Balanced Server have VIP as source address)

I'm Pretty sure there is another , more efficient way to make this thing =

work , meaning:

Having  a  Virtual Server configuration  *+* a NAT rule on the same =

equipement in order to  make
the balanced servers still able to reach the net for other purposes than =

balancing.

Any help about how to remove this dirty "goto dummy" rule would be =

appreciated.

Regards,

Cl=E9ment.
 =


Oliver Adam wrote:
> Hi Javier,
>
> 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.
>
> Clement,
>
> 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?
>
> A standard source-NAT configuration would have pips configured
>
> /cfg/slb/pip/pip1 a.b.c.d
> /cfg/slb/pip/pip2 q.w.e.r
>
> 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.
>
> On top of that it is necessary to have "proxy enable" at the incoming =

> port (the client facing external port of the L2-7 module):
>
> /cfg/slb/port EXT1/proxy ena
>
> Client processing is as well needed at this port:
>
> /cfg/slb/port EXT1/client ena
>
> This is pretty straight forward - does this fit to your configuration?
>
> Best regards,
>
> Oliver Adam
> Systems Engineer
> Blade Network Technologies
> [email protected] <mailto:[email protected]>
> Cell: +49 173 993 2827
> www.bladenetwork.net <http://www.bladenetwork.net>
>
>
>
> At 00:23 20.04.2010, Javier Checa wrote:
>> Hi Clement,
>>
>> NAT process for most load balancers use to work this way:
>>
>>         Original packet at the outside interface:
>> Client IP (src) -> External Interface Load Balancer VIP (dst)
>>
>>         Translated packet at the unside interface:
>> Internal Load Balancer VIP (src) -> Server (dst)
>>
>> However, if you can't fix this, try adding a host route like this in =

>> the server:
>>
>> route add -host ExternalLoadBalancerIP gw InternalLoadBalancerIP
>>
>> Regards,
>> -- =

>> Javier Checa
>> Germinus XXI | Gesfor
>>
>>
>>
>> Cl=E9ment Gam=E9 <[email protected]> ha escrito:
>>
>>> Hi guys,
>>>
>>> I've got troubles configuring an Hardware load-Balancer with NAT =

>>> functions.
>>>
>>> I have the following architecture:
>>>
>>> Internet =3D=3D=3D> VIP (public) [Load Balancer] (private ip) =3D=3D=3D=
=3D> private
>>> addressed servers
>>>
>>> When a connection is initialised from the outside (internet) , the LB
>>> correctly forwards the SYN packet to one of the private servers. But
>>> when these servers want to reply with a SYN/ACK there is a problem.
>>>
>>> the SYN packet coming in the private servers has as ip header : VIP =3D>
>>> Private_server_Address
>>>
>>> The answer packet then logically has: Private_server_Address =3D> VIP ,
>>> in its source =3D> dest ip header
>>>
>>> But the private servers cannot reach VIP from their side (this is
>>> normal since it's nated), and then provide a correct reply.
>>>
>>> Have you guys any solution to correctly forward the packets back to the
>>> LB, and make it process them correctly ?
>>>
>>> Note: The load balancer, which is the default gw for the servers, also
>>> has a NAT rule for "masquerading" (actually more SNAT than real
>>> masquerading)
>>>
>>> Regards,
>>>
>>> Cl=E9ment.
>>>
>>> _______________________________________________
>>> lb-l mailing list
>>> [email protected]
>>> http://vegan.net/mailman/listinfo/lb-l
>>> Searchable Archive: http://vegan.net/lb/archive
>>> http://lbdigest.com <http://lbdigest.com/> Load Balancing Digest
>>> http://lbwiki.com <http://lbwiki.com/> Load Balancing Wiki
>>
>>
>>
>>
>> ___________________________________________
>> -Aviso legal-
>> http://webmail.grupogesfor.com/Aviso_legal
>>
>>
>> _______________________________________________
>> lb-l mailing list
>> [email protected]
>> http://vegan.net/mailman/listinfo/lb-l
>> Searchable Archive: http://vegan.net/lb/archive
>> http://lbdigest.com <http://lbdigest.com/> Load Balancing Digest
>> http://lbwiki.com <http://lbwiki.com/> Load Balancing Wiki
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
>   =


_______________________________________________
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