Alexandre Biancalana wrote: > On 7/27/07, Patrick Tracanelli <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" ------------------------- Histórico: http://www.fug.com.br/historico/html/freebsd/ Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd