Problemas Concentrador PPPoe + Radius

Senhores boa tarde,

estamos migrando nossa rede de bridge para OSPF, também visando a melhor utilização de nossos blocos de endereços estamos utilizando o pool de ip centralizado no Radius, porém estamos identificando alguns problemas.

1 - Tivemos alguns casos de clientes que autenticavam corretamente, pegavam um /32 valido, subia sua interface pppoe e sua rota tal rota era propagada pelo caminho que o cliente fazia até a borda porém o cliente não navega.

2 - Clientes que pegaram o mesmo ip /32 válido

Alguém tem alguma experiência com PPPoe + Radius + OSPF e identificaram algum problema?

desde já agradeço a atenção de todos.

Boa tarde julio

Implementamos em alguns clientes essa solução (concentrar os ips no Radius) em provedores que usam OSPF com nosso sistema Altarede System e não tivemos problemas.

Hoje inclusive migramos mais um provedor nesses moldes em Alagoas, se quiser pode fazer contato com nosso parceiro que implementou nesse cliente, George (82) 9165-9257 whatsapp ou no nosso skype altarede.sistemas.

Abraço.

Eder

Citação:

---

Postado originalmente por Arthur Bernardes

Tenho vários clientes trabalhando da mesma forma e não tenho problemas! Está usando qual sistema de Radius? Algum do mercado ou está utilizando FeeRadius?

---

Arthur, estamos trabalhando com FreeRadius mesmo não utilizamos nenhuma solução paga, somos dois analistas eu cuido do roteamento e um outro que cuida do Radius, porém ambos estamos procurando soluções para estes problemas, você recomenda alguma solução paga?

Obrigado Arthur!

Julio, tenho provedores com mais de 1000 clientes com OSPF e PPPoE na rede rodando sem problemas. Todos com mais de 15 MKs na rede.

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!).

No caso de OSPF para aproveitar o ASN é necessário aproveitar o Radius para distribuição dos IPs de forma dinâmica na rede toda.

O seu problema "1" não me parece ser algo do FreeRadius, pode ser algo de rotas mesmo.

Já o problema "2" me parece ser um problema de comunicação entre o MK e o servidor Radius.

O FreeRadius é extremamente simples e inteligente, tanto que é utilizado largamente em todo o mundo. Porém sua configuração é um pouco complexa.

O RadiusNet já tem um servidor radius completamente configurado, funcional e amplamente testado em redes com PPPoE e OSPF.

Caso queira instalar e testar basta seguir as instruções aqui.

Abraços
Fabricio

www.radius.net.br - Sistema de Gerenciamento para Provedores
www.vianatel.com.br - Licenças Anatel

Citação:

---

Postado originalmente por FabricioViana

Obrigado Arthur!

Julio, tenho provedores com mais de 1000 clientes com OSPF e PPPoE na rede rodando sem problemas. Todos com mais de 15 MKs na rede.

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!).

No caso de OSPF para aproveitar o ASN é necessário aproveitar o Radius para distribuição dos IPs de forma dinâmica na rede toda.

O seu problema "1" não me parece ser algo do FreeRadius, pode ser algo de rotas mesmo.

Já o problema "2" me parece ser um problema de comunicação entre o MK e o servidor Radius.

O FreeRadius é extremamente simples e inteligente, tanto que é utilizado largamente em todo o mundo. Porém sua configuração é um pouco complexa.

O RadiusNet já tem um servidor radius completamente configurado, funcional e amplamente testado em redes com PPPoE e OSPF.

Caso queira instalar e testar basta seguir as instruções aqui.

Abraços
Fabricio

www.radius.net.br - Sistema de Gerenciamento para Provedores
www.vianatel.com.br - Licenças Anatel

---

Salve Salve
@FabricioViana tudo tranquilo amigo ??
Então API funcionar perfeitamente com qualquer que seja o senário, assim como radius também funciona.
Afirmo sito porque tenho em pratica aqui no meu provedor rodando OSPF, e tenho vários clientes que também usam OSPF alguns com MPLS/VPS pois gostam de ter único concentrador, outros estão somente OSPF

Mais então qual a diferença de radius e API ??
Vamos de uma forma técnica o que seria o radius
O famoso Radius é uma sigla para Remote Authentication Dial In User Service ou seja é um protocolo de rede que provê de forma centralizada de autenticação o qual permite que diversos autenticadores possa fazer a requisição para um único local.Em uma forma mais simples o radius é um banco de dados que fica escutando as solicitações de quem pode se autenticar e se pode ele oferece alguns atributos a esta solicitação.
Vamos de uma forma técnica o que seria o API
A tal de API é uma sigla para Application Programming Interface é um conjunto de rotinas e padrões estabelecidos por um software para a utilização das suas funcionalidades por aplicativos que não pretendem envolver-se em detalhes da implementações do software, mas apenas usar seus serviços.De modo geral, a API é composta por uma série de funções acessíveis somente por programação e que permitem utilizar características do software menos evidentes ao utilizador tradicional. Em uma forma mais simples a API é um conjunto de códigos enviado para o software no caso mikrotik para se criar, alterar e excluir etc.. algo do próprio software, resumindo uma API para Mikrotik vai realizar tudo que o Winbox faz porem usando uma outra interface vamos como colocar como ex o FoxPanel quando vc cria um login pppoe no FoxPanel o mesmo vai enviar este conjunto de códigos para o mikrotik assim o mikrotik vai ler e executar a solicitação. é a mesma coisa que Winbox faz quando você vai criar um login pppoe (isto o Winbox é uma API do mikrotik assim como o aircontrol é da ubiquit etc...)

