PPoE - QoS Dinâmico e Individual

[AndrioPJ]

Como citei acima, cheguei a pesquisar esse assunto em vários locais, vi vários tópicos e videos, não cheguei a citar todos os fontes pq alguns acabei perdendo enquanto estudava o assunto (mas se quiser, posso editar o tópico inicial e adicionar seu video como fonte? pra mim n tem problema).

Me recordo de ter visto seu vídeo de demonstração (esse mesmo que vc postou ai), ele me deu umas ideias tbm.

De qualquer forma, me mandaram no privado (facebook) seu script e Acabei de analisar.... tem varias diferenças:
1- As variáveis não são as mesmas.
2 - nas suas regras de firewall, vc faz marcação em uma interface, e nesse script que postei faz marcação em outra interface.
3 - Seu script não verifica se o usuário possui burst ou não, nem adiciona nenhuma regra de burst.
4 - Seu script não faz a conversão do tempo recebido para um valor que o mikrotik aceite, alias, nem sequer menciona parte disso. Por exemplo, se o Burst Time do cliente é 80s, o script ao buscar esse dado, o mikrotik retorna o valor de 1m20... se pegar esse valor e adicionar a regra, dá erro.... Esse script que postei pega esse valor e converte de volta para 80.

PS: esse script postado aqui já está 2 versão atrás, tenho novas regras nele.

5 - No seu script, no firewall vc faz as mesmas marcações, uma para TCP e outra UDP, nesse que postei existe uma unica marcação para os dois.
6 - No seu script, vc nem menciona o bucket-size, no que postei, na regra Queue Tree Pai possui bucket-size = 0.20
7 - No seu script, se somar o valor do limit-at das regras filha dá igual a 100% do valor do max-limit da regra pai. No caso do script que postei, ele dá um pouco mais... pois qdo estava criando as regras, percebi que nem sempre todas as regras filha estão sendo usadas, logo, o limit-at das regras filha poderiam ser um pouco maior.
8 - Desconsiderando os comentários e as regras de debug do script, o seu tem no total 34 regras, o que postei aqui tem 37, e o Atual que uso (estou testando) tem 42.

@AdrianoPJ acho que deve, como você se propôs citar ele, já que lembra de ter usado. O cara foi infeliz na forma de expor principalmente em justificar. A inversão sua é válida. Eu ainda não tô usando, nem sei se vou, mas tô seguindo que gostei da iniciativa. Você expôs uma forma de fazer em cima de regras que todos tem acesso e conhecem, o que vai permitir colaboração pra sua melhoria.

Dizer que vai banir as receitas de bolo é ridículo. Seguindo a idéia da receita de bolo todos nós sabemos fazer bolo, conhecemos os ingredientes, mas as vezes pegamos na receita dos outros a dica da pitada de sal o pulinho que faz toda a diferença. Agora pode alguém pegar a receita e se queimar no forno, falta de prática e conhecimento mínimo. Culpa de quem escreveu a receita, dela existir?
Por isso a partir de agora só admitirmemos comer de cozinheiros formados.

Opa, vou editar o tópico inicial e adicionar o vídeo dele.

[MaxSolucao]

O cara quis foi fazer uma propaganda do curso dele aki.
Isso foi pura jogada de marketing.

[killerwollf]

AndrioPJ pretende postar este novo que esta testando tbm?

[AndrioPJ]

AndrioPJ pretende postar este novo que esta testando tbm?

Sim,
Coloquei ele em apenas um dos concentradores, ainda não tive um feedback se continua a mesma coisa, ou se piorou/melhorou algo.
E como não tive tempo para colocar no concentrador da minha casa, ainda não consegui testar.

O que foi feito de diferente nessa nova versão do script?
Apesar da primeira regra abranger pacotes pequenos (entre eles o ping), basicamente o que fiz foi adicionar mais algumas marcações/queue para ping e outros serviços importantes (como voip, dns, etc...), para que eles tenham uma prioridade diferente das demais e não seja afetado mesmo qdo o cliente está "apenas" navegando.

