Visão geral do recurso NFX150

A arquitetura de software do NFX150 foi projetada para fornecer um plano de controle unificado que funciona como um único ponto de gerenciamento.

A Figura 1 ilustra a arquitetura do NFX150.

Figura 1: Arquitetura NFX150

Os principais componentes do software do sistema incluem:

• VNF — A VNF é uma oferta consolidada que contém todos os componentes necessários para oferecer suporte a um ambiente de rede totalmente virtualizado. Você pode configurar e usar VNFs de terceiros em cadeias de serviço.

• Junos Control Plane (JCP) — O JCP é o Junos VM em execução no sistema operacional host, Wind River Linux. O JCP funciona como o ponto único de gerenciamento para todos os componentes. O JCP controla o plano de dados de Camada 2, que fornece os serviços de Camada 2 e o plano de dados de Camada 3, que fornece os serviços de Camada 3 a Camada 7.

  Além do gerenciamento do chassi, o JCP permite:

  • Configuração de recursos avançados de segurança.

  • Gerenciamento de funções de rede virtualizadas para convidados (VNFs) durante seu ciclo de vida.

  • Instalação de VNFs de terceiros.

  • Criação de cadeias de serviço VNF.

  • Gerenciamento de imagens VNF convidados (seus arquivos binários).

  • Gerenciamento do inventário do sistema e uso de recursos.

  • Gerenciamento da interface LTE.

• Juniper Device Manager (JDM) — um contêiner de aplicativos que gerencia VNFs e fornece serviços de infraestrutura. O JDM funciona em segundo plano e os usuários não podem acessar o JDM diretamente.

• Dataplane L2 — o plano de dados de Camada 2 que gerencia o tráfego de Camada 2. O plano de dados de Camada 2 encaminha o tráfego LAN para o backplane NFV, Open vSwitch (OVS). O plano de dados de Camada 2 é mapeado para o FPC0 virtual no JCP. Por padrão, todas as portas físicas Ethernet de 1 Gigabit são mapeadas para as interfaces virtuais no plano de dados de Camada 2.

• Dataplane L3 — o plano de dados de Camada 3 que fornece funções de datapath para os serviços de Camada 3 a Camada 7. O plano de dados da Camada 3 é mapeado para o FPC1 virtual no JCP. Por padrão, as duas portas SFP+ no chassi NFX150 são mapeadas para as interfaces virtuais no dataplane de Camada 3.

• Linux — O sistema operacional host, WindRiver Linux. No Junos OS Release 18.1R1, a versão WindRiver Linux é 8.

• Ponte vSwitch aberta (OVS) — A ponte OVS é uma ponte de sistema consciente de VLAN, que atua como o backplane NFV ao qual os VNFs e FPCs se conectam. Além disso, você pode criar pontes OVS personalizadas para isolar a conectividade entre diferentes VNFs.

• LTE — um driver conteinerizado que oferece gerenciamento de conectividade 4G LTE. O contêiner LTE está vinculado ao FPC1 para gerenciamento.

As interfaces dos dispositivos NFX150 incluem interfaces físicas, interfaces virtuais e a interface LTE.

• Interfaces físicas
• Interfaces virtuais
• LTE Interface
• Mapeamento de interface

A Tabela 5 lista os recursos do Junos suportados no NFX150.

Para obter mais detalhes sobre os recursos suportados, veja Feature Explorer.

Os dispositivos NFX150 oferecem os seguintes modos operacionais:

• Modo de transferência — fornece recursos máximos (CPU e memória) para o software Junos e recursos remanescentes, se houver, para VNFs de terceiros.

  Nota:

  Você não pode criar VNFs no modo de transferência.

  A partir do Junos OS Release 21.1R1, o mapeamento da OVS para a interface de plano de dados de Camada 3 não é suportado no modo de taxa de transferência em dispositivos NFX150-S1 e NFX150-S1E. Se o mapeamento OVS estiver presente em versões antes do Junos OS Release 21.1R1, você deve alterar o mapeamento antes de atualizar o dispositivo para o Junos OS Release 21.1R1 para evitar uma falha no comprometimento da configuração.

• Modo híbrido — oferece uma distribuição equilibrada de recursos entre o software Junos e VNFs de terceiros.

• Modo computação — oferece recursos mínimos para o software Junos e recursos máximos para VNFs de terceiros.

