[GTER] Configuração de strong x weak host model para servidores

Fri Oct 3 21:29:18 -03 2014

Fabiano,

Já fiz projeto com FabricPath, MPLS e OTV, infelizmente não é aplicável
neste cenário. A rede está montada e envolve serviços de datacenter de
terceiros. A solução precisa necessariamente usar os equipamentos
existentes.

Na verdade, essa envolvendo a configuração correta do host model nos
servidores é uma entre três opções. Postei aqui porque achei o tema
interessante, até pela pouca discussão, e queria ouvir as experiências do
grupo.

Carlos Ribeiro
Em 03/10/2014 20:35, "Fabiano Siqueira" <fabiano.siqueira at me.com> escreveu:

> Nesse caso poderia estar usando Cisco OTV, HP IVE ou VXLAN.
> Acredito que essas tecnologia são os melhores mundo para Data Center
> Interconnect (DCI).
>
> Fabiano Siqueira
>
> On 03/10/2014, at 17:03, Carlos Ribeiro <cribeiro at telbrax.com.br> wrote:
>
> > Douglas,
> >
> > Infelizmente, acredite em mim; não é questão de volume de tráfego. É um
> > ambiente de redundância legado e extremamente complicado, que eu não
> posso
> > redesenhar do zero.
> >
> > Resumindo, estou analisando possíveis melhorias para uma solução de alta
> > disponibilidade envolvendo sites redundantes em estados diferentes. Não
> dá
> > para usar agregação por causa disso. Os servidores podem estar rodando em
> > qualquer um dos datacenters, e podem acessados diretamente por clientes
> > externos por qualquer um links. Se eu usar solução L2, ou deixar com o
> weak
> > model, vou ter tráfego assimétrico; ou pior ainda, vou dar volta entre os
> > dois datacenters prejudicando a performance.
> >
> > Para ter maior controle de tráfego, e evitar o famoso "trombone" (tráfego
> > que entra um site, passeia no outro e volta para o site origem), estou
> > avaliando a possibilidade de fazer a solução de continuidade funcionar em
> > cima de L3.
> >
> > O uso de duas interfaces de rede em cada servidor, com IPs distintos, com
> > strong model, permite garantir maior controle sobre o roteamento com o
> > maior nível de disponibilidade possível. Em cima disso ainda tem monte de
> > coisa: DNS round robin, firewall de alta disponibilidade, storage
> > replicado, etc.
> >
> > Infelizmente não posso dar muito mais detalhes sem autorização cliente,
> mas
> > acreditem: não é um caso trivial :-)
> >
> > Carlos Ribeiro
> > Em 03/10/2014 16:28, "Douglas Fischer" <fischerdouglas at gmail.com>
> escreveu:
> >
> >> Na correria,
> >> confesso que lí muito rapidamente seu texto.
> >> Mas creio que a melhor forma de garantir que estejas usando o
> "StrongModel"
> >> é não ter duas interfaces de rede Layer3 em um mesmo servidor.
> >>
> >> Não consigo entender a função de um servidor operar em mais de uma rede.
> >> Para isso existem os roteadores...
> >> Use o servidor em uma rede só, e roteie o acesso a ele.
> >>
> >> "A demanda de trafego de rede é muito grande?"
> >> Use Link Aggregation, use Switch Router.
> >>
> >>
> >>
> >>
> >> Maaaaas, se realmente pretendes usar duas sub-redes distintas em um
> mesmo
> >> server.
> >> Sugiro que uses VRF nos servidores.
> >> Se não me engano, no linux o nome disso é network namespace.
> >>
> >>
> >>
> >> Em 3 de outubro de 2014 15:09, Carlos Ribeiro <cribeiro at telbrax.com.br>
> >> escreveu:
> >>
> >>> Prezados,
> >>>
> >>> Como parte de um trabalho para um cliente, estou pesquisando o suporte
> a
> >>> tipos diferentes de "host model" para servidores. É um tema
> interessante
> >> e
> >>> para o qual existe relativamente pouca informação e troca de
> experiência.
> >>>
> >>> Basicamente, em um servidor com várias interfaces, existem dois modos
> >>> primários de comunicação:
> >>>
> >>> - No "weak model" o servidor pode enviar e receber pacotes com o IP de
> >>> qualquer uma das interfaces existentes em todas as interfaces. Este é o
> >>> comportamento default do Linux e das versões antigas do Windows.
> >>>
> >>> - No "strong model" o servidor só pode receber (ou enviar) pacotes se o
> >> IP
> >>> de destino (ou origem) estiver na subrede correta para uma determinada
> >>> interface. Este é o comportamento default do BSD e das versões mais
> novas
> >>> (depois do Vista) do Windows.
> >>>
> >>> O problema é que muitos servidores operam com o "weak model" e podem
> >> criar
> >>> assimetria de tráfego, criando problemas com o firewall, por exemplo.
> >>>
> >>> Minhas perguntas no estilo "TLDR" são:
> >>>
> >>> 1) Alguém já precisou reconfigurar os servidores para mudar o modo de
> >>> operação da pilha TCP?
> >>>
> >>> 2) Em um ambiente híbrido, com servidores de diversos tipos (Windows
> >> 2003,
> >>> Windows 2008, Linux OpenSUSE e RedHat, etc.), há como garantir que
> todos
> >> os
> >>> servidores estejam usando obrigatoriamente o "strong model"? Seria essa
> >> uma
> >>> recomendação razoável?
> >>>
> >>> Agora para quem quiser detalhes... seguem mais comentários e
> explicações.
> >>>
> >>> ==========================================
> >>>
> >>> OBSERVAÇÃO IMPORTANTE
> >>>
> >>> O uso do "weak model" ou do "strong model" é uma propriedade da pilha
> TCP
> >>> de um sistema operacional, em alguns casos pode ser configurado, mas é
> um
> >>> comportamento intrínseco de cada host. A RFC1122 estabelece as
> definições
> >>> básicas para IPv4; a RFC3484 trata da extensão para IPv6, que segue
> >>> critérios semelhantes; e finalmente, a RFC6419 trata das "práticas
> >> atuais"
> >>> para cada sistema operacional.
> >>>
> >>> WEAK MODEL
> >>>
> >>> Para entender o impacto do "weak model", suponha a configuração:
> >>>
> >>> - Servidor Linux "genérico" (opera em 'weak mode' por default)
> >>> - eth0: 10.0.1.1/24
> >>> - eth1: 10.0.2.1/24
> >>>
> >>> Se o servidor estiver configurado em "weak mode", e um pacote destinado
> >> ao
> >>> IP 10.0.2.1 chegar na interface eth0, o mesmo será recebido e
> encaminhado
> >>> internamente para a interface lógica correta.
> >>>
> >>> No caso do recebimento de pacotes, este comportamento é necessário em
> >>> alguns casos mas deixa o sistema vulnerável, e neste caso pode ser
> >> aplicado
> >>> um filtro, que é configurado por default em algumas distribuições.
> >>>
> >>> No caso do envio de pacotes, o "weak model" é mais complicado e pode
> >> causar
> >>> problemas de tráfego assimétrico. Suponha o seguinte cenário:
> >>>
> >>> - eth0: 10.0.1.1/24
> >>> - eth1: 10.0.2.1/24
> >>> - servidor web configurado no endereço da eth1 (10.0.2.1:80)
> >>> - duas saídas para a Internet (ex: dois "upstreams" diferentes), um em
> >> cada
> >>> rede
> >>> - rota default para 10.0.1.254 (ou seja, o gateway fica na rede da
> eth0)
> >>>
> >>> Quando um cliente externo tentar acessar a página web, o servidor
> >>> provavelmente receberá os pacotes pela eth1. Porém, assumindo a
> >>> configuração default de "weak model", o pacote de resposta será enviado
> >>> pela eth0**, criando a assimetria. Essa assimetria nem sempre causa
> >>> impacto, mas em certos casos - por exemplo, se houver um firewall
> >> stateful
> >>> no caminho - irá quebrar as coisas.
> >>>
> >>> Obs: No caso do Linux, há um flag (SO_BINDTODEVICE) que força o envio
> dos
> >>> pacotes pela mesma interface onde o socket foi inicialmente aberto, que
> >>> "resolve" o problema. Mas eu não sei qual é a prática para servidores
> Web
> >>> hoje em dia, se é que existe uma; e além do mais, esse flag não é
> >> suportado
> >>> em outros OSs.
> >>>
> >>> STRONG MODEL
> >>>
> >>> No "strong model", se repetirmos o mesmo cenário do servidor web
> acima, o
> >>> pacote sempre sairá pela interface "certa", mesmo que a rota default
> >> esteja
> >>> configurada para a interface eth0. Não haverá assimetria de tráfego.
> >>>
> >>> CONFIGURAÇÕES DEFAULT
> >>>
> >>> - No Windows server 2003 e XP, o default é weak model.
> >>> - No Windows Vista para cima, e no Windows 2008 para cima, o default é
> >>> strong model, mas pode ser configurado como weak model.
> >>> - No BSD, o default é strong model.
> >>> - No Linux, o default é weak model, mas pode ser configurado como
> strong
> >>> model (apesar de ser difícil descobrir como :-/)
> >>>
> >>> *Carlos Ribeiro*
> >>> *Sócio*
> >>> Cel: +55 (31) 9303-3366
> >>> Tel: +55 (31) 3305-5620
> >>> Geral: +55 (31) 3305-5600
> >>> cribeiro at telbrax.com.br
> >>> www.telbrax.com.br
> >>> --
> >>> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >>
> >>
> >>
> >> --
> >> Douglas Fernando Fischer
> >> Engº de Controle e Automação
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
>
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>