[GTER] NE40 PBR

Thu Nov 14 14:26:37 -03 2019

Um artigo sobre esse assunto no BPF será fantástico!

Att;

André Dias
HexaNetworks
(17)99670-0482

> On 14 Nov 2019, at 11:32, Gondim <gondim at linuxinfo.com.br> wrote:
> 
> Bom dia Evandro,
> 
> Posso te sugerir, já que vai escrever um artigo sobre isso, que seja no
> Brasil Peering Fórum [1]?
> 
> A comunidade agradece e sucesso!
> 
> [1] https://wiki.brasilpeeringforum.org/
> 
> Em 04/11/2019 12:47, Evandro Alves 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 at 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 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.
>>> 
>> 
> -- 
>  ⢀⣴⠾⠻⢶⣦⠀  Marcelo Gondim 
>  ⣾⠁⢠⠒⠀⣿⡁  Sysadmin - https://www.linuxinfo.com.br
>  ⢿⡄⠘⠷⠚⠋   DA04 922E 78B3 44A5 3C8D 23D0 8DB5 571E E151 4E19
>  ⠈⠳⣄⠀⠀⠀⠀  Logic will get you from A to B. Imagination will take you everywhere. (Albert Einstein)
> 
> 
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter