[BPF] [GTER] NE40 PBR

Evandro Alves evandroalves28 em gmail.com
Segunda Dezembro 9 13:38:20 -03 2019


Tiago
Me fizeram uma pergunta mais ou menos semelhante à sua... na verdade a
questão levantada foi diferente, mas a solução é a mesma. Eu já descobri
como tratar de forma efetiva, tanto o caso que você expôs, quanto o que o
outro camarada me questionou em privado. Vou publicar  uma atualização do
artigo ainda essa semana.
Iria publicar hoje, mas tenho uma migração para fazer durante a madrugada,
então estou com a cabeça em outra galáxia.

Atenciosamente

Evandro Alves

On Sat, Dec 7, 2019 at 7:04 PM Evandro Alves <evandroalves28 em gmail.com>
wrote:

> 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.
>


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


More information about the bpf mailing list