[GTER] NE40 PBR

[Evandro Alves]

Bruno,  a ideia é fazer assim mesmo, mas de forma gradual.
De forma gradual, estamos forçando os clientes a utilizar preferencialmente
ipv6.
Mas como ainda carece de maturidade de IPV6 nas CPEs, ainda é gradual.

On Mon, Nov 4, 2019 at 1:49 PM Bruno Cabral <bruno at openline.com.br> wrote:

> Se me permite sugerir devia usar cgnat pra todos e usar o pool público
> para quem precisasse como por ex donos de câmeras que precisam de acesso
> externo
> ------------------------------
> *De:* gter <gter-bounces at eng.registro.br> em nome de Evandro Alves <
> evandroalves28 at gmail.com>
> *Enviado:* segunda-feira, 4 de novembro de 2019 11:27:38
> *Para:* Grupo de Trabalho de Engenharia e Operacao de Redes <
> gter at eng.registro.br>
> *Assunto:* Re: [GTER] NE40 PBR
>
> como vpn-instances não resolve, porque a ideia é a seguinte:
> tenho um pool de ips publicos que é limitado. Ele será preenchido primeiro.
> Assim que este pool estiver populado, os assinantes passarão a obter ip do
> pool de ips privados. Muda-se o pool de ips, mas o dominio, vpn-instance,
> são os mesmos.
> Para fazer via vpn-instance, teria que definir via radius que o usuário ou
> grupo de usuário utilizasse determinada vpn-instance, porém no meu cenário,
> não há diferença entre os usuários que obterão ip público e os que obterão
> ip privado. A única diferença é que "quem chega primeiro, pega ip público",
> e quem tem ip publico, vai tem uplink na interface X, e quem tem ip
> privado, vai na interface Y, para que seja feito o CGNAT em uma caixa
> externa.
>
>
> On Mon, Nov 4, 2019 at 12:21 PM Evandro Alves <evandroalves28 at gmail.com>
> wrote:
>
> > Tentei aplicar na interface de entrada também e não deu certo.
> > Tanto na GE0/3/13 quanto na GE0/3/13.2000 como inbound.
> > Tentei aplicar no escopo global também, mas só funciona como UCL. O
> > problema de UCL é que trata somente se a conexão pertence ao user-group
> > definido na UCL e no dominio, e os usuários se conectam usando o mesmo
> > domínio.
> >
> > On Mon, Nov 4, 2019 at 12:16 PM Joelson Vendramin via gter <
> > gter at eng.registro.br> wrote:
> >
> >> Evandro,
> >> Talvez o problema esteja em aplicar a traffic-policy na saída da
> >> interface. O roteador já deve ter processado os pacotes colocando o
> >> next-hop seguindo a tabela de roteamento. Portanto, o tráfego que você
> está
> >> tentando aplicar a PBR não vai aparecer na GigabitEthernet0/3/14.
> >>
> >> Tente mudar a lógica da sua policy para aplicar na (ou nas) interfaces
> >> onde o tráfego "entra" no roteador.
> >> De qualquer forma, se você puder fugir das PBRs e usar uma solução com
> >> vpn-instances, conforme o Tales sugeriu, seria bem melhor!
> >> Sds,
> >> --Joelson Vendramin
> >>
> >>     Em sexta-feira, 1 de novembro de 2019 21:39:28 BRT, Tales Rodarte <
> >> talesrodarte at gmail.com> escreveu:
> >>
> >>  Evandro,
> >>
> >> Não obtive sucesso ao realizar está configuração em alguns NE20 (aplicar
> >> o PBR baseado nas interfaces UPLINK) e tão pouco conseguir aplicar o PBR
> >> direto no template PPP.
> >>
> >> A forma mais simples de contornar isso é criar uma vpn-instance com rota
> >> default para o next-hop que deseja e colocar os PPP para usarem ela.
> >> O parâmetro da vpn-instance tu envia via radius.
> >>
> >> Outra forma que tem também é vincular a vpn-instance a POOLs diferentes
> >> e enviar o parametro de pool via radius  ou usar ucl-group.
> >> Mas nem todas as formas se encaixam na maioria dos ambientes de ISP.
> >>
> >> --
> >>
> >> Tales
> >>
> >>
> >> Em 01/11/2019 17:41, Evandro Alves escreveu:
> >> > estou com alguma dificuldade para configurar uma PBR no NE40.
> >> > O que preciso é trocar o next-hop de acordo com o ip de origem do
> pacote
> >> > para tráfego de saída para direcionar o tráfego dos clientes
> conectados
> >> com
> >> > ip de CGNAT para uma caixa externa.
> >> > segui a receitinha de bolo, mas não funciona.
> >> >
> >> > acl name from-temp-cgnat number 3100
> >> >
> >> > rule 64 permit ip source 100.64.0.0 0.63.255.255
> >> >
> >> >
> >> > traffic classifier TEMP-CGNAT operator or
> >> >
> >> > if-match acl 3100
> >> >
> >> >
> >> > traffic behavior TEMP-CGNAT
> >> >
> >> > redirect ip-nexthop 10.192.0.157
> >> >
> >> >
> >> > traffic policy TEMP-CGNAT
> >> >
> >> > share-mode
> >> >
> >> > classifier TEMP-CGNAT behavior TEMP-CGNAT precedence 1
> >> >
> >> >
> >> > interface GigabitEthernet0/3/4
> >> >
> >> > undo shutdown
> >> >
> >> > ip address <ip-de-enlace-uplink-padrão>
> >> >
> >> > traffic-policy TEMP-CGNAT outbound
> >> >
> >> >
> >> > interface GigabitEthernet0/3/14
> >> >
> >> > undo shutdown
> >> >
> >> > ip address 10.192.0.158 255.255.255.252
> >> >
> >> >
> >> > display ip routing-table 0.0.0.0 0
> >> >
> >> > Route Flags: R - relay, D - download to fib, T - to vpn-instance, B -
> >> black
> >> > hole route
> >> >
> >> >
> >>
> ------------------------------------------------------------------------------
> >> >
> >> > Routing Table : _public_
> >> >
> >> > Summary Count : 1
> >> >
> >> >
> >> >
> >> > Destination/Mask    Proto  Pre  Cost        Flags NextHop
> >> Interface
> >> >
> >> >
> >> >
> >> >          0.0.0.0/0  Static  60  0            D
> <ip-do-gateway-padrao>
> >> > GigabitEthernet0/3/4
> >> >
> >>
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >> --
> >> gter list    https://eng.registro.br/mailman/listinfo/gter
> >>
> >
> >
> > --
> > Evandro Alves P.
> >
>
>
> --
> Evandro Alves P.
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>


-- 
Evandro Alves P.