[BPF] RES: [GTER] NE40 PBR

Sábado Dezembro 7 14:08:01 -03 2019

Uma dúvida aqui da solução Evandro.

A configuração é aplicada no plano de encaminhamento geral da caixa, ou seja, não importa por qual interface o tráfego “entrar” ele será tratado pela ACl global.

Nesse caso, se no ambiente de rede do operador ele usar alguma sub rede pertencente a rede 100.64/10, por exemplo: algum servidor/serviço interno configurado dentro da sub-rede 100.100.0.0/24, ou até mesmo quando o operador tem diversos BNG na rede e não quer usar NAT para que um usuário do BNG A fale com o usuário do BNG B.
Esse tráfego de origem 100.100.0.0/24 entrando pela interface de uplink do roteador não vai conseguir alcançar os usuários PPPoE/IPoE. Ainda não encontrei como resolver essa situação no NE40 de forma simples, sem ter que criar N termos na ACL geral excluindo essas redes uma a uma.  Você avaliou esse cenário?

Seria bem mais fácil se aplicasse configurações de ACL nas interfaces virtuais criadas para os usuários PPPoE/IPoE.

De: bpf <bpf-bounces em listas.brasilpeeringforum.org> Em nome de Evandro Alves
Enviada em: sábado, 7 de dezembro de 2019 01:39
Para: Lista das indisponibilidades da Internet brasileira <caiu em eng.registro.br>; bpf em listas.brasilpeeringforum.org
Assunto: Re: [BPF] [GTER] NE40 PBR

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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<http://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.
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.brasilpeeringforum.org/pipermail/bpf/attachments/20191207/5f422de1/attachment-0001.html>