[GTER] PPPoE B-RAS ignorar Cliente com base em Tabela

Alexandre J. Correa (Onda) alexandre at onda.net.br
Fri Jan 29 15:21:43 -02 2016


Passei o mesmo problema que o Diogo descreveu em sua 'história', 
conectava, mas demorava uns 5 segundos para funcionar.

Migramos para iBGP e passou a ser mais rápido inclusive baixou 10 a 15% 
de cpu.

Na borda CISCO.. e concentradores Mikrotik. Aposto um RIM que é 
implementação (diga-se arranjo técnico) do OSPF do RouterOS.


Em 29/01/2016 14:33, Elizandro Pacheco [ Pacheco Tecnologia ] escreveu:
> Também acho, exceto se o ospf dele fosse em nbma.
>
> Se não me engano, o Bruno utiliza bastante cenários assim ( com i BGP ), ele poderia nos brindar com um comparativo.
>
>
> Elizandro Pacheco
>
>
>> Em 29 de jan de 2016, à(s) 09:50, Fábio Hernandes <fabio at hernandes.eti.br> escreveu:
>>
>> Que estranho o BGP convergir mais rápido que o OSPF.
>>
>>
>> -- 
>> Fábio R. Hernandes
>> Fone: (17) 99643 6715
>>
>> Em 29 de janeiro de 2016 01:24, Alexandre J. Correa (Onda) <
>> alexandre at onda.net.br> escreveu:
>>
>>> Após um certo tempo estudando, migramos de OSPF para iBGP, justamente pelo
>>> mesmo sintoma, demora na instalação da rota. Com iBGP ficou muito mais
>>> rápido, mais simples .. menos recursos em uso.. principalmente quando um
>>> NAS cai...
>>>
>>> Usamos pool via radius
>>>
>>>
>>> Em 28/01/2016 09:20, Douglas Fischer escreveu:
>>>
>>>> O tema é recorrente por aqui.
>>>> PPP usando Pool Local ou Pelo Radius e a tabela de roteamento com muitas
>>>> rotas /32
>>>>
>>>>
>>>> CONTANDO ESTORINHA
>>>> ------------------
>>>>
>>>> Tenho um cliente que atendi há cerca de 18 meses.
>>>> Ele já vinha sofrendo com problemas de roteamento, e fazia pouco tempo que
>>>> havia migrado de B-RAS distribuídos nos POPs para centralizado passando
>>>> Vlans pelos enlaces.
>>>>
>>>> Apesar de ter amenizado os problemas, ainda estava sofrendo com lentidão
>>>> para iniciar a navegação do cliente.
>>>> Mexi daqui e dali... Conclusão era o OSPF e vários /32 que estavam
>>>> demorando para convergir.
>>>>
>>>> Na época, a solução que escolhemos foi fatiar a rede dele em duas seções:
>>>> - Pool Geral
>>>>    Atendido por 2 MK
>>>>    IP Atribuído pelo local Pool do MK
>>>> - Pool IP Fixos
>>>>    Atendido por 1 CCR
>>>>    IP Atribuído pelo Radius(Todos os Fixos estão dentro da mesma subrede)
>>>>
>>>> Se o cliente é de uso Geral, esta na Vlan X.
>>>> Se o cliente paga os pilas pelo IP FIXO, esta na Vlan Y.
>>>>
>>>>     Ele mesmo separou entre uma Vlan e outra com regras
>>>>     de Switch nas RBs dos POPs com base nos MACs dos clientes.
>>>>
>>>>
>>>> Com isso, a tabela de rotas virou 3 rotas redistribuídas pelo OSPF.
>>>>
>>>> Ficou tudo bem razoável...
>>>> - Funcionamento perfeito
>>>> - Com alguns pontos-únicos de falha conhecidos
>>>>
>>>>
>>>> O PROBLEMA ATUAL
>>>> ----------------
>>>> Ele disse que está ficando complicado de lidar com a questão das Vlans
>>>> para
>>>> IP Comum / IP Fixo.
>>>>
>>>> Então pensei em colocar todo mundo(IP Comum/Fixo) na mesma Vlan, e migrar
>>>> essas regras de Switch-MAC/Vlan para o equipamento imediatamente anterior
>>>> aos B-RAS.
>>>>     P.S.: Confesso que estou reticente em fazer isso.
>>>>
>>>> Aí fiquei pensando se não existe(como no DHCP) um jeito de filtrar para
>>>> quais MACs o serviço do PPPoE pode ou não dar a primeira resposta.
>>>> E logicamente fazer isso com base numa tabela centralizada(talvez o
>>>> radius).
>>>>
>>>>
>>>>
>>>>
>>>> E aí?
>>>> Alguma sugestão?
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>> Sds.
>>>
>>> Alexandre Jeronimo Correa
>>> Sócio-Administrador
>>>
>>> Office: +55 34 3351 3077
>>>
>>> Onda Internet
>>> www.onda.net.br
>>>
>>>
>>> --
>>> gter list    https://eng.registro.br/mailman/listinfo/gter
>>>
>> --
>> gter list    https://eng.registro.br/mailman/listinfo/gter
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter


-- 
Sds.

Alexandre Jeronimo Correa
Sócio-Administrador

Office: +55 34 3351 3077

Onda Internet
www.onda.net.br




More information about the gter mailing list