Cache Full com controle individual por cliente

[rodrigoMK]

Bom dia Pessoal,

Depois de muito pesquisar sem resultados, resolvi postar o meu problema aqui.

Já esta rodando na minha rede um Servidor WebCache belezinha, fazendo o cache 100% e tudo mais, mas o grande problema é que quero fazer um controle de banda individual por cliente quando o mesmo estiver usando os arquivos do cache. Por exemplo:

1 cliente de 600k esta vendo um video do youtube que esta no cache, a banda dele vai automaticamente para 1M mas esse 1M seja restrito a ele e não compartilhado se uma 2ª pessoa estiver pegando arquivos do cache.

OBS: as marcações dos pacotes do cache com regras de mangle ja estão prontas, preciso apenas da logica do controle de banda.


Desde já agradeço a Todos!

Abraços!

[mamaunet]

Otima ideia, acompanhando espero que algum dos Mestres ajudem...

[rodrigoMK]

esqueci de especificar que esse controle de banda tem que ser feito no mikrotik.

[conquesttelecom]

qual equipamento vc usa nos clientes?

[rodrigoMK]

qual equipamento vc usa nos clientes?

Amigo,

Tem todo o tipo de equipamento, desde plaquinhas até NANOLOCO5.

[conquesttelecom]

fiz a pergunta pq no meu caso uso nano m5 e air grid nos clientes entao dexei o proxy livre a banda como cache ful e limitei de 5 a 10 megas no proprio nano ou airgrid
assim o cliente contrata 300k entrego 300kbps banda normal e o que ta no cache entrega 6 megas
lembrando que tenho um servidor de cache em cada torre onde faco isso

[conquesttelecom]

nao uso banda alta onde e cliente com placa pci, sua base nao vai passar banda suficiente pra eles

[rodrigoMK]

fiz a pergunta pq no meu caso uso nano m5 e air grid nos clientes entao dexei o proxy livre a banda como cache ful e limitei de 5 a 10 megas no proprio nano ou airgrid
assim o cliente contrata 300k entrego 300kbps banda normal e o que ta no cache entrega 6 megas
lembrando que tenho um servidor de cache em cada torre onde faco isso

Isso realmente é uma boa, mas como eu comprei o provedor de outra pessoa, aqui tem MUUUIIITAAA plaquinha ainda e não vale a pena trocar,

Mas obrigado por enquanto.

[rodrigoMK]

Os meus enlaces de PtP para as repetidoras são todos com ROCKETM5, tenho banda pra aguentar bastante coisa, mas o que limitaria seria o 2.4Ghz, mas não pretendo liberar os 5 - 10 Megas que vc libera ai, apenas dobrar a velocidade, por exemplo de 400k -> 800k, 200k -> 400k e assim por diante.

[sostenes]

procure sobre regras pcq...

[rodrigoMK]

poiseh, eu lancei uma vez um produto desses.

controlador de banda duplo, se sair do cache sai com up1/down1 se não sair do cache sai com up2/down2.

Ainda tenho os códigos fonte de projeto aqui. Mas o povo ficou tão bitolado em mikrotik que não aceitam que não funcione em mikrotik.

A solução é baseada no FreeBSD + Squid.

DUVIDO (eu não vou dizer que é impossível por que quase tudo tem um jeito) MUITO que alguem consiga fazer isso no mikrotik ou no linux.

Alias, no linux tem como, mas é mais simples no BSD.

A questão toda gira em torno do seguinte :

O controle de banda do Linux (e até mesmo do FreeBSD se for usado o PF) só faz controle de subida, do que é transmitido pela placa.

O DOWN do cliente é o UP da placa LAN e aqui se faz o controle de download do cliente.
Como o UP do cliente é DOWN da placa LAN, nessa placa o cliente sobe livre.

Para compensar, o UP do cliente do ponto de vista da placa WAN é seu UP, o que permite fazer controle de banda aqui, já o DOWN da WAN é o DOWN do cliente e não se faz controle de banda, o que é compensado na LAN.

A filosofia disso é que teoricamente não adianta jogar fora pacotes que já trafegaram pelo link de internet.

Qual o efeito disso ? Uma conexão saindo do cliente e interceptada pelo SQUID não tem controle de banda up. O cliente manda como quiser (Pois só é vista pela placa LAN). [PS.: como de todo jeito o squid vai ter que mandar os dados - um form POST grande, ou um upload de arquivo, por exemplo - para cima, esse acaba sofrendo controle de banda, mas não sem sobressaltos]

