FAQ

Sim, para implementar mais de 100 Gb/s em um único servidor. É possível usar 2,4 soquetes e atingir 400 Gbps. É preferível usar sistemas uniprocessadores com um número suficiente de núcleos.

Você precisa desativar o Hyper-Threading para a operação correta do Stingray. O SSH funciona somente com núcleos de processadores físicos.

Sim, você pode. As funções BRAS/BNG e DPI podem ser controladas por sub-rede ou por um sistema autônomo, e isso pode ser configurado.

O banco de dados do Stingray SG contém a correspondência de todos os endereços com seus sistemas autônomos, para que você possa entender a qual ASN o tráfego pertence e correlacionar isso com a localização geográfica do proprietário do AS. No momento, não há integração direta com os serviços de localização de IP por localização geográfica.

Sugere-se usar o agente SNMP, que é instalado no servidor para enviar informações ao sistema existente do operador.

Muitas operadoras de telecomunicações usam o sistema de monitoramento Zabbix. Nesse caso, o zabbix-agent é instalado nos servidores da plataforma, sua configuração padrão e a conexão com o servidor zabbix são realizadas. Como modelo, você deve usar o modelo padrão “Template OS Linux” – para monitorar os parâmetros principais. E também conectar um modelo personalizado “Template DPI”, que permite monitorar parâmetros específicos do fastDPI. A disponibilidade do zabbix-agent para a plataforma permite que você use todo o poder desse sistema de monitoramento.

Há as seguintes opções para receber e processar estatísticas:

• Produto gratuito NFSEN em conjunto com NFDUMP – adequado apenas para receber NetFlow v5 para analisar estatísticas por protocolo e direção.
• Ipfixreceiver – usado para receber IPFIX e armazená-lo em um arquivo local.
• Módulo QoE Stor em conjunto com a GUI DPIUI2.

Recomendamos o uso do QoE Stor para obter o máximo efeito das estatísticas carregadas do módulo DPI.

O NetFlow é enviado ao coletor a partir de uma interface DPI dedicada, normalmente a interface mgmt, que é usada para acesso SSH, integração RADIUS, etc.

*Só pode haver um fluxo do mesmo tipo. Se for necessário enviar para várias fontes, a reexportação do módulo QoE ou de outros coletores é usada.

A largura de banda necessária para exportar dados do NetFlow normalmente é inferior a 0,5% do consumo total de largura de banda. Por exemplo, se você estiver monitorando um link que usa 100 Gbps, o DPI usará menos de 0,5 Gbps para exportar dados do NetFlow.

A DPI acumula estatísticas e as transmite ao coletor em uma frequência especificada. Com base nos princípios de operação do DPI, as estatísticas sempre serão carregadas com algum atraso, dependendo dos intervalos de tempo definidos no arquivo de configuração.

• Insere banners de publicidade
• Bloqueio de anúncios
• Listas de sites permitidos e não permitidos
• Notificação de assinantes (para solicitações via HTTP)
• Caching
• Proteção DDoS
• Coleta de estatísticas NetFlow para faturamento, contabilidade
• CG-NAT
• Registro do tráfego de assinantes no PCAP
• ACL (mini firewall)
• Desvio de tráfego para plataformas externas
• Proporcionar atividades de marketing

Se for necessário lidar com mais tráfego do que a capacidade de uma plataforma DPI (100G full-duplex), serão instalados módulos DPI adicionais. Para a operação correta, é necessário cumprir a condição de organizar a simetria do tráfego (todos os pacotes em uma sessão devem passar por um dispositivo DPI). A simetria pode ser obtida por meio do balanceamento de IP SRC / DST em switches e roteadores ou pela instalação de balanceadores especiais – Packet Broker.

É possível transferir o tráfego de/para os Assinantes para a plataforma por meio de um “espelho” usando um divisor óptico ou o modo SPAN no roteador. Nesse modo, a plataforma pode fornecer filtragem por listas de blocos (semelhante ao modo “assimétrico”), coleta de estatísticas sobre o tráfego no QoE Stor, notificação de assinantes via HTTP Redirect.

