[GTER] Prioridade em um bloco

Tue Dec 13 10:31:02 -02 2016

André.
Não falei nem de marcar os pacotes no mangle. Fazer isso diretamente no
queue, que não vai fazer diferenciação de pacotes. Não recomendaria
aumentar a complexidade a esse ponto, até por que, volto a frisar, tudo
isso tem custo computacional.

Recomendo a leitura
http://wiki.mikrotik.com/wiki/Bandwidth_Managment_and_Queues
http://wiki.mikrotik.com/wiki/Manual:Queue

Em 13 de dezembro de 2016 09:56, Andre Almeida <andre at bnet.com.br> escreveu:

> Certo, Lucas... mas cara, ainda fiquei na dúvida...
>
> No caso de a banda de upload não gargalar, teria efeito de atraso de TCP
> ACK se o limite estipulado na parent queue não atingir o limite ??
>
> Pois na realidade o que começa a afunilar quando perdemos eventualmente o
> link principal é o download pelo link de contingencia.
> Se formos ver o gráfico, upload fica "tranquilo".
>
> Claro que, se o upload também for feito em TCP (o que acontece na maioria),
> o pacote TCP ACK que vem do destino virá como download, logo, sofrerá
> também.
> Mas os pacotes SYN por exemplo, serão encaminhados "sem problemas" pois o
> link não teria gargalo na saida.
>
> Como o objetivo é priorizar uma classe para o download e vamos acabar
> atingindo o objetivo atrasando os pacotes ACK dos demais clientes.... não
> sei como eu poderia fazer isso se o upload não sofrer gargalos.
>
> Teria que simular um gargalo no upload???
>
> Por isso não compreendi se marcar somente pacotes TCP com flags ACK na
> mangle, e separar na queue os VIPs e os not-VIPs, terá efeito, pois a queue
> terá o limite total do link, coisa que não estamos atingindo nem em
> momentos de falha.
>
> Obrigado!
>
> Andre
>
>
>
> Em 10 de dezembro de 2016 11:25, Lucas Willian Bocchi <
> lucas.bocchi at gmail.com> escreveu:
>
> > Desculpe, esqueci de citar que no parent dos das duas outras queues vc
> tem
> > que colocar a primeira queue criada como "pai" desses dois "filhos".
> >
> > Em 10 de dezembro de 2016 11:24, Lucas Willian Bocchi <
> > lucas.bocchi at gmail.com> escreveu:
> >
> > > Você pode criar uma queue com o valor total da banda do link de
> > > redundância e criar mais dois queues. Na queue A vc coloca a faixa de
> IP
> > > dos clientes vip, na outra você deixa sem faixa (0.0.0.0/0). Na
> primeira
> > > vc coloca priority 1, no max limit o valor total da banda do link de
> > > redundância, e no limit-at o quando você quer garantir para os clientes
> > > dessa classe (80%, 90%, sei lá que conta vc quer fazer). No B vc deixa
> a
> > > priority 8, no max limit vc coloca o valor total da banda do link de
> > > redundância, e no limit-at o resto da banda que sobrou da conta
> anterior.
> > > Se quiser caprichar mais, pode usar o mangle e marcar os pacotes (como
> já
> > > foi falado) e usar o recurso do packet-mark do queue. E como tudo que
> nós
> > > queremos fazer na nossa rede isso tem um custo, no caso o custo
> > > computacional de fazer esse controle todo na RB, mas nada que uma 1006
> > não
> > > dê conta.
> > >
> > > Em 9 de dezembro de 2016 22:42, Andre Almeida <andre at bnet.com.br>
> > > escreveu:
> > >
> > >> O objetivo é:
> > >>
> > >> Sobre a banda:
> > >> Se os clientes Link full precisarem, vai ser disponibilizada dentro do
> > >> possível, tentando minimizar o gargalo para esses.
> > >>
> > >> Se os clientes Link full estiverem ociosos, o tráfego, mesmo já
> > afunilado
> > >> naturalmente, será utilizado para qualquer cliente.
> > >>
> > >> Se eu marcar os pacotes com flags ACK, dos blocos dos que não são link
> > >> full
> > >> nas regras de mangle, acho que terei que criar queues no roteador de
> > borda
> > >> , aplicando prioridades?
> > >>
> > >> Isso vai gerar muito consumo de recursos?
> > >>
> > >> A princípio será necessário criar regras somente na borda e nesse caso
> > em
> > >> específico vou adicionar essas regras somente na borda onde se
> encontra
> > o
> > >> link de contingência....
> > >>
> > >> Ainda não consegui entender como posso fazer de forma "descomplicada"
> e
> > >> sem
> > >> exagero de uso de recursos.
> > >>
> > >> Agradeço muito a ajuda de todos que estão disponibilizando de seu
> tempo
> > >> para me ajudar.
> > >>
> > >>
> > >> André Almeida
> > >>
> > >>
> > >> * Email enviado através de dispositivo móvel.
> > >>
> > >> Em 9 de dez de 2016 10:30 PM, "Rubens Kuhl" <rubensk at gmail.com>
> > escreveu:
> > >>
> > >> > 2016-12-09 17:31 GMT-02:00 Andre Almeida <andre at bnet.com.br>:
> > >> >
> > >> > > Verdade, sobre TCP, faz sentido.
> > >> > >
> > >> > > Bom, agora no mesmo assunto, qual a melhor forma de fazer isso na
> > >> borda.
> > >> > > No caso, usamos Mikrotik.... não sei se seria interessante fazer
> > queue
> > >> > mas
> > >> > > sim talvez uma mangle pra alterar algo que fizesse ter mais
> > >> prioridade.
> > >> > >
> > >> > > Alguém com alguma dica ?
> > >> > >
> > >> >
> > >> > O Mikrotik tem um match "limit" que pode ser colocado em
> > "mode=packet" e
> > >> > com isso contar pacotes por segundo. Junte isso com o bloco dos
> > >> clientes e
> > >> > flags ACK que você tem um caracterização do tráfego que quer
> > >> > limitar/atrasar/dropar.
> > >> >
> > >> >
> > >> > > Alterar DSCP por exemplo somente daquele bloco? Surtiria efeitos?
> > >> > >
> > >> >
> > >> > Não, somente teria efeito se algo à frente usasse isso como
> > referência.
> > >> >
> > >> >
> > >> > Rubens
> > >> > --
> > >> > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >> --
> > >> gter list    https://eng.registro.br/mailman/listinfo/gter
> > >>
> > >
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>