Documentos BQN

Esta secção descreve alguns exemplos de utilização de BQN.

Implementação de Planos de Taxas de Assinantes

O objectivo é aplicar os limites de velocidade no plano de dados de cada subscritor.

O BQN aplica esses limites melhor do que um elemento de modelagem convencional porque, para o tráfego TCP (o mais comum), ele não precisa descartar pacotes. Além disso, usa filas independentes por fluxo, o que torna as latências das aplicações independentes umas das outras, o que melhora muito a experiência das aplicações interactivas. A figura seguinte mostra a estrutura de filas, com uma fila por fluxo e controlo de políticas ao nível do fluxo e do assinante.

A forma mais fácil de implementar planos tarifários é utilizar a interface RADIUS, a API REST ou os sistemas de faturação (ver as secções correspondentes). As políticas tarifárias serão então atribuídas por um sistema externo a cada assinante. O sistema externo pode criar diretamente essas políticas ou pode atribuir políticas de tarifas configuradas a partir da GUI do BQN.

Se não for possível utilizar um sistema externo, é possível criar uma política tarifária para cada plano, um perfil de acesso com todos os endereços IP dos assinantes (ou intervalos) atribuídos a esse plano e, em seguida, uma regra que ligue os perfis de acesso e as políticas tarifárias correspondentes.

No exemplo seguinte, criamos três políticas de taxa de subscrição: taxa-10Mbps, taxa-20Mbps e taxa-30Mbps:

Definimos perfis de acesso com os intervalos de IP dos assinantes atribuídos a cada política:

E associamos perfis e políticas numa árvore de regras:

Também é possível definir tais regras apenas para um endereço IP de teste que é utilizado durante uma prova de conceito para ver o desempenho do BQN como um gestor de largura de banda:

Limitando a velocidade de algumas aplicações

O objectivo é reduzir o pico de produção da rede para mitigar o congestionamento na hora de ponta. Para o efeito, é definido um perfil DPI (vídeo no exemplo) para identificar as aplicações a limitar. Este exemplo faz uso de assinaturas pré-definidas de transmissão de vídeo. Para as incluir, no perfil Add DPI, seleccione Add Predefined Signatures e escolha a assinatura pré-definida do Video Streaming .

Além disso, um perfil de taxa de transferência é criado com a carga de tráfego a partir da qual a limitação será iniciada(acima de 5 Gbps neste exemplo). Em seguida, uma política de fluxo de assinante(fluxo-10Mbps no exemplo) é criada com um limite de downlink(modelagem de downlink por assinante) definido em 10 Mbps. Por fim, o perfil DPI, o perfil de taxa de transferência e a política de fluxo de assinante são vinculados em uma regra de fluxo de assinante.

Limitando a velocidade de algumas aplicações com NAT

O objectivo é reduzir o pico de produção da rede para mitigar o congestionamento na hora de ponta. Neste cenário, existe um NAT entre o servidor BQN e os assinantes finais e, por conseguinte, não é possível uma modelação por assinante.

Usaremos os mesmos perfis Throughput e DPI do exemplo anterior, mas usaremos a política de modelagem aper-flow.

Serviços não limitados pela Taxa de Assinante

O objetivo é preservar a qualidade da experiência de alguns serviços, concedendo-lhes débito mesmo quando o plano tarifário do assinante é totalmente utilizado. Um exemplo poderia ser um serviço de voz sobre IP (VoIP) hospedado pelo ISP. A política é limitada a assinantes com planos ouro. É criada com um perfil de Internet(voip) com o endereço IP e a porta do serviço VoIP alojado pelo ISP, um perfil de taxa de política e uma política de fluxo (com a limitação da taxa de subscrição de salto selecionada para Ligado). Em seguida, o perfil de Internet e os perfis de taxa de política são vinculados à política por uma regra de fluxo de assinante.

Aplicações de Bloqueio

Neste cenário, algumas aplicações precisam de ser bloqueadas, por exemplo, servidores que são fontes de ataques. Para isso, é criado um perfil de Internet( no exemplo,aplicações maliciosas ) para identificar os endereços IP a bloquear. Em seguida, é definida uma política de fluxo de assinantes com ação de bloqueio (com o nome flow-block neste exemplo) e, por fim, o perfil da Internet e a política de fluxo de assinantes são combinados em uma regra de fluxo de assinantes.