O monitor Radius, que carrega pacotes de IP-Login para o UDR DPI, é usado para obter informações sobre o IP pertencente aos logins.

Os pacotes IP são enviados para clientes e hosts a partir de uma porta de resposta que é usada para implementar filtragem e notificações.

*É necessário saber que a interface de rede da plataforma só funcionará para “receber” tráfego. Assim, por exemplo, se nesse modo for aplicada uma porta de 10 Gbps, o tráfego “espelhado” será de 8 Gbps de entrada (para assinantes) e 5 Gbps de saída (de assinantes), então o tráfego total será de 13 Gbps, o que é claramente maior do que os recursos da porta física de recebimento.

Em alguns esquemas de uso da plataforma DPI, é possível usar somente o tráfego de saída dos assinantes. Essas opções incluem o modo de filtragem de sites bloqueados.

Uma característica desse modo é que o módulo DPI recebe somente o tráfego dos assinantes, e a saída da plataforma é a formação de uma resposta “fictícia” de um recurso proibido para o roteador ou simplesmente o bloqueio de um pacote destinado a um recurso proibido.

Este modo é usado quando a operadora não tem a capacidade de usar a plataforma no modo simétrico ou não há necessidade de outras funções da plataforma. Esse modo não é recomendado.

Se as funções de autorização já estiverem implementadas na rede, a DPI será ativada após o BRAS / BNG antes do NAT. Assim, os IPs privados reais dos assinantes ficarão visíveis no tráfego analisado.

Se a plataforma executar as funções de BRAS/NAT/DPI, a habilitação será realizada no núcleo da rede entre o nível de agregação e o roteador de borda.

A plataforma DPI sempre tem portas de destino: para o assinante – a porta está conectada à rede de dados e para a Internet – a porta está conectada ao roteador de borda.

Assim, o tráfego de/para o Assinante deve passar pela plataforma, o que é chamado de habilitação simétrica. Esse modo fornece o uso funcional completo da plataforma. Mas é possível que a plataforma funcione no modo “assimétrico” ou “espelhamento”.

O componente é responsável pela interação da plataforma com o servidor AAA da operadora de telecomunicações por meio do protocolo RADIUS. (AAA – Autenticação, Autorização, Contabilidade). Usado quando os recursos BRAS/BNG são ativados na plataforma DPI.

Os componentes DPI e PCRF se comunicam entre si usando um protocolo de comunicação interno por meio da pilha TCP/IP. O PCRF pode ser hospedado em um servidor físico ou virtual separado ou executado no mesmo servidor junto com o DPI.

Se forem usados vários DPIs, será usado o esquema 1xPCRF: NxDPI.

A DPI (fastDPI) é o principal componente sem o qual a plataforma como um todo não pode funcionar. A DPI fornece análise e processamento do tráfego que passa pela plataforma, aplicação de vários serviços ao tráfego e seu gerenciamento.

As principais tarefas funcionais da DPI:

• Aplicação de políticas de taxa a todo o tráfego ou individualmente por assinante
• Aplicação de serviços de plataforma (CG-NAT, lista de permissões, filtro de sites bloqueados, etc.)
• Formação de exportação de informações de tráfego em vários formatos (NetFlow, IPFIX-clickstream, IPFIX-nat, IPFIX-flow, etc.)
• Funções BRAS (IPoE, PPPoE, DHCP L2)

O SSG fornece análise e processamento do tráfego que passa pela plataforma, aplicando policiamento e gerenciamento de tráfego. Por meio de uma combinação de tecnologia DPI, software BRAS/BNG e CG-NAT, ele resolve a maioria dos desafios do ISP.

O servidor DHCP é responsável pela emissão de endereços privados para os assinantes. Qualquer implementação compatível com o CentOS pode ser usada. A implementação atual usa o servidor Kea DHCP.

Um roteador de software é um componente que anuncia e recebe rotas via OSPF, BGP e outros protocolos de roteamento dinâmico suportados pelo daemon do roteador. A implementação atual usa o BIRD.

