[GTER] Solução de Roteador - Otimização de WAN

[Douglas Fischer]

Sim!


Em 25 de agosto de 2014 10:49, Antonio Modesto <modesto at isimples.com.br>
escreveu:

>
>
> On 2014-08-23 1:52 pm, Patrick Tracanelli wrote:
>
> > On 08/23/14
> 07:49, Douglas Fischer wrote:
> >
> >> Antes de mais nada, vale lembrar que
> não tem mágica que reduza a latência do link. O que essas soluções de
> WAN optimization vão fazer e comprimir, suprimir, e cachear... E com a
> configuração certa, isso pode ser bem efetivo haja vista que uma das
> coisas que podes fazer com links de satélite é aumentar um pouco o MTU.
> Mas os pacotes ainda vão levar 600ms para chegar. Uma coisa que podes
> fazer é contratar(se houver) um link miudinho(dial-up ou gprs) só para
> passar dados sensíveis à latência(Ex.: Voip). /*Android told-me that
> this text should be at bottom.*/ Em 22/08/2014 17:40, "Douglas Fischer"
> <fischerdouglas at gmail.com> escreveu:
> >>
> >>> Não tenho experiência com
> soluções opnsorce até o momento, portanto não posso me posicionar sobre
> elas. Mas falando das soluções proprietárias, eu iria de SteelHead da
> Riverbed. A não ser que já use roteadores Cisco, então eu iria de Cisco
> WAAS. Cisco WAAS tem a vantagem de ser integrado ao Router, eliminando
> assim um ponto único de falha físico.
> >
> > Bom dia,
> >
> > De todas opcoes
> que usei, a melhor e' o Traffic Squeezer. Corra de WAN
> > Proxy, alem de
> ineficiente e' instavel, vai cair quando voce gerar uma
> > taxa mais alta
> de pacotes por segundo e seus usuarios vao te crucificar.
> >
> > O Traffic
> Squeezer nao chega a ser um Riverbed. Nesse ramo nao conheco
> > solucao
> livre melhor nem que se compare a essa solucao proprietaria. No
> >
> entanto gera condicoes de aumento de trafego muito interessantes.
> Tenho
> > por exemplo um circuito de 6Mbit/s trafegando a 10Mbit/s.
> Pendurado no
> > satelite creio que os recursos de caching e reassembly de
> pacotes com
> > base em dataseq ja existentes e cacheados que o Riverbed
> oferece serao
> > quase nulos -- existem, mas nunca pude comprovar sua
> eficiencia no
> > squeezer e nem creio muito nela, mas seu cenario sob
> satelite vai poder
> > tirar isso a limpo.
> >
> > Voce tem pacotes prontos
> compilados pra pfSense por exemplo entao subir
> > o cenario e voce fazer
> um PoC vai ser facilitado. Questao de pouco
> > tempo. Se seu trafego
> entre as pontas for essencialmente CIFS e HTTP
> > como e' comum entre
> cenarios matriz-filial/sede-comarca, pode esperar
> > grandes taxas de
> incremento de vazao.
> >
> > Outra possibilidade mais simples e usualmente
> mais estavel, mas que
> > tambem nao vai ajudar em nada a maior parte das
> limitacoes de
> > comunicacao por satelite, mas vai aumentar sua vazao
> total 'e compressao
> > de ethernet sob tunel IP. Basicamente voce pode
> fazer isso com qualquer
> > software de VPN, habilitando compressao mas
> sem habilitar cryptografia
> > caso seu interesse nao seja esse,
> amenizando payload e cpu na
> > criptografia e tirando proveito dos
> recursos de compressao que toda
> > solucao VPN oferece.
> >
> > Uma forma
> facil e que funciona em Linux e BSD e' o vtun. Uma solucao
> > FreeBSD e'
> criar um tunel gif(4) e fazer a comp e decomp com netgraph
> > deflate
> e/ou netgraph pred1 que implementam a RFC 1979 e RFC 1978
> >
> respectivamente. Nesse cenario tenho visto de 8% a 30% de compressao.
> >
> Unica e exclusivamente compressao.
> >
> > Depois que testar nao se esqueca
> de compartilhar com a lista suas
> > experiencias :-)
> >
> > Bicando o
> assunto aqui por curiosidade hehehe. Essa compreensão não deveria estar
> nas duas pontas?
> >
> > --
> > gter list
> https://eng.registro.br/mailman/listinfo/gter [1]
>
> --
>
>
>
>
> Links:
> ------
> [1] https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>



-- 
Douglas Fernando Fischer
Engº de Controle e Automação