Pois notei o seguinte:
Em uma casa com muitas pessoas, mesmo que estejam apenas navegando na internet (sem fazer download ou assistir video), o consumo de banda acaba sempre atingindo os 100% por longos períodos (a regra Queue tree usada fica sempre na primeira em 100% de uso), ai o ping (ou outros serviços importantes como voip, dns) acabam oscilando/sendo prejudicados, pois tem que concorrer com o restante do trafego.

Depois que tiver testado e chegado a um script bacana, vou começar a estudar melhor o script para ver se consigo diminuir a quantidade de regras sem afetar o resultado final.

[killerwollf]

Parece promissor, Boa sorte!

[EvertonMachado]

Sim,
Coloquei ele em apenas um dos concentradores, ainda não tive um feedback se continua a mesma coisa, ou se piorou/melhorou algo.
E como não tive tempo para colocar no concentrador da minha casa, ainda não consegui testar.

O que foi feito de diferente nessa nova versão do script?
Apesar da primeira regra abranger pacotes pequenos (entre eles o ping), basicamente o que fiz foi adicionar mais algumas marcações/queue para ping e outros serviços importantes (como voip, dns, etc...), para que eles tenham uma prioridade diferente das demais e não seja afetado mesmo qdo o cliente está "apenas" navegando.

Pois notei o seguinte:
Em uma casa com muitas pessoas, mesmo que estejam apenas navegando na internet (sem fazer download ou assistir video), o consumo de banda acaba sempre atingindo os 100% por longos períodos (a regra Queue tree usada fica sempre na primeira em 100% de uso), ai o ping (ou outros serviços importantes como voip, dns) acabam oscilando/sendo prejudicados, pois tem que concorrer com o restante do trafego.

Depois que tiver testado e chegado a um script bacana, vou começar a estudar melhor o script para ver se consigo diminuir a quantidade de regras sem afetar o resultado final.

AndrioPJ...você esta de parabéns pela dedicação e principalmente pela boa vontade/iniciativa em compartilhar este material... independente das circunstancias/detalhes, as outras pessoas que em algum momento compartilharam este tipo de material também estão de parabéns, afinal o conhecimento esta sendo compartilhado.

Router OS v6.37.5...ao aplicar as regras nos profiles de cada plano não surgiu efeito no On Up e On Down, percebi que o meu servidor PPPoE esta considerando/usando os profiles "remotos" do servidor Radius (sistema de gestão), então apliquei as regras no ServerProfile (é o default profile do servidor PPPoE) e bombou.

Inicialmente tudo funcionando perfeitamente, tanto na conexão como na queda do túnel PPPoE do cliente, vou acompanhar o desempenho para deixar um Feedback na sequencia.

Sei que este detalhe não é tão simples assim, mas quanto ao Queue Type alguém tem alguma sugestão para o melhor Kind (pcq ou pfifo ou sfq) ???

[AndrioPJ]

AndrioPJ...você esta de parabéns pela dedicação e principalmente pela boa vontade/iniciativa em compartilhar este material... independente das circunstancias/detalhes, as outras pessoas que em algum momento compartilharam este tipo de material também estão de parabéns, afinal o conhecimento esta sendo compartilhado.

Router OS v6.37.5...ao aplicar as regras nos profiles de cada plano não surgiu efeito no On Up e On Down, percebi que o meu servidor PPPoE esta considerando/usando os profiles "remotos" do servidor Radius (sistema de gestão), então apliquei as regras no ServerProfile (é o default profile do servidor PPPoE) e bombou.

Inicialmente tudo funcionando perfeitamente, tanto na conexão como na queda do túnel PPPoE do cliente, vou acompanhar o desempenho para deixar um Feedback na sequencia.

Sei que este detalhe não é tão simples assim, mas quanto ao Queue Type alguém tem alguma sugestão para o melhor Kind (pcq ou pfifo ou sfq) ???

SFQ é melhorzinho...

https://under-linux.org/showthread.php?t=98859

https://under-linux.org/showthread.php?t=184070

PS: vlw pelo reporte do funcionamento nessa versão do RouterOS

[EvertonMachado]

SFQ é melhorzinho...

https://under-linux.org/showthread.php?t=98859

https://under-linux.org/showthread.php?t=184070

PS: vlw pelo reporte do funcionamento nessa versão do RouterOS

Valeu pelo retorno, esta questão do melhor Kind (pcq ou pfifo ou sfq) é muito relativo, cada caso é um caso!