PCRF fornece a interação da plataforma com o servidor AAA da operadora por meio do protocolo RADIUS (AAA – Authentication, Authorization, Accounting).

QoE Stor é um conjunto de aplicativos para coletar e armazenar informações de tráfego do SSG.

Sim, você pode. As funções BRAS/BNG e DPI podem ser controladas por sub-rede ou por um sistema autônomo, e isso pode ser configurado.

• DHCP L3 – O assinante recebe um endereço IP do servidor DHCP (ele não está conectado de forma alguma ao SCAT), e, por meio da rede roteada, chega ao SCAT. Onde, pelo IP de origem, ele passa pela autorização no faturamento (policiamento, serviços) e chega ao próximo roteador após o SSH (o IP pode ser transmitido usando o CG-NAT).
• DHCP L2 – O assinante recebe um endereço IP por meio do SSH DHCP Proxy ou DHCP Relay e é autorizado no Billing. Em seguida, ele é terminado pelo SCAT e chega ao roteador que o segue.
• Static L2 – O assinante tem um endereço IP fixo, de acordo com os dados recebidos pelo SCAT da solicitação ARP para o gateway, ele passa pela autorização no faturamento, é encerrado pelo SCAT e chega à fronteira.
• PPPoE – O assinante cria um túnel PPP a partir do SCAT, através do login/senha, passa pela autorização no Billing, é encerrado pelo Stingray SG e chega à fronteira.

Não, se o SSH for reiniciado, ele continuará funcionando no mesmo modo.

• Por endereço IP em um pacote recebido ao usar o BRAS no modo L3.
• Por PPPoE – um pacote para autorização recebido da porta PPPoE (PADI) do assinante. Ele permite que você identifique um assinante por login, endereço mac, tags qinq.
• Por pacote DHCP – a partir do pacote DHCP Discovery de difusão que é recebido da porta do assinante no modo L2, que permite obter informações para identificar o assinante por mac-address ou qinq-tag.

* Opcional – essa opção pode ser adicionada à Licença principal mediante pagamento adicional.

• O roteador anuncia uma rota (BGP, OSPF) para o pool NAT no momento em que ele é criado.

• Para assinantes com endereços públicos, o anúncio é feito depois que o assinante foi autorizado.

• O usuário faz a solicitação via PPP (PAP, CHAP, MS-CHAPv2).
• O SSG processa a solicitação e forma uma Access-Request para o servidor Radius via PCRF.

Acct-Session-Id = “001122334455667788”
Nome do usuário = “login04”
User-Password = “password”
Calling-Station-Id = “84:16:f9:05:8b:12”
NAS-Port-Type = 5 (Virtual)
NAS-Port = 0
NAS-Port-Id = “321/654”
NAS-IP-Address = “5.5.5.5”
VasExperts-Service-Type = 3

• O Radius gera uma resposta Access-Accept especificando o nome do pool de servidores DHCP a partir do qual o endereço IP privado será atribuído.

Session-Timeout = 86400
User-Name = “login04”
Framed-Pool = default
VasExperts-Policing-Profile = “rate_50mbits” (taxa_50mbits)
VasExperts-Service-Profile = “11:CG-NAT_pool_001”

• O servidor PCRF faz uma solicitação DHCP ao servidor DHCP e recebe os parâmetros para um assinante específico.
• O login que foi recebido do Radius e o endereço IP que foi recebido do servidor DHCP são vinculados. O policiamento e os dados de serviço do Radius são aplicados ao login.
• É gerada uma resposta do SSG para o usuário de que a conexão PPPoE foi estabelecida com sucesso.

Existem três opções de implementação:

1. comprar um servidor x86 padrão de qualquer fabricante
2. usar o equipamento que você já tem
3. implantar o BNG como um sistema virtual (componente VNF no servidor eSXI, KVM, Hyper-V).

Aproximadamente 4 terabytes em 6 meses, com uma carga média diária de 1 gigabit/s. Dados mais precisos podem ser obtidos experimentalmente.

MPLS – sim.

GRE – sim, mas somente se o tráfego no túnel não for criptografado.

