[GTER] NE40 PBR

Thu Nov 14 11:32:42 -03 2019

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)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://eng.registro.br/pipermail/gter/attachments/20191114/5c94e629/attachment.sig>