AndrioPJ...olha só, caso você precise de ambiente para testar seus scripts pode me chamar em particular, tenho diversas redes em produção, ambientes atendendo com Rádio e com Fibra, desde planos de baixa velocidade até bandas maiores tipo 50 a 100 mega...ficarei contente em colaborar.

[gregorypv]

Rpz....eles deveriam pedir desculpa ao @AndrioPJ. Nem isso eles fizeram. Lamentável.

[alextaws]

@AndrioPJ, como esta os testes nessa nova versão do script?

[AndrioPJ]

@AndrioPJ, como esta os testes nessa nova versão do script?

Acredito que nesse FDS devo realizar os testes e postar os resultados.

Aproveitando.
Para ter uma ideia:
Para fazer o QoS Down, caso você tenha 100 clientes no concentrador, você teria que ter umas 8 regras no mangle, e o script criaria umas 600 regras no Queue Tree (06 regras para cada cliente).

Para fazer o QoS UP, caso você tenha 100 clientes no concentrador, o script criaria outras 100 regras no mangle e outras 400 no Queue Tree.

Dependendo do Concentrador, já é complicado o script apenas para o QoS Down, imagina fazer o QoS UP?

Estava a dias pensando em como diminuir essas regras afim de diminuir o processamento, mas sem prejudicar o resultado do QoS.
E Essa semana, olhando o forum da mikrotik, vi um post que me deu umas ideias que além de ter diminuído drasticamente a quantidade de regras, o resultado do QoS é o mesmo....
porem, diferente do script postado aqui e da versão nova que estava usando até então, onde é possível visualizar no Que Tree qual QoS individual que está sendo aplicado (Tipo, na versão postada aqui, basta ir no Queue Tree, procurar as regras do cliente, e ver qual está sendo usada), Nessa nova versão n tem como ver isso, mas o QoS está sendo feito perfeitamente.

Para fazer esse novo QoS, agora tanto de Down quanto de UP, são necessárias apenas 15 Regras no mangle e 12 regras no Queue Tree.

As prioridades que configurei aqui são as seguintes:
### Download
- Ping, DNS, VoIP = 1
- Pacotes Pequenos (até 512k) = 2
- Pacotes médio (Até 5M) = 4
- Pacotes Grandes (Até 50M) = 6
- Todo o Restante (Pacotes acima de 50M) = 8

### UPload
- Ping, DNS, VoIP = 1
- Pacotes Pequenos (até 256k) = 2
- Pacotes Medios (até 512k) = 4
- Pacotes Grandes (até 5M) = 6
- Todo o Restante (Pacotes acima de 5M) = 8

[AndrioPJ]

Haaaa, também foi resolvido um problema que tinha quando reiniciava a RB, ai qdo voltava e os clientes conectavam, algumas regras não eram aplicadas.

[Mitigo]

Mais esse não seria um QoS estático.

[pedrohafe]

Um detalhe que notei no funcionamento desses script é que se o cliente estiver cadastrado no Secrets o script não funciona, mesmo o cliente estando configurado para utilizar o profile com o script. Já os clientes que autenticam no Radius a regra funcionou sem problemas. Versão 6.37.5

[EvertonMachado]

Um detalhe que notei no funcionamento desses script é que se o cliente estiver cadastrado no Secrets o script não funciona, mesmo o cliente estando configurado para utilizar o profile com o script. Já os clientes que autenticam no Radius a regra funcionou sem problemas. Versão 6.37.5

Aqui na versão 6.37.5 apliquei no Profile que uso como "Default Profile" do servidor PPPoE e funcionou perfeito tanto para autenticação Radius como Local.

[gregorypv]

Acredito que nesse FDS devo realizar os testes e postar os resultados.

Aproveitando.
Para ter uma ideia:
Para fazer o QoS Down, caso você tenha 100 clientes no concentrador, você teria que ter umas 8 regras no mangle, e o script criaria umas 600 regras no Queue Tree (06 regras para cada cliente).

Para fazer o QoS UP, caso você tenha 100 clientes no concentrador, o script criaria outras 100 regras no mangle e outras 400 no Queue Tree.

