[GTER] Accounting dhcp mikrotik

[Paiva, Gilson de]

On Fri, 26 Jan 2018 at 15:54 NOC Provale <noc at provale.com.br> wrote:

> Bom dia, Xará.
>
> Aqui temos a mesma característica. Pesquisei já nas listas que participo
> (aqui no GTER inclusive) e sem grandes soluções.
>
> Depois de muito pesquisar, acabei desistindo de encontrar solução de
> accounting para esse cenário de DHCP Server Mikrotik com auth via Radius.
> Então, como me sugeriram aqui na lista na ocasião, acabei subindo um
> rsyslog numa máquina onde a CCR1036 que faz esse trabalho grava os logs
> de alocação de IP do DHCP, salvando tudo em banco de dados.
>
> Subi esse cenário no dia 05-09-2017, com lease time de 5 minutos por IP.
> Até o momento o banco de dados está com tamanho de 36 MB.
>
> Um parceiro nosso aqui na região usa solução com DHCP relay em switch e
> servidor Kea-DHCP, e daí nesse caso as alocações são registradas em
> banco de dados diretamente. Estou estudando implementar essa mesma
> solução aqui também.
>
> Att.,
>
> *_Bruno Santos_
> Operações de Rede*
> PROVALE TELECOM
> Tel: (12) 2131-4900
> http://www.provale.com.br/ <http://www.provale.com.br>
>
> Em 25/01/2018 10:00, Bruno Viviani escreveu:
> > Bom dia,
> >
> > Alguém sabe se é possível fazer accounting de IPs alocados por DHCP via
> > radius em mikrotik?
> >
> > Em testes aqui o IP é alocado, porém não existe um pacote acounting
> > retornando após isso...
> >
> > att,
> > Bruno Viviani
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter


Olá Bruno Santos,

Fizemos laboratório básico com o Kea como estudo para alternativa a PPPoE
ou o accel-ppp, para uso de roteamento em IPoE já que o mesmo, além da
integração nativa com banco de dados, também permite o uso dos "hooks" em
qualquer etapa da conversação DHCP entre estação e servidor...

O assunto é off-topic e o correto talvez seria discutí-lo em outra thread,
local / lista e, então, peço a licença para explicar nossa experiência e o
que tínhamos em mente para, caso você ou alguém se interesse...

Nossa idéia seria distribuir endereços /32 aos clientes ( conseguimos ) e
utilizar os "hooks" para execução de scripts shell alimentados com as (
ricas ) variáveis providas para encaminhar o tráfego dos clientes para
pipes ipfw ( em FreeBSD já que somos mais confortáveis com este, mas nada
impede de sê-lo em outros SOs / sistema de gerência de tráfego )...

A contabilização do tráfego seria dada com "ipfw show" na regra criada para
o cliente e a saída armazenada periodicamente ( 5 min ), ou em banco de
dados, ou diretamente para o rrdtool e, desta forma, teríamos o histórico /
gráfico do cliente para consulta e, quanto a contabilização da sessão,
lendo os dados do "ipfw show" no momento do hook do dhcp release.

Poderíamos ter dois, ou mais, servidores atendendo o mesmo domínio de
broadcast e, inclusive, com o cliente flutuando entre roteadores de maneira
transparente já que o endereço cedido poderia ser anunciado internamente
por protocolo de roteamento dinâmico. A próxima versão do ISC Kea promete
recursos de HA nativos, o que o torna ainda mais interessante.

Tudo estava indo bem até quando começamos a pensar no IPv6 e de como isso
escalaria, pensando em caixas para atendimento de, talvez, 8k clientes,
isso se tornaria possivelmente "fácil" de "quebrar" ou difícil de depurar,
exigindo reinicialização dessas leases e destruição de todo conjunto de
regras caso o "caos" se instalasse, o que é inaceitável com o nível de
criticidade envolvida, mesmo para acesso doméstico.

No cenário proposto RADIUS seria totalmente dispensável e o conjunto Kea /
Hooks / Banco de dados fariam todo o trabalho. A idéia é, ao cabo, simples
e, de certo modo, exequível.

Com os problemas de escalabilidade expostos, e como disse, tendo os testes
iniciais sendo bem sucedidos, ainda pensamos ser a idéia uma opção para
ambientes específicos ( como em empresas onde haja necessidade de
automatizar ações que possam ser disparadas pela conversação DHCP ) mas
que, para provedores, ainda encontra desafios no modelo por nós imaginados.

Caso tenha alguma proposta ou possa compartilhar sua experiência
ficaría-mos felizes de ouvi-lo,

Sem mais,