Então quando se afirma que API não é capaz de fazer tal solicitação, é a mesma coisa que você afirmar que o winbox tb não pode ou seja o próprio mikrotik , entenderam ao ponto que quero chegar ???
se o API e Winbox são a mesma coisa ambos somente faz o cadastro no mikrotik , porque somente a API não consegue ???? ambos são API !!!
No caso vamos usar o ex do OSPF:
se eu criar minha rede com OSPF e quiser usar apenas o Winbox pra cadastrar os login em pppoe não vai funcionar ???? pois winbox é a mesma coisa que API . Vou ter que usar radius ???? pergunto isto pois winbox vai cadastrar o login no mikrotik da mesma forma que API vai fazer.

Então ambos podem fazer tando Radius quanto API a diferença é que o com radius vai ficar concentrado em um único servidor
o qual tem seu PROS e CONTRAS o PROS todo munda sabe que fica todo centralizado o qual já se torna um Contra se o servidor com radius cair, queimar ou seja ficar off-line todos seus clientes vão ficar sem autenticação, uma coisa é fato é muito mais simples vc programar um sistema que utilize o radius este é um ponto forte pro radius vc só tem que alimentar o banco de dados, ja com API vc tem que alimentar o banco de dados e mais os concentradores deixando todos corretamente, isto é mais trabalhoso para o programador, porem se o servidor que fica a API der problema queimar explodir, todos seus clientes vão continuar se autenticando

Então qual é melhor ???
Isto é gosto e gosto não se discute , a uma teoria que radius é a melhor forma de autenticação, o qual pra mim vai continuar sendo teoria, pois até hoje não conseguiram me provar que radius é a melhor forma de autenticação



chega falei demais

Vale lembrar que isto não é discussão e nem ofensas, é o meu ponto de vista a respeito de radius e api nada contra ao @FabricioViana alias umas das pessoas mais serias que conheço é o fabricio

Abraços a Todos

Bom dia, entendo pouco de OSPF mais ultimamente venho estudando sobre o assunto, acredito que esteja faltando o NAT no router principal para a pool do cliente.

Olá Bruno tudo bem?

Eu gosto muito de trabalhar com API, não tem nada contra mesmo! Mas é que cada tecnologia tem sua limitação. No caso de API com OSPF, quando se quer utilizar para economizar IPs de um ASN penso que não dará certo, explico:

Vamos supor que você tenha 10 RBs internas, todas elas autenticando PPPoE. Sem OSPF você terá que colocar uma pool em cada RB e criar rotas estáticas para cada uma das 10 RBs. Vai funcionar.

Quando o provedor adquire um ASN, vamos supor, com 1024 IPS. Ele poderia, por exemplo, distribuir estaticamente esses IPs PÚBLICOS entre as 10 RBs: 128 IPs para uma RB, 64 para outra, 256 , etc..

O que acontece então? DISPERDÍCIO! Vamos supor que você tenha no máximo 50 clientes na RB1 e determinou 64 IPs para ela. Nesse caso 14 ficarão parados.

IPs custam CARO. O que o provedor faz então? Coloca OSPF! Com o OSPF não precisa criar rotas estáticas, tudo é dinâmico!

Um cliente autentica lá na RB1 e pega o IP 200.200.200.1. O cliente lá na RB7 autentica e pega o IP 200.200.200.2.... Veja, cada IP pode se conectar na ponta que os MKs criam as rotas automaticamente, aproveitando assim TODO o ASN, sem desperdício!

Para que isso funcione precisa ter um "cérebro" fora da rede, controlando as pools de IP. No caso do exemplo, cada RB no MK irá controlar somente suas pools, não irá gerenciar os IPs do ASN.

Esse "cérebro" é o servidor radius. O radius fica com a "tabelinha" de IPs e vai distribuindo de forma dinâmica, conforme chegam as requisições.

Dessa forma, resumindo:

API: É estático, você popula a secrets do PPPoE e/ou users do Hotspot e desliga. A partir daí o MK é que faz o trabalho.

Radius: É dinâmico. A cada requisição feita o Mikrotik joga isso para o radius que dará uma resposta que simplesmente o MK obedece e pronto.

No meu entender não faz sentido ter OSPF numa rede em que se usa SECRETS ou USERS, pois OSPF é para distribuir IPs dinamicamente e quando se usa secrets ou users o universo é somente uma RB.

