Configure um roteador Linux para alocação de largura de banda justa sem limitação desnecessária

1

Eu corro um roteador Linux (mais precisamente OpenWRT) em uma conexão de internet com largura de banda muito limitada, cerca de 1 MBit / s downstream e algumas dúzias de upstream de kBit / s.

Existem várias máquinas na rede que fazem coisas com pouca largura de banda, como tocar rádio na web ou enviar dados de medição. Outras máquinas podem iniciar downloads normais para atualizações de software ocasionalmente.

Sempre que uma máquina inicia um download, o material de baixa largura de banda fica instável. Eu suponho que a largura de banda do fluxo seja reduzida porque há outra conexão no roteador, embora ela se encaixe bem na WAN b / w. Isso é um pouco contra minha intuição e gostaria de configurar o roteador para alocar a largura de banda de forma mais justa.

Por "razoavelmente", quero dizer:

Suponha que haja uma largura de banda de downstream de 1 MBit / s e 64 kBit / s dela sejam usados. O próximo cliente que acessa a WAN deve obter no máximo (1 MBit - 64 kBit) / s largura de banda. Se, e somente se, a largura de banda a jusante estiver esgotada, a largura de banda das conexões individuais deve ser diminuída e ela deve ser adaptada para que as conexões sejam estranguladas proporcionalmente ao seu tamanho (quanto menor, menos).

Em primeiro lugar, a minha compreensão do problema está correta? Em caso afirmativo, o que posso fazer para influenciar as alocações de largura de banda do roteador? Nota: Eu faço não querer o que é geralmente recomendado na literatura, ou seja, limitar a largura de banda de cada cliente para uma fração da largura de banda total disponível. Há pouca velocidade de WAN no meu site para fazer isso.

    
por jstarek 30.01.2012 / 23:55

3 respostas

3

A sua compreensão do problema é geralmente correta, mas o tipo de solução que você propõe é MUITO complicado de implementar. As perguntas de "O que é um cliente?" e "O que é uma conexão?" surgir, e pode ser difícil responder bem.

A estratégia mais típica de limitação de largura de banda é algo assim:

  • Defina o limite da largura de banda a montante (digamos 1Mbit / s)
  • Opcionalmente, Reserve alguma quantidade dessa largura de banda para "administração do sistema" (por exemplo, 64 KB / s)
  • Opcionalmente, "garanta" uma certa quantidade de largura de banda para um propósito específico (digamos 192Kb / seg para VOIP)
  • Permite que todos usem a largura de banda restante (768 kbit / s).

O VOIP pode usar mais de 192 Kbit / seg, portanto podemos permitir que ele seja emprestado do pool "everyone" (ou vice-versa). Quando o pool de "todos" estiver saturado, comece a eliminar pacotes como faríamos se o link upstream estivesse realmente saturado (usando, por exemplo, Random Early Detection para escolher suas vítimas de queda.

Geralmente isso é feito no tráfego UPSTREAM. O tráfego a jusante pode ser limitado da mesma maneira, mas você não pode evitar a saturação de link do tráfego downstream (os pacotes ainda precisam vir ao seu firewall antes que as decisões de queda possam ser tomadas, então eles ainda estão viajando pelo fio. é uma onda de tráfego seguida por um decaimento natural, já que o protocolo TCP detecta congestionamento "saturação de link" e o lado remoto retrocede sua taxa de envio até que a perda de pacotes pare.

Observe também que isso não garante "justiça" às máquinas clientes, exceto na medida em que a Detecção Antecipada Aleatória derrubará os pacotes "aleatoriamente" (aleatoriamente o suficiente para que nem sempre o cliente A receba pacotes descartados quando o link está saturado). O que você está contando é que as quedas "aleatórias" naturalmente moldarão o tráfego de uma forma que você não terá que se preocupar com o fato de um cliente morrer de fome enquanto outro adora toda a largura de banda.

Uma solução pronta para uso em seu caso particular pode ser limitar a largura de banda disponível para atualizações (presumivelmente estas vêm de sub-redes conhecidas, limitando-as), mas isso ainda está sujeito às advertências que mencionei acima.

Alternativamente, se você tiver hardware disponível, você pode distribuir suas atualizações de um servidor local (WSUS, Local apt mirror, etc.) - Isso permitiria que você agendasse essas atualizações para serem feitas localmente fora do horário normal, quando ninguém é usando sua rede e, finalmente, pouparia muita largura de banda transferindo atualizações individuais para cada máquina.
Uma vez que as atualizações já são locais, não importa quando as máquinas individuais dos clientes as pegam - elas não estão saindo para a internet, então contanto que você não esteja saturando sua rede local (muito difícil!) Você ganhou t sofrem problemas significativos de desempenho. A desvantagem, claro, é que você precisa investir tempo e hardware na configuração do servidor de atualização.

    
por 31.01.2012 / 00:21
0

Não, não há uma boa maneira de fazer isso agora. O problema básico é que seu ISP decide quais pacotes colocar em seu link, e não tem nenhuma informação que possa usar para tomar essa decisão. A resposta curta e triste é que o acesso à Internet do consumidor não está configurado para isso.

    
por 31.01.2012 / 00:17
0

Existe este script bastante antigo que faz exatamente isso. Eu tenho usado isso há anos.

Ele faz coisas bem complicadas nos bastidores, mas a configuração real do usuário é bem simples.

Meu fork: link (Ele tem algumas pequenas correções que permitem que ele seja executado em versões recentes do Linux)

Existe uma versão do script para o openwrt, mas ele não o usou.

(Eu tive que desativar o suporte ao TOS, porque ele causou redefinições aleatórias de TCP para alguns sites (wikia, imgur, etc.). Provavelmente é devido a algumas estranhezas neste ISP específico, mas eu não sei. )

    
por 30.11.2014 / 16:27