Dependendo do Concentrador, já é complicado o script apenas para o QoS Down, imagina fazer o QoS UP?

Estava a dias pensando em como diminuir essas regras afim de diminuir o processamento, mas sem prejudicar o resultado do QoS.
E Essa semana, olhando o forum da mikrotik, vi um post que me deu umas ideias que além de ter diminuído drasticamente a quantidade de regras, o resultado do QoS é o mesmo....
porem, diferente do script postado aqui e da versão nova que estava usando até então, onde é possível visualizar no Que Tree qual QoS individual que está sendo aplicado (Tipo, na versão postada aqui, basta ir no Queue Tree, procurar as regras do cliente, e ver qual está sendo usada), Nessa nova versão n tem como ver isso, mas o QoS está sendo feito perfeitamente.

Para fazer esse novo QoS, agora tanto de Down quanto de UP, são necessárias apenas 15 Regras no mangle e 12 regras no Queue Tree.

As prioridades que configurei aqui são as seguintes:
### Download
- Ping, DNS, VoIP = 1
- Pacotes Pequenos (até 512k) = 2
- Pacotes médio (Até 5M) = 4
- Pacotes Grandes (Até 50M) = 6
- Todo o Restante (Pacotes acima de 50M) = 8

### UPload
- Ping, DNS, VoIP = 1
- Pacotes Pequenos (até 256k) = 2
- Pacotes Medios (até 512k) = 4
- Pacotes Grandes (até 5M) = 6
- Todo o Restante (Pacotes acima de 5M) = 8

Man,

No meu caso a simple queue não sao criadas dinamicamente. Eu crio manualmente porque eu quero saber qnt cada cliente consome de dados por mês. Qnd criava automaticamente o valor se apagava a cada desconexão. Neste caso como tem como alterar o script para pegar os dados de outro lugar? Ou no caso...deixar com que as desconexoes não apague o dados consumidos ?

[pedrohafe]

Vocês utilizam profiles diferentes mesmo utilizando servidor Radius?

[alextaws]

Acredito que nesse FDS devo realizar os testes e postar os resultados.

Aproveitando.
Para ter uma ideia:
Para fazer o QoS Down, caso você tenha 100 clientes no concentrador, você teria que ter umas 8 regras no mangle, e o script criaria umas 600 regras no Queue Tree (06 regras para cada cliente).

Para fazer o QoS UP, caso você tenha 100 clientes no concentrador, o script criaria outras 100 regras no mangle e outras 400 no Queue Tree.

Dependendo do Concentrador, já é complicado o script apenas para o QoS Down, imagina fazer o QoS UP?

Estava a dias pensando em como diminuir essas regras afim de diminuir o processamento, mas sem prejudicar o resultado do QoS.
E Essa semana, olhando o forum da mikrotik, vi um post que me deu umas ideias que além de ter diminuído drasticamente a quantidade de regras, o resultado do QoS é o mesmo....
porem, diferente do script postado aqui e da versão nova que estava usando até então, onde é possível visualizar no Que Tree qual QoS individual que está sendo aplicado (Tipo, na versão postada aqui, basta ir no Queue Tree, procurar as regras do cliente, e ver qual está sendo usada), Nessa nova versão n tem como ver isso, mas o QoS está sendo feito perfeitamente.

Para fazer esse novo QoS, agora tanto de Down quanto de UP, são necessárias apenas 15 Regras no mangle e 12 regras no Queue Tree.

As prioridades que configurei aqui são as seguintes:
### Download
- Ping, DNS, VoIP = 1
- Pacotes Pequenos (até 512k) = 2
- Pacotes médio (Até 5M) = 4
- Pacotes Grandes (Até 50M) = 6
- Todo o Restante (Pacotes acima de 50M) = 8

### UPload
- Ping, DNS, VoIP = 1
- Pacotes Pequenos (até 256k) = 2
- Pacotes Medios (até 512k) = 4
- Pacotes Grandes (até 5M) = 6
- Todo o Restante (Pacotes acima de 5M) = 8

Ficarei no aguardo da conclusão dos testes, e efetuas os testes aqui ver como vão se comportar

[killerwollf]

Alguma novidade amigo?

[pedrohafe]

Vocês estão utilizando pfifo/bfifo ou sfq no tipo de queue?