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.
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.
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:
For Junos OS Release 18.2 R2
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:
|
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.
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 |
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.
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 |
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.
Versão do Junos OS |
Roteamento |
Segurança |
Comutação |
---|---|---|---|
18.1R1 |
|
|
|
18,2 R1 |
|
|
|
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-1Mapeie 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.
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:
user@host# run request vmhost mode throughput error: Mode cannot be changed; Reason: No CPUs are available for VNFs in the desired mode, but there is atleast one VNF currently configured
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.
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.
user@host# set vmhost mode custom custom-mode-name layer-2-infrastructure offline
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:
set vmhost virtualization-options interfaces ge-0/0/0 mapping interface heth-0-0
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
ememory 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
ememory 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ê configurarcpu 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 configurarcpu 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 ecpu 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.
user@host# set vmhost mode custom custom-mode-name layer-2-infrastructure cpu count count user@host# set vmhost mode custom custom-mode-name layer-2-infrastructure memory size memG user@host# set vmhost mode custom custom-mode-name layer-3-infrastructure cpu count count user@host# set vmhost mode custom custom-mode-name layer-3-infrastructure memory size memG
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.
user@host# set vmhost mode custom custom-mode-name layer-2-infrastructure cpu count count user@host# set vmhost mode custom custom-mode-name layer-2-infrastructure memory size memG user@host# set vmhost mode custom custom-mode-name layer-3-infrastructure cpu count count user@host# set vmhost mode custom custom-mode-name layer-3-infrastructure memory size memG user@host# set vmhost mode custom custom-mode-name nfv-back-plane cpu count count user@host# set vmhost mode custom custom-mode-name nfv-back-plane memory size memG
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:
set vmhost mode custom flex layer-2-infrastructure cpu count MIN set vmhost mode custom flex layer-2-infrastructure memory size MIN set vmhost mode custom flex layer-3-infrastructure cpu count MIN set vmhost mode custom flex layer-3-infrastructure memory size MIN
- Para modelos NFX150-S1/S1E:
set vmhost mode custom flex layer-2-infrastructure cpu count MIN set vmhost mode custom flex layer-2-infrastructure memory size MIN set vmhost mode custom flex layer-3-infrastructure cpu count MIN set vmhost mode custom flex layer-3-infrastructure memory size MIN set vmhost mode custom flex nfv-back-plane cpu count MIN set vmhost mode custom flex nfv-back-plane memory size MIN
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.
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.
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.
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 |