[GTER] Hotspot centralizado

[Anderson Araújo]

Como o Paulo falou descentralização é a palavra chave, estou mudando a rede
daqui para pppoe, com centralização nas rb 1100 das erbs, mas isso só
quando não tenho equipamento mk mais perto do cliente final, autenticação e
accounting rodando no freeradius com loadbalance e failover em cima de
keepalived e mysql com replicação sincrona com o galera cluster. Mais outra
coisa, sem for pra fazer tunel, faça mpls/vpls que é mais rapido e gasta
menos cpu que bridge ou roteamento.

Att,

Anderson
Em 22/07/2012 18:59, "Paulo Henrique BSD Brasil" <paulo.rddck at bsd.com.br>
escreveu:

>
>
> Em 22/7/2012 17:58, Juliano Primavesi | KingHost escreveu:
>
>>
>> Tem como fazer como no LDAP, onde voce tem um cluster de autenticacao?
>>
>> Juliano
>>
>> Em 22/07/12 09:39, Bruno Cabral escreveu:
>>
>>> Nao ha problema em manter o hotspot (que é roteado) centralizado. Só
>>> em redes PPPoE é que voce precisaria de PPPoE-relay ou outro esquema
>>> para chegar na central
>>> !3runo Cabral
>>>
>>> --
>>> Cursos e Consultoria BGP em Mikrotik, Vyatta/JunOS e Quagga/IOS
>>> Novas turmas em http://www.cfide.com.br/**cursos/<http://www.cfide.com.br/cursos/>
>>>
>>>> Tenho uma rede todo em bridge onde todos os meus clientes autenticam
>>>> numa
>>>> RB de borda, gostaria que alguem me desse um opniao, pois gostaria de
>>>> rotear essa minha rede, mas gostaria de manter os clientes
>>>> autenticando na
>>>> minha RB  de borda, quel seria a melhor situção para fazer isto, ja
>>>> pensei
>>>> que crir tuneis para as rbs que estao na bridge, me ajundem ai a
>>>> encotrar
>>>> uma solução.
>>>>
>>>
>>> --
>>> gter list    https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>>>
>> --
>> gter list    https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>>
>
> Bom vamos lá, embora esse assunto já correu varias vezes aqui no GTER, é
> sempre bom para reclicar o conhecimento.
>
> Colocar vários equipamentos onde apenas gerencia a conexão e manter um
> servidor central com todos os dados de autenticação sobre uma base SQL
> permitirá além de resiliência na rede como um todo evitará pontos de falha
> únicos, visto que é muito mais viável colocar um servidor SQL redundante do
> que colocar vários router gerenciando além do usuário a conexão.
>
> O melhor que lhe garantirá isso será parecido com o esquema abaixo.
>
> SERVIDOR_BD_AUTH PRI--( PPPoE )--> RB1100(Segmento01)---(QoS)--->**Usuario
> ------|BBone|-------
> ------|BBone|-------
> ------||===========>(PPPoE)---**>RB1100(Segmento02)----(QoS)--**-->Usuario
> ------|BBone|-------
> ------|BBone|-------
> ------||===========>(PPPoE)---**>RB1100(Segmento03)----(QoS)--**-->Usuario
> ------|BBone|-------
> ------|BBone|-------
> ------||===========>(PPPoE)---**>RB1100(Segmento04)----(QoS)--**-->Usuario
> ------|BBone|-------
> ------|BBone|-------
> ------||===========>(PPPoE)---**>RB1100(Segmento04)----(QoS)--**-->Usuario
> ------|BBone|-------
> ------|BBone|-------
> SERVIDOR_BD_AUTH-RED--( PPPoE )--> RB1100(Segmento05)---(QoS)--->**Usuario
>
> Acredite qualquer rede onde será uma bridge entre usuário e base de
> autenticação é uma rede passível de falha catastrófica onde atingirá todos
> os usuários, além de ser mais cara e estará limitada a L2 qualquer controle
> em L3 ou superior será um problema.
>
> Fica ai o modo onde rede de provedor deveria seguir, manter o backbone
> separado da rede de acesso no mínimo em L3 nos dias atuais até por questão
> de segurança é requerimento.
>
> Att.
>
> --
> "Quando a Morte decide contar uma historia,
> A melhor ação que possa fazer é ouvi-la,
> e torcer por não ser a sua própria a tal história."
>
> Flames > /dev/null ( by Irado !! ).
> RIP Irado!
>
> Paulo Henrique.
> Analista de Sistemas / Programador
> BSDs Brasil.
> Genuine Unix/BSD User.
> Fone: (21) 9683-5433.
>
> --
> gter list    https://eng.registro.br/**mailman/listinfo/gter<https://eng.registro.br/mailman/listinfo/gter>
>