Problemas de instalação
Verifique o seguinte:
- A ISO deveria ter sido copiada para uma unidade USB com partições MBR e modo DD.
- A BIOS do servidor deve ter o seu modo de inicialização padrão de fábrica (por exemplo, DUAL).
- Se houver um controlador RAID, um disco lógico deve ser configurado e marcado como inicializável.
- Verificar se o servidor utilizado na instalação cumpre os requisitos de hardware BQN.
- Verificar se a instalação foi feita no disco rígido e não sobrescrever a unidade USB.
Sem acesso ao endereço IP de gerenciamento
O BQN utiliza uma interface de rede dedicada para a gestão. A interface de gestão suporta os serviços SSH e WEB (HTTPs). Em caso de problemas no acesso ao IP de gestão configurado, verifique o seguinte:
- Certifique-se de que a porta da interface de rede de gestão está ligada à rede adequada.
- Verifique se o estado da ligação da interface de rede de gestão está ativo. Se a interface de gestão estiver ligada a um comutador de rede, verifique se a porta do comutador está ativa e se os respectivos atributos correspondem às propriedades apresentadas pelo comando show interface.
- Se aceder ao endereço IP de gestão a partir de uma rede diferente, certifique-se de que o encaminhamento estático está configurado para a rede de acesso, conforme explicado na secção Interface de Rede no Guia do Utilizador.
- Se houver firewalls na rede de gestão, permitir o acesso à porta TCP 22 para o serviço SSH e à porta TCP 443 para o serviço WEB.
- Verificar utilizando a consola do sistema que o endereço IP de gestão e o prefixo de rede estão correctos. Ligar um monitor e um teclado ao servidor e iniciar sessão como raiz:
- Se suspeitar que as definições de IP do OAM estão incorrectas ou são desconhecidas, ligue um monitor e um teclado ao servidor e inicie sessão como raiz para o alterar utilizando o assistente bta em modo interactivo. Por exemplo, para alterar a interface de gestão para en0o1 com endereço IP 10.10.10.12/24 (prima enter para aceitar a resposta sugerida):
Se a interface não estiver disponível no momento da alteração (por exemplo, participou numa wire), uma mensagem solicitará uma reinicialização. Após a reinicialização, o BQN deverá ter o novo IP e a nova interface de rede de gestão.
- A interface de gestão da BQN pode estar protegida pela sua própria firewall. O problema pode ser o facto de o seu endereço IP de origem não estar incluído na lista branca da firewall. Isto pode acontecer mesmo para endereços da mesma sub-rede do IP de gestão da BQN se a sub-rede não fizer parte das regras da firewall. É possível desativar temporariamente a firewall até que a ligação à porta de gestão seja restabelecida. Ligue um monitor e um teclado ao servidor e inicie sessão como root:
Uma vez que o IP de gerenciamento esteja acessível, é possível definir a nova lista branca de gamas de IP de fonte permitida.
- If the command <span class="character-highlight">wizard bta interactive</span> fails, connect with a console and a keyboard and try changing the configuration directly. In the following example, the management interface is in en0o2 and we will move it to interface en0o1 and from IP address 192.168.0.121 to IP address 10.0.0.121, with default gateway 10.0.0.1:
Web não Acessível
- Verificar se o endereço IP de gerenciamento é acessível utilizando SSH,
- Verifique se está a utilizar HTTPS no acesso (HTTP não é suportado). Exemplo de URL: https://192.168.0.121
- Verifique se está a utilizar o utilizador bqnadm (a raiz não pode ser utilizada no acesso GUI).
- Ao instalar do zero, certifique-se de que o assistente de comando bta foi executado (caso contrário, o serviço web GUI não estará activo um utilizador sem bqnadm criado).
- Verificar que a porta SSH do servidor BQN não tenha sido modificada. Para aceder ao BQN utilizando uma porta diferente da 22, é possível definir regras de encaminhamento de portas no router no caminho de acesso, mas a porta SSH do BQN não pode ser alterada. Ao aceder ao servidor como root, pode verificar que a porta SSH é 22, como se segue:
Se necessário, comente a linha que especifica um porto que não seja 22.
- Verifique se o seu navegador é suportado (Edge, Firefox, Chrome). O MS Explorer, por exemplo, não é suportado.
Interface de Rede Down
Se o ícone de Interfaces de Rede no Painel não estiver em verde.
Ir para Configuração->Interfaces->Dados Wires
Em Vermelho (Crítico)
- Se não existir um wire configurado, crie um.
- Se houver wires configurado, mas suas interfaces não estiverem no estado UP, isso provavelmente indica que as interfaces não são compatíveis com Intel. Vá para Configuration->Interfaces->Data Wires e clique na interface descendente para ver o modelo(ID do fornecedor PCI) e confirmar que não é Intel. Remova o wire e crie um novo com ambas as interfaces no modo pcap. Isso deve colocar as interfaces no estado UP, mas com uma capacidade de transferência muito menor (menos de 1Gbps).
- Se existir wires configurado, com as interfaces em estado UP mas com o LINK down, existe um problema na ligação com o outro equipamento. Ligar as duas portas de interface uma à outra num loop, utilizando um cabo/fibra adequado. Se ambas as interfaces estiverem em up, então o problema está no outro equipamento.
Se a ligação ainda estiver em baixo e forem utilizadas portas ópticas, verificar se os transceptores:
- são compatíveis com a Intel
- são suportados (consulte a lista de placas de rede suportadas).
- do tipo exigido pela instalação (por exemplo, SFP+-LR numa instalação com fibra monomodo e SFP+-LR no outro lado).
Em Amarelo (Aviso)
- Se as wires aparecem como inativas deverem ter tráfego, siga os passos da secção anterior (Crítico)
- Se os wires aparecem como «inativos» não estiverem a ser utilizados e pretender remover o sinal de aviso, pode eliminar os wires não utilizados. Tenha em conta que as alterações na wire irão interromper o tráfego durante algum tempo (entre 10 segundos e dois minutos, dependendo da configuração do servidor).
Tráfego Invertido
Se o ícone «Tráfego Invertido» no Painel de Controlo estiver a laranja (Aviso), isso indica que o débito de tráfego na direção de subida é superior ao da direção de descida. Isto pode ser normal em pequenas implementações (menos de cem assinantes, como um BQN num laboratório), mas numa implementação de rede indica, muito provavelmente, que alguns dos wires ligados incorretamente, com a porta de acesso ligada ao lado da Internet e vice-versa.
Para verificar se é esse o caso, aceda a Estado->Interfaces->Capacidade de transmissão e verifique se as interfaces de acesso transmitem mais tráfego do que recebem e, inversamente, nas interfaces de Internet. Se não for esse o caso, isso indica que a wire invertida.
Para resolver o problema, vá a Configuração->Interfaces->Dados Wires e, na página wire invertida, prima o ícone Trocar interfaces.
Em «Estado» → «Interfaces» → «Capacidade de transmissão», deverá agora ser apresentado mais tráfego enviado do que tráfego recebido nas interfaces de acesso:
Baixo tráfego
O ícone «Baixo Tráfego » no Painel de Controlo está a amarelo e no estado «AVISO».
Passe o cursor do rato sobre o ícone para confirmar que é apresentado o aviso «Tráfego baixo ». Isso indica que há muito pouco tráfego a passar pelo servidor BQN. Isto é normal se o sistema ainda estiver à espera que o tráfego seja encaminhado através dele. No entanto, num sistema em produção, pode ser um indício de que alguma falha noutro ponto da rede está a impedir que o tráfego chegue ao servidor BQN.
Tráfego assimétrico
O tráfego assimétrico ocorre quando o servidor BQN deteta apenas uma das direções do tráfego (uplink ou downlink) e não a outra.
O tráfego assimétrico pode afetar todo o tráfego que passa pelo BQN ou apenas uma parte deste.
A otimização do TCP requer tráfego simétrico, pelo que a assimetria provoca uma degradação da experiência do assinante e o TCPO deve ser desativado no tráfego afetado enquanto o problema é resolvido.
Todo o tráfego é assimétrico
O ícone «Tráfego Baixo » no Painel de Controlo está a laranja e no estado «AVISO».
Passe o rato sobre o ícone. Se «Tráfego de subida» ou«Tráfego de descida» estiverem em estado de aviso, isso indica que não há tráfego a passar pelo BQN nessa direção e, por conseguinte, o tráfego é assimétrico. Se tanto «Tráfego de subida» como «Tráfego de descida» estiverem em estado de aviso, isso significa que não há tráfego, ou há muito pouco, a passar pelo BQN e não existe assimetria.
Para desativar o TCPO no tráfego afetado, aceda a Configuração->Definições de otimização e desative o botão «Otimização TCP global» até que o problema de encaminhamento de tráfego que está a causar a assimetria seja resolvido.
Algum tráfego é assimétrico
O ícone «Baixo Tráfego» no Painel de Controlo está verde, no estado NORMAL, mas, mesmo assim, recebem-se reclamações de clientes relativas à degradação do serviço.
Para confirmar se parte do tráfego é assimétrico, aceda a Status->Assinantes->Métricas de QoE e defina um filtro na tabela de assinantes para ver apenas os assinantes com 0 bytes nas direções de uplink (MBYTES-DOWN) ou de downlink (MBYTES-UP).
Ignore os endereços IP de multicast ou de difusão. No caso desses endereços IP, é perfeitamente normal observar tráfego apenas numa direção. Por exemplo, o endereço de difusão IPv4 255.255.255.255 ou o endereço de multicast de ligação local IPv6 ff02::,
Se observar endereços IP normais com 0 bytes numa direção e tráfego substancial na outra, esse endereço IP está a sofrer de tráfego assimétrico. Uma vez que o problema é normalmente causado por um encaminhamento incorreto do tráfego, outros endereços IP na mesma sub-rede também o sofreriam.
Para desativar o TCPO no tráfego afetado enquanto o encaminhamento é corrigido, aceda a Configuração->Fluxos de Assinantes e crie uma política de fluxo com a otimização TCP desativada; crie um Perfil de Acesso que inclua os endereços IP/intervalos de endereços dos assinantes afetados e associe-os a uma regra. Consulte os detalhes neste exemplo.
Gestor da licença
Se o ícone License Manager (Gestor de licenças ) no painel de controlo estiver a amarelo e o texto indicar "license-mgr-connection:notice", isso deve-se ao facto de o servidor BQN não conseguir aceder ao gestor de licenças. O gestor de licenças é responsável pela validação das licenças de software BQN e também ajuda o Bequant a fornecer um suporte mais proactivo, comunicando problemas do servidor.
Certifique-se de que o servidor BQN pode iniciar ligações de saída para o IP do Gestor de Licenças (contacte o suporte Bequant para obter mais informações).
Para verificar se é possível estabelecer uma ligação de saída, inicie sessão como root e execute um telnet para o endereço IP e a porta indicados:
A ligação via Telnet deverá ser bem-sucedida se o gestor de licenças estiver acessível.
Licença não OK
Se o ícone da Licença no Painel de Controlo estiver a vermelho e o texto indicar «license-available:critical»ou«license-expiration: critical», significa que não existe uma licença válida. Isto pode dever-se a várias razões:
- Não há nenhuma licença definida no nó
- A licença não é válida
- A licença já não é válida (a sua data final expirou).
Contacte o seu distribuidor para obter uma licença válida.
Pode verificar o estado da licença em Administração->Licença.
Quando não existe uma licença válida, o BQN encaminhará todo o tráfego de forma transparente: o serviço não será afectado, mas nenhum dos processamentos avançados do BQN será aplicado ao tráfego.
Limite de Licença Excedido
Se o ícone da Licença no Painel de Controlo estiver laranja e o texto indicar «license-usage: warning», significa que a capacidade máxima da licença está a ser excedida (o tráfego total no servidor BQN está acima do limite da licença).
Contacte o seu distribuidor para uma actualização da licença.
Pode verificar a capacidade da licença em Administração->Licença.
Em Statistics->Throughput->Overview, uma linha vermelha mostrará o limite da licença juntamente com os níveis de rendimento recentes.
A ultrapassagem do limite da licença deve ser temporária, enquanto a licença é actualizada para a capacidade correcta.
Quando o limite da licença é ultrapassado, o QoE não deixa cair nenhum pacote; simplesmente coloca-os em ponte.
O efeito no tráfego é diferente ao nível do fluxo e ao nível da sessão do assinante.
Efeitos ao nível do caudal:
- Enquanto o limite da licença estiver a ser excedido, os novos fluxos não terão licença.
- Os caudais existentes antes da ultrapassagem da licença não são afectados: se estavam a ser optimizados, continuam a sê-lo e o mesmo se passa sem licença.
- Quando o tráfego optimizado desce abaixo do limite, os novos fluxos são novamente optimizados.
- Os caudais existentes antes da licença que se encontravam abaixo do limite não são afectados: se não tinham licença continuam a ter e o mesmo acontece se estiverem a ser optimizados.
- Um fluxo sem licença tem:
- Sem TCPO
- Sem modelagem
- Não gera métricas (retransmissões, latências, DPI, etc.).
Efeitos a nível da sessão do assinante:
- Enquanto o limite de licenças estiver a ser excedido, as novas sessões de subscritores não terão qualquer licença.
- As sessões de assinantes existentes antes de se ter excedido o limite da licença permanecem, inicialmente, no seu estado atual: se estavam a ser otimizadas, continuam assim; e o mesmo se aplica caso não estivessem a ser otimizadas.
- Se a licença se mantiver acima do limite, as sessões de subscritor que estão a ser optimizadas podem passar a não ter licença se acumularem um grande número de fluxos não optimizados.
- Quando o tráfego optimizado desce abaixo do limite, as novas sessões de subscritores são novamente optimizadas.
- As sessões de assinantes que saem antes de a licença ficar abaixo do limite permanecem inicialmente no seu estado actual: se não tiverem licença, permanecem assim e o mesmo acontece se estiverem a ser optimizadas.
- Se a licença permanecer abaixo do limite, as sessões de assinante sem licença podem passar a ser optimizadas se acumularem um pequeno número de fluxos optimizados.
- Uma sessão de assinante sem licença apresenta:
- sem ACM,
- sem limitação de taxa
- continua a gerar os totais de volume de tráfego.
- A comunicação do volume das quotas está suspensa.
- Não haverá bloqueio quando a quota se esgotar.
- Os outros indicadores, como retransmissões, latências, etc., serão reduzidos aos valores dos fluxos que estão a ser otimizados.
- Uma sessão de assinante que esteja a ser optimizada será afetada pelo facto de alguns dos seus fluxos poderem não ter uma licença e, por conseguinte, o assinante pode ter um conjunto reduzido de medições em comparação com o funcionamento normal. Isto afecta o ACM e também as métricas geradas para esse assinante.
O efeito de exceder o limite licenciado é que cada vez mais tráfego deixará de obter a funcionalidade de QoE e, inversamente, a quantidade de tráfego que obtém a funcionalidade de QoE diminui. Quando a quantidade de tráfego que obtém a funcionalidade QoE estiver abaixo do limite da licença, os novos fluxos e as sessões de assinantes recuperarão a funcionalidade QoE. Isto continua até que o limite da licença seja excedido, após o que o efeito se repete novamente. Com este comportamento oscilante, a QoE continua a fornecer funcionalidade ao tráfego até ao limite da licença. O BQN está continuamente a verificar o nível de débito em relação aos limites da licença (a cada minuto ou menos), pelo que a adaptação é bastante rápida.
Carga elevada de CPU
Se o ícone da CPU no Painel não estiver a verde, algumas CPUs estão a funcionar a níveis anormalmente elevados. Isto deve-se normalmente a um tráfego desequilibrado (concentrado em poucos IPs de subscritores) ou a um excesso de tráfego a ser processado pelo servidor BQN.
O nível de rendimento pode ser verificado em Estatísticas->Rendimento->Visão geral e os níveis da CPU em Estatísticas->Sistema->CPU.
Existem dois tipos de alarme, dependendo dos níveis de carga da CPU:
- Laranja se alguns núcleos da CPU estiverem com uma carga elevada (utilização superior a 80 %).
- Vermelho se alguns núcleos da CPU estiverem com uma carga muito elevada (utilização superior a 90 %).
Em primeiro lugar, uma breve introdução à utilização básica do BQN.
Descobrir as afinidades dos núcleos da CPU: IOs e workers
No BQN, os processos críticos são executados com a máxima prioridade nos núcleos de CPU que lhes foram atribuídos. Este conceito é designado por «afinidades de núcleo». São atribuídos núcleos de CPU a dois processos:
- Processos de E/S: são responsáveis pelas operações de leitura e gravação dos pacotes de tráfego que entram e saem das portas da interface de rede.
- Workers: são os processos do plano de dados responsáveis por todo o processamento de pacotes (otimização TCP, ACM, vários limites de regulação de tráfego, inspeção DPI, etc.).
Os restantes processos BQN são executados em qualquer núcleo disponível, mas, no caso de um núcleo designado, o agendador pode interromper o processo de baixa prioridade para executar um de alta prioridade. Se o servidor tiver núcleos de CPU suficientes, alguns ficam sem atribuição para que possam ser dedicados a processos de baixa prioridade.
Para ver a afinidade dos núcleos da CPU no seu servidor, execute este comando:
Neste exemplo, o servidor tem 10 núcleos. Sete núcleos são atribuídos a processos de alta prioridade: seis para executar processos de trabalho e um para executar processos de E/S. Três núcleos ficam por atribuir, prontos para executar processos de baixa prioridade. A atribuição específica dos núcleos dependerá do número de núcleos da CPU, do número de wires da velocidade dessas wires. O BQN tentará efetuar a atribuição mais otimizada com base nessas variáveis. No exemplo, existe uma wire capacidade de débito wire 10 Gbps.
O campo de afinidade indica os núcleos atribuídos. No exemplo, o IO está no núcleo número 3, sendo 0 o primeiro núcleo (0x8 = 1000), e trata do tráfego de ambas as interfaces da wire. Os workers estão nos núcleos de 4 a 9 (0x3F0 = 1111110000). Os núcleos de 0 a 2 não estão atribuídos (núcleos de uso geral).
As instâncias dos processos de trabalho são numeradas a partir de um. No exemplo, a instância de trabalho n.º 1 está no núcleo 4 e a instância de trabalho n.º 6 no núcleo 9.
Pode ver qual a instância de trabalho que está a tratar de um assinante específico consultando a secção «Detalhes adicionais» no painel de controlo do assinante.
Descubra quais são os núcleos que estão sobrecarregados
Vá a Estatísticas->Sistema->CPU e identifique os núcleos da CPU cuja utilização seja superior a 80%. Analise as últimas 24 horas, pois a carga elevada pode ter ocorrido no passado.
Identifique se os núcleos da CPU afetados são IOs ou workers.
Por vezes, os picos de carga da CPU são breves e não são visíveis nas estatísticas do sistema, uma vez que estas apresentam uma média calculada em intervalos de 5 minutos. Aceda a Administração->Registos->Sistema.
Aumente o número de linhas (por exemplo, 1000 linhas) e defina a expressão regular positiva para filtrar «cpu». Isto deverá mostrar os alarmes de CPU gerados e, mais importante ainda, uma entrada de registo que indique qual o núcleo específico da CPU afetado. No exemplo seguinte, o código 6 entra em estado de alarme elevado devido a uma utilização de 94%:
O Core 6 é um trabalhador no nosso exemplo.
Elevada carga nos núcleos da CPU dos trabalhadores
O culpado habitual é o tráfego desequilibrado. O BQN utiliza os endereços IP dos assinantes para distribuir o tráfego pelos trabalhadores disponíveis. Se alguns endereços IP concentrarem demasiado tráfego, os trabalhadores que os processam podem ficar sobrecarregados.
Vá a Estatísticas->Assinantes->Principais por tempo para ver como o tráfego se distribui entre os assinantes com maior utilização. Verifique se os principais concentram muito mais tráfego do que os restantes.
Para confirmar, clique com o botão direito do rato nos IPs com maior utilização para aceder ao painel de controlo do respetivo assinante e verifique o número da instância em «Detalhes adicionais». Por exemplo, no exemplo que estamos a seguir, se o núcleo de trabalho for o número 6, a instância esperada é a 3. A instância deve corresponder à indicada nos registos do sistema.
Se não for detetado qualquer tráfego desequilibrado, o problema poderá ser causado por níveis elevados de tráfego em geral. Nesse caso, o núcleo de trabalho com carga elevada irá variar de tempos a tempos. Aceda a Estatísticas->Rendimento->Visão geral e verifique se os picos de tráfego correspondem aos picos de trabalho.
Poderá ser necessária uma atualização do hardware. Contacte o suporte Bequant .
Entretanto, o BQN dispõe de mecanismos internos para mitigar a elevada carga nos núcleos de trabalho, procurando evitar perdas de tráfego através da redução do volume de tráfego otimizado.
Outras medidas de mitigação que pode tomar enquanto aguarda a atualização do hardware:
- Ative o desvio para os endereços IP que estão a causar a sobrecarga. O tráfego desses endereços IP não será otimizado nem sujeito a limitação de taxa, mas a carga dos núcleos afetados deverá ser reduzida, uma vez que não será efetuado qualquer processamento de tráfego nos workers para esses endereços IP.
- Se estiver a utilizar NAT entre a BQN e os assinantes finais, aumente o número de endereços IP utilizados pelo NAT, para que a BQN possa distribuir o tráfego por mais endereços.
Se o servidor BQN for utilizado apenas para TCPO e/ou limites de velocidade por fluxo, a distribuição da carga da CPU pode ser melhorada ativando o direcionamento por fluxo. O direcionamento por fluxo distribui a carga de tráfego pelos núcleos da CPU por cada fluxo individual, em vez da distribuição de tráfego por assinante, que é a predefinição. Isto melhora o equilíbrio da carga da CPU, mas, como o controlo por assinante é feito por núcleo, não permite o controlo ao nível do assinante, como o ACM, as taxas de política ou os limites de fluxo por assinante.
Elevada carga de E/S nos núcleos da CPU
Uma carga elevada nos núcleos de E/S constitui um problema crítico, uma vez que alguns pacotes não serão retransmitidos e, por conseguinte, serão descartados devido à capacidade de processamento insuficiente dos núcleos.
O problema é normalmente causado por níveis elevados de tráfego. Aceda a Estatísticas → Rendimento → Visão geral paraverificar se os picos de tráfego correspondem aos picos nos núcleos de E/S afetados.
Outra possibilidade é que a interface de rede no servidor BQN não suporte a distribuição da carga de tráfego entre vários processos de E/S. Isto acontece com o tráfego PPPoE em alguns modelos de placas de rede. Ver Interfaces de rede suportadas e Resolução de problemas do XL710.
Outra causa possível é uma wire modo pcap, o que limita a sua capacidade a cerca de 1 Gbps de largura de banda1. Se se tratar de uma configuração incorreta e a placa de rede for compatível com a Intel, aceda a Configuração->Interfaces-> Wires de Dados e altere a wire o modo normal (DPDK).
Poderá ser necessária uma atualização do hardware. Contacte o suporte Bequant .
Entretanto, uma medida possível consiste em alterar as afinidades dos núcleos da CPU, reatribuindo núcleos de trabalho ou núcleos não atribuídos aos processos de E/S. O apoio técnico da Bequant irá ajudá-lo nessa tarefa.
Carga alta de memória
Se o ícone da Memória no Painel de Controlo não estiver a verde, significa que alguns processos estão a ficar sem memória.
Existem dois tipos de alarme, dependendo dos níveis de carga da memória:
- Laranja se alguns processos atingirem uma utilização elevada (acima de 90% de utilização).
- Vermelho se alguns processos atingirem uma utilização muito elevada (acima de 95% de utilização).
Verificar a utilização da memória
Vá a Estatísticas->Sistema->Memória e identifique qual é a memória cujo consumo está acima do limiar. Analise as últimas 24 horas, pois o consumo elevado pode ter ocorrido no passado.
A memória do sistema está dividida em três secções:
- Pool do DPDK: é a memória do sistema reservada para a biblioteca DPDK e onde são armazenados os pacotes de tráfego. Em servidores NUMA, cada NUMA terá o seu próprio pool do DPDK para armazenar o tráfego relacionado com as placas de rede instaladas nesse NUMA.
- Pool de memória (mpool): é a memória do sistema utilizada pelos processos de trabalho para armazenar informações sobre fluxos, assinantes e metadados de tráfego.
- Resto da memória do sistema (20% do total): é utilizada pelo resto do sistema, por exemplo, pelo gestor de API que interage com sistemas de faturação externos, tarefas de gestão, etc.
Uma causa comum do elevado consumo de memória é o débito de tráfego excessivo. Verifique se os picos em Estatísticas → Débito → Visão geral correspondem aos picos em Estatísticas → Sistema → Memória.
Por vezes, os picos de utilização de memória são breves e não são visíveis nas estatísticas do sistema, uma vez que estas apresentam uma média calculada em intervalos de 5 minutos. Aceda a Administração->Registos->Sistema.
Aumente o número de linhas (por exemplo, 1000 linhas) e defina a expressão regular positiva para filtrar por «memória». Isto deverá mostrar os alarmes de memória gerados
Uma entrada no registo que indica que o conjunto DPDK está a registar uma utilização elevada tem o seguinte aspeto (neste exemplo, o conjunto DPDK apresenta uma utilização de 92%):
O conjunto de recursos do DPDK é partilhado por todos os workers e, por isso, o facto de o alarme ter sido gerado quando a instância 2 do worker estava a efetuar uma consulta não significa que seja a instância 3 a responsável pelo elevado consumo de recursos.
Uma entrada no registo que indica que o mpool está a apresentar uma utilização elevada tem o seguinte aspeto (neste exemplo, o mpool apresenta uma utilização de 96%):
O mpool é dividido igualmente entre todos os workers, cada um com o seu próprio subpool e, por conseguinte, a instância do worker onde o alarme é gerado é a responsável pelo elevado consumo (instância do worker 3 no nosso exemplo).
Poderá ser necessária uma atualização do hardware. Contacte o suporte Bequant .
Entretanto, o BQN dispõe de mecanismos internos para mitigar o elevado consumo de memória, procurando evitar perdas de tráfego através da redução da quantidade de tráfego otimizado.
Elevada utilização do pool DPDK
Isto pode ser causado por uma configuração NUMA incorreta: em servidores NUMA, espera-se que as placas de rede estejam distribuídas pelos dois NUMA. Se todas as placas de rede estiverem no mesmo NUMA, o conjunto DPDK do outro NUMA não será utilizado, enquanto o conjunto DPDK do NUMA que contém todas as placas de rede apresentará uma elevada taxa de utilização.
Para resolver o problema, as placas de rede devem ser reatribuídas, de modo a ficarem distribuídas entre as duas zonas NUMA do servidor. O apoio técnico da Bequant irá ajudá-lo nessa tarefa e também no ajuste fino da utilização do conjunto DPDK, entretanto. Além disso, é possível encaminhar parte do tráfego para o bypass, acedendo a «Configuração» → «Definições de otimização».
Utilização elevada do mpool
Se apenas algumas instâncias de trabalho estiverem envolvidas no problema, este poderá ser causado por um tráfego desequilibrado. O BQN utiliza os endereços IP dos assinantes para distribuir o tráfego pelos trabalhadores disponíveis. Se alguns endereços IP concentrarem demasiado tráfego, os trabalhadores que os processam podem ficar sem memória.
Vá a Estatísticas → Assinantes → Topo por Tempo para ver como o tráfego se distribui entre os assinantes com maior utilização. Verifique se os que estão no topo concentram muito mais tráfego do que os restantes.
Para confirmar, clique com o botão direito do rato nos IPs com maior utilização para aceder ao painel de controlo do respetivo assinante e verifique o número da instância na secção «Detalhes adicionais». Por exemplo, no exemplo que estamos a seguir, será a instância 3. A instância deve corresponder à indicada nos registos do sistema.
Uma utilização elevada do mpool também pode ser causada por um nível elevado de assinantes simultâneos e/ou de fluxos de tráfego.
Este problema exigirá uma atualização de hardware. Entretanto, os endereços IP com tráfego concentrado podem ser colocados em bypass, acedendo a Configuração -> Definições de otimização.
Elevada utilização da memória do sistema
Isto pode ser causado por um elevado nível de tráfego, fluxos simultâneos de assinantes e/ou de tráfego e pela troca de dados de sincronização com sistemas de faturação externos.
A memória será transferida para o disco, o que irá abrandar significativamente o servidor; por isso, a ação recomendada é aceder a «Configuração» → «Definições de otimização» e ativar o desvio de todo o tráfego enquanto a memória estiver a ser atualizada.
Sem sincronização RADIUS
O RADIUS está configurado em «Configurar» → «RADIUS/REST/Faturação», mas não se encontram informações sobre o RADIUS em «Estado» → «Assinantes» → «Atributos do assinante»: ao filtrar por «Atribuído pelo RADIUS», não aparece nenhum assinante.
Verificar a receção do tráfego RADIUS
Capture o tráfego RADIUS em Status->Interfaces->Link State, selecionando a interface de gestão (aquela com a coluna MGT marcada) e utilizando «porta 1812 ou porta 1813» como filtro:
Defina o tempo limite de captura para um período superior ao seu intervalo contabilístico intermédio.
Também é possível capturar o tráfego RADIUS através da CLI. Ligue-se via SSH:
Se não for capturado qualquer tráfego, as mensagens RADIUS não estão a chegar ao servidor BQN. . Consulte a secção seguinte.
Não foram recebidas mensagens RADIUS
Se a firewall do BQN estiver configurada (Configuração->Interfaces->Firewall de gestão), todos os endereços IP dos clientes RADIUS devem ser adicionados (neste exemplo, 10.10.10.10 e 10.10.10.11).
Se as mensagens RADIUS continuarem a não ser recebidas, é necessário verificar os restantes saltos de tráfego. No nosso exemplo, os clientes RADIUS encontram-se na sub-rede 10.10.10.0/24 e o BQN na sub-rede 192.168.0.0/24. Verifique se existe uma rota válida entre as duas sub-redes e se nenhum firewall intermédio está a bloquear a porta UDP 1813 (contabilização RADIUS) e, se estiver no modo de proxy RADIUS, a porta UDP 1812 (autenticação RADIUS).
Verifique o registo do sistema
Se forem recebidas mensagens RADIUS, mas sem sincronização RADIUS, verifique os registos do sistema.
Vá a Administração->Registos->Sistema e utilize a expressão regular «RADIUS».
Se não for encontrada nenhuma entrada no registo do sistema, pode aumentar o seu nível. Aceda ao servidor BQN através de SSH:
Aguarde algum tempo e volte a verificar em Administração->Registos->Sistema, utilizando a expressão regular «RADIUS».
Por exemplo, esta entrada no registo indica que o endereço IP 10.10.10.10 é desconhecido:
Vá a Configuração->RADIUS/REST/Faturação->RADIUS e adicione o endereço como um cliente RADIUS válido.
Esta outra entrada no registo indica que o segredo utilizado pelo cliente não corresponde ao que consta no BQN:
Aceda a Configuração->RADIUS/REST/Faturação->RADIUS e verifique se o segredo do cliente RADIUS está correto.
Ativar os registos da API
Se forem recebidas mensagens RADIUS, mas sem sincronização RADIUS, uma alternativa aos registos do sistema são os registos da API.
Aceda ao shell do servidor BQN através do SSH:
E consulte os registos da API com o comando:
Um exemplo de uma mensagem «Accounting Start» recebida com sucesso e da resposta correspondente do BQN ao cliente RADIUS:
A mensagem RADIUS associa a política de débito RA-30M/40M-60M/80M-50M/70M-2/3 ao endereço IP do assinante 10.0.0.1.
Segue-se um exemplo de uma mensagem «Accounting Start» recebida que foi processada e à qual foi dada uma resposta «OK», mas com um problema no nome da taxa de política:
Não foi possível extrair o nome da política de taxa da mensagem RADIUS: policyName (n/a). Se isto acontecer, consulte a secção «Verificar os parâmetros AVP».
Verificar os parâmetros AVP do RADIUS
Se forem recebidas e aceites mensagens RADIUS, mas o BQN não apresentar quaisquer atributos provenientes do RADIUS, verifique nas capturas de tráfego RADIUS recebidas se as mensagens contêm os AVP esperados.
Além disso, aceda a Configuração->RADIUS/REST/Faturação->RADIUS e verifique, na secção «Seleção de AVP», se o AVP com a política de tarifas está listado (e, por conseguinte, é suportado pelo BQN) e se não está a ser ignorado. Por exemplo, se for utilizado o AVP «Mikrotik-Rate-Limit»:
Sem sincronização REST
O REST está configurado em Configurar->RADIUS/REST/Faturação->REST, mas não são encontradas informações sobre o REST emEstado->Assinantes->Atributos do Assinante: ao filtrar por «Atribuído pelo REST» , não aparece nenhum assinante.
Verificar a receção do tráfego REST
Capture o tráfego REST em Status->Interfaces->Link State, selecionando a interface de gestão (aquela com a coluna MGT marcada) e utilizando «tcp e porta 3443» como filtro:
Envie algumas consultas REST para o endereço IP do BQN OAM.
Também é possível capturar o tráfego REST utilizando a CLI. Estabeleça ligação via SSH:
Se não for capturado qualquer tráfego, as mensagens REST não estão a chegar ao servidor BQN. Consulte a secção seguinte.
Não foram recebidas mensagens REST
Se a firewall do BQN estiver configurada (Configuração->Interfaces->Firewall de gestão), todos os endereços IP dos clientes REST devem ser adicionados (neste exemplo, 10.10.10.10 e 10.10.10.11).
Se as mensagens REST continuarem a não ser recebidas, é necessário verificar os restantes saltos de tráfego. No nosso exemplo, os clientes REST encontram-se na sub-rede 10.10.10.0/24 e o BQN na sub-rede 192.168.0.0/24. Verifique se existe uma rota válida entre as duas sub-redes e se nenhum firewall intermédio está a bloquear a porta TCP 3443.
Verifique o registo do sistema
Se forem recebidas mensagens REST, mas sem sincronização REST, verifique os registos do sistema.
Vá a Administração->Registos->Sistema e utilize a expressão regular «REST|HTTP».
Se não for encontrada nenhuma entrada no registo do sistema, pode aumentar o seu nível. Aceda ao servidor BQN através de SSH:
Aguarde algum tempo e volte a verificar em Administração->Registos->Sistema, utilizando a expressão regular «REST|HTTP».
Por exemplo, esta entrada no registo indica que o endereço IP 10.10.10.10i é desconhecido:
Aceda a Configuração->RADIUS/REST/Faturação->REST e certifique-se de que o endereço corresponde a um cliente REST válido.
Esta outra entrada no registo indica que o nome de utilizador ou a palavra-passe do utilizador estão incorretos:
Aceda a Configuração->RADIUS/REST/Faturação->REST e verifique se o nome de utilizador e as palavras-passe de utilizador são os mesmos utilizados pelo cliente REST.
Ativar os registos da API
Se forem recebidas mensagens REST, mas sem sincronização RADIUS, uma alternativa aos registos do sistema são os registos da API.
Aceda ao shell do servidor BQN através do SSH:
E consulte os registos da API com o comando:
Um exemplo de uma consulta REST recebida com sucesso e da resposta BQN:
Segue-se um exemplo de uma consulta REST recebida com um URI desconhecido (a consulta não foi formulada corretamente):
Ativar os registos da API
Se tivermos identificado que existe um problema numa das solicitações, podemos descobrir qual delas está a causar o problema ativando os registos de API. Isto irá gerar um ficheiro de registo para cada solicitação ou resposta.
Aceda ao shell do servidor BQN através do SSH:
Além disso, o BQN irá gerar registos das últimas 5 solicitações e respostas REST. Os registos podem ser encontrados no diretório /opt/bqn/var/trace. Inicie sessão através do ssh:
A primeira solicitação/resposta está correta:
A segunda solicitação/resposta apresenta um erro:
The POST request has a wrong body. Review the REST clientPOST request and compare it with the REST API reference manual. In this example,the POST body had a typo (double quotes after value missing): {"subscriberId": "myid}
Problema com a emissão do certificado REST
Se uma solicitação à API REST receber um erro relacionado com a verificação do certificado, por exemplo:
A razão é que o certificado BQN é auto-assinado e o cliente deve desativar a validação do certificado. Por exemplo, usando curl:
E usando python:
Versão TLS do REST
A BQN utiliza o TLS 1.2. Algumas versões novas do python rejeitam o TLS 1.2 por defeito. Para o fazer aceitar, use o seguinte código:
Um exemplo completo desta situação pode ser encontrado aqui.
Sem sincronização de faturação
Se o sistema de facturação estiver configurado e o ícone de facturação no Painel de instrumentos estiver vermelho, o acesso ao sistema de facturação está a falhar.
Clique no ícone de faturação para aceder à página de estado da faturação:
Neste exemplo, houve uma sincronização bem-sucedida às 12:13:52, recuperando 1000 subscritores, mas houve uma tentativa falhada depois disso. Pode forçar uma tentativa de sincronização premindo o botão Sincronizar agora.
Se a falha persistir, siga estes passos:
- Verifique as credenciais de acesso ao sistema de faturação: chave API, nome de utilizador/palavra-passe, etc. Estas credenciais têm de estar registadas no sistema de faturação.
- Em alguns sistemas de faturação (por exemplo, o Splynx), é necessário conceder acesso a chamadas específicas da API REST.
- Em alguns sistemas de faturação (por exemplo, o Azotel), o endereço IP de origem a partir do qual se acede ao sistema de faturação também tem de ser autorizado. Trata-se do endereço IP público que acede ao sistema de faturação a partir do endereço de gestão do BQN (o mesmo, caso o servidor BQN utilize um endereço IP público).
- Verifique se é possível determinar o endereço IP do servidor de faturação. Caso contrário, o BQN apresentará 0.0.0.0 no campo «Servidor» do «Estado da faturação». Isto pode dever-se a um nome de servidor desconhecido ou ao facto de o BQN não ter nenhum servidor DNS configurado. Para configurar um servidor DNS, aceda à página da interface de gestão.
- Verificar se o endereço IP de facturação está acessível a partir do servidor BQN:
Verifique o registo do sistema
Vá a Administração->Registos->Sistema e utilize a expressão regular «billing».
Se houver algum problema ao aceder ao servidor de faturação, irá ver uma mensagem do tipo:
Se não for encontrada nenhuma entrada no registo do sistema, pode aumentar o seu nível. Acesso ao servidor BQN via SSH:
Aguarde algum tempo e volte a verificar em Administração->Registos->Sistema, utilizando a expressão regular «billing»:
Neste primeiro exemplo, um pedido devolveu um erro: o código HTTP é 200, mas contém o código de erro ao nível da REST RATE_LIMITED.
E se pesquisar por %ERR-EINVAL:
A BQN queixa-se de que não consegue obter as «contas» do sistema de faturação.
Estes dois registos revelam a causa principal: o problema ocorre porque a chave da API excedeu o seu limite de solicitações. A solução seria aumentar esse limite.
Outro exemplo de um erro de pedido:
Neste caso, o sistema de faturação devolve um código HTTP 401 com o código interno UNAUTHORIZED. Assim, a causa principal neste outro exemplo reside nas credenciais de acesso: ou a chave API ou as credenciais complementares estão incorretas, ou o BQN está a aceder ao sistema de faturação a partir de um endereço IP não autorizado.
Ativar os registos da API
Se o servidor de faturação estiver acessível, mas a sincronização falhar e não for encontrada nenhuma entrada no syslog, aprofunde a análise ativando os registos da API. Aceda ao shell do servidor BQN através do ssh:
E consulte os registos da API com o comando:
Um exemplo de um pedido bem-sucedido (POST para obter o conjunto «produtos», neste caso):
E um exemplo de um pedido sem sucesso (relacionado com uma tentativa de consultar as «contas» de faturação):
Ativar os registos da API
Se tivermos identificado que existe um problema numa das solicitações, podemos descobrir qual delas está a causar o problema ativando os registos da API. Isto irá gerar um ficheiro de registo para cada solicitação ou resposta.
Aceda ao shell do servidor BQN através do SSH:
Além disso, o BQN irá gerar registos das últimas 5 solicitações e 5 respostas entre o BQN e o sistema de faturação. Os registos podem ser encontrados no diretório /opt/bqn/var/trace. Inicie sessão através do ssh.
Procure um pedido relacionado com «contas»:
E assim que identificarmos o pedido (0001 neste exemplo), verifique a resposta com o mesmo ID:
Neste caso, o problema ocorre porque a chave da API excedeu o seu limite de solicitações. A solução seria aumentar esse limite.
Interaja diretamente com o servidor de faturação utilizando o curl
Se a causa do problema ainda for desconhecida, pode enviar um pedido diretamente para o sistema de faturação utilizando o comando «curl» do Linux. Pode fazê-lo a partir de um servidor diferente do servidor BQN, a menos que o sistema de faturação só seja acessível a partir do BQN. Esta tarefa requer conhecimentos especializados sobre o sistema de faturação e as convenções de pedidos da API. Por exemplo, para enviar uma consulta a um sistema de faturação da Azotel:
Sem Servidores NTP Sincronizados
Se o ícone do NTP for amarelo, o NTP não está configurado. Clique no ícone para ir para a página de configuração.
Se os servidores NTP estiverem configurados mas o BQN não puder sincronizar-se com nenhum deles, o ícone NTP no travessão estará em laranja:
Uma mudança abrupta na hora do sistema devido à falta de sincronização NTP pode levar a breves perdas de serviço enquanto o sistema se ajusta. Para evitar que isso aconteça, tenha sempre pelo menos um servidor NTP em sincronia.
Pode verificar a lista de servidores NTP configurados em Administração->Data do Sistema->Servidores NTP.
Pelo menos um servidor NTP deve ser sincronizado. No exemplo acima, o servidor NTP 145.238.203.14 foi escolhido para sincronização do relógio (indicado pelo * ao lado do endereço IP do servidor) e foi contactado há 36 segundos (coluna QUANDO).
Se nenhum servidor NTP estiver disponível, o BQN mostrará a mensagem de aviso NTP não sincronizada, como na janela abaixo:
To solve the issue, if you have a local NTP server, add it to the list clicking the <i class="fa-solid fa-ellipsis-vertical"></i> menu icon and selecting Add Server…
Se não tiver servidores NTP locais, certifique-se que a porta UDP 123 está aberta desde o IP de gestão BQN até à Internet, incluindo na firewall BQN, se estiver activada.
A coluna REACH indicará as tentativas bem-sucedidas de contacto com o servidor. Um 0 indica que o servidor está inacessível.
Se um servidor NTP não parecer estar sincronizado, apesar de estar acessível, tente eliminá-lo e adicioná-lo novamente.
Enquanto se resolve a falta de sincronização NTP, verifique a hora e a data atuais na secção «Hora do sistema» do Painel de Controlo e compare-as com a hora atual. Se a diferença for pequena, não se trata de um problema crítico, embora deva ser resolvido para evitar que se torne urgente no futuro.
Problemas com o disco
Para verificar o estado do disco do sistema, clique no ícone DISCO do painel de controlo:
O ícone do disco fica a laranja (estado de aviso) quando menos de 15% do armazenamento do disco está livre.
A placa de rede Intel XL710 não atinge 40 Gbps de tráfego PPPoE
Uma placa de rede Intel XL710 que lida com tráfego PPPoE pode estar limitada a 10 Gbps de taxa de transferência, apesar de ter negociado um link de 40 Gbps. Uma possível razão é que a placa não está fazendo o balanceamento de carga do tráfego PPPoE e os pacotes são entregues a um único processo, limitando a taxa de transferência máxima.
A funcionalidade de distribuição de pacotes na placa Intel é implementada pela Intel Dynamic Device Personalization (DDP). Três condições devem ser atendidas:
- O pacote BQN bqnkernel deve ser R3.0.19 ou posterior. Requer uma reinicialização do sistema após a instalação do pacote.
- A versão de firmware da placa deve suportar DDP com balanceamento de carga PPPoE (ver secção abaixo).
- O pacote BQN bqn deve ser R4.27 ou posterior.
Atualização do firmware da placa de rede
O seguinte procedimento de atualização de firmware funciona apenas com placas de rede Intel. As placas de rede de outros fornecedores que não a Intel que utilizam um chipset Intel não podem ser actualizadas através deste procedimento.
A distribuição PPPoE requer a versão 7.0 do firmware e a versão 1.1.6.1 do DDP (em teoria, a versão 6.01 do firmware também funcionaria, mas tal não foi verificado no nosso laboratório).
O procedimento seguinte implica a interrupção do tráfego e a reinicialização do servidor, pelo que o servidor BQN deve ser retirado do caminho do tráfego.
Primeiro, para verificar a versão do firmware da placa, as portas de interface XL710 devem estar acessíveis pelo sistema operativo, ou seja, não estar sob o controlo do DPDK. Portanto, se alguma das portas de interface fizer parte de um wire, ela deve ser colocada no modo pcap. Na GUI do BQN, vá para Configuração->Interfaces-> Wires de dados e remova os wires portas dessa placa de rede e crie-os novamente com as portas no modo pcap.
Depois de fazer isso, as interfaces devem ficar visíveis e a versão do firmware pode ser obtida usando o comando ethtool:
Neste exemplo, a versão do firmware é 5.0 e o cartão necessita de uma atualização. O resto da secção descreve como o fazer.
Para fazer uma atualização de firmware, o servidor tem de arrancar para que o kernel do SO permita tais alterações. Faça uma cópia de segurança do ficheiro de configuração do grub antes de o editar:
Na primeira entrada do menu, adicione iomem=relaxed na linha linuxboot . A linha ficará semelhante a esta:
Guarde o ficheiro e reinicie o servidor.
Descarregue a ferramenta de atualização Intel para a família X700 para o seu PC, descompacte-a e transfira o pacote Linux para o servidor BQN. Exemplo:
Aceda ao servidor BQN para descompactar o tarball e executar a ferramenta de atualização:
A ferramenta irá guiá-lo através do processo de atualização do firmware para todas as placas de rede X710 detectadas no sistema.
Após concluir a atualização do firmware, restaure os wires o modo normal (sem pcap). Na GUI do BQN, vá para Configuração->Interfaces->Fios de dados e remova os wires portas dessa placa de rede e crie-os novamente com as portas no modo normal (caixa pcap desmarcada).
Remova o parâmetro iomem=relaxed do ficheiro de configuração do grub e reinicie o sistema:
Verificar se a distribuição de carga PPPoE está activada
Uma vez que o firmware de rede, os pacotes bqnkernel e bqn estejam na versão correta, a distribuição de carga do tráfego PPPoE deve ser habilitada em cada porta de rede do XL710 por padrão. Por exemplo:
O comando show indica que existe um perfil DDP (para PPPoE) e que a distribuição de carga está ativada.
Desativar a distribuição de carga PPPoE
Se houver algum problema com a placa de rede e o perfil DDP, o DDP pode ser desativado usando o comando no ddp pppoe em todas as portas da placa de rede, seguido pela reinicialização da interface do sistema ddp em qualquer uma dessas interfaces. Por exemplo:
A interface do sistema de comando ddp reset descarrega o perfil DDP sem a necessidade de reiniciar o sistema. Observe que basta aplicá-lo a uma das portas para reiniciar toda a placa de rede.
Se o problema persistir, mantenha a opção no ddp pppoe em todas as portas da placa de rede e reinicie o sistema.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.