Abraços
Fabricio

@Arthur Bernardes;
Mas esses ips quando estão via API, são enviados via API externamente?
Quem vai controlar essa distribuição?
Imagine que você tenha 2 concentradores PPPoE.. via radius ele entrega e não repete o IP.
Via API, se não tiver um equipamento só controlando essa entrega, vai duplicar IPs.
A distribuição de rotas vai continuar acontecendo e seu roteador de borda receberá 2 gateways para aquela rede /32.

Bom Dia a Todos @FabricioViana como falei em cima as possibilidades iguais, afinal a rota dinâmica quem oferece é o OSPF e não a forma de de autenticação seja ela radius ou o próprio Mikrotik

O que temos que entender é que:
Radius:
É um autenticador qual após validar o logins e senha fornece alguns atributos, estes atributos pré definidos e aceitos pelo Mikrotik.
O radius não ter poder pra entregar um atributo qual não seja suportado pelo Mikrotik, então o radius não faz milagre e não tira leite de pedra, embora eu não utilize o radius como autenticar eu acho fantástico a facilidade de programar um sistema que tenha como forma de autenticação o radius, porém não gosto da ideia que se a maquina que o radius ficar off-line eu pare de autenticar os clientes por isto escolhi fazer a autenticação direta no Mikrotik
Usando o Radius como autenticador:
O cliente ira fazer uma solicitação com informando usuário e senha para o mikrotik, no entanto como o mikrotik esta associado a um servidor radius ele não vai ter autoridade de permitir a conexão ou não, ele requisitara ao radius caso o radius autorize envia responder ao mikrotik pode permitir o login e forneça os seguinte atributos (ex: ip, gw etc).
Em uma Rede OSPF
Quando o cliente solicita a conexão o mikrotik envia ao radius o login e senha fornecido pelo cliente então o radius vai confrontar estes dados
caso o login e senha seja valido ele vai responder ao mikrotik que pode aceitar a conexão e vai informar tb os atributos neste caso fornece ao cliente o ip-remoto 200.200.200.2 e ip-local 200.200.200.2
(entregar o mesmo ip-remoto e mesmo ip-local é o que muitos que utilizam radius fazem salvo engano como é o caso do radiusnet, e já vi também alguns que entrega um ip-local diferente usando um ip privado se não me falha a memoria vi isto no gerenet ou vigo)

API:
É nada mais que uma forma de você fazer estes cadastro direto no mikrotik por uma outra interface vamos dizer mais amigável utilizando o próprio Mikrotik como autenticação. A API vai simplesmente cadastras o user, senha , ip-remoto, ip-local etc diretamente no Mikrotik
Usando o Mikrotik como autenticador:
O cliente ira fazer uma solicitação com informando usuário e senha para o mikrotik, no entanto como o Mikrotik é o próprio autenticador pois ele já tem todas informações já cadastrada pela API ele tem autoridade em responder se autoriza ou não a conexão fornecendo os atributos

Em uma rede OSPF
API, quando o cliente solicita a conexão com o mikrotik o próprio mikrotik vai confrontar o login e senha fornecido pelo cliente caso o login e senha seja valido ele vai oferecer ao cliente o ip-remoto 200.200.200.2 e ip-local 200.200.200.2


Então após entender que radius é um autenticador e api é apenas a forma de cadastrar os logins e senhas para que o próprio Mikrotik seja o autenticador, temos que concordar que:
Indiferentemente de API ou Radius vc vai usar o secrets, user, password a diferença a onde e quem vai ser responsável por aceitar ou não a solicitação.


quando você diz que na sua teoria "No meu entender não faz sentido ter OSPF numa rede em que se usa SECRETS ou USERS, pois OSPF é para distribuir IPs dinamicamente e quando se usa secrets ou users o universo é somente uma RB." ,
Eu não concordo com esta teoria , pois sabendo que a forma que o radius e api trabalha na autenticação são diferente porém o resultado é o mesmo então ambos funciona comprovadamente

Esta teoria teoria que API não funciona com rede OSPF não é valida afinal o mikrotik não iria desenvolver algo que funcione adequadamente apenas usando o radius como autenticador, caso ela tenha desenvolvido algo que funcione adequadamente apenas usando radius seria no mínimo seria coerente eles tornar isto publico pelo menos na wiki deles

Pessoal eu gosto de discutir uma teoria acho isto muito saudável.
Por isto deixo bem claro que não estamos discutindo sobre sistema de gerenciamento RadiusNet vs FoxPanel é apenas uma teoria de Radius, API e OSPF
A Qual eu tenho minha tese o Fabricio tem a dele, podemos nunca concordar, porem nunca vamos brigar :)

Citação:

---

Postado originalmente por klabundee

