[FUG-BR] FreeBSD + 2 Links redundantes HA

[Patrick Tracanelli]

Alexandre Biancalana wrote:
> On 7/27/07, Patrick Tracanelli <eksffa em freebsdbrasil.com.br> wrote:
>>
>> Pessoa, esta havendo varios problemas de conceito ai na conversa. Como
>> voce vai saber se o link esta indisponivel? Pra isso é necessario
>> conhecer a outra ponta. E dada a caracteristica comercial e
>> provavelmente motivo pelo link adsl ser a escolha, obviamente num link
>> barato desse ninguem vai oferecer cooperacao/conhecimento do estado do
>> link entre as pontas.
> 
> 
> Concordo... uma coisa é HA, a outra eh utilização de dois links para
> saida....
> Mas com um mix das tecnologias faladas você consegue fazer bastante coisa.

Pois é, isso que quero ilustrar. Com scripts e algumas ferramentas se 
consegue o objetivo, porem nada que de pra dizer que "é nativo do 
FreeBSD" ou "nativo do Linux"... sao apenas scripts.

> 
> Entao eu pergunto, carp onde? Colocar carp na operadora e na ponta final
>> do adsl vai funcionar, sem duvida, mas entao vai la na operador por..
>> hehe. Entao carp nao resolve nada nesse cenario.
> 
> 
> Ninguem até agora falou em cooperação das operadoras... estamos falando nas
> alternativas a isso.

Exatamente, pra isso carp nao se aplica. Indicar cap na situação 
inicialmente proposta é um tiro no escuro recomendar pro amigo ;) E ele 
vais e frustrar.

> Temos basicamente 2 cenários balanceamento de saíde que ai sim Carp não é
> utilizado. Mas existe a situação em que você possa querer ter 2 gateways e 2
> links ai sim você usaria o carp para fazer o failover dos gateways.

Pois é. Cenário hipotético distinto do cenário que o amigo perguntou. Eu 
nao disse que o carp n serve pra nada hehe, ao contrario, carp é uma das 
melhores contribuicoes do OpenBSD pro mundo open source. Porem, pro 
cenario proposto, nao serve.

> 
> pf route-to tbm n resolve nada. Route do que pro que? Se o link cair nao
>> ha o retorno do pacote, se nao ha como voce retorna um pacote por um
>> link sendo que a rota do caminho de volta é outro?
> 
>     ipfw fwd, mesma coisa, fwd do pacote pra onde
> 
> Você pode ter um script checando o gateway default do adsl, se ele não
> responder você tira a regra de route-to deste link.

Muito bem, essa é a conclusao do meu e-mail anterior =)

>> trunk entao... pior ainda; vai fazer agregacao entre quem, e isso vai
>> ajudar no que?
> 
> 
> Nunca usei trunk, mas pelo que li..você pode agregar as interfaces de saída
> e da mesma forma acima ter um script que checa o gateway default em caso de
> queda, voce remove o link com problema do trunk.

Entao vamos entender:

"pegue uma interface que nao existe (virtual, kernel) e coloque um IP 
nela, e mande ela transmitir os pacotes pelas interfaces que existem, 
balanceando ou agregando e detectando falha em qualquer uma das 
interfaces reais".

O trunk faz isso. Mesma coisa que o ng_one2many, porem, mais facil e sem 
ter que aprender a "programar" nos netgraph. Entao ai chega a questao, 
que IP por no trunk0? do adsl1 ou do adsl2? ou nenhum? E ai nenhum tem 
que natear neh? Natear de quem pra quem sob que circunstancias?

Pois é, entao trunk nao ajuda em nada nesse caso, e no final, se for 
reescrever pacotes faz-se a mesma coisa sem precisar do trunking.

> 
> Quanto ao iproute2, do Linux, olha o nome... iproute2, pf route-to
>> (rotear para). Parece coincidencia os nomes? Nao. Eles fazem a mesma
>> coisa. Entao com Linux tbm fica no nivel da gambiarra. Entao seja com
>> Linux ou FreeBSD as opcoes sao as mesmas. E cada qual gambiarra mais que
>> o outro. No caso do FreeBSD as ferramentas sao intrisecas a ferramenta
>> de firewall. No Linux é independnete e voce tem que ficar fazendo
>> "mangle" e marcando pacotes pra saber "o que veio de onde vai por onde".
>>   Bem "xunxo".
> 
> 
> Não vejo como gabiarra... e sim uma alternativa de baixo custo... ninguém
> disse que é a solução ideal, mas dependendo dos requisitos funciona e
> atende.

Concordo, é uma alternativa muito valida na maioria dos casos. A 
"gambiarra" foi pra diferenciar o que seria ideal, e as soluoes onde os 
BSD se destacariam sobre Linux (carp, trunk, netgraph) infelizmente nao 
se aplicam pois dependem de um nivel de protocolo, seja formal, 
especificado em RFC, ou exclusivo de BSDs/nao-formal. Mas como isso 
depende de cooperacao da outra ponta, a solucao pra "se virar sozinho" é 
  essa... obviamente cheia de limitacoes, mas melhor do que nada sem 
duvida =)


> 
> 
>> Ja com NAT de entrada o natd, usando redirect_* com "dynamic yes" é em
>> modo LSNAT éc apaz de detectar se alguem do round-robin (LSNAT, RFC
>> 2391) ficar indisponivel e tirar ele do balanceamento. Pra isso o natd
>> fica acompanhando se recebe codigos smp de "host/net unreach". Ou seja,
>> so funciona localmente, e só pra entrada. Pra saida nao, que é o que
>> voce quer.
> 
> 
> isso eu não sabia ;-)
> -------------------------
> Histórico: http://www.fug.com.br/historico/html/freebsd/
> Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd


-- 
Patrick Tracanelli

FreeBSD Brasil LTDA.
(31) 3281-9633 / 3281-3547
316601 em sip.freebsdbrasil.com.br
http://www.freebsdbrasil.com.br
"Long live Hanin Elias, Kim Deal!"