[BPF] [GTER] NE40 PBR

Sábado Dezembro 7 19:04:32 -03 2019

Olá Tiago.
Eu pensei nas desvantagens desse método sim, porém a caixa não permite
aplicar a traffic policy nos virtual templates e não encontrei uma forma de
aplicar individualmente durante a criação da interface virtual do cliente.
Eu usei no exemplo a rede 100.64.0.0/10, mas em produção, possuo uma ACL
listando apenas as redes /24 que compoe o pool de ips privados que utilizo
para o CGNAT. É uma senhora lista, com 128 entradas, que no meu caso
utilizo um /24 público inteiro, com rateio de 64 clientes por ip público
(1000 portas por cliente).
Eu diria que para evitar cenários como os que você descreveu, seria ser tão
específico quanto possível nas ACLs e não utilizar as mesmas sub-redes
privadas de CGNAT em outras caixas, seja para CGNAT também ou para outro
serviço qualquer.

On Sat, Dec 7, 2019 at 3:39 PM André Luiz Rodrigues Dias <
andredias em hexanetworks.com.br> wrote:

> Também sou a favor do autor publicar esse artigo no BPF!
>
> Será de grande relevância para a comunidade.
>
> Att;
>
> André Dias
> HexaNetworks
> (17)99670-0482
>
>
>
> On 7 Dec 2019, at 11:36, Michael Henrique <mhamadeira em gmail.com> wrote:
>
> Bom dia!
>
> Parabéns pelo artigo, ficou excelente!!
>
> Att.
> Michael Henrique
> Cel.: (19) 99310-8201
>
> Em sáb, 7 de dez de 2019 01:39, Evandro Alves <evandroalves28 em gmail.com>
> escreveu:
>
>> 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.
>> _______________________________________________
>> bpf mailing list
>> bpf em listas.brasilpeeringforum.org
>> https://listas.brasilpeeringforum.org/mailman/listinfo/bpf
>>
> _______________________________________________
> bpf mailing list
> bpf em listas.brasilpeeringforum.org
> https://listas.brasilpeeringforum.org/mailman/listinfo/bpf
>
>
>

-- 
Evandro Alves P.
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.brasilpeeringforum.org/pipermail/bpf/attachments/20191207/9c2c1314/attachment-0001.html>