Já a conexão que o SQUID gera com o mundo exterior não sofre controle de banda (Pois só é vista pela placa WAN). [PS.: Do mesmo jeito que o anterior, com sobressaltos]

Dá pra resolver ? Parcialmente, mas nunca é a melhor solução.

Por que não concordo com essa filosofia ? Por que o protocolo TCP tem o chamado sliding window, que é diminuido (consequentemente diminuindo a velocidade) se algum pacote é perdido. Logo fazer controle de banda tanto no UP quanto no DOWN da placa de rede tem efeito nos clientes/servidores envolvidos, além do que a maior parte dos sistemas operacionais (Mesmo o windows) suporta o bit ECN, que pode explicitamente avisar aos envolvidos na comunicação de que algum roteador no meio do caminho quer que eles diminuam a velocidade pois em algum ponto da rede há um congestionamento.

*PS : Normalmente essa tranferencia do servidor remoto para o cache e do cache para o cliente é feito por buffers de tamanho fixo, por exemplo, de 2k em 2k. Dependendo de como o aplicativo (não apenas o squid) trasfere esses buffers e de seu tamanho em relação ao MTU, pode gerar picos intermitentes na rede, que se vistos num gráfico formariam uma imagem de dente de serra.

Obrigado primeiramente pelo post amigo, creio que o seu código seria de grande valor se eu não trabalhasse com Mikrotik.

Mas também não acho que seja impossível de implementar algo do tipo, pois o meu mikrotik ja sabe o que é INTERNET e o que é CACHE, na pior das hipótese uma regra de firewall para cada cliente do Hotspot pode ser funcione, mas vamos aguardar alguma solução em MK e enquanto isso vou dar uma estudada na DICA do AMIGO : pcq.

Obrigado a todos!

[rodrigoMK]

Vou tentar explicar melhor :

Quando um pacote vai ser transmitido por uma placa de rede, no linux, ele entra num queue.

Por default, esse queue apenas faz o pacote esperar até poder ser transmitido pelo hardware.

Se você ativar os mecanismos de TC (traffic control) do linux, tais mecanismos irão tirar vantagem desse queue, controlando a maneira como ele é usado (derrubando pacotes de conexões que estejam acima da velocidade permitida, por exemplo). É possível criar sub-queues etc.

Por outro lado um proxy HTTP funciona da seguinte maneira : Quando uma requisição é enviada para o proxy (Seja explícitamente ou por interceptação) ela é processada pelo proxy, e, baseado numa consulta interna (Se o pedido já está no cache, etc) ela pode dar origem a uma segunda requisição (espelho) gerada pelo próprio proxy. O problema é que, se o proxy gera uma conexão TCP nova, essa conexão sairá com o IP do squid e não com o IP do cliente que a provocou.

Existem algums macetes com TOS que permitem fazer alguma coisa a respeito, mas no geral o resultado da soma proxy + controle de banda baseado em queue não é favorável a essa função qeu você quer.

É possível solucionar isso no linux/mikrotik usando pcq. Mas não chega nem perto da solução que eu bolei com o FreeBSD.

T

Tudo bem amigo, então como seria essa solução de mikrotik com PCP?

[rodrigoMK]

Pronto, seguinte :

/ip proxy
set cache-hit-dscp=4

; isso significa que um cache hit passa a ter TOS=4

/ip firewall mangle add action=mark-packet chain=output comment="CACHE HIT" disabled=no dscp=4 new-packet-mark=cache-packets place-before=0 passthrough=no

; isso faz os pacotes com TOS=4 serem marcados
/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=1M name=from-proxy packet-mark=cache-packets parent=global-out priority=8 queue=default

Testa ai e me diz, enquanto eu penso em alguma solução que não envolva tirar o controle de banda do hotspot

JorgeAldo,

Esse controle funciona sim, testei aqui tambem, mas ele limita todo o trafego do cache, seria praticamente um cache FULL não?

Se tivesse a opção de fazer esse controle dos pacotes marcados por IP de cliente ja resolveria tudo.

[minelli]

