Entendendo o slicing de nós do Junos
Visão geral do slicing de nós do Junos
O slicing de nós do Junos permite que provedores de serviços e grandes empresas criem uma infraestrutura de rede que consolida várias funções de roteamento em um único dispositivo físico. Ele ajuda na hospedagem de vários serviços em uma única infraestrutura física, evitando a complexidade operacional envolvida. Ele também mantém a separação operacional, funcional e administrativa das funções hospedadas no dispositivo.
Usando o slicing de nós do Junos, você pode criar várias partições em um único roteador físico da Série MX. Essas partições são referidas como funções de rede de convidados (GNFs). Cada GNF se comporta como um roteador independente, com seu próprio plano de controle dedicado, plano de dados e plano de gerenciamento. Isso permite que você execute vários serviços em um único roteador da Série MX convergente, mantendo o isolamento operacional entre eles. Você pode utilizar o mesmo dispositivo físico para criar partições paralelas que não compartilham o plano de controle ou o plano de encaminhamento, mas apenas compartilham o mesmo chassi, espaço e energia.
Você também pode enviar tráfego entre GNFs pela malha do switch usando uma interface de malha abstraída (af) uma interface pseudo que se comporta como uma interface Ethernet de primeira classe. Uma interface de malha abstraída facilita o controle de roteamento, dados e tráfego de gerenciamento entre GNFs.
O slicing de nós junos oferece dois modelos - um modelo de servidor externo e um modelo no chassi. No modelo de servidor externo, os GNFs estão hospedados em um par de servidores x86 padrão do setor. Para o modelo no chassi, os GNFs estão hospedados nos mecanismos de roteamento do próprio roteador da Série MX.
O slicing de nós do Junos oferece suporte à compatibilidade de software de multiversão, permitindo assim que os GNFs sejam atualizados de forma independente.
Benefícios do slicing de nós do Junos
Converged network— Com o slicing de nós do Junos, os provedores de serviços podem consolidar vários serviços de rede, como borda de vídeo e borda de voz, em um único roteador físico, mantendo a separação operacional entre eles. Você pode alcançar convergência horizontal e vertical. A convergência horizontal consolida as funções do roteador da mesma camada para um único roteador, enquanto a convergência vertical colapsa as funções do roteador de diferentes camadas em um único roteador.
Improved scalability— O foco em partições de roteamento virtual, em vez de dispositivos físicos, melhora a programabilidade e a escalabilidade da rede, permitindo que provedores de serviços e empresas respondam aos requisitos de infraestrutura sem precisar comprar hardware adicional.
Easy risk management— Embora várias funções de rede convergam em um único chassi, todas as funções funcionam de forma independente, beneficiando-se da separação operacional, funcional e administrativa. A partição de um sistema físico, como o Broadband Network Gateway (BNG), em várias instâncias lógicas independentes garante que as falhas sejam isoladas. As partições não compartilham o plano de controle ou o plano de encaminhamento, mas apenas compartilham o mesmo chassi, espaço e potência. Isso significa que a falha em uma partição não causa nenhuma interrupção de serviço generalizada.
Reduced network costs— O slicing de nós do Junos permite a interconexão de GNFs através de malhas internas de comutação, que aproveita a interface de malha abstraída (
af) uma interface pseudo que representa um comportamento de interface Ethernet de primeira classe. Comafa interface em vigor, as empresas não precisam mais depender de interfaces físicas para conectar GNFs, resultando em economias significativas.Reduced time-to-market for new services and capabilities— Cada GNF pode operar em uma versão diferente do software Junos. Essa vantagem permite que as empresas evoluam cada GNF no seu próprio ritmo. Se um novo serviço ou um recurso precisar ser implantado em uma determinada GNF, e exigir uma nova versão de software, apenas a GNF envolvida requer uma atualização. Além disso, com o aumento da agilidade, o slicing de nós do Junos permite que provedores de serviços e empresas introduzam um modelo de negócios altamente flexível de tudo como serviço para responder rapidamente às condições de mercado em constante mudança.
Componentes do slicing de nós do Junos
O slicing de nós do Junos permite que você partique um único roteador da Série MX para fazê-lo aparecer como vários roteadores independentes. Cada partição tem seu próprio plano de controle Junos OS, que funciona como uma máquina virtual (VM) e um conjunto dedicado de placas de linha. Cada partição é chamada de função de rede de convidados (GNF).
O roteador da Série MX funciona como o sistema base (BSYS). O BSYS possui todos os componentes físicos do roteador, incluindo as placas de linha e a malha de comutação. O BSYS atribui placas de linha aos GNFs.
O software Juniper Device Manager (JDM) orquestra as VMs de GNF. No JDM, uma VM de GNF é referida como uma função de rede virtual (VNF). Uma GNF compreende assim uma VNF e um conjunto de placas de linha.
Por meio da configuração no BSYS, você pode atribuir placas de linha do chassi a diferentes GNFs. Além disso, dependendo do tipo de placa de linha, você pode até atribuir conjuntos de PFEs em uma placa de linha a diferentes GNFs. Veja a visão geral da placa sub-linha para obter mais detalhes.
O slicing de nós do Junos oferece suporte a dois modelos:
Modelo de servidor externo
Modelo no chassi
No modelo de servidor externo, JDM e VNFs estão hospedados em um par de servidores x86 padrão do setor externos.
A Figura 1 mostra três GNFs com suas placas de linha dedicadas em execução em um servidor externo.
externo
Veja conectando os servidores e o roteador para obter informações sobre como conectar um roteador da Série MX a um par de servidores x86 externos.
No modelo no chassi, todos os componentes (JDM, BSYS e GNFs) são executados dentro do mecanismo de roteamento do roteador da Série MX. Veja a Figura 2.
de nós Junos no chassi
Sistema base (BSYS)
No slicing de nós do Junos, o roteador da Série MX funciona como o sistema base (BSYS). O BSYS possui todos os componentes físicos do roteador, incluindo todas as placas de linha e malha. Através da configuração do Junos OS no BSYS, você pode atribuir placas de linha a GNFs e definir interfaces de malha abstraída (af) entre GNFs. O software BSYS é executado em um par de mecanismos de roteamento redundantes do roteador da Série MX.
Função de rede para convidados (GNF)
Uma função de rede de convidados (GNF) é logicamente proprietária das placas de linha atribuídas a ela pelo sistema base (BSYS) e mantém o estado de encaminhamento das placas de linha. Você pode configurar vários GNFs em um roteador da Série MX (veja Configuração de funções de rede de convidados). O plano de controle do Junos OS de cada GNF é executado como uma máquina virtual (VM). O software Juniper Device Manager (JDM) orquestra as VMs de GNF. No contexto JDM, os GNFs são chamados de funções de rede virtual (VNF).
Uma GNF equivale a um roteador autônomo. Os GNFs são configurados e administrados de forma independente, e estão operacionalmente isolados uns dos outros.
A criação de uma GNF requer dois conjuntos de configurações, uma para ser realizada no BSYS e outra no JDM.
Uma GNF é definida por um ID. Este ID deve ser o mesmo no BSYS e JDM.
A parte BSYS da configuração da GNF inclui oferecer a ele um ID e um conjunto de placas de linha.
A parte JDM da configuração da GNF compreende especificar os seguintes atributos:
Nome de VNF.
Uma ID da GNF. Este ID deve ser o mesmo que o ID da GNF usado no BSYS.
Tipo de plataforma da Série MX (para o modelo de servidor externo).
Uma imagem do Junos OS a ser usada para a VNF.
O modelo de recursos do servidor VNF.
O modelo de recursos do servidor define o número de núcleos de CPU dedicados (físicos) e o tamanho do DRAM a ser atribuído a uma GNF. Para obter uma lista de modelos de recursos de servidor predefinidos disponíveis para GNFs, consulte a seção Requisitos de recursos de hardware de servidor (por GNF) em Requisitos mínimos de hardware e software para slicing de nós junos.
Após a configuração de uma GNF, você pode acessá-la conectando-se à porta de console virtual da GNF. Usando o Junos OS CLI na GNF, você pode então configurar as propriedades do sistema GNF, como nome de host e endereço IP de gerenciamento, e posteriormente acessá-lo por meio de sua porta de gerenciamento.
Gerente de dispositivos da Juniper (JDM)
O Juniper Device Manager (JDM), um contêiner Linux virtualizado, permite o provisionamento e o gerenciamento das VMs da GNF.
O JDM oferece suporte ao Junos OS-like CLI, NETCONF para configuração e gerenciamento e SNMP para monitoramento.
No modelo no chassi, o JDM não oferece suporte a SNMP.
Uma instância JDM é hospedada em cada um dos servidores x86 no modelo de servidor externo e em cada mecanismo de roteamento para o modelo no chassi. As instâncias JDM normalmente são configuradas como pares que sincronizam as configurações de GNF: quando um VM GNF é criado em um servidor, seu VM de backup é criado automaticamente no outro servidor ou mecanismo de roteamento.
Um endereço IP e uma conta de administrador precisam ser configurados no JDM. Depois que estes forem configurados, você pode fazer login diretamente no JDM.
Veja também
Interface de malha abstraída
Interface de malha abstraída (af) é uma pseudo interface que representa um comportamento de interface Ethernet de primeira classe. Uma af interface facilita o controle de roteamento e o tráfego de gerenciamento entre funções de rede convidados (GNFs) através da malha do switch. Uma af interface é criada em uma GNF para se comunicar com sua GNF peer quando os dois GNFs estão configurados para serem conectados entre si. As interfaces de malha abstraídas devem ser criadas no BSYS. A largura de banda das af interfaces muda dinamicamente com base na inserção ou acessibilidade da placa de linha remota/MPC. Como a malha é o meio de comunicação entre GNFs, af as interfaces são consideradas as interfaces WAN equivalentes. Veja a Figura 3.
de malha abstraída
- Entendendo a largura de banda da interface de malha abstraída
- Recursos suportados em interfaces de malha abstraídas
- Restrições abstraídas da interface de malha
Entendendo a largura de banda da interface de malha abstraída
Uma interface de malha abstraída (af) conecta dois GNFs pela malha e agrega todos os mecanismos de encaminhamento de pacotes (PFEs) que conectam os dois GNFs. Uma af interface pode aproveitar a soma da largura de banda de cada Mecanismo de encaminhamento de pacotes pertencente à af interface.
Por exemplo, se o GNF1 tiver um MPC8 (que tem quatro mecanismos de encaminhamento de pacotes com capacidade de 240 Gbps cada), e o GNF1 estiver conectado com GNF2 e GNF3 usando af interfaces (af1 e af2), a capacidade máxima af de interface na GNF1 seria de 4x240 Gbps = 960 Gbps.
GNF1—af1——GNF2
GNF1—af2——GNF3
Aqui, af1 e af2 compartilham a capacidade de 960 Gbps.
Para obter informações sobre a largura de banda suportada em cada MPC, consulte a Tabela 1.
Recursos suportados em interfaces de malha abstraídas
As interfaces de malha abstraídas oferecem suporte aos seguintes recursos:
Upgrade unificado de software em serviço (ISSU)
Configuração de modo hiper no nível BSYS (a partir do Junos OS Release 19.3R2). Esse recurso é compatível com placas de linha MPC6E, MPC8E, MPC9E e MPC11E.
Nota:Você não pode ter configurações de hiper-modo diferentes para GNFs individuais, pois elas herdam a configuração do BSYS.
Os roteadores MX2020 e MX2010 com SFB3 surgem no modo hiper por padrão. Se você precisar de hiper-modo para ser desativado em qualquer GNF, você deve configurá-lo no BSYS, e ele se aplicará a todos os GNFs desse chassi.
Balanceamento de carga baseado nas placas de linha de GNF remotas presentes
Suporte a classe de serviço (CoS):
Classificador e reescrito de inet-precedência
Classificador e reescrito DSCP
Classificador e reescrito MPLS EXP
Classificador e reescrito DSCP v6 para tráfego IP v6
Suporte para os protocolos OSPF, IS-IS, BGP, OSPFv3 e L3VPN
Nota:As não-interfaces
afoferecem suporte a todos os protocolos que funcionam no Junos OS.Encaminhamento multicast
Switchover gracioso do mecanismo de roteamento (GRES)
Aplicativos MPLS onde a
afinterface atua como uma interface de núcleo (L3VPN, VPLS, L2VPN, L2CKT, EVPN e IP sobre MPLS)As seguintes famílias de protocolo são apoiadas:
Encaminhamento IPv4
Encaminhamento IPv6
MPLS
ISO
CCC
Suporte ao sensor Junos Telemetry Interface (JTI)
A partir do Junos OS Release 19.1R1, as funções de rede para convidados (GNFs) oferecem suporte a VPNs Ethernet (EVPN) com encapsulamento de protocolo de LAN virtual extensível (VXLAN). Esse suporte está disponível com interface e
afinterface não-físicasafcomo a interface voltada para o núcleo. Esse suporte não está disponível para a placa de linha MPC11E.Com a configuração da interface, os
afGNFs oferecem suporteafa MPCs. A Tabela 1 lista osafMPCs capazes, o número de PFEs suportados por MPC e a largura de banda suportada por MPC.Tabela 1: MPCs abstratos com capacidade de malha suportados MPC
Versão inicial
Número de PFEs
Largura de banda total
MPC7E-MRATE
17.4R1
2
480G (240*2)
MPC7E-10G
17.4R1
2
480G (240*2)
MX2K-MPC8E
17.4R1
4
960G (240*4)
MX2K-MPC9E
17.4R1
4
1,6T (400*4)
MPC2E
19.1R1
2
80 (40*2)
MPC2E NG
17.4R1
1
80G
MPC2E NG Q
17.4R1
1
80G
MPC3E
19.1R1
1
130G
MPC3E NG
17.4R1
1
130G
MPC3E NG Q
17.4R1
1
130G
32x10GE MPC4E
19.1R1
2
260G (130*2)
2x100GE + 8x10GE MPC4E
19.1R1
2
260G (130*2)
MPC5E-40G10G
18.3R1
2
240G (120*2)
MPC5EQ-40G10G
18.3R1
2
240G (120*2)
MPC5E-40G100G
18.3R1
2
240G (120*2)
MPC5EQ-40G100G
18.3R1
2
240G (120*2)
MX2K-MPC6E
18.3R1
4
520G (130*4)
MPC multisserviços (MS-MPC)
19.1R1
1
120G
16x10GE MPC
19.1R1
4
160G (40*4)
MX2K-MPC11E
19.3R2
8
4T (500G*8)
Recomendamos que você defina as configurações de af MTU na interface para se alinhar ao valor máximo permitido nas interfaces XE/GE. Isso garante uma fragmentação mínima ou nenhuma de pacotes pela af interface.
Restrições abstraídas da interface de malha
A seguir, as restrições atuais de interfaces de malha abstraídas:
Configurações como interface de endpoint
afúnica,afincompatibilidade de mapeamento interface-GNF ou mapeamento de váriasafinterfaces para a mesma GNF remota não são verificadas durante o compromisso no BSYS. Certifique-se de ter as configurações corretas.A alocação de largura de banda é estática, com base no tipo de MPC.
Pode haver quedas mínimas de tráfego (tanto de trânsito quanto de host) durante o offline/reinício de um MPC hospedado em uma GNF remota.
A interoperabilidade entre MPCs que são
afcapazes e os MPCs que nãoafsão capazes não é suportada.
Veja também
Otimizando o caminho da malha para interface de malha abstraída
Você pode otimizar o fluxo de tráfego sobre as interfaces abstraídas de malha (af) entre duas funções de rede de convidados (GNFs), configurando um modo de otimização de caminho de malha. Esse recurso reduz o consumo de largura de banda da malha impedindo qualquer salto de malha adicional (comutação de fluxos de tráfego de um mecanismo de encaminhamento de pacotes para outro) antes que os pacotes eventualmente cheguem ao mecanismo de encaminhamento de pacotes de destino. A otimização do caminho de malha, suportada no MX2008, MX2010 e MX2020 com MPC9E e MX2K-MPC11E, evita apenas um único salto de tráfego adicional que resulta do balanceamento abstrato da carga da interface de malha.
Você pode configurar um dos seguintes modos de otimização de caminho de malha:
monitor— Se você configurar esse modo, o peer GNF monitora o fluxo de tráfego e envia informações à GNF de origem sobre o Mecanismo de encaminhamento de pacotes para o qual o tráfego está sendo encaminhado atualmente e o mecanismo de encaminhamento de pacotes desejado que poderia fornecer um caminho de tráfego otimizado. Neste modo, a GNF de origem não encaminha o tráfego para o mecanismo de encaminhamento de pacotes desejado.optimize— Se você configurar esse modo, o peer GNF monitora o fluxo de tráfego e envia informações à GNF de origem sobre o Mecanismo de encaminhamento de pacotes para o qual o tráfego está sendo encaminhado atualmente e o mecanismo de encaminhamento de pacotes desejado que poderia fornecer um caminho de tráfego otimizado. A GNF de origem então encaminha o tráfego para o mecanismo de encaminhamento de pacotes desejado.
Para configurar um modo de otimização de caminho de malha, use os seguintes comandos CLI no BSYS.
user@router#set chassis network-slices guest-network-functions gnf id af-name collapsed-forward (monitor | optimize)user@router#commit
Após a configuração da otimização do caminho da malha, você pode usar o comando show interfaces af-interface-name na GNF para visualizar o número de pacotes que estão fluindo no caminho ideal/não ideal.
Veja também
Escolha entre o modelo de servidor externo e o modelo no chassi
O modelo externo do servidor permite configurar mais instâncias de GNFs com maior escala, já que você pode escolher um servidor com capacidade suficiente para atender aos requisitos da GNF. Com o modelo no chassi, o número de GNFs que podem ser configurados é uma função dos requisitos de escala dos GNFs constituintes e a capacidade geral do Mecanismo de Roteamento.
Os modelos externos de servidor e chassi do slicing de nós do Junos são mutuamente exclusivos. Um roteador da Série MX pode ser configurado para operar em apenas um desses modelos ao mesmo tempo.
Comportamento de função primária de BSYS e GNF
As seções a seguir abordam o comportamento de papel primário do BSYS e da GNF no contexto da redundância do Mecanismo de Roteamento.
A Figura 4 mostra o comportamento de papel primário da GNF e BSYS com redundância do mecanismo de roteamento.
Função primária da BSYS
O comportamento de arbitragem de função primária do mecanismo de roteamento BSYS é idêntico ao dos mecanismos de roteamento nos roteadores da Série MX.
Função primária da GNF
O comportamento de arbitragem de funções primárias de VM da GNF é semelhante ao dos mecanismos de roteamento da Série MX. Cada GNF é executado como um par de VMs de backup primário. Um VM GNF que funciona server0 (ou re0 para o chassi) é equivalente ao slot 0 do Mecanismo de Roteamento de um roteador da Série MX, e o VM GNF que funciona server1 (ou re1 para o chassi) é equivalente ao slot 1 do mecanismo de roteamento de um roteador da Série MX.
A função primária da GNF é independente do papel primário do BSYS e do de outros GNFs. A arbitragem da função primária da GNF é feita por meio do Junos OS. Em condições de falha de conectividade, o papel principal da GNF é tratado de maneira conservadora.
O modelo de função primária da GNF é o mesmo para modelos externos de servidor e chassi.
Como acontece com os mecanismos de roteamento da Série MX, você deve configurar o switchover gracioso do mecanismo de roteamento (GRES) em cada GNF. Este é um pré-requisito para que o VM de GNF de backup assuma automaticamente a função primária quando a VM da GNF primária falhar ou for reiniciada.
Funções de administrador de slicing de nós do Junos
As funções de administrador a seguir permitem que você realize as tarefas de fatiamento de nós:
Administrador de BSYS — Responsável pelo chassi físico, bem como pelo provisionamento de GNF (atribuição de placas de linha a GNFs). Os comandos CLI do Junos OS estão disponíveis para essas tarefas.
Administrador de GNF — Responsável pela configuração, operação e gerenciamento do Junos OS na GNF. Todos os comandos CLI do Junos OS regulares estão disponíveis ao administrador de GNF para essas tarefas.
Administrador JDM — Responsável pela configuração da porta de servidor JDM (para o modelo de servidor externo) e pelo gerenciamento de provisionamento e ciclo de vida das VMs (VNFs) da GNF. Os comandos JDM CLI estão disponíveis para essas tarefas.
Visão geral da placa sub-linha
No slicing de nós do Junos, cada GNF compreende um conjunto de placas de linha (FPCs). Por padrão, a melhor granularidade fornecida por uma GNF está no nível da placa de linha, porque cada GNF recebe placas de linha inteiras (ou seja, o conjunto completo de Mecanismos de encaminhamento de pacotes em cada placa de linha). Com o recurso de placa de sub-linha (SLC), você pode definir uma granularidade ainda mais fina da partição, atribuindo subconjuntos de Mecanismos de encaminhamento de pacotes em uma única placa de linha a diferentes GNFs.
Tais subconjuntos definidos pelo usuário dos Mecanismos de encaminhamento de pacotes em uma placa de linha são chamados de placas de sub-linha (SLCs). Operacionalmente, os SLCs funcionam como placas de linha independentes.
Quando você corta uma placa de linha, cada SLC dessa placa de linha deve ser atribuída a uma GNF diferente.
Você pode atribuir SLCs de várias placas de linha à mesma GNF.
Em uma configuração de fatiamento de nós do Junos com o recurso SLC, uma GNF pode incluir um conjunto de placas de linha inteiras, bem como um conjunto de fatias (SLCs) de placas de linha, oferecendo um nível mais alto de flexibilidade.
Quando uma placa de linha é fatiada, dois tipos de instâncias de software são executadas nessa placa de linha - uma única instância de placa de linha base (BLC) e várias instâncias SLC (tanto quanto o número de fatias dessa placa de linha). Atualmente, o recurso SLC está disponível apenas no MPC11E, que oferece suporte a dois SLCs. A instância BLC é responsável pelo gerenciamento de hardware comum a todos os SLCs dessa placa de linha, enquanto cada instância de SLC é responsável pelo gerenciamento do conjunto de mecanismos de encaminhamento de pacotes atribuídos exclusivamente a ele. A instância BLC executa o software Junos do BSYS, enquanto cada instância SLC executa o software Junos de sua GNF associada.
Os SLCs oferecem suporte a interface de malha abstraída e encaminhamento colapsado (ver Caminho de malha otimizado para interface de malha abstraída). Você pode usar o show interface af-interface-name comando para visualizar as estatísticas de equilíbrio de carga dos mecanismos de encaminhamento de pacotes específicos para fatias de FPC remotos. Veja detalhes das interfaces de exibição (Malha Abstraída).
O recurso de SLC está disponível apenas no MPC11E (número do modelo: MX2K-MPC11E).
Recursos de placa de linha para SLCs
Um SLC ou uma fatia de uma placa de linha define o conjunto de Mecanismos de encaminhamento de pacotes (dessa placa de linha) que devem operar juntos. Os mecanismos de encaminhamento de pacotes em uma placa de linha são identificados por IDs numéricos. Se uma placa de linha tiver "n" Mecanismos de encaminhamento de pacotes, os mecanismos individuais de encaminhamento de pacotes estarão numerados de 0 a (n-1). Além disso, os núcleos de CPU e DRAM na placa de controle da placa de linha também devem ser divididos e alocados na fatia. Para definir um SLC, então, é definir os seguintes recursos de placa de linha a serem dedicados a essa SLC:
-
Uma gama de mecanismos de encaminhamento de pacotes
-
O número de núcleos de CPU na placa de controle da placa de linha
-
O tamanho do DRAM (em GB) na placa de controle da placa de linha
Uma determinada quantidade do DRAM é automaticamente reservada para a instância BLC nessa placa de linha, e o restante está disponível para instâncias SLC.
Cada SLC é identificado por um ID numérico, atribuído pelo usuário.
Quando uma placa de linha é fatiada, as partições de recursos para cada fatia nessa placa de linha devem ser completamente definidas.
Recursos de placa de linha MPC11E para SLCs
Uma placa de linha MPC11E tem:
-
8 mecanismos de encaminhamento de pacotes
-
8 núcleos de CPU no conselho de controle
-
32 GB de DRAM no conselho de controle
5 GB de DRAM é automaticamente reservado para uso de BLC, 1 GB de DRAM é destinado ao host de placa de linha, e os 26 GB restantes estão disponíveis para fatias de SLC.
Um MPC11E é capaz de suportar dois SLCs.
A Tabela 2 define dois tipos de perfis de alocação de recursos suportados por um MPC11E para os dois SLCs, conhecidos aqui como SLC1 e SLC2.
No perfil simétrico, os Mecanismos de encaminhamento de pacotes e outros recursos de placa de linha são distribuídos uniformemente entre as fatias. No perfil assimétrico, apenas as combinações especificadas de recursos de placa de linha mostradas na Tabela 2 são suportadas.
Você pode configurar os seguintes perfis de SLC com base em como os Mecanismos de encaminhamento de pacotes [0-7] são divididos entre os dois SLCs:
-
Mecanismos de encaminhamento de pacotes 0-3 para um SLC e 4-7 para o outro SLC (perfil simétrico)
-
Mecanismos de encaminhamento de pacotes 0-1 para um SLC e 2-7 para o outro SLC (perfil assimétrico)
-
Mecanismos de encaminhamento de pacotes 0-5 para um SLC e 6-7 para o outro SLC (perfil assimétrico)
No perfil assimétrico, você pode atribuir 9 GB ou 17 GB de DRAM a uma SLC. Como todos os recursos da placa de linha devem ser totalmente atribuídos, e o DRAM total disponível para SLCs é de 26 GB, atribuir 9 GB de DRAM a um SLC exige que os 17 GB restantes sejam atribuídos à outra SLC.
| Perfil simétrico |
Perfil assimétrico |
|||
|---|---|---|---|---|
| Tipo de recurso |
SLC1 |
SLC2 |
SLC1 |
SLC2 |
| Mecanismo de encaminhamento de pacotes |
4 |
4 |
2 |
6 |
| DRAM |
13 GB |
13 GB |
17 GB/9 GB |
9 GB/17 GB |
| CPU |
4 |
4 |
4 |
4 |
Veja também: Configuração de placas sub-linha e atribuição a GNFs e gerenciamento de placas sub-linha.
Visão geral da interoperabilidade de software multiversão
A partir do Junos OS Release 17.4R1, o slicing de nós do Junos oferece suporte à compatibilidade de software multiversão, permitindo que o BSYS interopere com uma função de rede convidada (GNF) que executa uma versão do Junos OS que é superior à versão de software do BSYS. Esse recurso oferece suporte a uma gama de até duas versões entre GNF e BSYS. Ou seja, o software GNF pode ser duas versões superiores ao software BSYS. Tanto a BSYS quanto a GNF devem atender a um requisito de versão mínima do Junos OS Release 17.4R1.
As restrições no suporte à multiversão também são aplicáveis ao processo unificado de atualização de ISSU.
Embora a versão de software JDM não tenha uma restrição semelhante em relação às versões de software GNF ou BSYS, recomendamos que você atualize regularmente o software JDM. Uma atualização do JDM não afeta nenhum dos GNFs em execução.
Serviços de próxima geração no fatiamento de nós do Junos
O slicing de nós do Junos oferece suporte à placa de serviços MX-SPC3, uma placa de serviços de segurança que fornece poder de processamento adicional para executar os Serviços de próxima geração nas plataformas MX. Você pode habilitar serviços de próxima geração na função de rede de convidados (GNF), usando o CLI request system enable unified-services na GNF. Para oferecer suporte a um MX-SPC3, uma GNF deve ter uma placa de linha associada a ela.
Em uma configuração de fatiamento de nós do Junos, você pode usar tanto MX-SPC3 quanto MS-MPC no mesmo chassi, mas em diferentes mecanismos de roteamento GNF. Se você tiver habilitado os serviços de próxima geração na GNF, usando request system enable unified-serviceso MX-SPC3, você pode usar o MX-SPC3. Se você não tiver habilitado os Serviços de próxima geração, o MS-MPC entra em operação.
A instalação ou atualização de software de uma placa MX-SPC3 acontece quando você instala ou atualiza o Mecanismo de roteamento GNF associado.
O MX-SPC3 não oferece suporte a interfaces de malha abstraídas. Portanto, uma GNF que tenha uma placa MX-SPC3 vinculada a ela também deve ter uma placa de linha associada a ela.
Comparando o slicing de nós do Junos com sistemas lógicos
O slicing de nós junos é uma camada abaixo dos sistemas lógicos em Junos. Ambas as tecnologias têm alguns recursos sobrepostos, mas diferem em outros aspectos. Com o slicing de nós do Junos, placas de linha completas e, portanto, interfaces físicas, são atribuídas a uma GNF, enquanto com sistemas lógicos, uma única interface física em si pode ser compartilhada em diferentes sistemas lógicos, uma vez que várias interfaces lógicas definidas em uma interface física podem ser atribuídas a sistemas lógicos separados. Isso significa que os sistemas lógicos permitem uma granularidade mais fina de compartilhamento do que o fatiamento de nós do Junos. Mas todos os sistemas lógicos compartilham um único kernel Junos, executando necessariamente a mesma versão Junos, além de precisar compartilhar o Mecanismo de Roteamento e recursos físicos de placa de linha, como CPU, memória e armazenamento. Com o slicing de nós do Junos, cada GNF recebe seu próprio equivalente a um par de mecanismos de roteamento, como também placas de linha dedicadas a essa GNF, para que os GNFs não compartilhem a maioria dos recursos físicos – eles apenas compartilham o chassi e a malha de switches. Os GNFs, ao contrário dos sistemas lógicos, podem ser atualizados e administrados de forma independente como um roteador autônomo MX.
O slicing de nós do Junos é uma tecnologia que complementa e até aumenta sistemas lógicos, já que uma GNF pode ter vários sistemas lógicos dentro dele. Quando o isolamento físico, os recursos garantidos e o isolamento administrativo completo são primordiais, o slicing de nós do Junos seria uma combinação melhor. E onde a granularidade fina do compartilhamento, até o nível lógico da interface, é primordial, um sistema lógico seria a melhor combinação.
Licenciamento para slicing de nós do Junos
Operar o slicing de nós do Junos requer licenças para que os GNFs e as interfaces de malha abstraídas sejam instaladas no BSYS. Executar uma GNF sem licença instalada no BSYS resultará na seguinte mensagem de syslog e alarme menor:
CHASSISD_LICENSE_EVENT: License Network-Slices: Failed to get valid license('216') 'gnf-creation'
Minor alarm set, 1 Guest network functions creation for JUNOS requires a license.
Entre em contato com a Juniper Networks se tiver consultas relacionadas às licenças de fatiamento de nós do Junos.