Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Visão geral do recurso NFX150

Arquitetura de software

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 Architecture 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ços.

  • Junos Control Plane (JCP)— O JCP é o Junos VM em execução no sistema operacional de hospedagem Wind River Linux. O JCP funciona como um único ponto de gerenciamento para todos os componentes. A 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, JCP permite:

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

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

    • Instalação de VNFs de terceiros.

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

    • Gerenciamento de imagens VNF convidadas (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 de 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+ do 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 fornece gerenciamento de conectividade 4G LTE. O contêiner LTE está vinculado ao FPC1 para gerenciamento.

Interfaces

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

Interfaces físicas

As interfaces físicas representam as portas físicas do chassi e módulo de expansão NFX150. As interfaces físicas incluem portas de rede e gerenciamento:

  • Portas de rede — Quatro portas Ethernet de 1 Gigabit e duas portas Ethernet SFP+ de 10 Gigabits funcionam como portas de rede no chassi NFX150. Os módulos de expansão consistem em seis portas Ethernet de 1 Gigabit e duas portas Ethernet SFP de 1 Gigabit.

    As portas de rede seguem a convenção heth-slot number-port numberde nomeação, na qual:

    • heth denota host Ethernet

    • slot number é 0 para as portas do chassi e 1 para as portas do módulo de expansão. As portas do chassi são nomeadas como heth-0-x e as portas do módulo de expansão são nomeadas heth-1-x.

    • port number é o número da porta no chassi ou módulo de expansão

    Cada porta física tem quatro funções virtuais (VFs) habilitadas por padrão.

    Nota:

    Você não pode mapear um VF de uma porta que é mapeada para o plano de dados de Camada 2.

  • Porta de gerenciamento — o dispositivo NFX150 tem uma porta de gerenciamento dedicada rotulada MGMT (fxp0), que funciona como a interface de gerenciamento fora da banda. A interface fxp0 é atribuída a um endereço IP na rede 192.168.1.1/24.

Interfaces virtuais

Os FPCs virtuais em execução no JCP contêm as interfaces virtuais. As interfaces virtuais dos dispositivos NFX150 são categorizadas da seguinte forma:

  • Interfaces virtuais de Camada 2 (FPC0)— Denotadas como ge-0/0/x, onde o valor de x varia de:

    • 0 a 3 para dispositivos NFX150 sem um módulo de expansão

    • 0 a 11 para dispositivos NFX150 com um módulo de expansão

    Essas interfaces são usadas para configurar os seguintes recursos de comutação Ethernet:

    • Comutação de tráfego de Camada 2, incluindo suporte para portas de tronco e acesso

    • Protocolo de descoberta de camada de enlace (LLDP)

    • Bisbilhotamento de IGMP

    • Recursos de segurança de porta (limitação de MAC, aprendizado MAC persistente)

    • MVRP

    • Ethernet OAM, CFM e LFM

    Todas as portas físicas de Ethernet de 1 Gigabit (portas de heth) são mapeadas para FPC0, por padrão.

  • Interfaces virtuais de Camada 3 (FPC1)— Denotadas como ge-1/0/x, onde o valor de x varia de 0 a 9. Essas interfaces são usadas para configurar recursos de Camada 3, como protocolos de roteamento e QoS.

    Em um dispositivo NFX150, você pode configurar qualquer uma das interfaces ge-1/0/x como interfaces de gerenciamento na banda. No gerenciamento da banda, você configura uma interface de rede como uma interface de gerenciamento e a conecta ao dispositivo de gerenciamento. Você pode configurar qualquer número de interfaces para gerenciamento em banda, atribuindo um endereço IPv4 ou IPv6 a cada uma das portas e um VLAN de gerenciamento em banda.

    Nota:

    Os dispositivos NFX150 não oferecem suporte a interfaces integradas de roteamento e ponte (IRB). A funcionalidade IRB é fornecida pelo ge-1/0/0, que sempre é mapeado para o backplane de encadeamento de serviços (OVS). Observe que este mapeamento não pode ser alterado.

  • Interfaces SXE virtuais — duas interfaces estáticas, sxe-0/0/0 e sxe-0/0/1, conectam o FPC0 (dataplane de Camada 2) ao backplane OVS.

LTE Interface

Os modelos de dispositivos NFX150 com suporte a LTE podem ser configurados para conectividade WAN sem fio em redes 3G ou 4G. A interface física LTE usa o nome cl-1/1/0. A interface de dialer, dl0, é uma interface lógica, que é usada para acionar chamadas.

Mapeamento de interfaces

A Tabela 1 resume as interfaces do NFX150.

Tabela 1: Interfaces no NFX150

Nome da interface

Descrição

heth-0-0 a heth-0-5

Portas físicas no painel frontal do dispositivo NFX150, que podem ser mapeadas para interfaces de Camada 2 ou Camada 3, ou VNFs.

As portas heth-0-0 a heth-0-3 são portas de cobre de 10 Mbps/100 Mbps/1 Gbps de tri-velocidade.

Portas heth-0-4 e heth-0-5 são portas SFP+ de 10 Gbps

For Junos OS Releases 18.1, 18.2 R1, and 18.3 R1:

  • As portas heth-0-0 a heth-0-3 são mapeadas para as portas LAN ge-0/0/0 para ge-0/0/3, respectivamente.

  • As portas heth-0-4 e heth-0-5 são mapeadas para as portas WAN ge-1/0/1 e ge-1/0/2, respectivamente.

For Junos OS Release 18.2 R2

  • As portas heth-0-0, heth-0-1 e heth-0-2 são mapeadas para as portas LAN ge-0/0/0/0 para ge-0/0/2, respectivamente.

  • A porta heth-0-4 é mapeada para a porta LAN ge-0/0/3.

As portas heth-0-3 e heth-0-5 são mapeadas para as portas WAN ge-1/0/1 e ge-1/0/2, respectivamente.

heth-1-0 para heth-1-7

Portas físicas no módulo de expansão do dispositivo NFX150-S1. Essas portas são mapeadas para as portas ge-0/0/n por padrão.

As portas heth-1-0 a heth-1-5 são de 10 Mbps/100 Mbps/1 Gbps de cobre tri-velocidade mapeadas para as portas LAN ge-0/0/4 para ge-0/0/9, respectivamente.

As portas heth-1-6 e heth-1-7 são portas SFP de 1 Gbps mapeadas para as portas LAN ge-0/0/10 e ge-0/0/11, respectivamente.

ge-0/0/x

Interfaces lógicas de Camada 2, que podem ser usadas para conectividade LAN. Os valores de x variam de:

  • 0 a 3 para dispositivos NFX150 sem um módulo de expansão

  • 0 a 11 para dispositivos NFX150 com um módulo de expansão

ge-1/0/x

Um conjunto de até 10 interfaces lógicas de Camada 3. Cada uma dessas interfaces pode ter sub-interfaces 4k. O valor de x varia de 0 a 9.

cl-1/1/0

A interface celular LTE, que transporta os atributos de camada física.

dl0

A interface de dialer LTE, que transporta serviços de Camada 3 e segurança. A sessão de fluxo de segurança contém a interface dl0 como a interface de entrada ou saída.

st0

Interface de túnel segura usada para VPNs IPsec.

fxp0

A interface de gerenciamento fora da banda.

A lista de transceptores suportados para o NFX150 está localizada em https://pathfinder.juniper.net/hct/product/.

A Tabela 3 ilustra o mapeamento padrão entre as interfaces físicas e virtuais em um dispositivo NFX150.

Tabela 2: Mapeamento padrão de portas físicas para portas virtuais no NFX150 (para os lançamentos do Junos OS 18.1, 18.2 R1 e 18.3 R1)

Porta física

Interface virtual (plano de dados de Camada 2)

Interface virtual (plano de dados de Camada 3)

heth-0-0

ge-0/0/0

NA

heth-0-1

ge-0/0/1

NA

heth-0-2

ge-0/0/2

NA

heth-0-3

ge-0/0/3

NA

heth-0-4

NA

ge-1/0/1

heth-0-5

NA

ge-1/0/2

Tabela 3: Mapeamento padrão de portas físicas para portas virtuais no NFX150 (para lançamentos do Junos OS 18.2 R2)

Porta física

Interface virtual (plano de dados de Camada 2)

Interface virtual (plano de dados de Camada 3)

heth-0-0

ge-0/0/0

NA

heth-0-1

ge-0/0/1

NA

heth-0-2

ge-0/0/2

NA

heth-0-3

NA

ge-1/0/1

heth-0-4

ge-0/0/3

NA

heth-0-5

NA

ge-1/0/2

A Tabela 4 ilustra o mapeamento padrão entre as portas físicas do módulo de expansão e as interfaces virtuais.

Tabela 4: mapeamento padrão de portas físicas para portas virtuais para o módulo de expansão

Porta física

Porta virtual (dataplane de Camada 2)

heth-1-0

ge-0/0/4

heth-1-1

ge-0/0/5

heth-1-2

ge-0/0/6

heth-1-3

ge-0/0/7

heth-1-4

ge-0/0/8

heth-1-5

ge-0/0/9

heth-1-6

ge-0/0/10

heth-1-7

ge-0/0/11

Nota:

As portas do módulo de expansão são mapeadas por padrão para as interfaces de plano de dados de Camada 2. Você pode alterar o mapeamento para atender aos seus requisitos. Qualquer uma das portas do chassi e do módulo de expansão pode ser mapeada para as interfaces ge-1/0/x ou ge-0/0/x. Qualquer mudança na configuração de mapeamento de portas redefinirá automaticamente o FPC afetado.

Recursos suportados

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

Tabela 5: recursos suportados no NFX150

Versão do Junos OS

Roteamento

Segurança

Comutação

18.1R1

  • BGP, OSPF, RIP, IS-IS,

  • MVRP

  • NAT

  • ALG

  • Ipsec

  • IPv6 NTP

  • IPv6 TACACS

  • Porque

  • Filtros de firewall

  • LLDP

  • Espelhamento de porta

  • Bisbilhotamento IGMP/MLD

  • Bisbilhotamento de MLD

  • Aprendizado mac persistente

  • L2Rewrite

  • VLAN nativa

18,2 R1

  • Segurança de aplicativos

  • IDP

  • Firewall de usuário integrado

  • UTM

Para obter mais detalhes sobre recursos suportados, consulte o Feature Explorer.

Modos de desempenho

Os dispositivos NFX150 fornecem os seguintes modos operacionais:

  • Modo de transferência — fornece recursos máximos (CPU e memória) para o software Junos e recursos restantes, 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 do OVS para a interface de plano de dados de Camada 3 não é suportado no modo de transferência em dispositivos NFX150-S1 e NFX150-S1E. Se o mapeamento OVS estiver presente em lançamentos 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 — fornece uma distribuição balanceada de recursos entre o software Junos e VNFs de terceiros.

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

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

    • Plano de dados de Camada 2, plano de dados de Camada 3 e backplane de 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 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 nas 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 para apenas 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.

Nota:

Você não pode anexar uma única interface VNF ao SR-IOV e ao OVS. No entanto, você pode anexar interfaces diferentes da mesma VNF ao SR-IOV e OVS.

Quando o mapeamento para uma interface de plano de dados de Camada 3 muda entre NICs SR-IOV (por exemplo, heth-0-0) ou de heth-x-x para OVS ou vice-versa, então o FPC1 reinicia automaticamente.

Para alterar 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 transferência.

Antes de mudar para um modo, emita o e show vmhost mode os show system visibility cpu comandos para verificar a disponibilidade de CPUs. Ao alternar entre 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 a VNFs para o modo 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, 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, garanta que as CPUs físicas não se sobreponham às CPUs usadas para componentes do sistema Juniper, incluindo a CPU física 0.

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

Como definir um modelo de modo personalizado

Você pode usar um modelo de modo personalizado se precisar alocar o máximo de recursos para VNFs de terceiros. No modo personalizado, você deve configurar a contagem de CPU e a quantidade de memória para:

  • Plano de dados de Camada 2, plano de dados de Camada 3 e backplane de 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, NFX150-C-S1E-AE/AA

A ausência de qualquer uma das configurações causa uma falha de comprometimento.

Nota:

Você pode optar por desativar o plano de dados de Camada 2 para liberar recursos de CPU e memória em implantações que não exigem serviços PFE de software de Camada 2.

Se você desativar o plano de dados de Camada 2, não poderá configurar os mapeamentos de interface virtual do plano de dados da Camada 2. Por exemplo:

Antes de configurar o modo personalizado, observe o seguinte:

  • Se você desativar o plano de dados da Camada 2, você não pode configurar cpu count e memory size para o plano de dados da Camada 2.

    Se você não desativar o plano de dados da Camada 2, então você deve configurar o cpu count e memory size para ele. A contagem e a memória da CPU não devem exceder a contagem total de CPU e a memória disponíveis no sistema.

  • Você pode optar por configurar a cota de CPU para o plano de dados de Camada 3 usando o set vmhost mode custom custom-mode-name layer-3-infrastructure cpu colocation quota quota-value comando, onde quota-value pode variar de 1 a 99. Se você configurar cpu colocation quota, a soma total das cotas de CPU dos componentes de colocação da cpu deve ser menor ou igual a 100. Você deve configurar cpu count usando valores numéricos e não palavras-chave como MIN, pois o MIN pode ter valores diferentes para diferentes componentes.

  • O número de CPUs e as CPUs específicas (por CPU ID) disponíveis para uso de VNF em um modo personalizado é determinado automaticamente com base na configuração do cpu count modo personalizado e cpu colocation quota na alocação de CPU fixa internamente para outros componentes do sistema juniper.

  • A quantidade de memória, em termos de unidades 1G, disponível para uso de VNF em um modo personalizado é determinada automaticamente com base na configuração de tamanho de memória específica do modo personalizado e na alocação de memória fixa por SKU internamente para outros componentes do sistema Juniper. Observe que esse número é apenas um valor aproximado e a alocação de memória máxima real para VNFs pode ser menor do que isso.

  • Se você não configurar o tamanho da memória para uma VNF, a memória será considerada como 1G (valor padrão).

Para definir um modelo de modo personalizado nos modelos NFX150-C-S1, NFX150-C-S1-AE/AA, NFX150-C-S1E-AE/AA, use a configuração a seguir. A configuração cpu colocation quota é opcional.

Para definir um modelo de modo personalizado nos modelos NFX150-S1 e NFX150-S1E, use a configuração a seguir. A configuração cpu colocation quota é opcional.

A memória especificada por meio de um modo personalizado é criada e apoiada por páginas enormes de 1G para o backplane de NFV e o uso do plano de dados de Camada 2 e páginas enormes de 2M para o uso do plano de dados de Camada 3.

O modelo flex é o modelo de modo personalizado presente na configuração padrão do Junos. Este modelo oferece suporte a uma palavra-chave MIN, que é um valor pré-definido específico do dispositivo para alocar recursos mínimos. O modelo flex usa a palavra-chave MIN para alocar recursos para componentes do sistema, como plano de dados de Camada 3 e backplane NFV. Nesse modo, o dispositivo oferece memória e CPUs máximas para VNFs de terceiros.

Para alocar recursos no modo flex, use os seguintes comandos:

  • Para NFX150-C-S1, modelos NFX150-C-S1-AE/AA, NFX150-C-S1E-AE/AA:
  • Para modelos NFX150-S1/S1E:

Quando o dispositivo está operando no modo personalizado, você pode fazer alterações na configuração do modo personalizado. Reinicialize o dispositivo para que as mudanças entrem em vigor. A configuração de interfaces virtuais de Camada 2, interfaces virtuais de Camada 3, CPU virtual VNF para mapeamento físico de CPU, emulador de VNF para mapeamento físico de CPU e tamanho de memória VNF é validada durante a verificação de compromisso em relação aos parâmetros de configuração do modo personalizado atualmente ativo e aos parâmetros de configuração do modo personalizado modificado que fazem efeito após uma reinicialização.

Quando o dispositivo está no modo personalizado, apenas recursos básicos de firewall são suportados. No modo flex, você pode configurar um máximo de:

  • 8 túneis VPN IPSec

  • 16 IFL

  • 4 IFD

Mapeamento de núcleo para CPU no NFX150

As tabelas a seguir listam a CPU aos mapeamentos de núcleo dos modelos NFX150:

NFX150-S1 e NFX150-S1E
Núcleo 0 1 2 3 4 5 6 7
CPU 0 1 2 3 4 5 6 7
NFX150-C-S1
Núcleo 0 1 2 3
CPU 0 1 2 3

Licenciamento

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 dimensione 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 escalonamento são usados pelo dispositivo (não quando ele é cometido pela primeira vez). Em outras palavras, você pode comprometer recursos licenciados ou limites de escalonamento 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 escalonamento 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 a expiração do período de carência, o sistema gera mensagens de registro 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.

Nota:

As configurações podem incluir recursos licenciados e não licenciados. Para essas situações, a licença é aplicada até o ponto em que a licença pode ser claramente distinguida. Por exemplo, uma configuração de ordem de autenticação é compartilhada tanto pela Autenticação, Autorização e Contabilidade (AAA), que é licenciada, quanto pelo Protocolo de Tunelamento de Camada 2 (L2TP), que não é licenciado. Quando a configuração é comprometida, o dispositivo não emite avisos de licença, porque ainda não se sabe se AAA ou L2TP estão usando a configuração. No entanto, em tempo de execução, o dispositivo verifica uma licença quando a AAA autentica os clientes, mas não verifica quando o L2TP autentica os clientes.

O dispositivo relata qualquer violação de licença como uma mensagem de registro de aviso sempre que uma configuração é comprometida que contém um recurso ou uso de 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.

Nota:

O compromisso bem-sucedido de um recurso licenciado ou configuração de escalonamento não implica que as licenças necessárias sejam instaladas ou não necessárias. Se uma licença necessária não estiver presente, o sistema emitirá uma mensagem de aviso depois de comprometer a configuração.

Tabela 6: Licenças de software NFX150 Junos

Licença

Características

SKU de licença

Modelo de dispositivo

Software base (STD)

Serviços de camada 2, serviços de Camada 3, NAT, IPsec, firewall stateful

NFX150-C-STD

NFX150-C-S1 e NFX150-C-S1E

NFX150-S-STD

NFX150-S1 e NFX150-S1E

Software avançado (ADV)

Recursos no software base mais AppFW, AppID, AppTrack, AppRoute

NFX150-C-ADV

NFX150-C-S1 e NFX150-C-S1E

NFX150-S-ADV

NFX150-S1 e NFX150-S1E