@Arthur Bernardes;
Mas esses ips quando estão via API, são enviados via API externamente?
Quem vai controlar essa distribuição?
Imagine que você tenha 2 concentradores PPPoE.. via radius ele entrega e não repete o IP.
Via API, se não tiver um equipamento só controlando essa entrega, vai duplicar IPs.
A distribuição de rotas vai continuar acontecendo e seu roteador de borda receberá 2 gateways para aquela rede /32.

---

Boa Tarde @klabundee
Ótima observação , porém ai vai caber o gerenciador desta API entendeu ???
a nossa discussão amigável é sobre a teoria que com API você não tenha um OSPF perfeitamente e adequadamente funcionando .
Já a sua observação é muito valida pois se for simplesmente cadastrar no mikrotik via api os ips não tomando as devidas precauções para que não haja duplicidade de ips etc, isto vai gerar um transtorno grande.
Da mesma forma ocorrete com o Radius se gravar no banco de dados do radius o mesmo ip para vários clientes ocorrera o mesmo transtorno da API

nesta sua observação já fica nos méritos ou falha de programação

@Bruno;
Sim, entendi.
Ocorreu algumas falhas desse tipo no nosso sistema, mas foram corrigidas..

Citação:

---

Postado originalmente por Arthur Bernardes

Nesse caso, o API tem que ter a capacidade de saber quando um IP está em uso ou não!

---

Sim.
Era essa minha dúvida.

Citação:

---

Postado originalmente por klabundee

@Arthur Bernardes;
Mas esses ips quando estão via API, são enviados via API externamente?
Quem vai controlar essa distribuição?
Imagine que você tenha 2 concentradores PPPoE.. via radius ele entrega e não repete o IP.
Via API, se não tiver um equipamento só controlando essa entrega, vai duplicar IPs.
A distribuição de rotas vai continuar acontecendo e seu roteador de borda receberá 2 gateways para aquela rede /32.

---

se utilizar o pool do mikrotik ai é um problema serio mesmo pois ele não vai controlar corretamente

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

Cara, essa parte do Marco Civil eu não entendo, mais com o OSPF + RADIUS é sim possível fazer isso, mais desde que você não tenha mais que 254 clientes ativos, se é que você não esta utilizando nenhum ip dessa range.

Citação:

---

Postado originalmente por FabricioViana

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!)."

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.

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

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.

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

O RadiusNet usa as duas coisas. Mas a autenticação por Radius é muito, mas muito, mas muito superior. A gente vê no dia a dia. Tanto é que eu nem falo que usamos API para autenticação, justamente porque não é o ideal.

Nem me lembro a última vez que parou um servidor de radius de um cliente!

Com a fibra ótica e cabo de rede cada vez mais na rua os provedores estão indo fortemente para a franquia, afinal o cliente com um cabo/fibra manda ver no download de torrent e a rede responde, não tem gargalo.

API controlando franquia é algo que não vi ainda... Tomara que saia qq hora!
Abraços
Fabricio

Nossa, nem sei porque tanta discussão.

Praticamente todos os provedores que eu conheço que já tem mais de um ano de vida rodam radius!!

basta ver aqui no Underlinux: Mkauth, Radiusnet, Myauth, não tem reclamacoes

tem um outro ai que usa ssh e api: toda semana tem reclamação!!

isso não é coincidência!!!

Citação:

---

Postado originalmente por FabricioViana

O RadiusNet usa as duas coisas. Mas a autenticação por Radius é muito, mas muito, mas muito superior. A gente vê no dia a dia. Tanto é que eu nem falo que usamos API para autenticação, justamente porque não é o ideal.

Nem me lembro a última vez que parou um servidor de radius de um cliente!

Com a fibra ótica e cabo de rede cada vez mais na rua os provedores estão indo fortemente para a franquia, afinal o cliente com um cabo/fibra manda ver no download de torrent e a rede responde, não tem gargalo.

API controlando franquia é algo que não vi ainda... Tomara que saia qq hora!
Abraços
Fabricio

---

Faço um convite a você então a usar o melhor sistema de Gerenciamento para provedores o FoxPanel
com ele é possível você ter o recurso de franquias, você pode acessar seus clientes mesmo com ip privado pelo próprio gerenciador sem precisar ficar fazendo dnat e lembrando de porta que tem libre entre muito outros recurso

"Nem me lembro a última vez que parou um servidor de radius de um cliente! "
quando se referimos ou radius ficar fora não é só pelo motivo de dar problemas no radius, pode ser por falha de hardware pode ser o mysql entre muitas coisas

mais posso afirmar que estes problemas ocorre tando que estou migrando um cliente que por coincidência é cliente da radiusnet
segundo esta enfrentando alguns problema com o radius

ok bruno, parabéns para você! Só hoje fiz 3 importações aqui. Sabe de qual sistema?

Não vou dizer nunca!

que você continue sendo sempre ético assim!

um grande abraço
Fabricio

Citação:

---

Postado originalmente por ustelecom

Nossa, nem sei porque tanta discussão.

Praticamente todos os provedores que eu conheço que já tem mais de um ano de vida rodam radius!!

basta ver aqui no Underlinux: Mkauth, Radiusnet, Myauth, não tem reclamacoes

tem um outro ai que usa ssh e api: toda semana tem reclamação!!

isso não é coincidência!!!

---

Amigo é uma discussão saudável e amigável por isto que falo o foco original era sobre o OSPF ser capais de rodar usando API porem o foco foi desviado
e concordo contigo muito tem problema com ssh e api , também muitos tem problemas com radius .
Alias sempre veremos pessoas com problemas com ssh, api, radius pois tenho contato com vários provedores uns nunca tiveram problemas com radius outros tiveram, tem provedores que tiveram problemas com api outros não

mais o intuito da discussão era outra nunca foi qual sistema é melhor com radius ou com api a teoria original é quando foi citado que OSPF não funciona com API porém como podemos ver esta a discussão esta se encaminhando para outro eu encero por aqui,
Em resumo a teoria apresentada pelo Fabrício que OSPF não funciona quando a forma de autenticar seja própria do mikrotik não é valida pois foi provado que funciona com experiencias dos próprios usuários aqui do under.
E deixando muito claro que a intensão da discussão nunca foi pra dizer que um sistema é melhor que outro tão pouco desmerecer o sistema do @FabricioViana o qual respeito muito como já mencionei pessoa integra, por isto não acredito que o Fabrício teve a pretensão de desfazer dos sistema que utilizam API com intuito de vender o seu sistema e sim apenas que defendeu uma teoria a qual não se pode aprovar não somente pela minha defesa mais como relatos dos próprios usuários aqui do Under
agradeço ao @FabricioViana e aos demais pelo tempo dedicado a este post foi um prazer estar este tempo com vocês aqui




Abraços a Todos

Nossa...

Citação:

---

Postado originalmente por FabricioViana

ok bruno, parabéns para você! Só hoje fiz 3 importações aqui. Sabe de qual sistema?

Não vou dizer nunca!

que você continue sendo sempre ético assim!

um grande abraço
Fabricio

---

Amigo não me leve a mal e nem como falta de ética esta não era minha intensão, assim como não levei como falta de ética ou intensão sua quando você afirmou que com sistema em API o OSPF não funcionaria após o Artur ter indicado 2 sistemas para o amigo acima o qual foi conveniente afinal um usa radius e outro API e claro que o seu não é o da API, sinceramente embora eu tivesse todos os motivos pra entender como no minimo falta de ética ou capacidade comercial pois teve que levantar uma teoria em que com API+OSPF não funcionaria uma teoria a qual não foi defendida somente mudada de foco
Realmente se em algum momento te ofendi ou faltei com ética perante a você ou outros membros do Under peço humildemente que me perdoe não foi esta intensão




Abraços

Agora fiquei curioso!

Tenho 1024 IPs (ASpróprio) e minha rede tem umas 13 routerboards autenticando todo mundo com pppoe. Só que tenho mais de 1024 clientes mas nunca tenho mais de 1024 online. Chega quase nisso!!!

Hoje resolvo com OSPF e um servidor freeradius versão 3 controlando as pools nele.

Como faria essas pools dinâmicas diretamente no mikrotik, controlando por ssh/api? alguém poderia explicar?

(por favor, se possível alguém que não seja bruno ou fabricio)

Não conheço nenhum provedor de verdade que utilize API, todos que conheço utilizam servidores Radius, com relação ao fato da rede parar por que o servidor queimou, deu algum problema, acho que este é um problema de projeto da infraestrutura e não do Radius, o correto seria ter dois servidores 1 principal e Backup, sincronizado, e com regra caso o primeiro caia, o segundo assuma.

Citação:

---

Postado originalmente por biohazzard

Não conheço nenhum provedor de verdade que utilize API, todos que conheço utilizam servidores Radius, com relação ao fato da rede parar por que o servidor queimou, deu algum problema, acho que este é um problema de projeto da infraestrutura e não do Radius, o correto seria ter dois servidores 1 principal e Backup, sincronizado, e com regra caso o primeiro caia, o segundo assuma.

---

Concordo contigo o problema dificilmente vai estar no radius 90% vai esta ma maquina (fonte, memoria, processador, placa mãe , HD) porém acaba afetando o radius ele vai deixar de fazer seu papel sem culpa mais vai deixar, quando vc trabalha direto no mikrotik as possibilidade de dar problema com maquina é menor a não que você use um x86 como concentrador ai os risco são iguais
mais radius é um protocolo fantástico tanto que é disponível em vários router mais ai vai do gosto
sobre provedores que utilize API, conheço vários, tem 1 em particular que tem quase 8 mil clientes e a rede dele esta toda em bridge

Abraços

Citação:

---

Postado originalmente por julioalmada

Senhores boa tarde,

estamos migrando nossa rede de bridge para OSPF, também visando a melhor utilização de nossos blocos de endereços estamos utilizando o pool de ip centralizado no Radius, porém estamos identificando alguns problemas.

1 - Tivemos alguns casos de clientes que autenticavam corretamente, pegavam um /32 valido, subia sua interface pppoe e sua rota tal rota era propagada pelo caminho que o cliente fazia até a borda porém o cliente não navega.

2 - Clientes que pegaram o mesmo ip /32 válido

Alguém tem alguma experiência com PPPoe + Radius + OSPF e identificaram algum problema?

desde já agradeço a atenção de todos.

---

Postei tanto coisa neste tópico que acabei esquecendo do principal objetivo que é tentar ajudar o amigo vamos la
no numero 1
o cliente chega até a borda e a borda chega até o cliente ???
você utiliza uma ou mais operadora ???
como você esta anunciando sua AS você anunciou ela inteira ou dividiu em subnet, pergunto isto porque estes dias um amigo meu sofreu mais ele tinha dividido em varias /24 e bem a que ele estava querendo usar ele não tinha anunciado

no numero 2 verifica no freeradius veja se o Framed-IP-Address duplicado ou o Framed-Pool com mais de 1 pool usando a mesma rage ex: pool1 200.200.200.2 -200.200.200.100 e a pool2 200.200.200.50 200.200.200.200 ai o 50 ao 100 vai se repetir

Citação:

---

Postado originalmente por TechMaycon

pois ta na hora de rever seus conceitos e lhe apresento eu, uso api e nao tenho problema algum, posso te mostrar mais uns 300 se quiser, a nao ser q o seu de verdade seja algo q eu desconheça...

---

@TechMaycon

Você poderia ver se algum desses 300 provedores usam OSPF com API de forma a reaproveitar IPs? Vou até descrever novamente o problema:

Tenho 1024 IPs (ASpróprio) e minha rede tem umas 13 routerboards autenticando todo mundo com pppoe. Só que tenho mais de 1024 clientes mas nunca tenho mais de 1024 online. Chega quase nisso!!!

Hoje resolvo com OSPF e um servidor freeradius versão 3 controlando as pools nele.

Como faria essas pools dinâmicas diretamente no mikrotik, controlando por ssh/api? alguém poderia explicar?

(por favor, se possível alguém que não seja bruno ou fabricio)

Valeu

Boa tarde senhores,

Então, api na verdade é algo que foi criado para aumentar a performance e não diminuir em todos os sistemas. Quem trabalha com programação sabe bem disso. A implantação de um código mal feito de api sim traz perda de funcionalidade e riscos na sua aplicação. Na verdade o radius é construido com base em apis, conexões com banco de dados tudo preestabelecido em apis diferentes, obviamente que as alterações nas utilizadas pelo radius não possuem divergencias no código central o que em novas atualizações do radius não provoca perda de acesso.

Apis do mikrotik são problematicas apenas quando existe alteração na linha de código base do sistema.

Em relação ao ospf, o mesmo só vai ser implantado com sucesso caso exista realmente uma distribuição através de radius, visto que o sistema de autenticação se torna intrisseco dentro do roteamento e regras de redundancias estabelecidas. Caso exista uma pool interna vai gerar um nat desnecessário ao qual o ospf tenta fugir pois é preparado para atender a outras demandas com outros protocolos.

Infelizmente API não server para controlar o pool de ips, pois ele ira colocar o ip fixo em secrets do mikrotik, ai esse ip fica amarrado a um cliente que não estara usando o ip. A solução é somente Radius interno na rede, infelizmente API não é a solução para redes grandes e que precisam de gerenciamento de ip centralizado. Hj temos mais 6 mil ips publicos e quase isso online, API nenhum daria conta de distribuir os ips corretamente para que todos os clientes peguem ip publico, pois ele fixa o ip em algum cliente e esse ip não estara disponivel caso o cliente não esteja online. Então, para os profissionais que precisam de centralizar o pool de ips, é somente por radius!!

API com OSPF funciona sim, mas não tem gerenciamento e (re)aproveitamento de IPs no caso de quem tem ASN.

Se você tiver ASN eu recomendo fortemente usar qualquer sistema que use RADIUS como autenticador.

Mas se você não tem ASN pode ir com os 2 que vai dar certo, mas se um dia precisar de ASN e tiver usando um sistema que usa API, corra desse sistema.

Outra coisa, API é ótimo, mas é muito mais trabalhoso programar em vista que no RADIUS você precisa só popular o BD com as informações, por isso eu acho que o Bruno deveria repensar seu sistema, se não for agora, mas um hora irá perceber que com API nem tudo é possível.

Citação:

---

Postado originalmente por diorges

API com OSPF funciona sim, mas não tem gerenciamento e (re)aproveitamento de IPs no caso de quem tem ASN.

Se você tiver ASN eu recomendo fortemente usar qualquer sistema que use RADIUS como autenticador.

Mas se você não tem ASN pode ir com os 2 que vai dar certo, mas se um dia precisar de ASN e tiver usando um sistema que usa API, corra desse sistema.

Outra coisa, API é ótimo, mas é muito mais trabalhoso programar em vista que no RADIUS você precisa só popular o BD com as informações, por isso eu acho que o Bruno deveria repensar seu sistema, se não for agora, mas um hora irá perceber que com API nem tudo é possível.

---

Amigo nem tudo que é mais facil é melhor
radius é só um protocolo de autenticação

Amigo eu tenho ASN tenho OSPF e uso API eu não consigo fazer gambiarra em usa 250 ips para 350 clientes
Como alguns falam que Radius é a solução para este problema, pra mim a solução é ter mais ips do que clientes
outra coisa se o provedor esta preocupado com custo do ipv4 etc. usa ip privado alias eu não vejo muita vantagem vc ter um ASN e distribuir ip dinâmico o cliente vai ter ip valido mais vai ter que usar um ddns pra poder acessar seu servidor ou até as câmeras de monitoramento da sua casa

Repensar ???? amigo Radius é só uma forma de autenticação com radius não é possível muita coisas ou seja todas as outras coisas a não ser autenticação


"Mas se você não tem ASN pode ir com os 2 que vai dar certo, mas se um dia precisar de ASN e tiver usando um sistema que usa API, corra desse sistema."

Amigo não faça uma afirmação desta , tu vai querer realmente levantar essa teoria ??? fundada em que ??? é serio ???
você afirmando que com API não pode ter um ASN tu vai afirmar que o próprio mikrotik não é capais de gerenciar um rede com ANS sem usar Radius ????

Mais vamos la vamos novamente discutir amigavelmente esta teoria
para continuarmos esta discussão

1ª pergunta :
qual sua ASN ?? afinal para poder fazer uma afirmação desta você deve ter um ASN correto ??? a minha é AS263011
caso você não tenha ASN a 2ª pergunta é :
Qual é seu know-how nesta área ???
3ª pergunta :
fundada em que tu pode defender sua tese que com API você não pode ter ANS onde alguns amigos já postaram que ha possibilidade, afinal o mikrotik não iria criar um produto que dependesse de ferramenta de terceiros ???



Abraços

opa encontrei rs... vc tem uma ASN 264130 1024 ips show de bola ai podemos continuar já que temos ASN podemos debater o seu know-how dever ser bacana visto que tu ja tem experiencia com ASN

sabe o que eu acho engraçado já que os amigos tem tanta experiencia com Radius porque não tenta ajudar o dono do tópico em vez de tentar descriminar o uso de API sendo ela uma ferramenta usada e homologada pelo próprio mikrotik.
Eu que não trabalho com radius tentei ajudar o amigo façam o mesmo


Eu queria que alguém me expliquei a vantagem do OSPF em uma rede em estrela
já que só existe uma unica rota

certo, paramos por aqui.
.....

@julioalmada se quiser entrar em contato comigo via inbox, posso ajudar você a resolver seu problema.

Citação:

---

Postado originalmente por TechMaycon

O pensamento de ter 200 clientes no radius e ter 100 IPs é igual ter 100mb de banda e vender 200, se VC tem asn tanto faz o protocolo q vai usar, VC é obrigado a ter mais do q vende...discussão besta...

---

Sabe de uma coisa você esta correto discussão besta !!!
como eu falei acima já que os amigos tem tanta experiencia com Radius porque não tenta ajudar o dono do tópico em vez de tentar descriminar o uso de API

eu não vou gastar meu teclado e perder meu tempo discutindo sobre isto mais não , afinal eles tem o direito de pensar assim, embora fazem umas afirmações sem nexo algum e pior alguns aciona os dedos pra digitar sem ligar o cérebro rs...

fui...
Abraços...

Citação:

---

Postado originalmente por diorges

Primeiro, desde quando temos que dizer nossas qualificações antes de querer discutir um tópico?

Segundo em que hora eu disse que não pode ter ASN quem usa API? Se você ler direito eu falei em outras palavras que não é viável, eu tenho certeza que lá não está escrito "se você usa API não pode ter ASN". Amigo você não leu direito o que eu escrevi e ainda interpretou de forma errônea.

Mas já que faz questão de saber meu know-how:

Sou Bacharel em Ciência da Computação, sou consultor Oficial MikroTik, tenho ASN, tenho Provedor, e também sou programador em PHP com enfase em MVC e atualmente trabalho com a framework Laravel 5, e posso afirmar que com certeza não é possivel gerenciar e (re)aproveitar IPs e distribuir de forma eficaz usando API. (coloquei em negrito pra dar enfase no que estou tentando dizer).

E estamos falando em redes roteadas, no caso, de autenticar os clientes nos POPs, cada POP deve ter sua faixa de IP e o OSPF irá fazer essa distribuição, se o provedor usa IP privado, não tem problema algum em usar API.

Imagine que você tem um bloco /22 e você possui 800 clientes distribuídos em 15 POPs, como será feita a distribuição de IP nessa rede sem ter desperdício? Como garantir que até os 1000 clientes todos vão ter um IP publico?

E claro usando API, fica ai minha duvida.

