Alexandre Andrade wrote: > Olá, > > Ah isso realmente é verdade, mas o que na verdade eu queria saber é se > existia algo nativo pra ele entendeu, sem a necessidade de scripts e > tal. > O Cliente quer passar pra Linux com IPROUTE e tals, mas eu estou > lutando fortemente contra isso, mas preciso dar um jeito nessa > necessidade do fulano.
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. 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. 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 trunk entao... pior ainda; vai fazer agregacao entre quem, e isso vai ajudar no que? 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". Com ipfw fwd é tambem possivel. Mas se for nateado envolve um pouco mais de conhecimento com ipfw divert. Nesse caso como o Mario (M3) indicou, pesquise na lista sobre policy-routing, vao haver exemplos pronto, e use "prob" nas regras de divert de saida pra fazer o balanceamento. Com pf esse balanceamento voce faz com "round-robin" no route-to. Seja la como for, ate ai voce so tem, no maximo, balanceamento. Nesse caso aceitavel se os 2 links tiver o mesmo peso (mesma velocidade). Mas voce nao vai poder detectar se um caiu ou se esta congestionado, com as ferramentas. Vai ter "customizar a gambiarra" e fazer scripts. Sugiro usar o "nc" pra isso. É a forma gambiarrenta mais levinha e funcional. Se (e pode nao ser o caso) snmp for uma opção (alguns ADSL da CTBC Telecom tem SNMP na borda do cliente, pq eles fazem modem-a-modem. Se for telefonica, esquece), a gambiarra pode ser bem mais funcional. Portanto sjea com Linux ou FreeBSD, as possibilidades sao as mesmas e as limitações também. Nao ha justificativa tecnica entre escolher entre 1 e outro. No maximo ha justificativa operacional. Leia-se "simpatizar mais" ou achar um "mais facil" que outro, pra fazer a mesma coisa. 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. -- 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