[GTER] Prioridade em um bloco

Tue Dec 13 10:44:19 -02 2016

Na realidade vc comentou sobre isso

"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."

Andre

Em 13 de dezembro de 2016 10:31, Lucas Willian Bocchi <
lucas.bocchi at gmail.com> escreveu:

> 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
> >
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>