[GTER] Prioridade em um bloco

Tue Dec 13 10:37:23 -02 2016

Pense assim, se você não pode confirmar a recepção de um pacote, o próximo pacote não será enviado, logo controlar o upload também irá limitar o download.
Já vi isso em ação para controlar o monstrinho do update do Windows 8/10 e realmente funcionou, mas a banda de limitação de up foi algo quase que ridículo.
--
Enviado do aplicativo myMail para Android terça, 13 dezembro 2016, 09:56AM -02:00 de Andre Almeida  andre at bnet.com.br :

>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