[GTER] PBR HUAWEI NE20E-S2F

[Douglas Fischer]

Já tive um problema semelhante!

A solução que melhor resolveu nosso problema foi usar VRF no B-RAS.
 - Clientes com IP válido caiam num profile que estava num VRF que tinha a
rota default para o Agregador(Core como alguns chamam).
 - Clientes de CGNAT caiam num profile que estava num VRF que tinha a rota
default para a caixa de CGNAT, e rotas específicas(Rede interna do
provedor, etc) iam para o Agregador.
 - Tudo sempre através de protocolo de roteamento, pois usar rota estática
é foco de câncer na rede!
 - Para os dois casos, IPv6 só tinha rota para o Agregador(Core).

Em qui, 14 de fev de 2019 às 17:20, Bruno Vane <broonu at gmail.com> escreveu:

> Pessoal, esse é um assunto recorrente aqui na lista, alguns disseram que
> conseguiram e outros que ainda não, eu tenho uma caixa dessa (NE20E-S2F)
> recebendo clientes PPPoE com IPs públicos e com IPs privados de CGNAT. No
> momento, estamos enviando next-hop apontando para o A10 somente para
> clientes CGNAT via RADIUS (Huawei-Policy-Route) e os clientes com IP
> público tem o roteamento padrão da caixa.
>
> Agora surgiu a necessidade de não mais enviar os clientes CGNAT para o A10
> quando o destino for CDN (GGC,FNA e OCA), porém o envio do atributo
> Huawei-Policy-Route se sobrepõe ao roteamento da caixa e o cliente sempre
> vai no A10. Existe uma maneira de fazer essa PBR, para que clientes CGNAT
> não sejam encaminhados para o A10 quando o destino for CDN, direto na
> caixa?
>
> Tentei usar via traffic policy como vi aqui na lista, porém como a
> interface vlan do cliente (Ex. Eth-Trunk 1.2028) está bindada no Virtual
> Template de PPPoE, essa policy é ignorada, e não é possível aplicar a
> policy no VT.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


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