hehehehehehe, adoro isso ninguém capaz de ler um manual e dizer algo diferente incrível.....
Aqui mesmo no forum já foi postado material que daria conceito suficiente para qualquer um fazer isso. O que ocorre é que o povo não lê e quando lê não entende por falta de conhecimento (conceito técnico) e sabem porque, porque a maioria só sabe pedir, ver copiar e colar e a minoria e capaz de fazer algo em geral os mais antigos no forum.
Porque a moçada nova não se salva nem 5%, mas apesar do meu desabafo aos crtl+c e ctrl+v vamos ao que interessa na minha próximo aqui.

[rodrigoMK]

O problema consiste no seguinte :

1 - O hotspot cria seus próprios queues para os clientes logados.

2 - Isso ai precisa de um queue por cliente para limitar a banda.

O resultado é que você :

1 - Vai ter que fazer ao contrário (Marcar tudo QUE NÃO SEJA CACHE HIT).

2 - Cadastrar os clientes, não com a banda que eles deveriam ter, e sim com a banda máxima no caso de cache hit.

3 - Dar um jeito de criar um queue por cliente com a banda real (sem cache hit).

Esse segundo queue deve ser filho do primeiro.

4 - Fazer com que todos os pacotes atravessem o primeiro queue.

5 - Fazer com que os pacotes que NÃO FOREM CACHE HIT ou que não forem relacionados à HTTP passarem também pelo segundo queue.

Dai funciona.

Mas o que atrapalha ? O hotspot cria um queue por cliente.

Voce vai ter que fazer os queues por fora, sem interferencia do hotspot, o hotspot só vai servir para autenticar, não para determinar a banda.

Serve ?

Show de bola Jorge Aldo, Funcionou belezinha, desativando o controle de velocidade do Hotspot e fazendo o que vc disse. Abraço!

[rodrigoMK]

hehehehehehe, adoro isso ninguém capaz de ler um manual e dizer algo diferente incrível.....
Aqui mesmo no forum já foi postado material que daria conceito suficiente para qualquer um fazer isso. O que ocorre é que o povo não lê e quando lê não entende por falta de conhecimento (conceito técnico) e sabem porque, porque a maioria só sabe pedir, ver copiar e colar e a minoria e capaz de fazer algo em geral os mais antigos no forum.
Porque a moçada nova não se salva nem 5%, mas apesar do meu desabafo aos crtl+c e ctrl+v vamos ao que interessa na minha próximo aqui.

Esse é o mal do ser humano, se achar superior, provavelmente você é o sabidão e "O CARA" de redes, por que, tomara Deus que quando você tiver alguma dificuldade, UM ZÉ MANÉ lhe dê uma dica BOA como esta.

Passar bem.

[minelli]

Esse é o mal do ser humano, se achar superior, provavelmente você é o sabidão e "O CARA" de redes, por que, tomara Deus que quando você tiver alguma dificuldade, UM ZÉ MANÉ lhe dê uma dica BOA como esta.

Passar bem.

Não, não me acho superior, não sou o sabidão, não sou "O CARA" não sou melhor do que ninguém aqui no forum.
Aprenda a ser educado e já começará melhorando muito.
Se tivesse prestado atenção no que escrevi viria que:
"vamos ao que interessa na minha próximo aqui..."
Sendo assim se pelo menos interpreta-se o texto entenderia que estou fazendo algo que não costumo fazer que é arrumando um ctrl+c e ctrl_v para ajudar a quem ler esse poste, já que a maioria tem preguiça de ler ou até traduzir o manual ou documentação disponível no wiki da mikrotik.

[minelli]

Pessoal tento aqui resumir em regras o que o titulo do tópico diz.
Claro que terão de adaptar as regras a rede na qual forem utilizar, de acordo com cada rede as regras podem sofrer e muito alterações para seu funcionamento correto.

Segue explicações básicas:
Clientes = Aqui deve conter a classe de IP dos clientes que deverão passar pelo proxy.
Sem_Proxy = Aqui deve conter os IPs ou classes de IPs que não terá o cache feito geralmente usado para sites governamentais.

/ip firewall address-list
add address=10.10.10.0/24 comment="" disabled=no list=Clientes
add address=200.157.0.0/16 comment=ReceitaNet disabled=no list=Sem_Proxy

Marcação das conexões vindas do Proxy.
Marcação dos pacotes vindos do Proxy.

