Problema com LOAD BALANCE no Linux

rafaelgrinder
(usa openSUSE)

Enviado em 21/02/2016 - 17:56h

A questão é que quando defino uma regra p/ que o IP "X" vá para a tabela de "Load Balance" o host tem muita perca de pacote e não estabelece uma conexão...

esse é o cenário:
--------------------------------------
servidor VBOX:

eth0: 10.0.2.15/24 (NAT)
eth1: 192.168.5.150/24 (BRIDGE)
eth2: 172.16.0.1/28 (LAN)
eth3: 192.168.56.101/24 (host_only)

rota default = 10.0.2.2
gw rede bridge = 192.168.5.254
------------------------------------------
host CLIENTE:

IP: 172.16.0.2/28
------------------------------------------
ROTEAMENTO:

250 NAT
251 BRIDGE "conteúdo do /etc/iproute2/rt_tables"
50 LB


ip route add 10.0.2.0/24 dev eth0 src 10.0.2.15 table NAT
ip route add default via 10.0.2.2 dev eth0 table NAT
---
ip route add 192.168.5.0/24 dev eth1 src 192.168.5.150 table BRIDGE
ip route add default via 192.168.5.254 dev eth1 table BRIDGE
---
ip route add default scope global table LB nexthop dev eth0 via 10.0.2.2 weight 1 nexthop dev eth1 via 192.168.5.254 weight 1
---
POLÍTICAS DE ROTEAMENTO:

ip rule add from 10.0.2.15 table NAT
ip rule add from 192.168.5.150 table BRIDGE
ip rule add from 172.16.0.2 table LB (ESSA É A REGRA QUE CAUSA MUITA PERCA DE PACOTE!!!!!)
---
TABELAS:

NAT;

default via 10.0.2.2 dev eth0
10.0.2.0/24 dev eth0 scope link src 10.0.2.15

BRIDGE;

default via 192.168.5.254 dev eth1
192.168.5.0/24 dev eth1 scope link src 192.168.5.150

LB;

default
nexthop via 10.0.2.2 dev eth0 weight 1
nexthop via 192.168.5.254 dev eth1 weight 1

MAIN;

10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15
172.16.0.0/29 dev eth2 proto kernel scope link src 172.16.0.1
192.168.5.0/24 dev eth1 proto kernel scope link src 192.168.5.150
192.168.56.0/24 dev eth3 proto kernel scope link src 192.168.56.101

SarusKant
(usa CentOS)

Enviado em 22/02/2016 - 09:25h

Tente isso.
----------------------------------------------------------
$link1 = link1
$link2 = link2
$src_link1 = 192.168.1.10
$src_link2 = 192.168.2.10
$subnet_link1 = 192.168.1.0/24
$subnet_link2 = 192.168.2.0/24
$dev_link1 = eth0
$dev_link2 = eth1
$w_link1 = 1
$w_link2 = 1

----------------------------------------------------------------------------

echo "1" > /proc/sys/net/ipv4/ip_forward
echo "0" > /proc/sys/net/ipv4/conf/all/rp_filter
echo "1" > /proc/sys/net/ipv4/ip_dynaddr

----------------------------------------------------------------------------

ip route flush cache
ip route flush table $link1 cache
ip route flush table $link2 cache

ip rule add from $src_link1 table $link1
ip rule add from $src_link2 table $link2

ip route add $subnet_link1 table $link1
ip route add $subnet_link2 table $link2
ip route add default via $gw_link1 dev $dev_link1 table $link1 src $src_link1
ip route add default via $gw_link2 dev $dev_link2 table $link2 src $src_link2

ip route add default scope global nexthop via $gw_link1 dev $dev_link1 weight $w_link1 nexthop via $gw_link2 dev $dev_link2 weight $w_link2

-------------------------------------------------------------------------------

iptables -t nat -A POSTROUTING -j MASQUERADE

--------------------------------------------------------------------------------

--
Bruno Thomaz

rafaelgrinder
(usa openSUSE)

Enviado em 22/02/2016 - 23:45h

Ainda nada cara....

Configurei esses parâmetros que você me passou mas ainda continuo com muita perca de pacote

Consigo fazer o Load Balance no pfSense criando um "grupo de rotas", mas não sei o que está faltando no Linux
Caso descubra algo posto aqui a solução

Obrigado

SarusKant
(usa CentOS)

Enviado em 23/02/2016 - 09:43h

Estas perdas de pacote, são causadas para a internet ou para o servidor?

Cometi um erro nas regras que lhe passei acima, já corrigi, por favor tente as novamente.
Adicione somente 2 tabelas, não 3, somente as dos gateways

Qualquer duvida me add no Skype.

Skype: SarusKant

--
Bruno Thomaz

rafaelgrinder
(usa openSUSE)

Enviado em 23/02/2016 - 18:41h

Ainda a mesma situação...

A perca de pacotes ocorre quando realizo um teste para um ip fora da rede local, e não quando "pingo" para o servidor