[GTER] Roteamento CG-NAT

[Shine]

Douglas.

Essa questão do ponto de vista técnico é aberta na minha opinião. Existem
prós e contras.
Em caso de 1, eu vejo como vantagens:
- ip space overload: você pode usar o mesmo range de endereços IPv4 ou
integrar redes legadas com o mesmo subnet sem alterações drásticas como
mudar de range.
- convergência de tráfegos em um ponto único permitem uma visão mais
centrada do tráfego (nem sei se podemos considerar exatamente como uma
vantagem, isso pode ser discutível)
Acho que a maior desvantagem é a escala. NAT sempre é contabilizado e
limitado por fluxos, dificilmente um equipamento escala de graça nisso.
Se latência é caminho crítico, um caminho adicional L3 introduz mais um
tanto disso.

No caso de 2, além de não ter as vantagens e desvantagens de 1, temos que
considerar que a operação e o controle de redes indo "por fora/dentro" tem
que ser muito bem amarrada. Frequentemente, operações de exceção são
passíveis de erros humanos e corrigir normalmente toma tempo de pessoal
especializado. O ideal aqui seria ter um sistema orquestrado, mas
orquestrar demanda tempo e mão de obra considerável, dependendo do tamanho
da rede...
Pode ser que túneis sejam uma forma interessante de ter controle, mas mesmo
assim precisa avaliar a sua topologia para ser se aplica. Se tiver que
fazer vários a partir de vários pontos distintos pode virar mais um fator
de falha do que propriamente uma solução... fora que também introduz
overhead, pode consumir recursos de equipamentos.



Em 17 de junho de 2014 23:47, Douglas Fischer <fischerdouglas at gmail.com>
escreveu:

> Me surge uma dúvida acerca do roteamento nas redes que estão atrás de NAT.
>
> Em caso de comunicação inter-clientes que estão atrás de NAT, como
> proceder?
>
> Fazer com que essa comunicação ocorra toda nateada, ou seja:
> 1 - Da origem real, vai para o equipamento de NAT, faz o NAT da origem,
> vai para o IP válido do destino, faz o NAT do destino, vai para o destino
> real.
> Lembrando que origem e destino podem até estar no mesmo equipamento de NAT,
> ou inclusive ser o mesmo IP válido.
>
> 2 - Permitir que essa comunicação ocorra diretamente entre os IPs
> inválidos.
>        - O que nesse caso traria à tona problemas  de incompatibilidade das
> aplicações com NAT, além de criar um mundo isolado(AOL-style).
>
> O que as boas práticas rezam?
> Prós e contras?
>
> /*Android told-me that this text should be at bottom.*/
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter