Problemas Concentrador PPPoe + Radius

[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.

[ederzm]

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

[julioalmada]

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?

[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

[Bruno]

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

[newboy]

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.

[FabricioViana]

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

[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.

[Bruno]

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

[Bruno]

@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

[klabundee]

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

[klabundee]

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.

[Bruno]

@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

[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

[newboy]

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.

[Bruno]

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

[Fael]

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.

[FabricioViana]

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

[Fael]

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.

[Bruno]

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