Nota: o produto Bequant foi concebido para melhorar a qualidade das redes e não para bloquear conteúdos específicos, pelo que não é garantido que as suas assinaturas DPI predefinidas correspondam a todos os fluxos de um conteúdo específico. Além disso, a opção de bloqueio de fluxos pode não estar disponível em determinados países devido a restrições de exportação.

‍

‍

Excluir o tráfego da otimização TCP

O objetivo é que o BQN não optimize determinado tráfego. Por exemplo, alguns assinantes. Para isso, é definido um perfil de acesso(subs-no-tcpo no exemplo), com os endereços IP dos assinantes a serem excluídos. Em seguida, é definida uma política de fluxo de assinantes com a otimização definida como desativada(fluxo-no-tcpo no exemplo) e, então, o perfil de acesso e a política de fluxo de assinantes são combinados em uma regra de fluxo de assinantes.

Esta configuração é equivalente à lista negra de endereços IP no software BQN Versão 3.

Outro exemplo seria a utilização de um perfil da Internet para excluir algumas aplicações por porta TCP.

‍

Dar prioridade ao tráfego de teleconferências

Necessita de BQN R4.25 ou posterior.

Para tratar o tráfego de teleconferência com maior prioridade do que o resto, é necessário definir um DPI e perfis de Internet. São suportados o Zoom, o Microsoft Teams e o Google Meet. A imagem seguinte mostra as regras:

A política é definida com uma prioridade superior a zero:

Um exemplo de configuração está disponível aqui, com a lista completa de endereços IP e portas do perfil teleconf-ip-ports e a lista de assinaturas DPI do perfil teleconf-tcp. Guarde o ficheiro na sua máquina local utilizando a opção do browser Guardar como... e aplique-o indo a Administration->Backup->Load e selecionando a opção Merge .

Exemplo de conjunto de regras de política de fluxo

Necessita de BQN R4.25 ou posterior.

Segue-se um exemplo de um conjunto completo de regras que aplicam critérios razoáveis de gestão da largura de banda, em particular:

• É dada prioridade ao tráfego de teleconferência.
• As actualizações de software têm menos prioridade e, durante o horário de pico, ainda menos.
• Os testes de velocidade são efectuados com o limite total da taxa de subscrição.
• O streaming de vídeo está a impedir a utilização do limite de débito total.

Analisar as políticas:

A política flow-teleconf está definida como prioridade 1, superior à predefinição (0) e ainda superior à flow-updates-offpeak (-1) e flow-updates-peak(-2). Isto significa que o tráfego de teleconferência tem a maior prioridade e as actualizações de software têm a prioridade mais baixa (ainda mais baixa durante os períodos de pico de tráfego).

O Speedtest está limitado à velocidade total do plano (100%) e é permitido atingir essa velocidade mesmo quando, combinado com outro tráfego, excede o limite do plano(Skip Rate "yes").

A política de fluxo de vídeo limita o fluxo de vídeo a 90% do limite de taxa. A lógica é deixar alguma largura de banda para outros serviços. Além disso, a velocidade de um único fluxo é limitada a 10 Mbps.

Para além de terem uma prioridade mais baixa, os descarregamentos de SW estão limitados a 90% do plano tarifário e a 80% durante as horas de ponta.

Pode ajustar as percentagens de limite de velocidade e as prioridades relativas ao seu caso particular.

Está disponível um exemplo de configuração aqui. Guarde o ficheiro na sua máquina local utilizando a opção do browser Guardar como... e aplique-o indo a Administração->Cópia de segurança->Carregar e selecionando a opção Fundir.

‍

Pilha dupla IPv4/IPv6

A pilha dupla neste contexto consiste em sujeitar o tráfego IPv4 e IPv6 do mesmo assinante a um limite de taxa partilhado. O produto BQN suporta pilha dupla IPv4/IPv6 em RADIUS e em vários sistemas de faturação, mas é sempre possível suportar pilha dupla utilizando a API REST do BQN. A pilha dupla é implementada criando um grupo de assinantes por assinante, com os endereços IPv4 e IPv6 como membros e a política de tarifas do assinante como a política do grupo.