Os dados de QoE são armazenados no banco de dados do ClickHouse.

Sim, isso é possível. Tanto no esquema “In-Line” quanto no esquema “Mirror”.

O servidor DPI atua como um sensor. Ele registra informações sobre o fluxo em partições e as envia para o coletor do QoE Stor (o intervalo padrão é de 1 minuto). Depois que o QoE Stor recebe os dados, ele os converte em valores tabulares (registro bruto) e, em seguida, agrega (registro agregado).

Há 4 tipos de registros brutos no QoE Stor:

.
• Fluxo de rede completo bruto, gerado a partir do fluxo netflow_full
• Clickstream bruto, formado a partir do fluxo ipfix_tcp
• raw GTP Flow, para redes móveis
• raw NAT Flow, informações sobre traduções NAT

4 tipos de registros agregados:

.
• Netflow
• Clickstream
• Fluxo GTP
• Fluxo NAT

Os registros brutos consistem exclusivamente em tabelas com todas as informações coletadas sobre fluxos: início/fim/ID da sessão, endereços IPv4/v6 de origem/destino antes/depois do NAT, portas de origem/destino, ACs de destino etc. O modelo de tabela é descrito em Formatos do NetFlow.

Os logs agregados são gerados com base em dados brutos, combinando vários registros para um endereço IP, o que reduz a quantidade de armazenamento e aumenta a velocidade dos relatórios, mas os detalhes de cada sessão são perdidos.

Para um subsistema, você pode usar hardware ou máquinas virtuais com as seguintes características:

1. Processador (CPU) 2,5 GHz – 1 pc. (requer suporte ao conjunto de instruções SSE 4.2. A velocidade do clock é menos importante. Por exemplo, 16 núcleos a 2600 MHz é melhor do que 8 núcleos a 3600 MHz)
2. Memória de acesso aleatório (RAM) – a partir de 16 GB (a memória deve ser pelo menos tão grande quanto a quantidade de dados solicitados. Quanto mais memória, melhor será o desempenho ao criar relatórios. Quanto mais memória, menor será a carga do disco. O requisito mínimo é de 16 GB. Sempre desligue a troca de arquivos)
3. Disco rígido (SSD altamente desejável) – a partir de 500 GB (espaço em disco necessário de 16 GB para cada dia de armazenamento, dependendo do tráfego. Estima-se que 10 Gb/s de tráfego médio diário gerem aproximadamente 25 GB de dados por hora no Stor QoE). A calculadora de cálculo é apresentada no Wiki.
4. Sistema operacional – CentOS 8+
5. Placa de rede (NIC) – a partir de 1 Gbps.

*O módulo para receber e processar estatísticas não pode ser instalado em um servidor com uma plataforma DPI: a preparação de relatórios exige muitos recursos da CPU, o que pode afetar negativamente o desempenho da plataforma DPI.

Quatro componentes são usados para trabalhar com o IPFIX (NetFlow v10):

1. Exportador de fluxo: um dispositivo responsável por coletar informações sobre fluxos e exportá-las para o coletor de fluxo – SSH DPI (módulo DPI).
2. Coletor: O aplicativo que recebe as informações de fluxo exportadas é o ipfixreceiver2 como parte do QoE Stor.
3. Analisador de fluxo: Um aplicativo que analisa as informações de fluxo coletadas pelo coletor. As informações sobre o fluxo são registradas para armazenamento e análise no banco de dados do ClickHouse.
4. Interface de gerenciamento: um aplicativo que permite visualizar com eficiência as estatísticas sobre o fluxo e gerenciar todo o sistema de controle e análise de tráfego (SCAT DPI) – uma interface gráfica de usuário DPIUI2.

O módulo Quality of Experience (QoE) é um produto de software para coletar estatísticas e avaliar a qualidade da percepção dos serviços.

As estatísticas coletadas pelo módulo são sobrepostas a métricas específicas para determinar a experiência do usuário e responder à pergunta sobre a alta qualidade dos serviços de comunicação e acesso à Internet que o usuário final recebe.

