Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Entender o slicing de nós do Junos

Visão geral do slicing de nós do Junos

O slicing de nós 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 a hospedar 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 Junos, você pode criar várias partições em um único roteador físico da Série MX. Essas partições são chamadas de GNFs (funções de rede convidadas). Cada GNF se comporta como um roteador independente, com seu próprio plano de controle, plano de dados e plano de gerenciamento dedicados. Isso permite que você execute vários serviços em um único roteador da Série MX convergente, enquanto ainda mantém o isolamento operacional entre eles. Você pode aproveitar 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 através da malha de comutação usando uma interface de malha abstrata (af), uma pseudo interface que se comporta como uma interface Ethernet de primeira classe. Uma interface de malha abstrata facilita o controle de roteamento, dados e tráfego de gerenciamento entre GNFs.

slicing de nós Junos oferece dois modelos - um modelo de servidor externo e um modelo no chassi. No modelo de servidor externo, as GNFs são hospedadas em um par de servidores x86 padrão do setor. Para o modelo no chassi, as GNFs são hospedadas nos mecanismos de roteamento do próprio roteador da Série MX.

slicing de nós Junos suporta compatibilidade de software multiversão, permitindo assim que as GNFs sejam atualizadas de forma independente.

Benefícios do slicing de nós do Junos

  • Converged network— Com o slicing de nós Junos, os provedores de serviços podem consolidar vários serviços de rede, como a borda de vídeo e a borda de voz, em uma única roteador física, mantendo a separação operacional entre eles. Você pode obter convergência horizontal e vertical. A convergência horizontal consolida funções de roteador da mesma camada em um único roteador, enquanto a convergência vertical colapsa funções de 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 os provedores de serviços e as empresas respondam aos requisitos da infraestrutura sem precisar comprar hardware adicional.

  • Easy risk management— Embora várias funções de rede convergem em um único chassi, todas as funções funcionam de maneira independente, beneficiando-se da separação operacional, funcional e administrativa. O particionamento 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 energia. 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 Junos permite a interconexão de GNFs por meio de malhas de comutação internas, que utilizam uma interface de malha abstrata (af), uma pseudo interface que representa um comportamento de interface Ethernet de primeira classe. Com af a interface instalada, 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 em seu próprio ritmo. Se um novo serviço ou recurso precisar ser implantado em uma determinada GNF e exigir uma nova versão de software, somente a GNF envolvida exigirá uma atualização. Além disso, com o aumento da agilidade, o slicing de nós Junos permite que os provedores de serviços e as 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 Junos permite particionar 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 do Junos OS, que é executado como uma máquina virtual (VM), e um conjunto dedicado de placas de linha. Cada partição é chamada de função de rede convidada (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 a GNFs.

O software Juniper Device Manager (JDM) orquestra as VMs GNF. No JDM, uma VM GNF é chamada de função de rede virtual (VNF). Assim, uma GNF compreende uma VNF e um conjunto de placas de linha.

Através 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é mesmo atribuir conjuntos de PFEs dentro de uma placa de linha a diferentes GNFs. Consulte Visão geral da placa de sublinha para obter detalhes.

slicing de nós Junos suporta dois modelos:

  • Modelo de servidor externo

  • Modelo no chassi

No modelo de servidor externo, o JDM e os VNFs são hospedados em um par de servidores x86 externos padrão do setor.

A Figura 1 mostra três GNFs com suas placas de linha dedicadas rodando em um servidor externo.

Figura 1: GNFs no servidor High-level network architecture diagram showing an x86 server with Juniper Device Manager managing GNFs and an MX Series chassis with Base System and FPCs linked to GNFs. externo

Consulte 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.

Figura 2: Slicing de nós do Junos no chassi MX Series Chassis diagram showing internal structure. Highlights Routing Engine with JDM, BSYS, GNF 1, GNF 2, GNF 3. GNFs connect to FPCs: FPC 1, 2, 3 for GNF 1; FPC 5, 6 for GNF 2; FPC 7, 8 for GNF 3.

Sistema base (BSYS)

No slicing de nós Junos, o roteador da Série MX funciona como o sistema base (BSYS). O BSYS é responsável por todos os componentes físicos do roteador, incluindo todas as placas de linha e a malha. Por meio da configuração do Junos OS no BSYS, você pode atribuir placas de linha a GNFs e definir interfaces de malha abstrata (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 de convidados (GNF)

Uma função de rede de convidados (GNF) possui logicamente as 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árias GNFs em um roteador da Série MX (veja a 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 GNF. No contexto do JDM, as GNFs são chamadas de funções de rede virtual (VNF).

Uma GNF é equivalente a um roteador autônomo. As GNFs são configuradas e administradas de forma independente e são operacionalmente isoladas umas das outras.

A criação de uma GNF requer dois conjuntos de configurações, um a ser executado no BSYS e outro no JDM.

Uma GNF é definida por um ID. Esse ID deve ser o mesmo no BSYS e no JDM.

A parte BSYS da configuração GNF compreende dar a ela um ID e um conjunto de placas de linha.

A parte JDM da configuração GNF compreende a especificação dos seguintes atributos:

  • Um nome VNF.

  • UM ID GNF. Esse ID deve ser o mesmo que o ID GNF usado no BSYS.

  • O 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 recurso do servidor VNF.

O modelo de recurso do servidor define o número de núcleos de CPU dedicados (físicos) e o tamanho da DRAM a ser atribuída 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ó do Junos.

Depois que uma GNF é configurada, você pode acessá-la conectando-se à porta do 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 através de sua porta de gerenciamento.

Gerenciador de dispositivos da Juniper (JDM)

O Juniper Device Manager (JDM), um contêiner Linux virtualizado, permite o provisionamento e o gerenciamento das VMs GNF.

O JDM oferece suporte a CLI semelhante ao Junos OS, NETCONF para configuração e gerenciamento e SNMP para monitoramento.

Observação:

No modelo no chassi, o JDM não suporta 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 são normalmente configuradas como pares que sincronizam as configurações GNF: quando uma VM GNF é criada em um servidor, sua VM de backup é criada automaticamente no outro servidor ou Mecanismo de Roteamento.

Um endereço IP e uma conta de administrador precisam ser configurados no JDM. Depois de configurados, você pode fazer login diretamente no JDM.

Veja também

Interface de malha abstraída

A interface de malha abstrata (af) é uma pseudo interface que representa um comportamento de interface Ethernet de primeira classe. Uma af interface facilita o roteamento, o controle e o gerenciamento de tráfego entre funções de rede de convidados (GNFs) através da malha de comutação. Uma af interface é criada em uma GNF para se comunicar com sua GNF peer quando as duas GNFs são configuradas para serem conectadas uma à outra. Interfaces de malha abstratas 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 as GNFs, af as interfaces são consideradas as interfaces WAN equivalentes. Veja a Figura 3.

Figura 3: Interface High-level architecture of a networking system showing interconnections: GNF1 with FPC0, GNF2 with FPC4, PFEs linked via green fabric labeled Fabric, central AF point, and data paths as black lines. de malha abstraída

Entendendo a largura de banda da interface de malha abstraída

Uma interface de malha abstrata (af) conecta duas GNFs através da malha e agrega todos os Mecanismos de Encaminhamento de Pacotes (PFEs) que conectam as duas 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 a GNF1 tiver um MPC8 (que tem quatro mecanismos de encaminhamento de pacotes com capacidade de 240 Gbps cada) e a GNF1 estiver conectada com a GNF2 e a GNF3 usando af interfaces (af1 e af2), a capacidade máxima af de interface na GNF1 será 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 abstratas

As interfaces de malha abstraídas suportam os seguintes recursos:

  • Upgrade de software em serviço (ISSU) unificado

  • Configuração do modo Hyper no nível BSYS (a partir do Junos OS Release 19.3R2). Esse recurso é suportado nas placas de linha MPC6E, MPC8E, MPC9E e MPC11E.

    Observação:

    • Você não pode ter configurações de modo hiperativo diferentes para GNFs individuais, pois elas herdam a configuração do BSYS.

    • Os roteadores MX2020 e MX2010 com SFB3 aparecem no modo hiper por padrão. Se você precisar que o modo hiper seja desabilitado em qualquer GNF, você deve configurá-lo no BSYS e ele se aplicará a todas as GNFs desse chassi.

  • Balanceamento de carga baseado nas placas de linha GNF remotas presentes

  • Suporte a classe de serviço (CoS):

    • Classificador de precedência de inet e reescrita

    • Classificador e reescrita de DSCP

    • Classificador e reescrita do MPLS EXP

    • Classificador DSCP v6 e reescrita para tráfego IP v6

  • Suporte para protocolos OSPF, IS-IS, BGP, OSPFv3 e L3VPN

    Observação:

    As não-interfacesaf oferecem suporte a todos os protocolos que funcionam no Junos OS.

  • BFD para BGP, IS-IS e OSPF a partir do Junos OS versão 24.2R1.

  • Encaminhamento multicast

  • Comutação de Mecanismo de Roteamento Gracioso (GRES)

  • Aplicativos MPLS em que a af interface atua como uma interface central (L3VPN, VPLS, L2VPN, L2CKT, EVPN e IP sobre MPLS)

  • As seguintes famílias de protocolo são suportadas:

    • Encaminhamento de IPv4

    • Encaminhamento de IPv6

    • MPLS

    • ISO

    • CCC

  • Suporte a sensores da Interface de telemetria Junos (JTI)

  • A partir do Junos OS Release 19.1R1, as funções de rede de convidados (GNFs) oferecem suporte a VPNs Ethernet (EVPN) com encapsulamento do protocolo LAN virtual extensível (VXLAN). Esse suporte está disponível com interface nãoaf (ou seja, física) e af interface como 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 af interface, as GNFs suportam afMPCs com capacidade para -. A Tabela 1 lista os afMPCs com capacidade para -, o número de PFEs suportados por MPC e a largura de banda suportada por MPC.

    Tabela 1: MPCs com capacidade de malha abstrata suportada

    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

    130 ouros

    MPC3E NG

    17.4R1

    1

    130 ouros

    MPC3E NG Q

    17.4R1

    1

    130 ouros

    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

    120 ouros

    16 x 10GE MPC

    19.1R1

    4

    160G (40*4)

    MX2K-MPC11E

    19.3R2

    8

    4T (500G*8)
Observação:

Recomendamos que você defina as configurações de MTU na af interface para alinhar ao valor máximo permitido nas interfaces XE/GE. Isso garante uma fragmentação mínima ou nenhuma de pacotes na af interface.

Restrições de interface de malha abstraída

A seguir estão as restrições atuais de interfaces de malha abstraídas:

  • Configurações como interface de endpoint af único, af incompatibilidade de mapeamento de interface para GNF ou mapeamento de várias af interfaces para a mesma GNF remota não são verificadas durante a confirmação 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 (trânsito e host) durante o off-line/reinicialização de um MPC hospedado em uma GNF remota.

  • Não há suporte para interoperabilidade entre MPCs compatíveis afe MPCs não afcompatíveis.

Veja também

Otimizando o caminho da malha para a interface de malha abstraída

Você pode otimizar o tráfego que flui pelas interfaces de malha abstraída (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 finalmente 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 resultante do balanceamento de carga da interface de malha abstraída.

Você pode configurar um dos seguintes modos de otimização de caminho de malha:

  • monitor— Se você configurar este modo, a GNF peer monitora o fluxo de tráfego e envia informações para a 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. Nesse modo, a GNF de origem não encaminha o tráfego para o Mecanismo de Encaminhamento de Pacotes desejado.

  • optimize— Se você configurar este modo, a GNF peer monitora o fluxo de tráfego e envia informações para a 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.

Depois de configurar a 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 atualmente no caminho ideal/não ótimo.

Veja também

Escolhendo entre o modelo de servidor externo e o modelo no chassi

O modelo de servidor externo permite configurar mais instâncias de GNFs com maior escala, uma vez que você pode escolher um servidor de capacidade suficiente para atender aos requisitos da GNF. Com o modelo no chassi, o número de GNFs que podem ser configuradas é uma função dos requisitos de escala das GNFs constituintes e da capacidade geral do Mecanismo de Roteamento.

O servidor externo e os modelos no chassi do slicing de nós Junos são mutuamente exclusivos. Um roteador da Série MX pode ser configurado para operar em apenas um desses modelos por vez.

Comportamento de função primária de BSYS e GNF

As seções a seguir abordam o comportamento de função primária do BSYS e da GNF no contexto da redundância do Mecanismo de Roteamento.

A Figura 4 mostra o comportamento de função primária de GNF e BSYS com redundância de Mecanismo de Roteamento.

Figura 4: Comportamento de função primária de GNF e BSYS (modelo de servidor externo) High-level architecture of redundant system with software and hardware mastership arbitration, featuring two x86 servers coordinating mastership roles.

Função principal da BSYS

O comportamento de arbitragem de função primária do Mecanismo de Roteamento BSYS é idêntico ao dos mecanismos de roteamento em roteadores da Série MX.

Função primária da GNF

O comportamento de arbitragem de função primária da VM GNF é semelhante ao dos mecanismos de roteamento da Série MX. Cada GNF é executada como um par de VMs de backup primário. Uma VM GNF que é executada em server0 (ou re0 para dentro do chassi) é equivalente ao slot 0 do Mecanismo de Roteamento de um roteador da Série MX, e a VM GNF que é executada em server1 (ou re1 para no chassi) é equivalente ao slot 1 do Mecanismo de Roteamento de um roteador da Série MX.

O papel principal da GNF é independente do papel primário da BSYS e de outras GNFs. A arbitragem do papel principal da GNF é feita por meio do Junos OS. Em condições de falha de conectividade, a função primária da GNF é tratada de forma conservadora.

O modelo de função primária GNF é o mesmo para os modelos de servidor externo e no chassi.

Observação:

Assim como nos mecanismos de roteamento da Série MX, você deve configurar uma comutação de Mecanismo de Roteamento (GRES) graciosa em cada GNF. Esse é um pré-requisito para que a VM GNF de backup assuma automaticamente a função primária quando a VM GNF primária falhar ou for reinicializada.

Funções de administrador de slicing de nós do Junos

As seguintes funções de administrador permitem que você execute as tarefas de Slicing de nós:

  • Administrador BSYS — Responsável pelo chassi físico, bem como pelo provisionamento GNF (atribuição de placas de linha a GNFs). Os comandos CLI do Junos OS estão disponíveis para essas tarefas.

  • Administrador da GNF — Responsável pela configuração, operação e gerenciamento do Junos OS na GNF. Todos os comandos regulares da CLI do Junos OS estão disponíveis para o administrador da GNF para essas tarefas.

  • Administrador JDM — Responsável pela configuração da porta do servidor JDM (para o modelo de servidor externo) e pelo provisionamento e gerenciamento do ciclo de vida das VMs GNF (VNFs). Os comandos da CLI do JDM estão disponíveis para essas tarefas.

Visão geral da placa de sublinha

No slicing de nós Junos, cada GNF compreende um conjunto de placas de linha (FPCs). Por padrão, a granularidade mais fina fornecida por uma GNF está no nível da placa de linha, porque a cada GNF são atribuídas 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 sublinha (SLC), você pode definir uma granularidade ainda mais fina de particionamento, atribuindo subconjuntos de mecanismos de encaminhamento de pacotes em uma única placa de linha a diferentes GNFs.

Esses subconjuntos definidos pelo usuário de mecanismos de encaminhamento de pacotes em uma placa de linha são chamados de placas de sublinha (SLCs). Operacionalmente, os SLCs funcionam como placas de linha independentes.

Quando você fatia uma placa de linha, cada SLC dessa placa de linha deve ser atribuído a uma GNF diferente.

Você pode atribuir SLCs de várias placas de linha à mesma GNF.

Em uma configuração de slicing de nós 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, fornecendo um nível mais alto de flexibilidade.

Quando uma placa de linha é fatiada, dois tipos de instâncias de software são executados nessa placa de linha - uma única instância de placa de linha de base (BLC) e várias instâncias de SLC (até 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 por gerenciar o hardware comum a todos os SLCs dessa placa de linha, enquanto cada instância SLC é responsável por gerenciar o conjunto de mecanismos de encaminhamento de pacotes atribuídos exclusivamente a ela. A instância BLC executa o software Junos do BSYS, enquanto cada instância SLC executa o software Junos de sua GNF associada.

Figura 5: SLCs atribuídos a GNFs em uma configuração de slicing de nós Junos baseada em servidor externo High-level architecture diagram of a networking system showing Juniper Device Manager interacting with Guest Network Functions and Flexible PIC Concentrators.

Os SLCs oferecem suporte à interface de malha abstrata e ao encaminhamento recolhido (consulte Otimizando o caminho da malha para a interface de malha abstrata). Você pode usar o show interface af-interface-name comando para visualizar as estatísticas de balanceamento de carga dos mecanismos de encaminhamento de pacotes específicos de fatia FPC remotos. Consulte mostrar interfaces (malha abstraída) para obter detalhes.

O recurso 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 de encaminhamento de pacotes individuais serã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 para a fatia. Para definir um SLC, então, é necessário definir os seguintes recursos de placa de linha a serem dedicados a esse SLC:

  • Uma gama de Mecanismo de Encaminhamento de Pacotes

  • O número de núcleos de CPU na placa de controle da placa de linha

  • O tamanho da DRAM (em GB) na placa de controle da placa de linha

Observação:

Uma determinada quantidade de DRAM é reservada automaticamente 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 da placa de linha MPC11E para SLCs

Uma placa de linha MPC11E tem:

  • 8 mecanismos de encaminhamento de pacotes

  • 8 núcleos de CPU na placa de controle

  • 32 GB de DRAM na placa de controle

5 GB de DRAM são reservados automaticamente para uso BLC, 1 GB de DRAM é alocado para o host da placa de linha e os 26 GB restantes estão disponíveis para fatias 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, referidos 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 de recursos de placa de linha especificadas mostradas na Tabela 2 são suportadas.

Observação:

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 um SLC. Como todos os recursos da placa de linha devem ser totalmente atribuídos e a DRAM total disponível para SLCs é de 26 GB, a atribuição de 9 GB de DRAM a uma SLC requer que os 17 GB restantes sejam atribuídos à outra SLC.

Tabela 2: Perfis SLC suportados pelo MPC11E
 

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 de sublinha e atribuição delas a GNFs e gerenciamento de placas de sublinha.

Visão geral da interoperabilidade de software multiversão

A partir do Junos OS Release 17.4R1, o slicing de nós Junos oferece suporte à compatibilidade de software multiversão, permitindo que o BSYS interopere com uma função de rede de convidados (GNF) que executa uma versão do Junos OS superior à versão de software do BSYS. Esse recurso oferece suporte a uma variedade de até duas versões entre GNF e BSYS. Ou seja, o software GNF pode ser duas versões superior ao software BSYS. Tanto o BSYS quanto o GNF devem atender a um requisito de versão mínima do Junos OS Release 17.4R1.

Observação:

As restrições no suporte a várias versões também são aplicáveis ao processo de atualização unificado do ISSU.

Embora o controle de versão do software JDM não tenha uma restrição semelhante em relação às versões do software GNF ou BSYS, recomendamos que você atualize regularmente o software JDM. Um upgrade do JDM não afeta nenhuma das GNFs em execução.

Serviços de próxima geração no slicing de nós Junos

slicing de nós 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 os Serviços de Próxima Geração na função de rede convidada (GNF), usando a 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 slicing de nós Junos, você pode usar o MX-SPC3 e o MS-MPC no mesmo chassi, mas em mecanismos de roteamento GNF diferentes. Se você ativou os serviços de próxima geração na GNF, usando request system enable unified-services, o MX-SPC3 fica on-line. Se você não tiver habilitado os Serviços de Próxima Geração, o MS-MPC ficará online.

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.

Observação:

O MX-SPC3 não oferece suporte a interfaces de malha abstratas. 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

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 slicing de nós 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 pode ser compartilhada entre 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 de compartilhamento mais fina do que o slicing de nós Junos. Mas todos os sistemas lógicos compartilham um único kernel do Junos, portanto, necessariamente rodando a mesma versão do Junos, além de ter que compartilhar o Mecanismo de Roteamento e os recursos físicos da placa de linha, como CPU, memória e armazenamento. Com slicing de nós Junos, cada GNF recebe seu próprio equivalente a um par de mecanismos de roteamento, assim como placas de linha dedicadas a essa GNF, de modo que as GNFs não compartilham a maioria dos recursos físicos – elas apenas compartilham o chassi e a malha de switches. As GNFs, ao contrário dos sistemas lógicos, podem ser atualizadas e administradas de forma independente como um roteador autônomo MX.

O slicing de nós Junos é uma tecnologia que complementa e até aumenta os sistemas lógicos, uma vez que uma GNF pode ter vários sistemas lógicos dentro dela. Onde o isolamento físico, os recursos garantidos e o isolamento administrativo completo são fundamentais, o slicing de nós Junos seria uma combinação melhor. E onde a granularidade fina do compartilhamento, até o nível da interface lógica, é fundamental, um sistema lógico seria a melhor combinação.

Licenciamento para slicing de nós do Junos

A operação do slicing de nós Junos requer licenças para as GNFs e interfaces de malha abstraída a serem instaladas no BSYS. Executar uma GNF sem uma licença instalada no BSYS resultará na seguinte mensagem de syslog e alarme menor:

Entre em contato com a Juniper Networks se tiver dúvidas sobre as licenças de slicing de nós Junos.

Documentação relacionada