[BPF] Fwd: NE40 PBR

Terça Dezembro 10 08:50:52 -03 2019

Obrigado Humberto.

Tenho familiaridade com Wiki há bastante tempo, uso wikimedia para
documentação desde 2011 pelo menos.
Não tenho conhecimento das normas de publicação da comunidade BPF em si, e
afins.
Já tem estou atualizando o texto do artigo para incluir a resolução
cenários como os descritos pelo Tiago e também o cenário descrito pelo meu
amigo Roney que pode ser resolvido com a mesma técnica.

---------- Forwarded message ---------
From: Humberto Galiza <humbertogaliza em gmail.com>
Date: Tue, Dec 10, 2019 at 6:08 AM
Subject: Re: [BPF] [GTER] NE40 PBR
To: Evandro Alves <evandroalves28 em gmail.com>
Cc: Grupo de Trabalho de Engenharia e Operacao de Redes <
gter em eng.registro.br>, <bpf em listas.brasilpeeringforum.org>

Olá Evandro,

+1 parabéns pela iniciativa!

Aqui tem um guia sobre como escrever/publicar na wiki do BPF:
https://wiki.brasilpeeringforum.org/w/Como_Escrever_na_Wiki

Abs,

Humberto Galiza

On Mon, Dec 9, 2019 at 4:46 PM Evandro Alves <evandroalves28 em gmail.com>
wrote:

> André Luiz,
>
> Apesar de eu acompanhar com avidez o BPF, sinceramente ainda não faço
> ideia de como publicar algo lá.
> Tenho conta registrada na wiki de lá, mas não procurei saber como faz para
> de fato publicar algo.
> Posso tentar me informar quanto a isso por esses dias.
>
> On Mon, Dec 9, 2019 at 1:41 PM Evandro Alves <evandroalves28 em gmail.com>
> wrote:
>
>> André Luiz,
>>
>> Apesar de eu acompanhar com avidez o BPF, sinceramente ainda não faço
>> ideia de como publicar algo lá.
>> Tenho conta registrada na wiki de lá, mas não procurei saber como faz
>> para de fato publicar algo.
>> Posso tentar me informar quanto a isso por esses dias.
>>
>>
>> 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.
> _______________________________________________
> 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/20191210/d1756acf/attachment-0001.html>