[GTER] CCR 1072-1G-8S+

Rubens Kuhl rubensk at gmail.com
Wed Nov 18 09:27:42 -02 2015


2015-11-16 11:14 GMT-02:00 Rôney Eduardo <roneyeduardosantos at gmail.com>:

> Em 14 de novembro de 2015 12:00, Rodrigo Pedrosa
> <rodrigopa.uepb at gmail.com> escreveu:
> > Foi isso que pensei. Dividir apenas um poll válido neles e inválidos em
> x86.
> > Obrigado.
> >
>
> Ou então deixar o pool inválido também nos Juniper/Cisco e fazer um
> next-hop para cima de um x86 fazer o NAT...
>

Isso é Policy-Routing, que já tira um tanto da performance também... menos
do que fazer NAT, mas já um bom tanto.

O que eu já usei foi colocar um x86 NAT como bridge; assim, a performance
dos roteadores é máxima. Mas por redundância e por performance, é bom ter
uma rota paralela sem NAT, algo assim:

Roteador 1 ------ x86 NAT ---- Roteador 2---- Internet
    +         +-----+---------------+        |
     |                                                |
     +----------------------------------------
Entre Roteador 1 e Roteador 2, duas adjacências OSPF, uma passando pelo NAT
e outra não. Os custos no Roteador 1 fazem com que todo o uplink passe pelo
NAT se a adjacência estiver de pé, e não passem caso contrário. Já os
custos no Roteador 2 fazem com que todo o tráfego não passe pelo NAT,
exceto se forem do pool de NAT. O tráfego da Internet para o pool de NAT
vai por uma interface dedicada entre o x86 NAT e o Roteador2 que não está
no forwarding path da bridge. O tráfego do NAT para os IPs privados também
vai por uma interface com o Roteador 1.

Na configuração do x86 NAT, ele tem que fazer NOTRACK tanto no tráfego da
adjacência OSPF quanto no tráfego que tiver IP público como origem, além de
não se meter em ethertype ARP, MPLS e IPv6.


Rubens



More information about the gter mailing list