[MASOCH-L] Navis Radius

Fri Dec 21 08:07:23 BRST 2007

Oi Alexandre.

Essa é a opção 2 que eu havia comentado e funciona sim. Mas não adianta ter
apenas um content-switch, hein. :-)

Indo mais a fundo, recomendo que você use o balanceamento por pacote. Ou
seja: cada pacote Radius, mesmo que seja proveniente de um mesmo PDSN, será
direcioniado para um Radius diferente.

Digo isso pois há políticas que fazem o balanceamento por fluxo (flow) e não
por pacote. O primeiro pacote de um determinado client (no caso, o PDSN) vai
para o primeiro servidor Radius. A partir de então, TODOS os demais pacotes
provenientes deste mesmo client são redirecionados para o mesmo servidor
Radius. Quando chega o primeiro pacote de um cilent diferente, um outro
servidor Radius pode ser escolhido (de acordo com a política) e ele receberá
TODOS os pacotes deste outro client. Ou seja: o balanceamento por fluxo faz
o balanceamento de "client/PDSN", não de carga/pacotes.

Isso pode gerar problemas no caso de balanceamento por fluxo pois, se você
tiver um número pequeno de PDSNs em relação ao número de servidores Radius
(Pigeon Hole Principle - Princípio da casa dos Pombos), ou se o número de
usuários de um PDSN for muito diferente do número de usuários nos outros
PDSNs, pode acontecer dos PDSNs que geram maior carga serem atendidos pelo
mesmo Radius. Ou seja: apesar de cada Radius atender o mesmo número de
PDSNs, haverá um Radius que receberá maior carga porque teve o "azar" de ser
escolhido para atender justamente os PDSNs com maior número de
usuários/carga.

E há mais considerações a serem feitas:

No balanceamento por fluxo, todos os pacotes de um determinado PDSN chegam
sermpre no mesmo servidor Radius. Isso facilita o troubleshooting. Se há
suspeita de mal-funcionamento de um determinado PDSN, basta fazer a coleta
de pacotes num único Radius. No caso de balanceamento por pacote, como os
pacotes deste PDSN chegam em TODOS os servidores Radius, é preciso fazer
coleta em todos esses Radius.

Além disso, dependendo do content switch utilizado, quando é feita a
configuração de balanceamento por pacote, não se permite que um determinado
PDSN seja apontado diretamente para um servidor Radius que se queira usar
para fazer teste. Isso porque, como o CS está fazendo balanceamento de
pacote, ele não guarda a informação de qual pacote de cada PDSN foi enviado
para qual servidor Radius. E, quando o servidor Radius responde, ele
simplesmente muda o source-IP para o IP Virtual e repassa para o PDSN. Ou
seja: mesmo que o PDSN consiga enviar o pacote para um determinado servidor
Radius, ele receberá a resposta do IP Virtual. E dependendo do client Radius
(PDSN), ele vai dropar o pacote.

[]'s
Ricardo

Em 21/12/07, Alexandre Gorges <algorges at gmail.com> escreveu:
>
> Obrigado Ricardo,
>
> eu não fui bem claro no meu primeiro email.
> a rede aqui funciona assim:
>
> o banco roda em openldap.
>
> as informacoes dos clientes sao replicadas em 4 servidores Sun usando a
> propria replicacao do openldap.
>
> o servidor master se encontra em um predio da empresa. e os 3 slaves estão
> hoje espalhados em outras localidades.
>
> Ou seja. hoje as informacoes dos clientes já estão com uma redundancia.
> estão replicados em servidores fora do predio e tal.
>
> nesses servidores roda tambem o navis radius, onde os PDSN da Nortel e UT
> autenticam os usuarios.
> toda a conexao ele joga os logs em um servidor sql para consulta.
>
> agora o que eu estava pensando era fazer um virtual server para que eu
> possa
> ter mais seguranca.
>
> ou seja
>
> nos PDSN ficaria configurado um ip do virtual-server e no switch eu iria
> fazer o virtual server para ficar via load-balance consultando os
> servidores.
>
> ex.
>
>
>                        virtual server 10.x.x.x
>                                      | |
>                                      | |
> ---------------  --------------    --------------- -----------------
> Servidor A     Servidor B     Servidor C    Servidor D
>
> assim penso eu, eu poderia acrescentar mais servidores se preciso ou caso
> algum servidor parar o switch iria jogar a consulta para outro servidor.
>
> O que você me diz?
>
> ----- Original Message -----
> From: "Ricardo Rodrigues" <rcr.listas at ig.com.br>
> To: "Mail Aid and Succor, On-line Comfort and Help"
> < masoch-l at eng.registro.br>
> Sent: Friday, December 21, 2007 9:02 AM
> Subject: Re: [MASOCH-L] Navis Radius
>
>
> Alexandre,
>
> o que você quer dizer exatamente com "forma mais segura"? Seria alta
> disponibilidade?
>
> Eu sugeriria duas opções:
> 1. Se o equipamento que você estiver usando para autenticar no Radius
> permitir, basta você pode configurá-lo para se autenticar nos vários
> servidores Radius. Dependendo do equipamento, ele permite que você use
> políticas de round-robin, master/backup, etc.
> Vantagem: baixo custo de implementação
> Desvantagem: alto custo de manutenção. A cada inserção/remoção de servidor
> Navis Radius na sua rede, você terá que alterar a configuração de todos os
>
> seus equipamentos. Se você tiver dezenas/centenas de equipamentos que se
> autenticam no Radius, essa solução provavelmente não te atenderá.
>
> 2. Adquirir um balanceador de carga, configurar um endereço IP virtual,
> aplicar a política de balanceamento desejada (master/backup, round-robin,
> hash, etc) e configurar seus equipamentos para enviarem os pacotes Radius
> para este endereço IP virtual. Ao receber os pacotes Radius, o balanceador
>
> os redireciona para os servidores Radius
> Vantagem: Menor custo de manutenção. A cada inserção/remoção de servidor
> Navis Radius, só é preciso alterar a configuração do balanceador de carga.
> Os equipamentos da rede continuarão enviando os pacotes Radius para o
> mesmo
> IP virtual.
> Desvantagem: Maior custo de implantação
>
> Obviamente, dependendo do tipo de rede e dos clientes, o custo adicional
> pela compra do(s) balanceador(es) será menor que o custo de manutenção da
> solução 1.
>
> Mais: não adianta ter vários servidores Radius se você tiver todos ligados
> num mesmo switch ou usando um único balanceador. Se o switch pifar, seus
> servidores Radius ficarão indisponíveis. É necessário criar uma
> infra-estrutura de alta disponibilidade de rede chegando até os
> servidores.
> Logo, os servidores devem ter ao menos duas placas de rede para se
> configurar alta disponibilidade neles também.
>
> Se precisar de mais informação, conte comigo.
>
> []'s
> Ricardo
>
> Em 20/12/07, Alexandre Gorges <algorges at gmail.com> escreveu:
> >
> > Alguém ai da lista usa o NavisRadius para autenticação dos usuários?
> >
> > Se alguém usa, eu gostaria de saber se é usado alguma solução de cluster
> > ou redundancia.
> >
> > Aqui na empresa existe 3 AAA NavisRadius. e estamos vendo para ano que
> vem
> > mudar para uma forma mais segura.
> > Aceito todas as sugestões.
> >
> > []´s
> > Alexandre
> > __
> > masoch-l list
> > https://eng.registro.br/mailman/listinfo/masoch-l
> >
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>
> __
> masoch-l list
> https://eng.registro.br/mailman/listinfo/masoch-l
>