Amigo, entenda, não quis ser desrespeitoso em nenhum momento para você chegar com tanta agressividade, mas vamos conversar e chegar em uma conclusão amigável.

@julioalmada se quiser entrar em contato comigo via inbox, posso ajudar você a resolver seu problema.

---

"Primeiro, desde quando temos que dizer nossas qualificações antes de querer discutir um tópico"
você tem que ter conhecimento pra tentar defender sua tese baseado em sua teoria pelo menos quando eu foi defender o meu doutorado a bancada era composta por phd e não por acadêmico quando a sua teoria "não é possivel gerenciar e (re)aproveitar IPs e distribuir de forma eficaz usando API" Quantos aos termos gerenciar posso te afirmar que pode sim gerenciar perfeitamente usando API o termo reaproveitar IPs é aquela situação onde vc tem 250 ips e 350 clientes ??? e axa que isto é a forma correta ???
O que vocês tem que entender que radius é só uma forma de de autenticação gnt para com isto ,
quando vc afirma que API não pode fazer algo vc esta afirmando que o próprio mikrotik não pode

"Imagine que você tem um bloco /22 e você possui 800 clientes distribuídos em 15 POPs, como será feita a distribuição de IP nessa rede sem ter desperdício? Como garantir que até os 1000 clientes todos vão ter um IP publico? "

se você não pode imaginar eu consigo e sei como fazer isto usando API

"E claro usando API, fica ai minha duvida."
amigo se você tem duvida no minimo seria coerente você não fazer afirmações

eu sei que quando vcs falam de radius é por ele ser capaz de saber qual ip todos os concentradores estão usando isto torna ele eficiente eu sei disto e concordo com isto
agora vocês não podem afirmar que a api não possa fazer isto só pelo fato de vocês não ter conhecimento.
vou falar de uma maneira simples do gerenciador da API saber qual ip esta sendo em uso sendo eficiente com o radius ....
Simplesmente pelo log de cada concentrador, ou você nunca repararam que cada conexão pppoe que o mikrotik autentica ele informa qual ip foi atribuído ????

por isto que falou não façam afirmações sem nexo nem todo mundo é tapado pra ficar vendendo o peixe que compra
ai vcs acabam fazem afirmações erronia onde não vão poder defender sua tese pois ela esta sendo baseada em uma teoria invalida uma teoria de achometro


Abraços

Citação:

---

Postado originalmente por Arthur Bernardes

Eu vejo que uma coisa foi confundida nesse tópico, dá pra distribuir de forma dinâmica sim: usando "pool".
Mas como cada MK controla seu "pool", muitos provedores estão centralizando a autenticação em apenas um roteador.

---

ai vai do mérito do programado, assim como o radius vai centralizar e gerenciar o uso destes ips o gerenciador desta api tb tem que ser capaz de fazer o mesmo

Boa noite gente !!

Olha só, é um raciocínio lógico (coisa que todos nós usamos a muito tempo) e sem querer desmerecer ninguém, ao usar esse raciocínio mais que outros no dia a dia, desenvolvemos essa capacidade maior. (Estou citando nós, donos de provedores, programadores e etc.)

Concordo com o @Bruno quando diz que o Mikrotik não iria '''depender''' de terceiros para executar qualquer controle que seja a que ele foi designado. (raciocínio lógico)

Concordo com ele também, que os dois sistemas fazem a mesma coisa, porém de formas diferentes, agora, como a grande maioria das coisas, umas tem vantagens sobre as outras, e ai no final fica tudo meio que equilibrado.

Quando eu usava Rb1100 na rede, e ela estava chegando a 80% de processamento no horário de pico, não esperei muito, comprei uma cloud 1036 e não tive mais esse tipo de problema/preocupação. Sei também que ASN não está fácil, mas correr o risco de ficar sem ip's não vale a pena na minha concepção, e não pode ser usado como justificativa em uma discussão técnica como essa. O acúmulo de problemas no provedor inibe o seu crescimento, porque em tese ao invés de planejar o seu crescimento, suas energias estão voltadas para resolver problemas, então ''dar mole'' para problemas não faz parte de um empreendedorismo correto. (Então a justificativa de falta de ip's não pode ser colocada nesse diálogo, não faz sentido.)

As situações colocadas nesse tópico levam a diversas outras, mas o raciocínio lógico principal já foi dito, o mikrotik não iria criar um produto que dependesse de ferramenta de terceiros.

O raciocínio lógico aponta que o próprio WINBOX é um API.

Citação:

---

Postado originalmente por diorges

certo, paramos por aqui.
.....

@julioalmada se quiser entrar em contato comigo via inbox, posso ajudar você a resolver seu problema.

---

Amigo se você puder e quiser é claro ajudar o nosso amigo através do fórum seria muito interessante para todos membros aqui do under-linux afinal mais alguém pode passar por algo semelhante e ai já tem alguma documentação sobre o assunto , e também o principal intuito do fórum é compartilhar conhecimentos caso você queira compartilhar


Abraços