Os dados obtidos permitem que a operadora tome as medidas necessárias para melhorar a qualidade dos serviços e, como resultado, aumentar a fidelidade do assinante.

A rotação de arquivos fornece um backup diário do registro diário. Por padrão, esse processo é executado durante as horas de menor carga no sistema. A profundidade do armazenamento do log é definida na configuração /etc/logrotate.d/fastdpi parâmetro maxage, o valor é especificado em dias.

O NetFlow é enviado ao coletor a partir de uma interface DPI dedicada, normalmente a interface mgmt, que é usada para acesso SSH, integração RADIUS, etc.

*Só pode haver um fluxo do mesmo tipo. Se for necessário enviar para várias fontes, a reexportação do módulo QoE ou de outros coletores é usada.

A largura de banda necessária para exportar dados do NetFlow normalmente é inferior a 0,5% do consumo total de largura de banda. Por exemplo, se você estiver monitorando um link que usa 100 Gbps, o DPI usará menos de 0,5 Gbps para exportar dados do NetFlow.

A DPI acumula estatísticas e as transmite ao coletor em uma frequência especificada. Com base nos princípios de operação do DPI, as estatísticas sempre serão carregadas com algum atraso, dependendo dos intervalos de tempo definidos no arquivo de configuração.

O NetFlow v5 é limitado a fluxos IPv4. A seleção de campos que podem ser exportados usando essa versão também é limitada.

IPFIX – às vezes chamado de NetFlow v10. Dois novos conceitos de monitoramento de fluxo são introduzidos aqui: primeiro, o uso de modelos é permitido e, segundo, o usuário tem a oportunidade de “olhar” profundamente os pacotes e selecionar os campos de seu interesse para monitoramento. O IPFIX permite que quase todos os campos, todos os tipos de sinalizadores TCP e outras informações sejam selecionados no cabeçalho do IP, inclusive tags de VLAN e URLs.

Benefícios do IPFIX em relação ao NetFlow v5 tradicional:

• flexibilidade, escalabilidade e agregação de dados de fluxo além dos recursos do NetFlow tradicional
• a capacidade de monitorar uma ampla gama de informações sobre pacotes IP, da camada 2 à camada 7
• informações de fluxo configuráveis pelo usuário, permitindo a personalização da identificação do tráfego (uma oportunidade de destacar e monitorar o comportamento específico da rede).

A plataforma é completamente transparente para a aplicação do protocolo de agregação de links LACP, sujeito às seguintes condições:

• as portas de processamento de tráfego pertencem ao mesmo cluster
• as portas estão configuradas simetricamente e conectadas corretamente
• o tráfego de/para o Assinante (endereços IP de origem) passa pelas mesmas portas de processamento de tráfego.

Como protocolo de controle para LAG, podem ser usados tanto o LACP padrão (IEEE 802.3ad) quanto os proprietários, como o PAgP.

*Os protocolos LAG têm um tempo de “convergência” bastante longo, de até 30 segundos (sem usar configurações especiais), o que pode afetar a passagem correta do tráfego pela plataforma.

O suporte a bypass é implementado para as placas Silicom 40 GbE, 10 GbE e 1 GbE. As placas de rede multiportas têm um modo especial de “Bypass”. Quando esse modo é ativado na placa de rede, o tráfego para a placa de rede é fisicamente ligado em loop entre as duas portas e, portanto, ignora o processamento diretamente na placa de rede e, consequentemente, na plataforma.

Esse modo é usado quando é importante manter o tráfego em andamento mesmo que o sistema falhe. Obviamente, quando o “Bypass” está ativado, todas as funções da plataforma ficam indisponíveis.

*Ativação desse modo na placa de rede deve ser considerada uma emergência.

Para um subsistema, você pode usar hardware ou máquinas virtuais com as seguintes características:

