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.
Versão Imprimível
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 :)
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