Boa noite Manoel. Não sou expert, sei que qos e redirecinamento são duas coisas diferentes, estava tentando agregar alguma coisa. Sei também que uma pessoa bem embasada daria um veredito. Nas regras que usei (para qos) não tinha passthrough habilitado porque não seriam passadas a frente e também os tamanhos dos arquivos não se repetiam nas regras como pode ver abaixo.

add action=mark-packet chain=forward comment=512k< connection-bytes=0-524288 disabled=yes new-packet-mark=0bytes passthrough=no protocol=tcp
add action=mark-packet chain=forward comment=512-1M connection-bytes=524289-1048576 disabled=yes new-packet-mark=1Mbyte passthrough=no protocol=tcp
add action=mark-packet chain=forward comment=1-3M connection-bytes=1048577-3145728 disabled=yes new-packet-mark=3Mbyte passthrough=no protocol=tcp
add action=mark-packet chain=forward comment=3-6M connection-bytes=3145729-6291456 disabled=yes new-packet-mark=6Mbyte passthrough=no protocol=tcp
add action=mark-packet chain=forward comment=6-30M connection-bytes=6291457-31457280 disabled=yes new-packet-mark=30Mbyte passthrough=no protocol=tcp
add action=mark-packet chain=forward comment=30-60M connection-bytes=31457281-62914560 disabled=yes new-packet-mark=60Mbytes passthrough=no protocol=tcp
add action=mark-packet chain=forward comment=60M> connection-bytes=62914561-4294967295 disabled=yes new-packet-mark=Infinite passthrough=no protocol=tcp

Perfeito Izau, eu só acho que na sua regra você deveria separar por portas, assim você conseguiria fazer um QoS mais "fino".

Izaufernandes,

"...o problema é que quando o mikrotik detecta a conexão ou pacote pelo parâmetro especifico (conn bytes, content ou Layer7) a conexão já está estabelecida, aí se você manipula ela simplesmente cai..."

É esse comportamento mesmo que esperando dessas regras, que estávamos tentando explicar, mas houve insistência em dizer que isso funciona.

Mas enfim, conversei com um amigo hoje e por acaso surgiu este assunto, ele disse que num curso de mikrotik a 5 anos atrás alguém deu uma palestra mostrando como isso funciona, mas a conexão caia de fato (como esperado), ele fazia uma address-list para os ips dos destinatários que tinha arquivos com tamanho setado, mas isso pra mim esta longe de ser uma solução adequada.

PS: Agora não vale dizer que era isso que estavam querendo dizer no começo. kkkkkk

Xgames to ligado. Eu estava tentando testar mais uma vez em outro servidor aqui com RC 20.1 e aconteceu isso.

Henrique não tô com plugin da RC 19.4 não. Instalei e não mexi em nada somente nas configurações básicas.

"PS: Agora não vale dizer que era isso que estavam querendo dizer no começo. kkkkkk"

Rs. Mas éra justamente neste ponto que eu estava querendo chegar no post anterior ao ultimo que fiz. Se realmente fosse possível manipular arquivos ou conexões teria um leque enorme de utilidades, daria para fazer balanceamento muito eficaz marcando por layer7 ou por content .flv, .mp4, .exe, .rar, ou usando connection-bytes para separar arquivos grandes e jogando em uma adsl da vida. Más nunca consegui e ja pesquisei muito, talvez não o suficiente.

A transcrição do post na pagina anterior:

"A muito tempo atrás tentei alguma coisa parecida com isso, usando layer7, content, connection byte marcar extenções e redirecionar para um link específico, o problema é que quando o mikrotik detecta a conexão ou pacote pelo parâmetro especifico (conn bytes, content ou Layer7) a conexão já está estabelecida, aí se você manipula ela simplesmente cai."

Manoel Valdeliro, tentei as usar as regras que seguem abaixo, mas aqui não funcionam, veja o que acontece a interface do SPEEDR sobe o link, mas em instantes cai e fica tudo sem internet. Poderia me ajudar?

/ip firewall mangle
add action=mark-connection chain=prerouting comment="Conexoes HTTP e FTP" \
disabled=yes dst-address-list=!Out-Cache dst-port=80 new-connection-mark=\
conexoes_speedr passthrough=yes protocol=tcp src-address-list=Clientes
add action=mark-connection chain=prerouting disabled=yes dst-address-list=\
!Out-Cache dst-port=21,40000-42999 new-connection-mark=conexoes_speedr passthrough=yes \
protocol=tcp src-address-list=Clientes


/ip firewall mangle
add action=mark-routing chain=prerouting comment="Rota Conexoes HTTP e FTP" \
connection-mark=conexoes_speedr disabled=yes dst-address-list=!Out-Cache \
new-routing-mark=rota_conexoes_speedr passthrough=no src-address-list=\
Clientes

/ip firewall address-list
add address=186.x.x.x/28 disabled=no list=Clientes
add address=192.168.1.254 disabled=no list=Out-Cache


/ip route
add comment="Rota HTTP e FTP ---> Speedr" disabled=no distance=1 dst-address=\
0.0.0.0/0 gateway=192.50.50.2 routing-mark=rota_conexoes_speedr scope=30 \
target-scope=10

Ajudo sim, abra um ticket com os dados de acesso do mikrotik e do speedr, mas só amanhã pq agora estou indo dormir aahahahah

Henrique brother, ((nada será dito))!!! para de tentar ''cutucar'' para obter uma resposta. Essa solução que você disse ai já tinha sido feita a uns anos atras,...tenta pra ver...a quantidade de ip's que vai para tua lista será tão grande que dará um ''delay'' enorme na conexão(rsss).

Roberto, por isso eu disse que é esta longe de ser uma solução adequada, desculpa mas o que você disse de fato não funciona rsrs.

por que o pcc do Mk ''estabelece'' a conexão em um link e ela vai no mesmo link até o final? Se manipular a conexão ela cai, é exatamente o que você disse antes,(nada de novo) é assim mesmo e você tem razão.

Quanto a three-way-handshake é a forma que uma conexão TCP se realiza. Chama-se assim porque ocorre em 3 etapas:

1. O cliente manda uma requisição (SYN).
2. O servidor responde com SYN-ACK (quer dizer que aceitou o protocolo e estabeleceu a conexão).
3. O cliente envia as informações em forma de "pacotes".

Quando essas 3 fases acontecem, significa que o cliente e o servidor "chegaram a um acordo" e estão conectados.

Se manipular isso ai a conexão cai ( sabia? ) (rsssss)

Abração Henrique e vamos em frente, (aliás, espero vocês aqui em Natal-RN no MUM em novembro.