[caiu] [GTER] NE40 PBR

Evandro Alves evandroalves28 em gmail.com
Sáb Dez 7 01:39:07 -03 2019 

Olá pessoal.
Resolvi sair da toca e publicar o artigo que eu havia mencionado sobre a
configuração de PBR no NE40.
Segue o link para o artigo.

https://www.facebook.com/outsourceitnow/posts/434853920802173?__tn__=K-R

Desculpem a demora e obrigado pela paciência.



On Thu, Nov 21, 2019 at 11:06 AM Fábio Hernandes <fabio em hernandes.eti.br>
wrote:

> Tudo bem Evandro?
>
> Você por acaso já escreveu o artigo?
>
> --
> Fábio R. Hernandes
> Fone: (17) 99643 6715
>
>
> Em seg., 4 de nov. de 2019 às 12:42, Evandro Alves <
> evandroalves28 em gmail.com> escreveu:
>
>> Consegui fazer funcionar.
>> Vou escrever um artigo a respeito e passo pra galera.
>>
>> On Mon, Nov 4, 2019 at 12:27 PM Evandro Alves <evandroalves28 em gmail.com>
>> wrote:
>>
>> > 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 em 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 em 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 em 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.
>> >
>>
>>
>> --
>> Evandro Alves P.
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>
>

-- 
Evandro Alves P.

Mais detalhes sobre a lista de discussão caiu