• Modo personalizado — oferece uma opção de alocar recursos aos componentes do sistema:

  • Plano de dados de camada 2, plano de dados de Camada 3 e backplane NFV para modelos NFX150-S1 e NFX150-S1E

  • Plano de dados de camada 2 e plano de dados de Camada 3 para modelos NFX150-C-S1, NFX150-C-S1-AE/AA e NFX150-C-S1E-AE/AA

  Nota:

  Os modos de computação, híbridos e de taxa de transferência são suportados no Junos OS Release 19.1R1 ou posterior. O modo personalizado é suportado a partir do Junos OS Release 22.1R1.

  O modo padrão é a taxa de transferência em versões do Junos OS antes do 21.4R1. A partir do Junos OS Release 21.4R1, o modo padrão é a computação.

Em modos híbridos e de computação, você pode mapear interfaces de plano de dados de Camada 3 para SR-IOV ou OVS. No modo de transferência, você pode mapear interfaces de plano de dados de Camada 3 apenas para SR-IOV.

Por exemplo:

• Mapeie interfaces de plano de dados de Camada 3 para SR-IOV:

  user@host# set vmhost virtualization-options interfaces ge-1/0/1 mapping interface heth-0-1

• Mapeie interfaces de plano de dados de Camada 3 para OVS:

  user@host# set vmhost virtualization-options interfaces ge-1/0/1

No modo híbrido ou computacional, você pode criar VNFs usando as CPUs disponíveis em cada modo. Você pode verificar a disponibilidade da CPU usando o show vmhost mode comando. Cada VNF oferece suporte a no máximo 10 interfaces (eth0 a eth9), incluindo as duas interfaces de gerenciamento eth0 e eth1.

Para mudar o modo atual, execute o request vmhost mode mode-name comando. O request vmhost mode ? comando lista apenas os modos pré-definidos, como modos híbridos, de computação e de taxa de transferência.

Antes de mudar para um modo, emita o show system visibility cpu e show vmhost mode os comandos para verificar a disponibilidade de CPUs. Ao alternar entre os modos operacionais, garanta que os conflitos de recursos e configuração não ocorram. Por exemplo, se você passar do modo de computação que oferece suporte aos VNFs para o modo de taxa de transferência que não oferece suporte a VNFs, ocorrem conflitos:

Se o plano de dados de Camada 3 não for mapeado para SR-IOV, então a comutação do modo híbrido ou computacional para o modo de transferência resulta em um erro.

Se você fixar uma CPU virtual em CPUs físicas para uma VNF, então garanta que as CPUs físicas não se sobreponham com as CPUs sendo usadas para componentes do sistema da Juniper, incluindo a CPU física 0.

As CPUs físicas usadas para fixar um emulador podem se sobrepor às CPUs que estão sendo usadas para componentes do sistema da Juniper, exceto a CPU 0 física. Essa sobreposição pode afetar o desempenho de um ou mais componentes do sistema da Juniper e VNFs.

• Como definir um modelo de modo personalizado
• Mapeamento de núcleo para CPU no NFX150

Para recursos ou níveis de escala que exijam uma licença, você deve instalar e configurar adequadamente a licença para atender aos requisitos de uso do recurso ou nível de escala licencial. O dispositivo permite que você comprometa uma configuração que especifica um recurso ou escala licencial sem licença por um período de carência de 30 dias. O período de carência é uma concessão de curto prazo que permite que você comece a usar recursos no pacote ou amplie até os limites do sistema (independentemente do limite da chave da licença) sem uma chave de licença instalada. O período de carência começa quando o recurso licenciado ou o nível de escalabilidade são efetivamente usados pelo dispositivo (não quando ele é cometido pela primeira vez). Em outras palavras, você pode comprometer recursos licenciantes ou limites de escala para a configuração do dispositivo, mas o período de carência não começa até que o dispositivo use o recurso licencial ou exceda um nível de escalamento licencial.

Para obter informações sobre como comprar licenças de software, entre em contato com seu representante de vendas da Juniper Networks. O software Junos OS implementa uma estrutura de licenciamento baseada em honra e oferece a você um período de carência de 30 dias para usar o recurso sem uma chave de licença instalada. O período de carência começa quando você configura o recurso e seu dispositivo usa o recurso licenciado pela primeira vez, mas não necessariamente quando você instala a licença. Após o término do período de carência, o sistema gera mensagens de log do sistema dizendo que o recurso requer uma licença. Para limpar a mensagem de erro e usar o recurso licenciado corretamente, você deve instalar e verificar a licença necessária.

O dispositivo relata qualquer violação de licença como uma mensagem de log de aviso sempre que uma configuração é comprometida que contenha um recurso ou limite de escala que requer uma licença. Após o período de carência de 30 dias, o dispositivo relata periodicamente a violação de mensagens de syslog até que uma licença seja instalada e configurada adequadamente no dispositivo para resolver a violação.