Em 1998, a Juniper Networks lançou seu primeiro roteador, o M40 Aproveitando ASICs (Application-Specific Integrated Circuits), o M40 foi capaz de superar qualquer outra arquitetura de roteador. O M40 também foi o primeiro roteador a ter uma verdadeira separação dos planos de controle e dados, e a Série M nasceu. Originalmente, o nome do modelo M40 referia-se à sua capacidade de processar 40 milhões de pacotes por segundo (Mpps). Como o portfólio de produtos se expandiu, o “M” agora se refere aos múltiplos serviços disponíveis no roteador, como o MPLS com uma grande variedade de VPNs. O principal caso de uso da Série M era permitir que os provedores de serviços fornecessem serviços baseados em IP e, ao mesmo tempo, suportassem redes de retransmissão de quadros e redes ATM.
O avanço rápido de 10 anos e o número de clientes que os Provedores de Serviços têm para suportar aumentaram exponencialmente. O frame relay e o ATM foram dizimados, pois os clientes estão exigindo serviços baseados em Ethernet de Camada 2 e Camada 3 de alta velocidade. Empresas de grande porte estão se tornando mais prestadoras de serviços e estão oferecendo serviços de IP para departamentos e subsidiárias.
Quase todos os equipamentos de rede se conectam via Ethernet. É uma das tecnologias de rede mais bem compreendidas e implantadas usadas atualmente. As empresas têm requisitos desafiadores para reduzir os custos operacionais e, ao mesmo tempo, fornecer mais serviços. Ethernet permite a simplificação nas operações de rede, administração e manutenção.
A série MX foi introduzida em 2007 para solucionar esses novos desafios. Ele é otimizado para fornecer serviços Ethernet de Camada 2 e Camada 3 de alta densidade e alta velocidade. O “M” ainda se refere à herança de múltiplos serviços, enquanto o “X” refere-se à nova capacidade de comutação e foco nas interfaces 10G e além; Também é interessante notar que o numeral romano para o número 10 é "X".
Não é tarefa fácil criar uma plataforma capaz de resolver esses novos desafios. A Série MX tem um forte pedigree: embora seja mecanicamente diferente, ela aproveita a tecnologia das séries M e T para o gerenciamento do chassi, estrutura de comutação e o mecanismo de roteamento.
Os recursos que você conheceu e ama na série M e T certamente estão presentes na Série MX, pois ela é executada na mesma imagem do Junos. Além dos “oldies, but goodies”, há um conjunto completo de recursos focados na comutação de provedores de serviços e no gateway de rede de banda larga (BNG).Aqui está apenas uma amostra do que está disponível no MX:
Alta disponibilidade
Roteamento Non-Stop (NSR), Non-Stop Bridging (NSB), Growing Routing Engine Switchover (GRES), Gracioso Restart (GR) e Atualização de Software em Serviço (ISSU)
Roteamento
RIP, OSPF, IS-IS, BGP e Multicast
Comutação
Conjunto completo de Spanning Tree Protocols (STP), manipulação de tags de VLAN do Provedor de Serviços, QinQ e a capacidade de escalar além de 4.094 domínios de ponte, aproveitando switches virtuais
Serviços inline
Conversão de endereços de rede (NAT), exportação de informações de fluxo de IP (IPFIX), serviços de encapsulamento e espelhamento de porta
MPLS
L3VPN, L2VPNs e VPLS
Serviços de banda larga
PPPoX, DHCP, QoS Hierárquico e rastreamento de endereço IP
Virtualização
Agregação de Links Multi-Chassis, Chassi Virtual, Sistemas Lógicos, Comutadores Virtuais
Com um conjunto de recursos tão grande, o caso de uso da série MX é muito amplo. É comum vê-lo no núcleo de uma rede de provedores de serviços, fornecendo BNG ou na empresa fornecendo roteamento de borda ou comutação de núcleo.
Esta publicação apresenta a plataforma, os recursos e a arquitetura do MX. Analisaremos o hardware, os componentes e a redundância em detalhes.
Junos OS
O Junos OS é um sistema operacional de rede construído para esse fim, baseado em um dos sistemas operacionais mais estáveis e seguros do mundo: o FreeBSD. O software Junos foi projetado como uma arquitetura de kernel monolítica que coloca todos os serviços do sistema operacional no espaço do kernel. Os principais componentes do Junos são escritos como daemons que fornecem processo completo e separação de memória. Desde Junos 14.x, uma grande mudança foi introduzida - modularidade. Embora o Junos ainda seja baseado no FreeBSD, ele se torna independente do “guest OS” e oferece uma separação entre o Core OS e os drivers HW. Muitas melhorias estão chegando nos próximos anos.
De fato, o Junos OS está iniciando sua grande modernização à medida que esta Segunda Edição deste livro está sendo escrita. Para fins de dimensionamento, será mais modular, mais rápido e mais fácil de suportar toda a nova funcionalidade virtual que acompanha os SDN. O Junos já está migrando para arquiteturas de software recentes, como o Kernel SMP e o sistema operacional multi-core.
Um Junos
A criação de um único sistema operacional de rede capaz de ser aproveitado pelos roteadores, switches e firewalls simplifica as operações, a administração e a manutenção da rede. As operadoras de rede só precisam aprender Junos uma vez e tornar-se instantaneamente efetivas em outros produtos da Juniper. Um benefício adicional de uma única instância do Junos é que não há necessidade de reinventar a roda e ter 10 implementações diferentes do BGP ou do OSPF. Ser capaz de escrever esses protocolos principais uma vez e reutilizá-los em todos os produtos fornece um alto nível de estabilidade, pois o código é muito maduro e testado em campo.
Lançamentos de Software
Por um longo tempo (quase 15 anos) tem havido uma versão consistente e previsível de Junos a cada trimestre do calendário. Recentemente, a Juniper mudou sua estratégia de lançamento, começando com o Junos 12.xe 13.x, cada um oferecendo três lançamentos principais, e depois o Junos 14.x, que oferecia dois lançamentos principais. O desenvolvimento do sistema operacional principal é agora um único lançamento que permite aos desenvolvedores criar novos recursos ou corrigir erros e compartilhá-los em várias plataformas. Cada versão do software Junos é criada para os mecanismos de roteamento de 32 bits e 64 bits.
Os números de lançamento estão agora em um formato maior e menor. O número principal é a versão do Junos para um determinado ano e a versão secundária indica em qual semestre do ano o software foi lançado. Quando existem vários números maiores e menores, identifica uma versão principal - por exemplo, 14.1, 14.2.
Desde Junos 14.x, cada versão do Junos OS (as duas maiores por ano) é suportada por 36 meses. Em outras palavras, todo software Junos possui um Extended Life of Life (EEOL) conhecido, conforme mostrado na Figura 1-1 .
Existem alguns tipos diferentes de Junos que são lançados com mais freqüência para resolver problemas: versões de manutenção e serviço. Lançamentos de manutenção são lançados a cada oito semanas para corrigir uma coleção de problemas e eles são prefixados com “R.” Por exemplo, o Junos 14.2R2 seria a segunda versão de manutenção do Junos 14.2. As versões de serviço são liberadas sob demanda para corrigir especificamente um problema crítico que ainda precisa ser resolvido por uma versão de manutenção. Essas versões são prefixadas com um “S.” Um exemplo seria Junos 14.2R3-S2.
A regra geral é que novos recursos são adicionados a cada versão menor e correções de bugs são adicionadas a cada versão de manutenção. Por exemplo, os Junos 14.1 a 14.2 introduziriam novos recursos, enquanto o Junos 14.1R1 a 14.1R2 introduziria correções de bugs.
O próximo lançamento do Junos “15” introduz o conceito de prefixos de lançamento de “Inovação” com F. Cada lançamento principal oferecerá duas versões de inovação que devem ajudar os clientes a implementar rapidamente recursos inovadores. Os recursos inovadores serão incluídos no próximo grande lançamento. Por exemplo, a versão principal 15.1 terá duas versões “F”: 15.1F1 e 15.2F2. E isso será o mesmo para o segundo grande lançamento, 15.2. As inovações desenvolvidas no 15.1F1 serão incluídas nativamente na primeira versão de manutenção do próximo software principal: 15.2R1
Junos Continuidade - JAM
JAM significa Junos Agile Methodology , um novo conceito também conhecido por seu nome de marketing Junos Continuity .
O recurso JAM é um dos novos aprimoramentos de modularidade Junos. Em versões anteriores a 14.x, os drivers de hardware foram incorporados na versão maior do software Junos, que não permitia a instalação de novos modelos de placas de linha (por exemplo, aqueles ainda não disponíveis antes de uma determinada versão do Junos) sem exigir uma nova versão completa. Junos de instalação.
Desde Junos 14.x, foi feita uma separação entre o núcleo do Junos e os drivers de hardware, permitindo que um operador implemente novo hardware em versões existentes do Junos, conforme mostrado na Figura 1-2. É um avanço significativo em termos de tempo gasto para testar, validar e atualizar uma grande rede. De fato, o novo hardware geralmente é solicitado pelos clientes com mais frequência do que uma nova adição de software, geralmente para atualizar sua capacidade de largura de banda, que cresce muito rapidamente em redes de Internet Service ou Provedor de Conteúdo. Você só precisa de mais interfaces de 10G ou 100G por slot com apenas os recursos de paridade definidos. A capacidade de instalar um hardware mais novo, mais rápido e mais denso, mantendo a atual versão estável do Junos que você configurou, é um ótimo recurso. As funcionalidades do JAM também evitam o tempo de inatividade porque a instalação de um novo hardware com o JAM não requer qualquer reinicialização do roteador. Impressionante, não é?
O modelo JAM é composto por dois componentes principais:
O banco de dados JAM
Incluído no próprio Junos OS (em outras palavras, em um release Junos com reconhecimento de JAM), portanto, o sistema operacional mantém parâmetros e atributos específicos da plataforma.
O pacote JAM
Um conjunto de drivers de placa de linha e chipset (arquivo JFB).
Existem dois métodos para implementar o JAM e obter o máximo benefício dele:
Com um pacote JAM independente disponível para qualquer release eleitoexistente (uma versão que suporte oficialmente o modelo JAM). Os primeiros lançamentos eleitos para o JAM são 14.1R4 e 14.2R3. Um pacote JAM independente é diferente de um pacote jinstall que é prefixado por “ jam-xxxx ”
.
Através de um lançamento integrado do JAM. Nesta configuração, os pacotes JAM são diretamente integrados ao pacote jinstall.
Vamos pegar o exemplo do primeiro pacote JAM já disponível ( jam-mpc-2e-3e-ng64) : JAM para placas NG-MPC2 e NG-MPC3. Este pacote JAM único inclui drivers de hardware para os novos cartões a seguir:
MPC2E-3D-NG
MPC2E-3D-NG-Q
MPC3E-3D-NG
MPC3E-3D-NG-Q
Os lançamentos eleitos para este pacote são 14.1R4 e 14.2R3, como mencionado anteriormente. Os clientes que usam essas versões podem instalar a próxima geração de placas MPC sem qualquer nova instalação do Junos. Eles poderiam seguir o procedimento típico de instalação:
Inserir novo MPC (MPC permanece offline porque não é suportado).
Instale o pacote JAM independente para a FRU especificada.
Traga o MPC online.
O MPC recupera seu driver do banco de dados JAM (no RE).
O MPC inicializa e fica totalmente operacional.
Os usuários que usam versões mais antigas devem usar o modo integrado instalando o Junos release 14.1 ou 14.2, que inclui um pacote JAM para esses cartões. Finalmente, outra opção pode ser usar o release nativo , que fornece suporte integrado para esses novos MPCs; para placas NG-MPC 2 e NG -MPC3, a versão nativa é 15.1.R1.
Arquitetura de software
O Junos foi projetado desde o início para suportar uma separação de controle e plano de encaminhamento. Isso é verdadeiro para a Série MX, onde todas as funções do plano de controle são executadas pelo Mecanismo de Roteamento, enquanto todo o encaminhamento é executado pelomotor de encaminhamento de pacotes (PFE). PFEs são hospedados na placa de linha, que também tem uma CPU dedicada para se comunicar com o RE e lidar com alguns recursos inline específicos.
O fornecimento desse nível de separação garante que um avião não cause impacto no outro. Por exemplo, o plano de encaminhamento poderia estar roteando o tráfego na taxa de linha e realizando muitos serviços diferentes enquanto o mecanismo de roteamento fica com as funções do plano de controle ocioso e não afetado em vários formatos e tamanhos. Há um equívoco comum de que o plano de controle lida apenas com atualizações de protocolos de roteamento. Na verdade, existem muitas outras funções no plano de controle.
Alguns exemplos incluem:
Atualizando a tabela de roteamento
Respondendo a consultas SNMP
Processando o tráfego SSH ou HTTP para administrar o roteador
Alterando a velocidade do ventilador
Controlando a interface da embarcação
Fornecendo um micro-kernel Junos para os PFEs
Atualizando a tabela de encaminhamento nos PF
Em um nível alto, o plano de controle é implementado dentro do Mecanismo de Roteamento, enquanto o plano de redirecionamento é implementado dentro de cada PFE, usando um pequeno kernel de propósito específico que contém apenas as funções necessárias para rotear e mudar o tráfego. Algumas tarefas do plano de controle são delegadas à CPU das placas de linha do Trio para aumentar a escala. Este é o caso para o ppmdprocesso detalhado momentaneamente.
O benefício do controle e da separação do encaminhamento é que qualquer tráfego que esteja sendo roteado ou comutado através do roteador será sempre processado na taxa de linha nos PFEs e na malha do comutador; por exemplo, se um roteador estava processando tráfego entre servidores da Web e a Internet, todo o processamento seria executado pelo plano de encaminhamento.
O kernel Junos tem cinco principais daemons; Cada um desses daemons desempenha um papel crítico dentro do MX e trabalha em conjunto por meio da Interprocess Communication (IPC) e dos sockets de roteamento para se comunicar com o kernel Junos e outros daemons. Os seguintes daemons ocupam o centro do palco e são necessários para a operação de Junos:
Daemon de gerenciamento ( mgd)
Daemon de protocolo de roteamento ( rpd)
Daemon periódico de gerenciamento de pacotes ( ppmd)
Daemon de controle de dispositivos ( dcd)
Daemon do chassi ( chassisd)
Existem muitos outros daemons para tarefas como NTP, VRRP, DHCP e outras tecnologias, mas eles desempenham um papel menor e mais específico na arquitetura de software.
Daemon de gerenciamento
A Junos User Interface (UI) mantém tudo em um banco de dados centralizado. Isso permite que o Junos manipule dados de maneiras interessantes e abra as portas para recursos avançados, como reversão de configuração, aplicar grupos e ativar e desativar porções inteiras da configuração.
A interface do usuário tem quatro componentes principais: o banco de dados de configuração, o esquema do banco de dados, o daemon de gerenciamento ( mgd) e a interface da linha de comandos ( cli).
O daemon de gerenciamento ( mgd) é a cola que mantém toda a Junos User Interface (UI) unida. Em um nível alto, mgdfornece um mecanismo para processar informações para os operadores de rede e daemons.
O componente interativo de mgdé o Junos cli; este é um aplicativo baseado em terminal que permite ao operador de rede uma interface para o Junos. O outro lado mgdé a interface de chamada de procedimento remoto (RPC) da linguagem de marcação extensível (XML). Isso fornece uma API através do Junoscript e do Netconf para permitir o desenvolvimento de aplicativos de automação.
As cliresponsabilidades são:
Edição de linha de comando
Emulação de terminal
Paginação de terminal
Exibindo conclusões de comandos e variáveis
Monitorando arquivos de log e interfaces
Executando processos filhos, como ping, traceroute e ssh
mgd responsabilidades incluem:
Passando comandos do clipara o daemon apropriado
Localizando Comando e Complementos Variáveis
Comando de análise
É interessante notar que a maioria dos comandos operacionais do Junos usa XML para passar dados. Para ver um exemplo disso, simplesmente adicione o comando pipe display xmla qualquer comando. Vamos dar uma olhada em um comando simples como show isis adjacency:
{master}
dhanks @ R1-RE0> show isis adjacency
Sistema de interface L Estado Hold (segs) SNPA
ae0.1 R2-RE0 2 Up 23
Até agora tudo parece normal. Vamos adicionar o display xmlpara dar uma olhada mais de perto:
{master} dhanks @ R1-RE0> show isis adjacência | display xml
<rpc-resposta xmlns: junos = "http://xml.juniper.net/junos/11.4R1/junos">
<isis-adjacência-informação xmlns = "http://xml.juniper.net/junos/ 11.4R1 / junos
-routing "junos: style =" breve ">
<isis-adjacência>
<nome-da-interface> ae0.1 </ nome-da-interface>
<nome-do-sistema> R2-RE0 </ nome-do-sistema>
<nível > 2 </ level>
<estado de adjacência> Up </ estado de adjacência>
<holdtime> 22 </ holdtime>
</ isis-adjacência>
</ isis-adjacency-information>
<cli>
Como você pode ver, os dados são formatados em XML e recebidos mgdvia RPC.
Esse recurso (disponível desde o começo do Junos) é um mecanismo muito inteligente de separação entre o modelo de dados e o processamento de dados, e acaba sendo um grande ativo em nossa recém-descoberta era de automação de rede - além do protocolo netconf, O Junos oferece a capacidade de gerenciar e configurar remotamente o MX de maneira eficiente.
Daemon de protocolo de roteamento
O daemon de protocolo de roteamento ( rpd) lida com todos os protocolos de roteamento configurados no Junos. Em alto nível, suas responsabilidades estão recebendo anúncios e atualizações de roteamento, mantendo a tabela de roteamento e instalando rotas ativas na tabela de encaminhamento. Para manter a separação do processo, cada protocolo de roteamento configurado no sistema é executado como uma tarefa separada rpd. A outra responsabilidade rpdé trocar informações com o kernel do Junos para receber modificações na interface, enviar informações de rota e enviar mudanças na interface.
Vamos dar uma olhada rpde ver o que está acontecendo. O comando oculto set task accountingativa e desativa a contabilização da CPU:
{master}
dhanks @ R1-RE0> define a contabilidade de
tarefas na contabilidade de tarefas ativada.Agora estamos bem para ir. O Junos está atualmente desenvolvendo tarefas e daemons para obter uma idéia melhor do que está usando a CPU do Routing Engine. Vamos aguardar alguns minutos para coletar alguns dados.
Agora podemos usar show task accountingpara ver os resultados:
{master}
dhanks @ R1-RE0> mostrar contabilidade de
tarefas A contabilidade de tarefas está ativada.
Tarefa Iniciada Tempo do usuário Tempo do sistema
Programação de execução mais longa 265 0,003 0,000 0,000
Memória 2 0,000 0,000 0,000
hakr 1 0,000 0 0,000
ES-IS I / O. / var / run / ppmd_c 6 0,000 0 0,000
IS-IS I / O. / var / run / ppmd_c 46 0,000 0,000 0,000
PIM I / O. / var / run / ppmd_con 9 0,000 0,000 0,000
IS-IS 90 0,001 0,000 0,000
E / S de BFD / var / run / bfdd_con 9 0.000 0 0.000
Tarefa de Espelho.128.0.0.6 + 598 33 0.000 0.000 0.000
KRT 25 0.000 0.000 0.000
Redirecionar 1 0.000 0.000 0.000
MGMT_Listen./var/run/rpd_ 7 0.000 0.000 0.000
SNMP Subagente./var/run/sn 15 0,000 0,000 0,000Não muito aqui, mas você tem a ideia. Atualmente, os daemons e tarefas em execução rpdestão presentes e são contabilizados.
Depois de concluir a depuração, desative a contabilização:
{master}
dhanks @ R1-RE0> definir contagem de tarefas desativada Contabilidade de
tarefas desativada.
Daemon periódico de gerenciamento de pacotes
O gerenciamento periódico de pacotes ( ppmd) é um processo específico dedicado ao manuseio e gerenciamentoOlá pacotes de vários protocolos. Nos primeiros lançamentos do Junos, o RPD gerenciava o estado de adjacências. Cada tarefa, como o OSPF e o ISIS, era responsável por receber e enviar pacotes periódicos e manter o tempo de cada adjacência. Em algumas configurações, em ambientes de grande escala com temporizadores agressivos (próximos do segundo), o RPD poderia experimentar eventos SLIP do agendador , que quebraram o tempo real exigido pelos hellos periódicos.
A Juniper decidiu colocar o gerenciamento de pacotes Hello fora do RPD para melhorar a estabilidade e a confiabilidade em ambientes dimensionados. Outro objetivo era fornecer detecção de falhas de subsegundos, permitindo que novos protocolos como o BFD propusessem tempos de espera de milissegundos.
Primeiro de tudo, ppmdfoi desenvolvido para os protocolos ISIS e OSPF, como parte do processo de daemon de roteamento. Você pode mostrar este comando para verificar qual tarefa do RPD delegou seu gerenciamento de saudação para ppmd:
jnpr @ R1> show task | match ppmd_control
39 I / O ES-IS / var / run / ppmd_control 40 <>
39 I / O IS-IS / var / run / ppmd_control 39 <>
40 I / O PIM / var / run / ppmd_control 41 < >
40 LDP E / S / var / run / ppmd_control 16 <>ppmdfoi posteriormente estendido para suportar outros protocolos, incluindo LACP, BFD, VRRP e OAM LFM. Esses últimos protocolos não são codificados no RPD, mas possuem um processo dedicado e nomeado de forma correspondente: lacpd, bfdd, vrrpd, lfmd e assim por diante.
A motivação ppmdé ser o mais burro possível contra seus clientes (RPD, LACP, BFD ...). Em outras palavras, notifique os processos do cliente somente quando houver uma alteração de adjacência ou para enviar de volta estatísticas coletadas.
Por vários anos, ppmdnão foi um processo único hospedado no mecanismo de roteamento e agora ele foi desenvolvido para funcionar de maneira distribuída. Na verdade, ppmdroda no Mecanismo de Roteamento, mas também em cada placa de linha Trio, na CPU da placa de linha, onde é chamadaGerenciador de PPM , também conhecido como ppm man . O seguinte comando PFE mostra o segmento man ppm em uma CPU de placa de linha:
NPC11 (R1 vty) # mostrar tópicos
[...]
54 M Gerenciador de PPM adormecido 4664/8200 0/0/2441 ms 0%A motivação para a delegação de algum processamento de controle para o CPU da placa de linha originou-se com o surgimento de protocolos de subsegundos como o BFD. Recentemente, a placa de linha Trio oferece uma terceira versão aprimorada do ppm, impulsionada também pelo protocolo BFD em ambientes escalonados, que é chamado de inline ppm . Neste caso, o SO Junos empurrou o gerenciamento de sessão para os próprios mecanismos de encaminhamento de pacotes.
Para verificar qual adjacência é delegada ao hardware ou não, você pode usar os seguintes comandos ocultos:
/ * todas as adjacências gerenciam por ppmd * /
jnpr @ R1> mostra ppm adjacências
Protocolo Tempo de espera (ms)
VRRP 9609
LDP 15000
LDP 15000
ISIS 9000
ISIS 27000
PIM 105000
PIM 105000
LACP 3000
LACP 3000
LACP 3000
LACP 3000
Adjacências: 11, adjacências remotas : 4
/ * todas as adjacências gerenciam por ppmd remoto (ppm man ou inline ppmd) * /
jnpr @ R1> mostra ppm adjacências remotas
Protocolo Hold time (ms)
LACP 3000
LACP 3000
LACP 3000
LACP 3000
Adjacências: 4, adjacências remotas: 4Os recursos de delegação ppm e ppm em linha estão ativados por padrão, mas podem ser desativados. Na configuração a seguir, somente a ppmdinstância do mecanismo de roteamento funcionará.
set opções de roteamento ppm no-delegate-processing
set opções de roteamento ppm no-in-line-processing
Daemon de controle de dispositivos
O daemon de controle de dispositivos ( dcd) é responsável pela configuração de interfaces com base na configuração atual e no hardware disponível. Uma característica do Junos é poder configurar hardware inexistente, já que a suposição é que o hardware pode ser adicionado em uma data posterior e “apenas funcionar”. Um exemplo é a expectativa que você pode configurar set interfaces ge-1/0/0.0 family inet address 192.168.1.1/24e confirmar. Supondo que não haja hardware no FPC1, essa configuração não fará nada. Assim que o hardware for instalado no FPC1, a primeira porta será configurada imediatamente com o endereço 192.168.1.1/24.
Chassis daemon (e amigos)
O daemon de chassi ( chassisd) suporta todos os processos de chassi, alarme e ambientais. Em alto nível, isso inclui monitorar a integridade do hardware, gerenciar um banco de dados em tempo real do inventário de hardware e coordenar com o daemon de alarme ( alarmd) ecraft daemon ( craftd) para gerenciar alarmes e LEDs.
Tudo deve parecer auto-explicativo, exceto para craftd; a interface da embarcação que é o painel frontal do dispositivo, conforme mostrado na Figura 1-5 . Vamos dar uma olhada mais de perto na interface do ofício MX960.
A interface de artesanato é uma coleção de botões e luzes de LED para exibir o status atual do hardware e dos alarmes. Informações também podem ser obtidas:
dhanks @ R1-RE0> show chassi craft-interface
LEDs do painel frontal do sistema:
Routing Engine 0 1
--------------------------
OK * *
Falha . .
Mestre * .
Indicadores de alarme do painel frontal:
-----------------------------
LED vermelho.
LED amarelo
Relé principal
Relé menor
LEDs do painel frontal do FPC:
FPC 0 1 2
------------------
Vermelho. . .
Verde. * *
LEDs CB:
CB 0 1
--------------
Âmbar. .
Verde * *
LEDs
PS : PS 0 1 2 3
--------------------
Vermelho. . . .
Verde *. . .
LEDs da bandeja do ventilador:
FT 0
----------
Vermelho.
Verde *Uma das responsabilidades finais chassisd é monitorar os ambientes de energia e refrigeração. chassisd monitora constantemente as tensões de todos os componentes dentro do chassi e enviará alertas se a tensão cruzar qualquer limite. O mesmo vale para o resfriamento. O daemon de chassi monitora constantemente a temperatura em todos os diferentes componentes e chips, bem como a velocidade da ventoinha. Se alguma coisa estiver fora do comum, chassisd criará alertas. Sob condições extremas de temperatura, chassisd também pode desligar os componentes para evitar danos.
Para este post não ficar muito extenso continuaremos este assunto em uma próxima publicação à partir do assunto "Soquetes de Roteamento".
Até lá!
ASG
https://www.asgit.com.br/
contato@asg.com.br
(51) 3376.1210
Comments