1. Processador (CPU) 2,5 GHz – 1 pc. (requer suporte ao conjunto de instruções SSE 4.2. A velocidade do clock é menos importante. Por exemplo, 16 núcleos a 2600 MHz é melhor do que 8 núcleos a 3600 MHz)
2. Memória de acesso aleatório (RAM) – a partir de 16 GB (a memória deve ser pelo menos tão grande quanto a quantidade de dados solicitados. Quanto mais memória, melhor será o desempenho ao criar relatórios. Quanto mais memória, menor será a carga do disco. O requisito mínimo é de 16 GB. Sempre desligue a troca de arquivos)
3. Disco rígido (SSD altamente desejável) – a partir de 500 GB (espaço em disco necessário de 16 GB para cada dia de armazenamento, dependendo do tráfego. Estima-se que 10 Gb/s de tráfego médio diário gerem aproximadamente 25 GB de dados por hora no Stor QoE). A calculadora de cálculo é apresentada no Wiki.
4. Sistema operacional – CentOS 8+
5. Placa de rede (NIC) – a partir de 1 Gbps.

*O módulo para receber e processar estatísticas não pode ser instalado em um servidor com uma plataforma DPI: a preparação de relatórios exige muitos recursos da CPU, o que pode afetar negativamente o desempenho da plataforma DPI.

O módulo é exigente quanto ao número de núcleos de processador, à RAM e à velocidade do subsistema de disco. Requisitos: pelo menos 16 GB de RAM, 4 núcleos de CPU de 2,5 GHz, um subsistema de disco para um banco de dados de 1000 MB em uma unidade SSD, para um aplicativo de 128 MB. Cálculo de armazenamento: Em média, 10 Gbps de tráfego de DPI requerem cerca de 25 GB de armazenamento de dados no banco de dados.

Para gerenciamento – uma porta de rede separada (mas não inferior a 1 Gb / s) em qualquer chipset suportado pelo sistema operacional. Sistema operacional: CentOS 8+, arquivo de paginação desativado (swap).

Se apenas um servidor com DPI for usado, o módulo PCRF poderá ser colocado no mesmo servidor. Nos casos em que várias DPIs são usadas (para balanceamento de carga/redundância), faz sentido mover o PCRF para um servidor separado.

Requisitos: pelo menos 2 GB de RAM, 2 núcleos de CPU de 2,5 GHz, espaço em disco de 128 Gb.

Para gerenciamento – uma porta de rede separada (mas não inferior a 100 Mbps) em qualquer chipset compatível com o sistema operacional.

Sistema operacional: CentOS 8+ (x64).

É um módulo que consome muitos recursos: ele impõe requisitos maiores em termos de CPU, velocidade e capacidade de RAM, opcionalmente um HD rápido, mas é preferível um SSD habilitado para NVMe.

• Um processador com suporte a SSE 4.2, começando com Intel Nehalem e AMD EPYC Zen2 com 4 núcleos ou mais, uma velocidade de clock base de 2,6 GHz ou superior.
• Além disso, o HyperThreading deve estar desativado no servidor.
• Mínimo necessário de 3 portas: uma para controle SSH (qualquer chipset), duas para processamento de tráfego – placas de rede baseadas em chipsets com suporte à tecnologia DPDK.

Recomenda-se usar somente placas testadas baseadas em chipsets Intel (com 2, 4 e 62 portas):

1GbE interfaces
e1000 (82540, 82545, 82546)
e1000e (82571, 82572, 82573, 82574, 82583, ICH8, ICH9, ICH10, PCH, PCH2, I217, I218, I219)
igb (82573, 82576, 82580, I210, I211, I350, I354, DH89xx)
igc (I225)

10GbE interfaces
ixgbe (82598, 82599, X520, X540, X550)

Interfaces 10GbE e 40GbE
i40e (X710, XL710, X722, XXV710)
Interfaces de 100 GbE
mlx5 (Mellanox ConnectX-5 Ex)
ice (Intel E810) – não recomendado, pois há problemas no firmware da Intel na placa: ele não permite GREtunnels

• Suporte a bypass implementado para placas Silicom de 40 GbE, 10 GbE e 1 GbE
• Sistema operacional: CentOS 8+ (x64)

* Opcional – essa opção pode ser adicionada à Licença principal mediante pagamento adicional.