Por exemplo, para um assinante X com IPs 10.0.0.1 e 2001:abcd:ef00:1001::/64e política de tarifação "Plan-100Mbps":

curl -i -k -u myuser:mypw 
--request POST \
--urlhttps://some.bqn.net:3443/api/v1/subscriberGroups/DS-Customer-X \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '
{ 
  "subscriberMembers": [ "10.0.0.1", "2001:abcd:ef00:1001::" ],
  "policyRate": "Plan-100Mbps"
}'

Será criado um grupo de assinantes com o nome "DS-Customer-X". A política tarifária "Plan-100Mbps" deve ter sido criada através da API REST ou configurada diretamente nas políticas tarifárias dos assinantes BQN.

Note-se que, para os endereços IPv6, a máscara de sub-rede está implícita na lista "subscriberMembers". Este prefixo implícito é configurado em Administration->GeneralSettings e é 64 por defeito.

Se alguns subscritores tiverem sub-redes IPv6 com um prefixo diferente do dos restantes, este é suportado. Utilizar o campo "subscriberRanges":

curl -i -k -u myuser:mypw 
--request POST \
--urlhttps://some.bqn.net:3443/api/v1/subscriberGroups/DS-Customer-Y\
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '
{ 
  "subscriberMembers": [ "10.0.0.1"],
  "subscriberRanges": [ "2001:abcd:ef20::/48" ],
  "policyRate": "Plan-250Mbps"
}'

Tal como acontece com outras operações da API REST, pode modificar o grupo com um PUT:

curl -i -k -u myuser:mypw 
--request PUT \
--urlhttps://some.bqn.net:3443/api/v1/subscriberGroups/DS-Customer-X \
--header 'accept: application/json' \
--header 'content-type: application/json' \
--data '
{ 
  "policyRate": "Plan-500Mbps"
}'

Portal cativo

Discutimos os portais cativos no contexto da gestão de quotas. Neste exemplo, utilizaremos esse mecanismo para implementar redireccionamentos genéricos de portais cativos. Por genérico queremos dizer que um sistema externo poderá ativar ou desativar redireccionamentos de portal cativo por subscritor, utilizando a API REST do BQN.

Em primeiro lugar, definimos regras para excluir o tráfego do portal cativo dos blocos de quotas e dos limites dos grupos de assinantes:

Configuramos o portal cativo nas opções de Quota:

Precisamos de perfis para caraterizar dois tipos de tráfego:

• Tráfego do portal cativo: no exemplo, utilizámos o perfil DPI, mas se o endereço IP do portal cativo for conhecido, também pode ser utilizado um perfil Internet.
• Tráfego DNS para resolver o endereço do portal cativo: utilizamos um perfil de Internet.

Associamos esses perfis a uma política não sujeita a bloqueio de quotas, pelo que o tráfego do portal cativo passa:

Utilizaremos um grupo de subscritores onde colocaremos os subscritores com o portal cativo ativado, por exemplo, captive-group.

Agora, tudo o que precisamos de fazer para ativar o portal cativo é colocar o assinante no grupo cativo e definir uma quota de zero:

curl -i -k -u myuser:mypw --request PUT \
     --url https://some.bqn.net:3443/api/v1/subscribers/10.0.0.1 \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "quota": {"volume": 0},
  "subscriberGroups": ["captive-group"]
}
'

Note que a atribuição deve ser feita com base no endereço IP do assinante (10.0.0.1 neste exemplo).

Para desativar o portal cativo nesse subscritor, remova a quota e a associação ao grupo:

curl -i -k -u myuser:mypw --request PUT \
     --url https://some.bqn.net:3443/api/v1/subscribers/10.0.0.1 \
     --header 'accept: application/json' \
     --header 'content-type: application/json' \
     --data '
{
  "quota": {"volume": null},
  "subscriberGroups": []
}
'

‍

‍

‍

‍

‍