/ip firewall mangle
add action=mark-connection chain=postrouting comment="InstallAPP_Cache" content="X-Cache: HIT from InstallAPP" disabled=no new-connection-mark=LinuxInstallAPP_Cache-Conn-HIT passthrough=yes protocol=tcp
add action=mark-packet chain=postrouting comment="" connection-mark=LinuxInstallAPP_Cache-Conn-HIT disabled=no new-packet-mark=LinuxInstallAPP_Cache-Packet-HIT passthrough=yes

Nat para o IP do Proxy
Redirecionamento para clientes IP+Mac e PPPoe.
Redirecionamento para clientes HotSpot.

/ip firewall nat
add action=masquerade chain=srcnat comment="NAT InstallAPP_Cache" disabled=no src-address=192.168.10.0/24
add action=dst-nat chain=dstnat comment="Redirect - InstallAPP_Cache" disabled=yes dst-address=!192.168.10.2 dst-address-list=!Sem_Proxy dst-port=80 protocol=tcp src-address-list=Clientes to-addresses=192.168.10.2 to-ports=5128
add action=dst-nat chain=pre-hotspot comment="Redirect HotSpot - InstallAPP_Cache" disabled=yes dst-address=!192.168.10.2 dst-address-list=!Sem_Proxy dst-port=80 hotspot=auth protocol=tcp src-address-list=Clientes to-addresses=192.168.10.2 to-ports=5128

Aceitar trafego do Proxy
Bloquear acesso externo ao Proxy

/ip firewall filter
add action=accept chain=forward comment="Aceita InstallAPP_Cache" disabled=no src-address=192.168.10.0/24
add action=accept chain=forward comment="" disabled=no dst-address=192.168.10.0/24
add action=drop chain=input comment="Bloqueio InstallAPP_Cache" disabled=no dst-port=3128 in-interface="Router" protocol=tcp
add action=drop chain=input comment="" disabled=no dst-port=8080 in-interface="Router" protocol=tcp

Queue Type responsável pelo titulo do tópico. (Deve-se tomar cuidado com este tipo de Queue Type - Para cada rede deve-se aplicar de uma forma)

/queue type
add kind=pcq name=InstallAPP_Cache pcq-burst-rate=0 pcq-burst-threshold=0 pcq-burst-time=10s pcq-classifier=dst-address pcq-dst-address-mask=32 pcq-dst-address6-mask=64 pcq-limit=50 pcq-rate=0 pcq-src-address-mask=32 pcq-src-address6-mask=64 pcq-total-limit=2000

Controle da Banda do que foi marcado vindo do Proxy.

/queue tree
add burst-limit=0 burst-threshold=0 burst-time=0s disabled=no limit-at=0 max-limit=10240 name="2 - InstallAPP_Cache_Full" packet-mark=LinuxInstallAPP_Cache-Packet-HIT parent=global-out priority=2 queue=InstallAPP_Cache

Observem que esta Queue Tree tem sua "queue" selecionada para a Queue Type adicionado anteriormente "InstallAPP_Cache" e não para a "queue" padrão "default".
Na Queue Type anterior vocês devem ter reparado que foi setado pcq-total-limit=2000, logo tudo que vier do Proxy terá seu máximo de trafego na rede de 10MiB, como configurado na Queue Tree e cada cliente 2MiB como configurado no Queue type.
Recomendo o estudo do manual do Mikrotik e também de documentação sobre PCQ no Mikrotik, pois só a aplicação das regras não serão suficiente para o perfeito funcionamento.

Link´s para consulta:
http://wiki.mikrotik.com
http://wiki.mikrotik.com/wiki/Manual:Queues_-_PCQ
https://under-linux.org/blogs/m4d3/p...-por-m4d3-852/

Caro leitor se foi útil, então agradeça.

[rodrigoMK]

Obrigado pelas dicas, irei fazer os testes com calma e retorno os resultados.

Abraço

[egservice]

Pessoal tento aqui resumir em regras o que o titulo do tópico diz.<br>
Claro que terão de adaptar as regras a rede na qual forem utilizar, de acordo com cada rede as regras podem sofrer e muito alterações para seu funcionamento correto.<br>
<br>
<font color="#0000ff"> Segue explicações básicas:</font><br>
.....

Boa tarde a todos, caro Minelli e companheiros, pergunto: seria possivel criar uma queue tree (setando a respectiva interface em parent)para cada interface de entrada? por ex. wlan1 (2,4ghz) total cache 2MB, eth1 (5,8ghz) total cache 10MB, etc, para não estourar a capacidade de cada interface nem sacrificar o cache full em detrimento das 2,4ghz???