Página 4 de 10 PrimeiroPrimeiro 123456789 ... ÚltimoÚltimo
+ Responder ao Tópico



  1. Citação Postado originalmente por FabricioViana Ver Post
    Olha só, resolve esse problema:

    Tenho 256 IPs públicos, 5 RBs autenticando clientes e 350 clientes totais no provedor.

    Porém conectados simultaneamente tenho 230 no máximo.

    Ou seja: tenho IPs públicos para atender quem está online, mas não tenho para todos do provedor. Não posso DESPERDIÇAR. Essa é uma situação muito comum hoje em dia!


    Com Radius + OSPF eu consigo dar IPs públicos para 100% dos clientes o tempo todo. No momento que um usuário desligar o outro pega o IP dele. Com isso eu facilito o log para o Marco Civil e mantenho a qualidade do meu provedor, POIS TODOS meus clientes terão IPs públicos no momento de sua navegação!

    Como saber quando e onde os usuários vão conectar, no caso de se usar API e ter que distribuir as conexões entre as 5 RBs?

    Fica aí meu questionamento para todo mundo!

    Abraços
    Fabricio
    Amigo desculpa a sinceridade mais se você tem 350 cliente você deve ter 351 não é por que tenho simultâneo 230 que posso usar com segurança um /24 não posso confiar este numero de cliente simultâneo pois o máximo será 350
    e acontece se 260 cliente se conectar ????
    então não podemos correr o risco de deixar o sistema com esta vulnerabilidade

    Mais nossa discussão amigável da teoria esta relacionada sua citação no post #6 logo acima
    "Salvo melhor juízo, acho que com API não dá para rodar OSPF. No caso de API teria que criar os PPPoE na secrets e colocar um IP para cada um ou usar a pool da própria RB, criando rotas estáticas (nessa matou o OSPF!)."

  2. Mikrotik é autônomo, como pode uma ferramenta (api) que apenas insere e ler o dados impedir ou fazer com que o OSPF não funcione ?
    tem nem logica né...
    E como bruno disse, e se conectar 255 clientes como fica ? Provedor não pode contar com a sorte, hoje todo mundo com roteador, pessoal deixa conectado 24 Horas.



  3. Olha, se conectar mais de 256 clientes vc pode passar uma POOL secundária no Radius!

    Veja, está tudo pensado no Radius!

    "Tenho 230 no máximo, mas se por acaso ocorrer alguma sobrecarga repassa alguns IPs privados. Quando essa sobrecarga passar volta ao normal!"

    "Ajuste técnico" é usar API para tudo!

    Radius é um protocolo descrito o na RFC que independe do equipamento, tal como o protocolo http. Imagina se tivesse o http do Firefox, da Microsoft, da Google, etc? Não iria para frente!

    Com radius, por exemplo, você pode usar Mikrotik, Ubiquiti (EdgeRoter), Cisco, Juniper, etc!

    Pode também fazer planos com franquia! É automático num servidor de radius contabilizar o tráfego!

    Usar API para isso, se é que tem como, é tentar reinventar a roda e fazer "ajuste técnico"!

    Outro problema do API: a pessoal do MK muda a linguagem do API sem avisar! Vou dar um exemplo: até uma determinada versão, para criar uma queue, tinha um longo comando cujo a opção "priority" era assim: "priority=8". A partir de uma versão que não me lembro qual passou a ser "priority=8/8" (uma para o download e outra para o upload).

    Quem fez update no MK ficou com scripts sem funcionar até que passassem a utilizar o novo formato! O que aconteceu até perceberem? OS CLIENTES FICARAM SEM QUEUE!!! Imagina! O cara contrata 1 mega e navega liberado!!

    Sabe quantas vezes o protocolo radius mudou?? NENHUMA!

    API é ótimo para pegar dados dentro do MK e fazer alguns ajustes! Por exemplo, mudar a velocidade num determinado horário (plano corujão), o API do MK é PERFEITO para isso! Trabalhar com IPxMAC, o API é PERFEITO! Fazer backup do equipamento API na cabeça!

    Nada disso o radius faz!

    Agora, falar que API é melhor que radius em se tratando de AUTENTICAÇÃO não dá para concordar!

    Eu humildemente penso que API é bom para coisas secundárias! Algo tão essencial como autenticação deve ser feito pela ferramenta apropriada!

    Abraços
    Fabricio

  4. Mais o RadiusNet usa ou não Api ?
    Acho as duas formas legais, mais no tem como uma pessoa em sam consciência preferir autentica seus clientes né 1 servidor externo do que internamente...
    O que você citou esta certíssimo, mais a primeira coisa que o bruno me disse foi isso, ele lia e gravava os dados, porém usava sua própria ferramenta como o POOL, que ele usa o do fox, e não o do Mk, mais mesmo que a api do fox pare, o pool continua rodando...
    Agora o que acontece se o servidor radius parar ? a rede não para, mais perde as pernas e os braços. quem é quem ? quem tem quantos mb ? ta pago ou ta devedor ?.
    Sobre a franquia, tudo e possível basta colher os logs...
    Sistema 100% radius existe ?, Não só para autenticar é obvio.



  5. Boa Tarde embora o foco esteja de desviando mais vamos la
    Eu não concordo também com em dizer que API é melhor que Radius tão menos que Radius é melhor que API como já falei ambas fazem suas funções de executam processos diferente mais o resultado é o mesmo porém temos que concordar que ambas são homologadas pela mikrotik

    eu respeito sua opinião que api seja bom para coisas segundarias e algo tão essencial como autenticação deve ser feito por ferramenta apropriada, mais não concordo que autenticação tem que ser feita pelo radius porém tanto o radius quanto api são apropriada, tando que ambas são homologadas pela mikrotik, pois não seria coerente a mikrotik disponibilizar uma forma de autenticação ineficiente

    Sobre a api o pessoal da mikrotik mudar algo dentro do mikrotik e o utilizador da api ter que reprogramar isto é um contra da API, mais o radius não fica livre deste problema pode ser que até hoje a mikrotik não mudou os atributos suportados por elas, pode ser que em uma nova versão ele altere algum tributo, e não vejo isto como falha tando da API ou do radius, simplesmente o dia que a mikrotik mudar o atributo User-Name todos que usam radius vão ter que se adequar, creio que isto não va acontecer pois eles seguem um padrão.
    Assim como temos o contra da api ter que se adequar com as mudanças feita pela mikrotik, a qual não é uma falha da API assim também temos o contra do radius deixar de autenticar os clientes na falha de comunicação entre o servidor radius com o mikrotik o qual também não é falha do radius

    ao afirmar que usar API para autenticar é o mesmo que reinventar a roda e fazer ajuste técnico (gambiarra)
    é o mesmo que você estar afirmando que o próprio mikrotik o qual homologou esta forma é ultrapassado e ineficiente
    e não é coerente afirmar isto
    Ou mesmo afirmar que usar API pra tudo é ajuste técnico (gambiarra ) esta afirmando que o mikrotik jaz ajuste técnico(gambiarra), seria no minio coerente enviar um email ou entrar em contato com a mikrotik e defender uma tese alegando que API não deve ser usado como autenticador somente Radius afinal API é ajuste técnico

    quando me referi ao termo ajuste técnico foi a respeito do provedor ter 350 cliente e usar como base um numero de conexões simultâneas ex: 230 dizer que com 254 ip vc vai atender todos com ip valido ai a matemática não bate pois o numero máximo de conexões simultâneas vai ser o todal de clientes neste caso 350, o provedor usar 254 ip validos para atender 350 clientes é um ajuste técnico (gambiarra) não estou julgando os provedores que assim trabalhe afinal IPV4 é caro, mais não deixa de ser a forma inadequada de se usar e pode causar vulnerabilidade no sistema como o radius vai passar uma range segundaria não posso te dizer se ha possibilidade ou não não quero fazer afirmações as quais não tenho como defender em tese


    E como esta discussão amigável saindo um pouco do foco inicial a qual é a citação no post 6 onde é referido uma teoria que OSPF não pode ser feita usando API

    Caso deseje continuar a discussão amigável da teoria original "citado no post 6 onde é referido uma teoria que OSPF não pode ser feita usando API "e não qual esta tomando outro rumo e desviado o foco
    Pois para mim que cheguei no entendimento que radius é um forma de autenticação e api é uma forma de alimentar o mikrotik para usar o próprio mikrotik como forma de autenticação e que ambos trabalham diferente porém tem o mesmo resultado e são homologadas pelo Mikrotik não vejo porque abrir uma discussão de qual é melhor ou qual é mais eficiente por 3 motivos
    1 ambos são homologados pela mikrotik
    2 gosto não se discute rs....
    3 pros e contra apos eu analizar vejo que ambas tem pros e contra porem eu decidi que o contra de qualquer problema no radius eu tenho mais clientes sem autenticação tem mais peso que o fato da mikrotik mudar alguma coisa na api (alias é por isto sempre uso em laboratório a ultima versão do mikrotik)


    Abraços






Tópicos Similares

  1. Problema Concentrador PPPoE
    Por evertonsoares no fórum Redes
    Respostas: 4
    Último Post: 16-04-2013, 13:40
  2. Problemas Com Pppoe + Radius
    Por tianguapontocom no fórum Servidores de Rede
    Respostas: 1
    Último Post: 19-03-2007, 23:39
  3. problemas com pppoe + radius + bandlimit
    Por cooperbr no fórum Redes
    Respostas: 13
    Último Post: 30-08-2005, 14:29
  4. PPPoe+Radius - problema em navegar
    Por aljaab no fórum Servidores de Rede
    Respostas: 7
    Último Post: 22-06-2005, 22:55
  5. Problemas Servidor PPPoe + Radius
    Por ondasbr no fórum Redes
    Respostas: 25
    Último Post: 14-10-2004, 16:35

Visite: BR-Linux ·  VivaOLinux ·  Dicas-L