Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
Nesta página
 

Configuração do Gerenciamento de Falhas de Conectividade (CFM)

Use esse tópico para configurar recursos de gerenciamento de falhas de conectividade, como domínios de manutenção, associações de manutenção, pontos intermediários de manutenção (MIPs) e parâmetros de verificação de continuidade. Você também pode usar esse tópico para configurar um perfil de ação para especificar a ação do CFM que deve ser executada quando ocorre um evento CFM específico.

Criação de um domínio de manutenção

Para habilitar o gerenciamento de falhas de conectividade (CFM) em uma interface Ethernet, primeiro você deve configurar um domínio de manutenção e especificar o nome do domínio da manutenção. Você também pode especificar o formato do nome. Por exemplo, se você especificar o formato do nome como serviço de nome de domínio (DNS), você pode especificar o nome do domínio da manutenção como www.juniper.net. O formato de nome padrão é string de caracteres ASCII.

Nota:

Para interfaces lógicas, o nome do domínio da manutenção deve ser exclusivo em sistemas lógicos. Se você configurar o mesmo nome de domínio da manutenção em sistemas lógicos, receberá a seguinte mensagem de erro: error: configuration check-out failed.

Durante a criação do domínio da manutenção, você também pode especificar o nível do domínio da manutenção. O nível do domínio da manutenção indica a relação de aninhamento entre vários domínios de manutenção. O nível de domínio da manutenção está integrado em cada um dos quadros do CFM.

Para criar um domínio de manutenção:

  1. No modo de configuração, crie um domínio de manutenção especificando o nome e o formato do nome no nível edit protocols oam ethernet connectivity-fault-management [ ] da hierarquia.
    Nota:

    Se você configurar o comprimento do nome do domínio da manutenção com mais de 45 octetos, a seguinte mensagem de erro será exibida: error: configuration check-out failed.

  2. Especifique o nível do domínio da manutenção especificando o valor no nível edit protocols oam ethernet connectivity-fault-management da hierarquia [ ]

Configurando MIPs (Maintenance Intermediate Points, Pontos Intermediários de Manutenção)

Os roteadores da Série MX suportam pontos intermediários de manutenção (MIPs) para o protocolo CFM Ethernet OAM 802.1ag em nível de domínio de ponte. Com isso, você pode definir um domínio de manutenção para cada nível padrão. Os nomes de MIPs são criados em default-level-number nível [edit protocols oam ethernet connectivity-fault-management maintenance-domain] de hierarquia. Use as bridge-domain opções instance , e virtual-switchmip-half-function MIP para especificar a configuração MIP.

Use o show oam ethernet connectivity-fault-management mip (bridge-domain | instance-name | interface-name) comando para exibir as configurações de MIP.

Para configurar o ponto intermediário de manutenção (MIP):

  1. Configure um domínio de ponte em um switch virtual definido pelo usuário especificando a instrução e o nome do switch virtual definido pelo virtual-switch usuário, em nível [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name default-x] de hierarquia.
    Nota:

    Um domínio de ponte só deve ser especificado pelo nome se estiver configurado incluindo a vlan-id instrução na virtual-switch instrução. Se um domínio de ponte estiver configurado com uma variedade de IDs VLAN, as IDs VLAN devem ser listadas explicitamente após o nome do domínio da ponte.

    Nota:

    Você também pode configurar o domínio da ponte para o switch virtual padrão incluindo a bridge-domain instrução no nível [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name] da hierarquia.

  2. Configure a instância de roteamento VPLS para o domínio de manutenção padrão.
  3. Configure a metade da função de ponto intermediário de manutenção (MIP) para dividir a fuctionalidade MIP em dois segmentos unidirecionais para melhorar a cobertura da rede, aumentando o número de MIPs monitorados. A metade da função MIP também responde a mensagens de loop-back e de rastreamento de enlace para identificar falhas.
    Nota:

    Sempre que um MIP está configurado e um domínio de ponte é mapeado para vários domínios de manutenção ou associações de manutenção, é essencial que o valor para todos os domínios de manutenção e associações de manutenção seja o mip-half-function mesmo.

Configurando pontos intermediários da associação de manutenção na série ACX

O Maintenance Intermediate Point (MIP) fornece capacidade de monitoramento de pontos intermediários para serviços como pontes de Camada 2, circuito de Camada 2 e VPN de Camada 2. Os roteadores ACX5048 e ACX5096 são de suporte a MIPs para o protocolo OAM Ethernet 802.1ag CFM. Use as opções MIP de domínio de ponte, interface e mip-half-function para especificar a configuração MIP.

Nota:

Os roteadores ACX5048 e ACX5096 não suportam a configuração de MIP nos serviços de VPLS.

Nota:

ACX5448 roteador não tem suporte para MIP.

Nota:

Sempre que um MIP está configurado e um domínio de ponte é mapeado para vários domínios de manutenção ou associações de manutenção, é essencial que o valor para todos os domínios de manutenção e associações de manutenção seja o mip-half-function mesmo.

Para exibir configurações de MIP, use o show oam ethernet connectivity-fault-management mip (bridge-domain | instance-name | interface-name) comando.

As seguintes configurações de MIP são suportadas nos roteadores ACX5048 e ACX5096:

  • MIP com domínio de ponte

  • MIP com conexão cruzada de circuito (CCC)

  • MIP com domínio de ponte quando o ponto final da associação de manutenção está configurado

  • MIP com CCC quando o ponto final da associação de manutenção está configurado

As seções a seguir descrevem a configuração de MIP:

Configurando o domínio da ponte do domínio da manutenção

Para configurar o domínio da ponte, inclua a vlans declaração em nível de [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name] hierarquia.

Nota:

As configurações de CLI de Camada 2 e os comandos show para roteadores ACX5048 e ACX5096 diferem em comparação com outros roteadores da Série ACX. Para obter mais informações, consulte o modo de próxima geração da Camada 2 para a Série ACX.

Configurando a metade da função MIP do domínio de manutenção

A metade da função MIP (MHF) divide a funcionalidade de MIP em dois segmentos unidirecionais, aumenta a visibilidade com configuração mínima e aumenta a cobertura da rede aumentando o número de pontos que podem ser monitorados. O MHF amplia a capacidade de monitoramento respondendo a mensagens de loopback e linktrace para ajudar a isolar falhas.

Sempre que um MIP está configurado e um domínio de ponte é mapeado para vários domínios de manutenção ou associações de manutenção, é essencial que o valor da metade da função MIP para todos os domínios de manutenção e associações de manutenção seja o mesmo. Para configurar a metade da função MIP, inclua a mip-half-function instrução em [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name] nível de hierarquia.

Configuração de pontos intermediários da associação de manutenção com domínio de ponte

Nos roteadores ACX5048 e ACX5096, você pode configurar o MIP com domínio de ponte. A seguir, uma amostra para configurar o MIP com domínio de ponte:

Configuração de pontos intermediários da Associação de Manutenção com Circuit Cross-Connect

Nos roteadores ACX5048 e ACX5096, você pode configurar o MIP com ccc (circuit cross-connect). A seguir, uma amostra para configurar o MIP com CCC:

Configuração de pontos intermediários da associação de manutenção com domínio da ponte quando o end point da associação de manutenção está configurado

Nos roteadores ACX5048 e ACX5096, você pode configurar o MIP com domínio de ponte quando um ponto final da associação de manutenção (MEP) estiver configurado. A seguir, uma amostra para configurar o MIP com domínio de ponte quando o MEP estiver configurado:

Configurando os pontos intermediários de manutenção com o circuito cross-connect quando o end point da associação de manutenção está configurado

Nos roteadores ACX5048 e ACX5096, você pode configurar o MIP com CCC (Circuit Cross-Connect, Conexão cruzada de circuito) quando um ponto final da associação de manutenção (MEP) estiver configurado. A seguir, uma amostra para configurar o MIP com CCC quando o MEP estiver configurado:

Criação de uma associação de manutenção

Para criar uma associação de manutenção, inclua maintenance-association ma-name a declaração em nível de [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name] hierarquia.

Nomes de associação de manutenção podem estar em um dos seguintes formatos:

  • Como uma string de caracteres ASCII simples

  • Como o identificador de VLAN da VLAN, você se associará principalmente à associação de manutenção

  • Como um identificador de dois octetos na faixa de 0 a 65.535

  • Nome no formato especificado pela RFC 2685

O formato de nome curto padrão é uma string de caracteres ASCII.

Para configurar o formato de nome curto da associação de manutenção, inclua a short-name-format (character-string | vlan | 2octet | rfc-2685-vpn-id) declaração em nível de [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name] hierarquia.

Visão geral dos parâmetros do protocolo de verificação de continuidade

O protocolo de verificação de continuidade é usado para detecção de falhas por pontos de manutenção (MEPs) em uma associação de manutenção. Periodicamente, o MEP envia mensagens de verificação de continuidade de multicast. Os pacotes de protocolo de verificação de continuidade usam o valor de 0x8902 e o endereço MAC de destino multicast 01:80:c2:00:00:32.

A lista a seguir descreve os parâmetros de protocolo de verificação de continuidade que você pode configurar:

  • interval— Frequência das mensagens de verificação de continuidade (CCM), ou seja, tempo entre a transmissão das mensagens CCM. Você pode especificar 10 minutos 10m (), 1 minuto 1m (), 10 segundos 10s (), 1 segundo 1s (), 100 milissegundos (), ou 100ms 10 milissegundos ( 10ms ). O valor padrão é de 1 minuto. Por exemplo, se você especificar o intervalo de 1 minuto, o MEP enviará as mensagens de verificação de continuidade a cada minuto para o MEP receptor.

    Nota:

    Para que o intervalo de mensagem de verificação de continuidade seja configurado para 10 milissegundos, o gerenciamento periódico de pacotes (PPM) é executado no Mecanismo de Roteamento e Mecanismo de Encaminhamento de Pacotes por padrão. Você só pode desativar o PPM no Mecanismo de Encaminhamento de Pacotes. Para desativar o PPM na Mecanismo de Encaminhamento de Pacotes, use a no-delegate-processing instrução no [edit routing-options ppm] nível da hierarquia.

    O intervalo de verificação de continuidade de 10 milissegundos não é suportado para sessões de CFM em uma interface comutado por rótulos (LSI).

  • hold-interval— Frequência na qual o banco de dados MEP pode ser descarregado, caso não ocorram atualizações. O recebimento de MEPs usa as mensagens de verificação de continuidade para criar um banco de dados MEP de todos os MEPs na associação de manutenção. A frequência é o número de minutos a esperar antes de liberar o banco de dados MEP caso não ocorram atualizações. O valor padrão é de 10 minutos.

    Nota:

    A descarga baseada em tempo de espera é aplicável apenas para MEPs remotos autoconfigurados e não para MEPs remotos configurados estaticamente.

    A lógica do intervalo de espera executa um temporizador de pesquisa por nível de sessão do CFM (não por nível de MEP remoto), onde a duração do tempo de tempo de pesquisa é igual ao tempo de espera configurado. Quando o tempo de pesquisa expira, ele elimina todas as entradas MEP remotas descobertas automaticamente que estão em estado de falha por um período de tempo igual ou maior do que o tempo de espera configurado. Se o MEP remoto completar a duração do tempo de espera no estado com falha, a descarga não ocorrerá até o próximo temporizador de pesquisa expirar. Portanto, a descarga de MEP remoto pode não acontecer exatamente no tempo de espera configurado.

  • loss-threshold— Número de mensagens de verificação de continuidade que podem ser perdidas antes que o roteador marque o MEP como down. O valor pode ser de 3 a 256 unidades de dados de protocolo (PDUs). O valor padrão é de 3 PDUs.

Configurando parâmetros de protocolo de verificação de continuidade para detecção de falhas

O protocolo de verificação de continuidade é usado para detecção de falhas por um ponto final de associação de manutenção (MEP) em uma associação de manutenção. Periodicamente, um MEP gera e responde a mensagens multicast de verificação de continuidade. Os pacotes de protocolo de verificação de continuidade usam o valor de 0x8902 e o endereço MAC de destino multicast 01:80:c2:00:00:32. Os MEPs receptores usam as mensagens de verificação de continuidade (CCMs) para criar um banco de dados MEP de todos os MEPs na associação de manutenção.

Para configurar parâmetros de protocolo de verificação de continuidade:

  1. Especifique o tempo de espera em minutos antes de liberar o banco de dados MEP, caso não ocorram atualizações, com um valor de 1 minuto a 30.240 minutos. O valor padrão é de 10 minutos.
    Nota:

    A descarga com base no temporizador de espera é aplicável apenas para MEPs remotos autoconfigurados e não para MEPs remotos configurados estaticamente.

  2. Especifique o tempo de espera (duração) entre as transmissões de CCMs. A duração pode ser um dos seguintes valores: 10 minutos (10m), 1 minuto (1m), 10 segundos (10s), 1 segundo (1s), 100 milissegundos (100ms) ou 10 milissegundos (10ms). O valor padrão é de 1 minuto.
  3. Especifique o número de mensagens de verificação de continuidade que podem ser perdidas antes que o roteador marque o MEP como down. O valor pode ser de 3 a 256 unidades de dados de protocolo (PDUs). O valor padrão é de 3 PDUs.

Configurando um MEP para gerar e responder a mensagens de protocolo CFM

Um ponto final da associação de manutenção (MEP) refere-se à fronteira de um domínio. Um MEP gera e responde a mensagens de protocolo de gerenciamento de falhas de conectividade (CFM). Você pode configurar vários MEPs para uma única combinação de ID de associação de manutenção e ID de domínio de manutenção para interfaces pertencentes a um serviço VPLS específico ou a um domínio de ponte. Você pode configurar vários MEPs down para uma única instância de nome de associação de domínio de manutenção e identificador de manutenção para monitorar serviços fornecidos por VPLS (Virtual Private LAN Service, serviço de LAN privada virtual), domínio de ponte, circuito cross-connect (CCC) ou domínios IPv4.

Para instâncias de roteamento de VPNs de camada 2 (comutamento local) e de roteamento de EVPN, você também pode configurar vários MEPs up para uma única combinação de ID de associação de manutenção e ID de domínio de manutenção em interfaces lógicas. A interface lógica pode ser configurada em diferentes dispositivos ou no mesmo dispositivo. Para dar suporte a vários MEPs em dois IFLs, os serviços de rede IP aprimorados precisam ser configurados para o chassi.

Você pode habilitar a descoberta automática de um MEP. Com a descoberta automática, um MEP pode aceitar mensagens de verificação de continuidade (CCMs) de todos os MEPs remotos da mesma associação de manutenção. Caso a descoberta automática não seja habilitada, os MEPs remotos precisam ser configurados. Se o MEP remoto não estiver configurado, os CCMs do MEP remoto serão tratados como erros.

A medição da continuidade é fornecida por um protocolo de verificação de continuidade existente. A continuidade de cada MEP remoto é medida conforme a porcentagem de tempo que o MEP remoto tinha operacionalmente a mais ao longo do tempo total de habilitação administrativa. Aqui, o tempo de atividade operacional é o tempo total durante o qual a adjacência CCM está ativa para um MEP remoto específico, e o tempo ativado administrativo é o tempo total durante o qual o MEP local está ativo. Você também pode reinicializar a medição de continuidade eliminando o tempo de atividade operacional medido no momento e o tempo de atividade administrativo habilitado.

Configurando um end point de associação de manutenção (MEP)

Para configurar um ponto final da associação de manutenção:

  1. Especifique uma ID para o MEP no edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name] [ . Você pode especificar qualquer valor de 1 a 8191.
  2. Ative a descoberta automática de ponto final de manutenção para que o MEP aceite mensagens de verificação de continuidade (CCMs) de todos os MEPs remotos da mesma associação de manutenção.
  3. Especifique a direção na qual os pacotes CCM são transmitidas para o MEP. Você pode especificar para cima ou para baixo. Se você especificar a direção como up, as CCMs são transmitidas de todas as interfaces lógicas que fazem parte da mesma instância de bridging ou VPLS, exceto pela interface configurada no MEP. Se você especificar a direção como down, as CCMs serão transmitidas apenas para fora da interface configurada no MEP.
    Nota:

    As portas no estado de bloqueio do Protocolo de Árvore de Abrangia (STP) não bloqueiam pacotes CFM destinados a um MEP baixo. Portas em um estado de bloqueio de STP sem o protocolo de verificação de continuidade configurado para bloquear pacotes CFM.

    Nota:

    A partir da versão 12.3 do Junos OS, para todas as interfaces configuradas em MPCs (Modular Port Concentrators) na Série MX 5G Plataformas de roteamento universal, você não precisa mais configurar a instrução para todos os circuitos De Camada 2 e Camada 2 nos quais você está executando no-control-word MEPs de CFM. Para todas as outras interfaces em roteadores da Série MX e em todos os outros roteadores e switches, você deve continuar a configurar a instrução no nível ou na hierarquia quando configurar no-control-word[edit routing-instances routing-instance-name protocols l2vpn][edit protocols l2circuit neighbor neighbor-id interface interface-name] MEPs de CFM. Caso contrário, os pacotes de CFM não são transmitidos e o show oam ethernet connectivity-fault-management mep-database comando não exibe nenhum MEPs remoto.

  4. Especifique a interface à qual o MEP está conectado. Pode ser uma interface física, uma interface lógica ou uma interface de tronco. Nos roteadores da Série MX, o MEP pode ser conectado a uma VLAN específica de uma interface de tronco.
  5. Especifique as IEEE de prioridade 802.1 usadas por mensagens de verificação de continuidade e rastreamento de enlace. Você pode especificar um valor de até 7 como prioridade.
  6. Especifique o defeito de menor prioridade que gere um alarme de falha sempre que o CFM detectar um defeito. Os valores possíveis incluem: todos os defeitos, err-xcon, mac-rem-err-xcon, sem defeitos, rem-err-xcon e xcon.
  7. Especifique a ID do MEP remoto no edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name mep mep-id] [ . Você pode especificar qualquer valor de 1 a 8191.

Configurando um end point de associação de manutenção remota (MEP)

Para configurar um ponto final da associação de manutenção remota:

  1. Configure o MEP remoto especificando a ID DE MEP no [ edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name mep mep-id] . Você pode especificar qualquer valor de 1 a 8191.
  2. Especifique o nome do perfil de ação a ser usado para o MEP remoto, incluindo a action-profile profile-name instrução no [ edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name mep mep-id remote-mep remote-mep-id] . O perfil deve ser definido em nível de hierarquia edit protocols oam ethernet connectivity-fault-management [ ]
  3. Configure o MEP remoto para detectar perda inicial de conectividade. Por padrão, o MEP não gera mensagens de defeito de perda de continuidade (LOC). Ao configurar a declaração, um defeito de perda de continuidade (LOC) é detectado se nenhuma mensagem de verificação de continuidade for recebida do MEP remoto em um período igual a 3,5 vezes o intervalo de verificação de continuidade configurado para a associação de detect-loc manutenção. Caso um defeito de LOC seja detectado, uma mensagem de erro de syslog é gerada.
    Nota:

    Quando você configura o gerenciamento de falhas de conectividade (CFM) junto com , qualquer configuração para derrubar a interface é executada caso a mensagem de verificação de continuidade detect-locaction-profile não seja recebida. No entanto, a execução não será realizada se você não tiver configurado e a mensagem de verificação action-profile de continuidade não for detect-loc recebida.

Configurando interfaces MEP para dar suporte a medições de atraso do quadro ethernet

A medição do atraso do quadro de Ethernet é uma ferramenta útil para fornecer estatísticas de desempenho ou oferecer suporte ou desafiar acordos de nível de serviço (SLAs). Por padrão, a medição do atraso do quadro de Ethernet usa o software para cálculos de tempo e atraso. Opcionalmente, você pode usar o tempo de hardware para ajudar nesse processo e aumentar a precisão dos resultados da medição do atraso. Essa assistência está disponível no caminho da recepção.

Antes de realizar medições de atraso do quadro Ethernet nos roteadores da série MX, você deve ter feito o seguinte:

  • Ethernet OAM e CFM configurados corretamente

  • Prepare a medição entre dois roteadores da Série MX configurados com concompatibilidade

  • Habilitamos o daemon de gerenciamento de pacotes distribuídos (ppmd)

  • Evitada a tentativa de realizar a medição do atraso do quadro Ethernet em interfaces ethernet ou pseudowire agregadas, que não são suportadas

  • Certifique-se de que o timestamping assistido por hardware seja suportado caso esse recurso seja configurado

Ao final dessa configuração, você cria dois roteadores da Série MX que podem realizar e exibir medições de atraso do quadro Ethernet em interfaces Ethernet usando o timestamping opcional de tempo de hardware. Por padrão, a medição do atraso do quadro de Ethernet usa o software para cálculos de tempo e atraso. Opcionalmente, você pode usar o tempo de hardware para ajudar nesse processo e aumentar a precisão dos resultados da medição do atraso. Essa assistência está disponível no caminho da recepção.

Para configurar o timestamping assistido por hardware:

  1. Para habilitar assistência de hardware de medição de atraso do quadro Ethernet no caminho da recepção, inclua a hardware-assisted-timestamping declaração no nível da [edit protocols oam ethernet connectivity-fault-management performance-monitoring] hierarquia:
  2. A medição do atraso do quadro de Ethernet requer que o PPMD distribuído seja ativado. Antes de coletar estatísticas para a medição do atraso do quadro Ethernet, você deve ter certeza de que o PPMD está configurado corretamente. Sem o PPMD distribuído, os resultados da medição do atraso não são válidos.

    Para realizar a medição do atraso do quadro Ethernet, certifique-se de que a seguinte instrução de configuração não está presente:

Configuração de proteção de serviço para VPWS em MPLS usando a interface MEP

Você pode habilitar a proteção do serviço para um serviço virtual de cabo privado (VPWS) por MPLS, especificando um caminho de trabalho ou um caminho de proteção no MEP. A proteção do serviço fornece proteção de conexão de ponta a ponta do caminho de trabalho no caso de uma falha.

Para configurar a proteção do serviço, você deve criar dois caminhos de transporte separados: um caminho de trabalho e um caminho de proteção. Você pode especificar o caminho de trabalho e proteger o caminho criando duas associações de manutenção. Para associar a associação de manutenção com um caminho, você deve configurar a declaração do MEP na associação de manutenção e especificar o interface caminho como funcionando ou protegendo.

Nota:

Caso o caminho não seja especificado, a sessão monitorará o caminho ativo.

Tabela 1 descreve as opções de proteção do serviço disponíveis.

Tabela 1: Opções de proteção do serviço

Opção

Descrição

working

Especifica o caminho de trabalho.

protect

Especifica o caminho de proteção.

Nesta configuração, capacitamos a proteção do serviço para o serviço VPWS. A sessão CCM está configurada para o caminho de trabalho e faz referência à sessão CCM configurada para o caminho de proteção usando a protect-maintenance-association instrução. O nome do caminho de transporte protegido para a associação de manutenção está configurado e associado à associação de manutenção do caminho de trabalho.

Para configurar a proteção do serviço para VPWS por MPLS:

  1. No modo de configuração, crie um domínio de manutenção especificando o nome e o formato do nome no nível edit protocols oam ethernet connectivity-fault-management [ ] da hierarquia.
    Nota:

    Se você configurar o comprimento do nome do domínio da manutenção com mais de 45 octetos, a seguinte mensagem de erro será exibida: error: configuration check-out failed.

  2. Especifique o nível do domínio da manutenção especificando o valor no nível edit protocols oam ethernet connectivity-fault-management da hierarquia [ ]
  3. Crie uma associação de manutenção para o caminho de trabalho especificando o nome e o formato de nome curto no nível [ edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name ] da hierarquia.
  4. Especifique o nome da associação de manutenção usado para proteção de conexão e o nome do perfil de comutamento de proteção automática (perfil de aps) no nível edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name [ ] da hierarquia.
  5. Especifique o tempo de espera entre as transmissões de mensagens de verificação de continuidade no nível edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name continuity-check [ ] da hierarquia. A duração pode ser um dos seguintes valores: 10 minutos (10m), 1 minuto (1m), 10 segundos (10s), 1 segundo (1s), 100 milissegundos (100ms) ou 10 milissegundos (10ms). O valor padrão é de 1 minuto.
  6. Especifique uma ID para o MEP no edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name] [ . Você pode especificar qualquer valor de 1 a 8191.
  7. Ative a descoberta automática de ponto final de manutenção para que o MEP aceite mensagens de verificação de continuidade (CCMs) de todos os MEPs remotos da mesma associação de manutenção.
  8. Especifique a direção na qual os pacotes CCM são transmitidas para o MEP. Você pode especificar para cima ou para baixo. Se você especificar a direção como up, as CCMs são transmitidas de todas as interfaces lógicas que fazem parte da mesma instância de bridging ou VPLS, exceto pela interface configurada no MEP. Se você especificar a direção como down, as CCMs serão transmitidas apenas para fora da interface configurada no MEP.
    Nota:

    As portas no estado de bloqueio do Protocolo de Árvore de Abrangia (STP) não bloqueiam pacotes CFM destinados a um MEP baixo. Portas em um estado de bloqueio de STP sem o protocolo de verificação de continuidade configurado para bloquear pacotes CFM.

    Nota:

    A partir da versão 12.3 do Junos OS, para todas as interfaces configuradas em MPCs (Modular Port Concentrators) na Série MX 5G Plataformas de roteamento universal, você não precisa mais configurar a instrução para todos os circuitos De Camada 2 e Camada 2 nos quais você está executando no-control-word MEPs de CFM. Para todas as outras interfaces em roteadores da Série MX e em todos os outros roteadores e switches, você deve continuar a configurar a instrução no nível ou na hierarquia quando configurar no-control-word[edit routing-instances routing-instance-name protocols l2vpn][edit protocols l2circuit neighbor neighbor-id interface interface-name] MEPs de CFM. Caso contrário, os pacotes de CFM não são transmitidos e o show oam ethernet connectivity-fault-management mep-database comando não exibe nenhum MEPs remoto.

  9. Especifique a interface à qual o MEP está conectado. Pode ser uma interface física, uma interface lógica ou uma interface de tronco. Nos roteadores da Série MX, o MEP pode ser conectado a uma VLAN específica de uma interface de tronco. Além disso, especifique o caminho de transporte como funcionando.
  10. Crie uma associação de manutenção para o caminho de proteção especificando o nome e o formato de nome curto no nível [ edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name ] da hierarquia.
  11. Especifique o tempo de espera entre as transmissões de mensagens de verificação de continuidade no nível edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name continuity-check [ ] da hierarquia. A duração pode ser um dos seguintes valores: 10 minutos (10m), 1 minuto (1m), 10 segundos (10s), 1 segundo (1s), 100 milissegundos (100ms) ou 10 milissegundos (10ms). O valor padrão é de 1 minuto.
  12. Especifique uma ID para o MEP no edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name maintenance-association ma-name] [ . Você pode especificar qualquer valor de 1 a 8191.
  13. Ative a descoberta automática de ponto final de manutenção para que o MEP aceite mensagens de verificação de continuidade (CCMs) de todos os MEPs remotos da mesma associação de manutenção.
  14. Especifique a direção na qual os pacotes CCM são transmitidas para o MEP. Você pode especificar para cima ou para baixo. Se você especificar a direção como up, as CCMs são transmitidas de todas as interfaces lógicas que fazem parte da mesma instância de bridging ou VPLS, exceto pela interface configurada no MEP. Se você especificar a direção como down, as CCMs serão transmitidas apenas para fora da interface configurada no MEP.
    Nota:

    As portas no estado de bloqueio do Protocolo de Árvore de Abrangia (STP) não bloqueiam pacotes CFM destinados a um MEP baixo. Portas em um estado de bloqueio de STP sem o protocolo de verificação de continuidade configurado para bloquear pacotes CFM.

    Nota:

    A partir da versão 12.3 do Junos OS, para todas as interfaces configuradas em MPCs (Modular Port Concentrators) na Série MX 5G Plataformas de roteamento universal, você não precisa mais configurar a instrução para todos os circuitos De Camada 2 e Camada 2 nos quais você está executando no-control-word MEPs de CFM. Para todas as outras interfaces em roteadores da Série MX e em todos os outros roteadores e switches, você deve continuar a configurar a instrução no nível ou na hierarquia quando configurar no-control-word[edit routing-instances routing-instance-name protocols l2vpn][edit protocols l2circuit neighbor neighbor-id interface interface-name] MEPs de CFM. Caso contrário, os pacotes de CFM não são transmitidos e o show oam ethernet connectivity-fault-management mep-database comando não exibe nenhum MEPs remoto.

  15. Especifique a interface à qual o MEP está conectado. Pode ser uma interface física, uma interface lógica ou uma interface de tronco. Nos roteadores da Série MX, o MEP pode ser conectado a uma VLAN específica de uma interface de tronco. Além disso, especifique o caminho de transporte como funcionando.

Configurando o protocolo linktrace no CFM

O protocolo de linktrace é usado para detecção de caminho entre um par de pontos de manutenção. As mensagens do Linktrace são acionadas por um administrador que usa o comando para verificar o caminho entre um par de traceroute MEPs na mesma associação de manutenção. Mensagens do Linktrace também podem ser usadas para verificar o caminho entre um MEP e um MIP no mesmo domínio de manutenção. O protocolo linktrace permite configurar o tempo de espera por uma resposta. Se nenhuma resposta for recebida para uma mensagem de solicitação de linktrace, as entradas de solicitação e resposta serão eliminadas após o intervalo expirar. Você também pode configurar o número de entradas de resposta do linktrace a serem armazenadas para a solicitação correspondente de linktrace.

A operação da IEEE 802.1ag linktrace e mensagens de resposta é semelhante à operação dos comandos de Camada traceroute 3. Para obter mais informações sobre o comando, consulte a Biblioteca de Administração do tracerouteJunos OS para Dispositivos de Roteamento.

Para configurar o protocolo de linktrace:

  1. Configure o tempo para esperar por uma resposta do linktrace no nível edit protocols oam ethernet connectivity-fault-management [] da hierarquia. Você pode especificar o valor em minutos ou segundos. O valor padrão é de 10 minutos.
  2. Configure o número de entradas de resposta do linktrace a serem armazenadas por solicitação de linktrace. Você pode especificar um valor de 1 a 500. O valor padrão é de 100.

Configurando o limite de taxa de mensagens OAM Ethernet

A M320 com roteadores Enhanced III FPC, M120, M7i, M10 com CFEB e série MX suportam limitação de taxa de mensagens OAM Ethernet. Dependendo da configuração de gerenciamento de falhas de conectividade (CFM), os pacotes de CFM são descartados, enviados à CPU para processamento ou inundados para outras interfaces de ponte. Esse recurso permite que o roteador intercepte pacotes de CFM recebidos para prevenção de DoS ataques.

Você pode aplicar o limite de taxa de mensagens OAM Ethernet em dois níveis de policiamento CFM, da seguinte forma:

  • O policiamento CFM em nível global — usa um policial em nível global para policiar o tráfego de CFM que pertence a todas as sessões.

  • O policiamento CFM em nível de sessão — usa um policial criado para policiar o tráfego de CFM que pertence a uma sessão.

Para configurar o policiamento CFM em nível global, inclua a policer declaração e suas opções em nível de [edit protocols oam ethernet connectivity-fault-management] hierarquia.

Para configurar o policiamento CFM em nível de sessão, inclua a policer declaração em nível de [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name level number maintenance-association ma-name] hierarquia.

O exemplo a seguir mostra um cfm policer usado para limitar a taxa de CFM:

Caso 1: CfM Policing de nível global

Este exemplo mostra um policial de nível global, no nível do CFM, para o CFM que limita a taxa. A declaração em nível de hierarquia global especifica o policial a ser usado para policiar todos os pacotes de verificação de continuidade do tráfego CFM que pertencem a continuity-check cfm-policer[edit protocols oam ethernet connectivity-fault-management policer] todas as sessões. A declaração em nível de hierarquia especifica o policial a ser usado para policiar todos os pacotes de verificação de não continuidade do tráfego CFM que pertencem a todas other cfm-policer1[edit protocols oam ethernet connectivity-fault-management policer] as sessões. A all cfm-policer2 declaração especifica para a políciar todos os pacotes de CFM com o cfm-policer2 especificado. Se a all policer-name opção for usada, o usuário não pode especificar as opções continuity-checkother anteriores.

Caso 2: Policiamento CFM em nível de sessão

Este exemplo mostra um cfm em nível de sessão usado para limitar a taxa de CFM. A declaração em nível de hierarquia de sessão especifica o policial a ser usado para policiar apenas pacotes de verificação de continuidade do tráfego CFM que pertencem à policer[edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] sessão especificada. A instrução em nível de hierarquia especifica o policial a ser usado para policiar todos os pacotes de verificação de não continuidade do tráfego CFM que pertencem apenas other cfm-policer1[edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] a esta sessão. A all cfm-policer2 declaração especifica para a políciar todos os pacotes de CFM com o cfm-policer2 especificado. Se a all policer-name opção for usada, o usuário não pode especificar as opções continuity-checkother anteriores.

No caso do controle global de CFM, o mesmo policial é compartilhado em várias sessões de CFM. No policiamento CFM por sessão, um policial separado deve ser criado para limitar a taxa de pacotes específicos dessa sessão.

Nota:

A configuração de policer no nível de serviço para qualquer duas sessões de CFM na mesma interface em níveis diferentes deve atender às seguintes restrições se a direção das sessões for a mesma:

  • Se uma sessão estiver configurada, a policer all outra não poderá ter uma ou policer allpolicer other configuração.

  • Se uma sessão estiver configurada, a policer other outra não poderá ter uma ou policer allpolicer other configuração.

Um erro de commit ocorrerá se essa configuração for comprometida.

Nota:

Os agentes de polícia com PBB e MIPs não são suportados.

Configuração da interface de gerenciamento local ethernet

Visão geral da interface de gerenciamento local ethernet

As interfaces Gigabit Ethernet ( ), Ethernet de 10 Gigabits e Ethernet Agregada ( ) são de suporte à Interface de Gerenciamento Local Ethernet gexeae (E-LMI).

Nota:

Nos roteadores da Série MX, o E-LMI é suportado em interfaces Gigabit Ethernet ( ), Ethernet de ge 10 Gigabits (), e Ethernet agregada ( ) configuradas em roteadores da Série MX apenas com xeae DPC.

A especificação E-LMI está disponível no Fórum de Metro Ethernet. Procedimentos e protocolos E-LMI são usados para permitir a configuração automática da borda do cliente (CE) para dar suporte a serviços Metro Ethernet. O protocolo E-LMI também fornece informações de status da interface do usuário para a rede (UNI) e da conexão virtual Ethernet (EVC) ao CE. As informações da UNI e do EVC permitem a configuração automática CE operação baseada na configuração Metro Ethernet.

O protocolo E-LMI opera entre o CE e o dispositivo de borda do provedor (PE). Ele é executado apenas no enlace PE-CE e notifica os CE de status de conectividade e os parâmetros de configuração dos serviços Ethernet disponíveis na porta CE de serviços. O escopo do protocolo E-LMI é mostrado em Figura 1 .

Figura 1: Escopo do protocolo E-LMIEscopo do protocolo E-LMI

A implementação de E-LMI em roteadores ACX e série MX inclui apenas o lado PE do protocolo E-LMI.

O E-LMI interopera com um protocolo OAM, como o Connectivity Fault Management (CFM), executado na rede do provedor para coletar o status do OAM. O CFM é executado no nível de manutenção do provedor (UNI-N a UNI-N com up MEPs na UNI). O E-LMI depende do CFM para status completo de EVCs em domínios de CFM (domínio de SVLAN ou VPLS).

O protocolo E-LMI repassa as seguintes informações:

  • Notificação ao CE da adição/exclusão de um EVC (ativo, não ativo ou parcialmente ativo)

  • Notificação ao CE do estado de disponibilidade de um EVC configurado

  • Comunicação dos atributos UNI e EVC ao CE:

    • Atributos UNI:

      • Identificador UNI (nome configurado pelo usuário para UNI)

      • CE-VLAN tipo de mapa ID/EVC (com 1 a 1, multiplexação de serviços com coquelamento ou sem coalinamento)

      • O perfil da largura de banda não é suportado (incluindo os seguintes recursos):

        • CM (modo de junção)

        • CF (bandeira de cores)

        • CIR (taxa de informações comprometida)

        • CBR (tamanho comprometido de ruptura)

        • EIR (taxa de excesso de informações)

        • EBS (tamanho de ruptura em excesso)

    • Atributos de EVC:

      • ID de referência de EVC

      • Tipo de status EVC (ativo, não ativo ou parcialmente ativo)

      • Tipo EVC (ponto a ponto ou multipoint para multipoint)

      • ID EVC (nome configurado pelo usuário para EVC)

      • Perfil da largura de banda (sem suporte)

    • mapa CE-VLAN ID/EVC

O E-LMI nos roteadores da série MX oferece suporte aos seguintes tipos de EVC:

  • Q-in-Q SVLAN (ponto a ponto ou multipoint-para-multipoint)— Requer uma sessão de CFM de ponta a ponta entre UNI-Ns para monitorar o status do EVS.

  • VPLS (BGP ou LDP) (ponto a ponto ou multipoint-para-multipoint)— Status de pseudowire VPLS ou sessões de CFM de ponta a ponta entre UNI-Ns podem ser usadas para monitorar o status do EVC.

  • L2 circuit/L2VPN (ponto a ponto)— O status do pseudowire VPLS ou sessões de CFM de ponta a ponta entre UNI-Ns podem ser usadas para monitorar o status do EVC.

    Nota:

    l2-circuit e l2vpn não são suportados.

O protocolo E-LMI nos roteadores da Série ACX aceita os tipos EVC de Circuito de Camada 2 e VPN de Camada 2 e permite o encaminhamento de perda de enlace para serviços pseudowire (circuito de Camada 2 e VPN de Camada 2) da seguinte forma:

  • Intertrabalhando entre o protocolo de gerenciamento de falhas de conectividade (CFM) e o protocolo E-LMI para circuito de Camada 2 e VPN de Camada 2.

    • Sessão de CFM de ponta a ponta entre as UNIs para monitorar o status do EVC.

    • No caso da redundância de pseudowire, o CFM pode ser usado para monitorar sessões ativas e de backup de pseudofios. O status EVC é declarado como CE dispositivos somente quando as sessões de pseudofios ativas e de backup são inativas.

  • Intertrabalhando entre indicação de defeito remoto (RDI) e E-LMI para circuito de Camada 2 e VPN de Camada 2.

    • Se um ponto final da associação de manutenção (MEP) receber um bit RDI definido em um quadro de mensagem de verificação de continuidade (CCM), e se a detecção de falha de RDI estiver ativada na configuração de EVC em , o pseudowire será declarado como um CE roteadores por [edit protocols oam ethernet evcs evc-id evc-protocol cfm management-domain name management-association name faults rdi] E-LMI.

  • Se uma sessão de CFM de ponta a ponta não existir entre as UNIs, o pseudowire (circuito de Camada 2 ou VPN de Camada 2) em estado cima e embaixo aciona uma mensagem de mudança de estado EVC assíncrona para CE roteadores por meio do E-LMI.

Nota:

Os roteadores da Série ACX não suportam E-LMI para serviços de Camada 2 (pontes).

Configurando a interface de gerenciamento local ethernet

Para configurar o E-LMI, execute as seguintes etapas:

Configuração de um protocolo OAM (CFM)

Para obter informações sobre a configuração do protocolo OAM (CFM), consulte IEEE Visão geral do gerenciamento de falhas de conectividade do OAM 802.1ag.

Atribuição do protocolo OAM a um EVC

Para configurar um EVC, você deve especificar um nome para o EVC usando a evcsevc-id instrução no nível [edit protocols oam ethernet] da hierarquia. Você pode definir o protocolo EVC para monitorar estatísticas de EVC para ou usar a instrução e suas cfm opções em nível de vplsevc-protocol[edit protocols oam ethernet evcs] hierarquia.

Você pode definir o número de UNIs remotas no EVC usando a remote-uni-count number instrução no [edit protocols oam ethernet evcs evcs-protocol] nível da hierarquia. Os remote-uni-count padrões são 1. Configurar um valor maior que 1 torna o multipoint para multipoint de EVC. Se você inserir um valor maior do que o número real de endpoints, o status EVC será exibido como parcialmente ativo, mesmo que todos os endpoints sejam ativados. Se você inserir um número inferior ao número real de endpoints, o status será exibido como ativo, mesmo que todos os remote-uni-count endpoints não sejam ativados.

Você pode configurar um EVC incluindo a evcs instrução em [edit protocols oam ethernet] nível de hierarquia:

Ativação do E-LMI em uma interface e CE IDs VLAN para um EVC

Para configurar o E-LMI, inclua a lmi instrução em nível [edit protocols oam ethernet] de hierarquia:

Você pode definir o contador de status para contar erros consecutivos usando status-counter count a instrução no [edit protocols oam ethernet lmi] nível da hierarquia. O contador de status é usado para determinar se o E-LMI está operacional ou não. O valor padrão é 4.

Você pode definir a polling-verification-timer value declaração em nível de [edit protocols oam ethernet lmi] hierarquia. O valor padrão é de 15 segundos.

Você pode habilitar uma interface e definir suas opções de uso com E-LMI usando interface name a instrução em nível [edit protocols oam ethernet lmi] de hierarquia. Somente interfaces e gexeae interfaces são suportadas. Você pode usar a opção de interface uni-id para especificar um nome para o UNI. Se uni-id não estiver configurada, ela será padrão para a variável de interface name nome de .

Você pode especificar o tipo de mapa CE-VLAN ID/EVC usando a opção evc-map-type type de interface. As opções all-to-one-bundlingbundling são, service-multiplexing ou. Multiplexação de serviços é sem coaqueamento. O tipo padrão é all-to-one-bundling .

Para especificar o EVC que uma interface usa, use a evc evc-id instrução em [edit protocols oam ethernet lmi interface name] nível de hierarquia. Você pode especificar uma interface como a interface EVC padrão usando default-evc a instrução no [edit protocols oam ethernet lmi interface name evc evc-id] nível da hierarquia. Todos os VIDs que não são mapeados para quaisquer outros EVCs são mapeados para este EVC. Somente um EVC pode ser configurado como padrão.

Você pode mapear uma lista de VLANs para um EVC usando a vlan-list vlan-id-list instrução em [edit protocols oam ethernet lmi interface name evc evc-id] nível de hierarquia.

Configuração E-LMI por exemplo

Topologia de exemplo

Figura 2 ilustra a configuração de E-LMI para uma EVC point-to-point (SVLAN) monitorada pelo CFM. Neste exemplo, as VLANs de 1 a 2048 são mapeadas evc1 para (SVLAN 100) e de 2049 a 4096 são mapeadas evc2 para (SVLAN 200). Duas sessões de CFM são criadas para monitorar esses EVCs.

Figura 2: Configuração E-LMI para um EVC point-to-point (SVLAN) monitorado pelo CFMConfiguração E-LMI para um EVC point-to-point (SVLAN) monitorado pelo CFM

Configuração do PE1

Configuração do PE2

Configurando duas UNIs compartilhando o mesmo EVC

Configurando um perfil de ação de CFM para especificar ações de CFM para eventos de CFM

Você pode criar um perfil de ação de gerenciamento de falhas de conectividade (CFM) para definir flags e limites de evento a serem monitorados. Você também pode especificar a ação a ser realizada quando algum dos eventos configurados ocorrer. Quando os eventos de CFM ocorrem, o roteador realiza a ação correspondente com base na sua especificação. Você pode configurar um ou mais eventos no perfil de ação. Como alternativa, você pode configurar um perfil de ação e especificar ações padrão quando a conectividade com um endpoint da associação de manutenção remota (MEP) falha.

Nota:

No momento, não é possível configurar várias ações. Somente uma ação pode ser configurada. Essa limitação afeta as declarações actionclear-action e as declarações.

Para configurar o perfil de ação do CFM:

  1. No modo de configuração, no nível [ ] da hierarquia, especifique o nome do perfil de ação edit protocols oam ethernet connectivity-fault-management e o evento(s) CFM(s). Você pode configurar mais de um evento no perfil de ação. Os eventos possíveis incluem: interface-status-tlv, porta-status-tlv, perda de adjacency, RDI.
  2. Especifique a ação a ser realizada pelo roteador quando o evento ocorrer. A ação é acionada quando ocorre o evento. Caso tenha configurado mais de um evento no perfil de ação, não é necessário que todos os eventos ocorram para acionar a ação.
  3. Especifique a ação padrão a ser tomada pelo roteador quando a conectividade com um MEP remoto falhar. Se nenhuma ação for configurada, nenhuma ação será tomada.
    Nota:

    Não é recomendável associar um perfil de ação à ação em uma sessão MEP CFM em cima de uma interface de conexão cruzada (CCC) de circuito (l2circuit/l2vpn) e pode resultar em uma situação de interface-down bloqueio.

Perfil de ação do CFM para derrubar um grupo de interfaces lógicas Visão geral

Com as redes em expansão, existe um requisito de monitorar um grande número de serviços usando o CFM. Para monitorar cada serviço, é necessário uma sessão por interface lógica de serviço. Se os serviços são grandes em número, esse método não será dimensionado, pois o número de sessões é limitado. Em vez de uma sessão de CFM por serviço, uma única sessão de CFM pode monitorar vários serviços.

Além disso, existem cenários nos quais o dispositivo de interface do usuário para a rede (UNI) precisa ser derrubado com base em sessões na interface lógica da interface rede-para-rede (NNI). Aqui, a interface lógica da NNI refere-se à interface de núcleo e à interface física UNI refere-se a interface de acesso que hospeda várias interfaces lógicas de serviço. Com base no monitoramento da interface principal, você pode derrubar interfaces lógicas de serviço associadas à interface de acesso.

Figura 3 ilustra uma topologia em que vários serviços destinados a roteadores de borda do cliente (CE) compartilham uma única porta em um roteador de borda do provedor (PE). Cada serviço usa uma interface lógica. Um conjunto de serviços ou interfaces lógicas (coloridas em amarelo) estão destinados a um roteador CE e um conjunto de serviços ou interfaces lógicas coloridas em vermelho estão destinados a outro roteador CE. Para monitorar cada serviço, você precisa de sessões de end point (MEP) dedicadas para cada serviço. Você pode derrubar o serviço ao derrubar a interface lógica do serviço sempre que a sessão for final. Entretanto, essa abordagem não é escalável se temos um grande número de serviços. Monitorar a sessão de CFM na interface física também não é viável, porque vários roteadores CE podem ser conectados e os serviços a outros CE roteador podem ser interrompidos. Para resolver esse problema de monitoramento de vários serviços com uma única sessão, você pode criar um perfil de ação CCM para derrubar um grupo de interfaces lógicas usando uma sessão de CFM configurada em uma interface lógica única.

Figura 3: Topologia de vários serviços VLAN que compartilham uma única porta no roteador PE destinada a vários CE roteadores Topologia de vários serviços VLAN que compartilham uma única porta no roteador PE destinada a vários CE roteadores

Você pode configurar os perfis de ação CCM para os seguintes cenários:

  • Para derrubar um grupo de interfaces lógicas com a mesma porta-pai quando a sessão de monitoramento CCM está em execução em uma da interface lógica, mas em uma porta de pai diferente.

  • Para derrubar um grupo de interfaces lógicas quando a sessão de monitoramento CCM estiver em execução em uma das interfaces lógicas, todas pertencentes à mesma porta-pai.

  • Para derrubar a porta, quando a sessão de monitoramento CCM estiver em execução em uma das interfaces lógicas de uma porta-pai diferente.

Benefícios da criação do perfil de ação do CFM para derrubar um grupo de interfaces lógicas

  • Reduz os requisitos de recursos em redes dimensionadas onde vários serviços precisam ser monitorados.

  • Evita a necessidade de criar sessões de MEP individuais para cada serviço em uma topologia que inclua vários serviços a serem monitorados, o que aumenta o desempenho e a escalabilidade da rede.

Configurando um perfil de ação de CFM para derrubar um grupo de interfaces lógicas

Para monitorar vários serviços ou IFLs usando sessão de CFM configurada em uma única interface lógica, você pode criar um perfil de ação CCM para derrubar um grupo de interfaces lógicas. Você precisa definir uma ação para derrubar o grupo de interface no perfil de ação. Em seguida, você definirá o nome do dispositivo de interface e o número de interfaces lógicas que devem ser derrubadas. Uma interface lógica é representada por uma combinação interface-device-nameunit-list de. As etapas a seguir explicam o procedimento para derrubar um grupo de interfaces lógicas quando interface-device-name o e/ou unit-list são especificados.

  1. No modo de configuração, no nível [ ] da hierarquia, especifique o nome do perfil de ação edit protocols oam ethernet connectivity-fault-management e o evento(s) CFM(s). Você pode configurar mais de um evento no perfil de ação.

    Por exemplo,

    Nota:

    A ação não terá suporte para eventos que não sejam perda de interface-group-down adjabilidade e RDI. Quaisquer outros eventos configurados resulta em um erro de commit.

  2. No modo de configuração, em nível edit protocols oam ethernet connectivity-fault-management action-profile profile-name [ ] de hierarquia, defina a ação para derrubar o grupo de interface.
    Nota:

    A ação interface-group-down não será suportada com outras ações relacionadas à interface. Qualquer outra ação configurada resulta em erro de commit.

  3. No nível da hierarquia [ edit protocols oam ethernet connectivity-fault-management ], defina o domínio da manutenção. Especifique os parâmetros de associação de manutenção.

    Por exemplo,

  4. No edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name endpoint da associação de manutenção e os parâmetros associados.

    Por exemplo,

  5. Se o perfil de ação tiver a ação configurada, é obrigatório interface-group-down configurar interface-group o nível rmep. No modo de configuração na instrução include to [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name mep mep-id remote-mep mep-id action-profile profile-name down the interface group marked with the action profile as interface-groupinterface-group-down .

    Por exemplo,

    Nota:

    Caso a interface-group configuração não seja incluída na configuração RMEP. A configuração resulta em erro de commit.

  6. Uma interface lógica é representada por uma combinação interface-device-nameunit-list de. Configure o nome da interface do dispositivo e o número de interfaces lógicas no [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name mep mep-id remote-mep mep-id action-profile profile-name interface-group .

    Por exemplo,

    Neste exemplo de configuração, a interface ge-0/0/0.0 é derrubada.

    Nota:
    • Pelo menos um dos interface-group parâmetros ou interface-device-name deve ser unit-list configurado. Caso o nome do dispositivo de interface não seja configurado, a interface MEP é considerada como o nome do dispositivo e a interface lógica desse dispositivo é derrubada.

    • Se o unit-list parâmetro exceder o limite recomendado, ocorrerá um erro de commit.

    • Caso o nome do dispositivo de interface não seja especificado no, os números de interface lógicos mencionados na interface física são interface-groupunit-list derrubados.

    • Caso a lista de unidades não seja especificada na , IFLs são interface-group trazidas para a interface configurada.

  7. Verificar a configuração usando show protocols oam o comando.

Ativação do modo de gerenciamento de falhas de conectividade aprimorada

Você pode habilitar o modo de gerenciamento de falhas de conectividade aprimorada (CFM) para permitir a implantação eficaz do OAM Ethernet em redes de dimensionamento. Ao ativar o modo CFM aprimorado, o Junos OS tem suporte para 32.000 pontos de final da associação de manutenção (MEPs) e pontos intermediários de manutenção (MIPs) cada um por chassi para domínios de bridge, VPLS, L2VPN e CCC. Nas versões anteriores, o Junos OS tem suporte para 8.000 MEPs e 8.000 MIPS por chassi. Se você não habilitar CFM aprimorado, o Junos OS continuará a dar suporte ao número existente de MIPs e MEPs por chassi.

Nota:

Para dar suporte ao modo CFM aprimorado, configure o modo de serviços de rede no roteador como enhanced-ip . Caso o modo de serviços de rede não seja, e você tiver ativado o CFM aprimorado, a seguinte mensagem de aviso enhanced-ip será exibida:[edit protocols oam ethernet] 'connectivity-fault-management' enhanced ip is not effective please configure enhanced ip and give router reboot

Para habilitar o modo CFM aprimorado, execute as seguintes etapas:

  1. No modo de configuração, vá para o nível [edit protocols oam ethernet connectivity-fault-management] da hierarquia.
  2. Ative a implantação eficaz de Ethernet OAM capacitando o modo CFM aprimorado.
  3. Compromete a mudança de modo. É exibido uma mensagem de aviso solicitando que você reinicie o CFM. Caso você não reinicie o CFM, o CFM é reinicializado automaticamente pelo Junos OS.
  4. Para verificar se o modo CFM aprimorado está configurado, use o show oam ethernet connectivity-fault-management state comando.

Configuração de M120 e roteadores da série MX para pacotes encapsulados CCC

IEEE 802.1ag Suporte ao CFM OAM para visão geral de pacotes encapsulados CCC

A rede privada virtual de Camada 2 (L2VPN) é um tipo de serviço de rede privada virtual usado para transportar o tráfego privado de Camada 2 do cliente (por exemplo, Ethernet, ATM ou Relé de quadro) sobre a infraestrutura compartilhada de IP/MPLS do provedor de serviços. O roteador de borda do provedor de serviços (PE) precisa ter uma interface com o encapsulamento de conexão cruzada (CCC) do circuito para alternar o tráfego da borda do cliente (CE) para a rede pública.

O CFM (IEEE 802.1ag Ethernet Connectivity Fault Management, Gerenciamento de falhas de conectividade ethernet 802.1ag) é um padrão OAM usado para realizar detecção, isolamento e verificação de falhas em LANs de ponte virtual. os roteadores M120 e série MX fornecem suporte a CFM para interfaces bridge/VPLS/roteados e oferecem suporte a OAM Ethernet 802.1ag para pacotes encapsulados CCC.

Recursos de CFM suportados em circuitos VPN de Camada 2

Os recursos de CFM suportados em circuitos L2VPN são os seguinte:

  • Criação de MEPs para cima/para baixo em qualquer nível nas CE lógicas voltadas para a rede.

  • Criação de MIPs em qualquer nível nas CE lógicas voltadas para a segurança.

  • Suporte para verificação de continuidade, loopback e protocolo linkrace.

  • Suporte ao protocolo de medição do atraso ethernet Y1731.

  • Suporte para perfis de ação para derrubar CE interfaces lógicas voltadas para CE quando for detectada perda de conectividade.

Figura 4: Topologia de VPN de Camada 2Topologia de VPN de Camada 2

Para monitorar o circuito L2VPN, um CFM up MEP (Nível 6 in) pode ser configurado nas interfaces lógicas de CE de roteadores de borda do provedor PE1 e Figura 4 PE2. Para monitorar o circuito de CE-PE, um MEP com CFM em baixo pode ser configurado nas interfaces lógicas do cliente do CE1-PE1 e do CE2-PE2 (Nível 0 Figura 4 in ).

Configuração de CFM para pacotes encapsulados CCC

A única mudança da configuração de CLI existente é a introdução de um novo comando para criar um MIP na interface CE do roteador PE.

Configurando o gerenciamento de falhas de conectividade para interoperabilidade durante atualizações unificadas de software no serviço

A partir da versão 17.1, o Junos OS Connectivity Fault Management (CFM), durante um upgrade unificado de software no serviço (ISSU), funciona quando o dispositivo de peer não é um roteador Juniper Networks de segurança. Interoperando com o roteador de outro fornecedor, o roteador Juniper Networks retém informações de sessão e continua a transmitir PDUs de verificação de continuidade (CCM) durante a ISSU unificada. O gerenciamento de falhas de conectividade continua funcionando.

Esse recurso requer que as seguintes condições sejam atendidas:

  • Mecanismo de Encaminhamento de Pacotes manter as linhas deve ser habilitada para fornecer transmissão inline de CCMs. O recurso não funciona quando as CCMs são transmitidas pela CPU de uma placa de linha, que é o método de transmissão padrão.

  • O intervalo entre as CCMs deve ser de 1 segundo.

A interoperabilidade de CFM durante uma ISSU unificada é suportada nos seguintes MPCs: MPC1, MPC2, MPC2-NG, MPC3-NG, MPC5 e MPC6.

Para habilitar a interoperabilidade do CFM com dispositivos de terceiros em uma ISSU unificada:

  1. Habilitar linhas de linha.
  2. Definir o intervalo CCM para 1 segundo.

Configurando a ISSU unificada para 802.1ag CFM

Uma atualização unificada de software no serviço (ISSU) permite que você atualize entre duas versões diferentes do Junos OS, sem interrupção no plano de controle e com interrupção mínima do tráfego. A ISSU unificada é automaticamente habilitada para protocolos e interoperações de gerenciamento de falhas de conectividade (CFM) entre endpoints de manutenção local e remota (MEPs).

O Junos OS fornece suporte para ISSU unificada usando o valor de comprimento do tipo limiar de perda (TLV), que é ativado automaticamente para CFM. Os TLVs são descritos no padrão IEEE 802.1ag para CFM como um método de codificação de informações de comprimento variável e opcional em uma unidade de dados de protocolo (PDU). O TLV limiar de perda indica o valor do limiar de perda de um MEP remoto. O TLV limiar de perda é transmitido como parte das mensagens de verificação de continuidade do CFM.

Nota:

A partir da versão 15.1 do Junos OS, a configuração de ISSU com CFM (802.1ag) é suportada apenas em roteadores MX e PTX com suporte a TLV. A interoperação com outros fornecedores não é suportada.

Durante uma ISSU unificada, o plano de controle pode cair por vários segundos e fazer com que pacotes de verificação de continuidade de CFM seja descartado. Isso pode fazer com que o MEP remoto detecte uma perda de conectividade e marque o MEP como down. Para manter o MEP ativo durante uma ISSU unificada, o TLV limiar de perda comunica o valor de limiar mínimo que o MEP receptor requer para manter o MEP ativo. O MEP receptor avalia o TLV e atualiza o valor do limiar de perda, mas somente se o novo valor de limiar for maior do que o valor de limiar configurado localmente.

Uma visão geral do CFM é descrita a partir do IEEE 802.1ag OAM Connectivity ManagementOverview, e você deve observar ainda mais os requisitos adicionais descritos neste tópico.

Tabela 2 mostra o formato TLV do Limiar de Perda.

Tabela 2: Formato TLV limiar de perda

Parâmetro

Octeto (sequência)

Descrição

Type=31

1

Necessário. Necessário. Se 0, nenhum campo De comprimento ou valor for seguido. Caso não seja 0, pelo menos o campo Comprimento segue o campo Tipo.

Length=12

2

Obrigatório se o campo Tipo não for 0. Não estará presente se o campo Tipo for 0. Os 16 bits do campo Comprimento indicam o tamanho, em octetos, do campo Valor. 0 no campo Comprimento indica que não há campo Valor.

Oui

3

Opcional. Identificador exclusivo da organização (OUI), que é controlado pela IEEE e normalmente é os três primeiros bytes de um endereço MAC (Juniper OUI 0x009069).

Subtipo

1

Opcional. Subtipo definido organizacionalmente.

Valor

4

Opcional. Valor do limiar de perda.

Bandeira

4

Opcional. Bit0 (identifica que uma ISSU está em andamento)

Bit1-31 (reservado)

O Junos OS fornece suporte de configuração para a declaração, permitindo que você controle a transmissão do TLV limiar de perda nas mensagens de verificação convey-loss-threshold de continuidade das PDUs. A instrução especifica que o TLV limiar de perda deve ser transmitido como parte das mensagens de verificação convey-loss-threshold de continuidade. Caso a instrução não seja especificada, as mensagens de verificação de continuidade transmitem esse TLV somente convey-loss-threshold quando uma ISSU unificada está em andamento. O Junos OS fornece essa configuração em nível de verificação de continuidade. Por padrão, as mensagens de verificação de continuidade não incluem o TLV limiar de perda.

Para configurar o limiar de perda de transporte, use convey-loss-threshold a instrução no [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] nível da hierarquia.

Para o MEP remoto, o TLV limiar de perda é transmitido apenas durante a ISSU unificada, caso convey-loss-threshold a instrução não seja configurada. O MEP remoto volta ao limiar de perda padrão se nenhum TLV for recebido ou o TLV tiver um valor de limiar padrão de 3.

Segue-se um exemplo das declarações de configuração da ISSU:

O Junos OS economiza o último TLV do limiar de perda recebido do MEP remoto. Você pode exibir o último TLV do limiar de perda salvo recebido pelo MEP remoto, usando show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier o comando, como no exemplo a seguir:

O Junos OS economiza o último TLV do limiar de perda transmitida de um MEP local. Você pode exibir o último TLV limiar de perda transmitida e o limiar de perda eficaz (operacional) do MEP remoto, usando o comando, como show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier no exemplo a seguir:

Suporte do Junos OS para monitoramento de desempenho em conformidade com a especificação técnica MEF 36

A versão do Junos OS 16.1R1 e mais tarde aceita monitoramento de desempenho em conformidade com a Especificação Técnica MEF 36. Especificação técnica O MEF 36 especifica a área de monitoramento do MIB. O monitoramento de desempenho MIB é necessário para gerenciar implementações de operações de serviço, administração e manutenção (OAM) que atendam aos requisitos e estrutura do OAM de serviço especificados em MEF 17 e MEF 35, os objetos de gerenciamento especificados no MEF 7.1 e as funções de monitoramento de desempenho definidas em ITU-T Y.1731 e IEEE 802.1ag.

Você pode habilitar o monitoramento de desempenho em conformidade com MEF-36 configurando a measurement-interval instrução em nível [edit protocols oam ethernet cfm performance-monitoring] de hierarquia.

Quando o monitoramento de desempenho em conformidade com MEF-36 estiver ativado:

  • Uma próxima solicitação de SNMP para uma variável pode não buscar o valor atual, a menos que uma caminhada SNMP seja executada antes de realizar a próxima solicitação. Essa limitação se aplica apenas às estatísticas atuais para medição de atraso, avaliação de perda e medição de perda sintético.

  • A saída do campo pode exibir um intervalo de medição de 0 (zero) e um timestamp incorreto até o tempo do Current delay measurement statistics primeiro ciclo expirar.

  • O tamanho do TLV de dados suportado para unidades de dados de protocolo de monitoramento de desempenho (PDUs) é de 1.386 bytes quando o monitoramento de desempenho em conformidade com MEF-36 está ativado. O tamanho do TLV é de 1.400 bytes no modo legado.

  • O valor configurável máximo para o compartimento de limiar inferior é de 4.294.967.294.

  • A razão de perda de quadro (FLR) é excluída nas medições de perda durante um período de indisponibilidade apenas para medição de perda sintético. No caso de medição de perda, a FLR é incluída mesmo durante um período de indisponibilidade.

  • Durante um período de perda de continuidade (adjacency down), embora as PDUs soam não sejam enviadas, os cálculos de FLR e disponibilidade não são interrompidos. Esses cálculos são realizados com a premissa de perda de 100%.

  • O número de PDUs SOAM enviadas durante o primeiro intervalo de medição pode ser inferior ao esperado. Isso se deve ao atraso na detecção do estado de adjabilidade no nível da sessão de monitoramento do desempenho.

  • O número de PDUs SOAM transmitidas durante um intervalo de medição por um tempo de ciclo de 100 ms pode não ser preciso. Por exemplo, em um intervalo de 2 minutos com um tempo de ciclo de 100 ms, as PDUs soam transmitidas podem estar no intervalo de 1198 a 2000.

Amortecer armadilhas e notificações de monitoramento do desempenho do CFM para evitar congestionamento do NMS

Você pode atenuar as armadilhas e notificações de travessia de limiar de monitoramento de desempenho geradas sempre que ocorre um evento de travessia de limiar para impedir o congestionamento do sistema de gerenciamento de rede (NMS).

O amortecimento limita o número de armadilhas jnxSoamPmThresholdCrossingAlarm enviadas para a NMS resumindo as ocorrências do retalho durante um período de tempo, conhecidas como o temporizador de armadilha de retalhos, e envia uma única notificação do jnxSoamPmThresholdFlapAlarm para a NMS. Você pode configurar a duração do relógio de controle de retalhos para qualquer valor de 1 a 360 segundos.

A notificação do jnxSoamPmThresholdFlapAlarm é gerada e enviada quando as seguintes condições são atendidas:

  • Pelo menos um retalho ocorreu quando o temporizador de retalhos expirou.

  • Você mudou o valor do temporizador de armadilha do flap, o que fez o temporizador parar.

Você pode habilitar o amortecimento em nível global para o iterador ou habilitar o amortecimento no tipo de limiar individual do iterador. Por exemplo, para habilitar o amortecimento em nível global, para o iterador, use o seguinte comando: set protocols oam ethernet cfm performance-monitoring sla-iterator-profiles profile-name flap-trap-monitor. Para habilitar o amortecimento em um tipo de limiar específico, use avg-fd-twoway-threshold o seguinte comando: set protocols oam ethernet cfm performance-monitoring sla-iterator-profiles profile-name avg-fdv-twoway-threshold flap-trap-monitor.

Você também pode desativar o amortecimento.

Exemplo: Configuração de ETHERNET CFM em interfaces físicas

Este exemplo mostra a configuração de CFM (Connectivity Fault Management, Gerenciamento de falhas de conectividade Ethernet) em interfaces físicas.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Junos OS Release 9.3 ou mais tarde.

Visão geral

O CFM pode ser usado para monitorar o enlace físico entre dois roteadores. Essa funcionalidade é semelhante à suportada pelo protocolo IEEE 802,3ah LFM.

Na versão 9.3 e posterior do Junos OS, o CFM também tem suporte para interfaces Ethernet agregadas. Nas interfaces configuradas em Concentradores de Porta Modular (MPCs) e Placas de Interface Modular (MICs) em roteadores da série MX, o CFM não é suportado em links de membro Ethernet agregados não conectados. MPCs e MICs são de suporte para CFM em interfaces lógicas Ethernet agregadas e não etiquetadas.

Nota:

As configurações deste exemplo são apenas exemplos parciais de configurações completas e funcionais de roteador. Não copie essas configurações e use-as diretamente em um sistema real.

Configuração

No exemplo a seguir, dois roteadores (Roteador 1 e Roteador 2) são conectados por um enlace Ethernet de Gigabit ponto a ponto. O enlace entre esses dois roteadores é monitorado usando CFM. Isso é mostrado em Figura 5 . O limite único é um "mep down" na terminologia de CFM.

Figura 5: CFM ethernet em interfaces físicasCFM ethernet em interfaces físicas

Para configurar Ethernet CFM em interfaces físicas, realize essas tarefas:

Configuração rápida CLI

Roteador 1

Configure a interface e o CFM:

A configuração no Roteador 2 espelha-se no Roteador 1, com exceção do mep-id.

Roteador 2

Configure a interface e o CFM:

Para verificar se a interface física está configurada corretamente para CFM, use o show interface comando. Para verificar a configuração do CFM, use um ou mais dos show oam ethernet connectivity-fault-management comandos indicados no CLI Explorer.

Exemplo: Configuração de ETHERNET CFM em conexões de ponte

Neste exemplo, o cliente e o provedor de serviços estão executando ETHERNET CFM em uma rede de ponte simples. A rede é mostrada em Figura 6 . O cliente configurou Ethernet CFM nos roteadores da série MX L2-CE1 e L2-CE2. O provedor de serviços configurou Ethernet CFM nos roteadores da série MX PE1 e PE2.

Nota:

As configurações deste exemplo são apenas exemplos parciais de configurações completas e funcionais de roteador. Não copie essas configurações e use-as diretamente em um sistema real.

O provedor de serviços está usando o CFM nível 3 para o enlace entre PE1 e PE2 e o nível 5 de uma CE a porta voltada para a outra. O cliente está usando CFM nível 7. Os limites são marcados com terminologia de CFM "up mep" e "down mep" na figura.

Figura 6: ETHERNET CFM em uma rede de ponteETHERNET CFM em uma rede de ponte

Aqui estão as configurações de CFM nos roteadores do cliente.

CFM em L2-CE1

CFM em L2-CE2

Aqui estão as configurações de CFM nos roteadores provedores.

CFM em PE1

CFM em PE2

Exemplo: Configuração de ETHERNET CFM em VPLS

Neste exemplo, o cliente e o provedor de serviços estão executando ETHERNET CFM por meio de VPLS e uma rede de comutamento de rótulos multiprotocol (MPLS). A rede é mostrada em Figura 7 . O cliente configurou Ethernet CFM nos roteadores da série MX L2-CE1 e L2-CE2. O provedor de serviços configurou Ethernet CFM nos roteadores da série MX PE1, P e PE2.

Nota:

As configurações deste exemplo são apenas exemplos parciais de configurações completas e funcionais de roteador. Não copie essas configurações e use-as diretamente em um sistema real.

O provedor de serviços está usando CFM nível 5 e o cliente está usando CFM nível 7. Os limites são marcados com terminologia de CFM "up mep" e "down mep" na figura.

Figura 7: Ethernet OAM com VPLSEthernet OAM com VPLS
Nota:

As interfaces lógicas em uma instância de roteamento VPLS podem ter as mesmas ou diferentes configurações de VLAN. A normalização de VLAN é necessária para trocar os pacotes corretamente entre essas interfaces. A normalização aceita o mapeamento automático de VLANs e realiza operações em tags VLAN para alcançar a tradução desejada. Consulte Configurar uma VLAN normalizada para tradução ou marcação.

Nota:

As seguintes considerações de caminho de encaminhamento devem ser observadas:

  • Caminho de recebimento de pacotes:

    • Esse é o caminho de encaminhamento para pacotes recebidos nas interfaces.

    • OAM Ethernet 802.1ag para VPLS usa filtros de interface implícitos e filtros de tabela de encaminhamento para inundar, aceitar e soltar os pacotes de CFM.

  • Caminho de transmissão de pacotes:

    • O Junos OS usa o encaminhamento baseado em hardware do roteador para pacotes gerados por CPU.

    • Para os MEPs, os pacotes são transmitidas na interface na qual o MEP está configurado.

    • Nos roteadores da série MX, para up MEPs, os pacotes devem ser inundados para outras interfaces na instância de roteamento VPLS. O roteador cria uma rota de inundação atrelada a um flood next hop (com todas as interfaces a inundação) e, em seguida, cria os pacotes a serem encaminhados com essa rota de inundação.

A seguir estão as configurações de VPLS e CFM nos roteadores do provedor de serviços.

Configuração do PE1

Configuração do PE2

Configuração do roteador P

MPLS, sem a necessidade de CFM:

CFM em L2-CE1

Aqui está a configuração do CFM em L2-E1:

CFM em L2-CE2

Aqui está a configuração do CFM L2-CE2:

Notificação assíncrona do perfil de ação do CFM

SUMMARY 

A notificação assíncrona orientada por CFM permite a sincronização de status do enlace entre dois CE de rede

conectados entre si por meio de um pseudo fio originado de seus respectivos dispositivos PE. Ela emula

o cenário como se dois CE estivesse conectados diretamente. O CFM fornece sinalização de ponta a ponta, mesmo que PE1

e o PE2 não estão conectados por meio de uma única rede, mas sim um conjunto de redes.

Conectividade de Camada 2 entre PE1 e PE2

A Figura 1 é um exemplo de cenário de implantação no qual a notificação assíncrona baseada em CFM pode ser usada

para sincronizar o status do enlace entre CE1 e CE2. Seguir dois requisitos pode ser atendido com o

configuração de notificação assíncrona.

  • Quando o enlace entre PE2 e CE2 é baixado, o enlace entre PE1 e CE1 também é feito.

    Quando o enlace for restabelecido, ele também deve restaurar o status do enlace PE1 para CE1. O status do enlace muda

    PE1 a CE1 deve funcionar da mesma forma.

    • Quando há um problema de conectividade entre PE1 e PE2, ele aciona um enlace entre PE1 e CE1

      e PE2 a CE2. Se o status da conexão for restabelecido, ele deve restaurar o status do enlace em ambas as extremidades

Tabela de histórico de liberação
Versão
Descrição
17.1
A partir da versão 17.1, o Junos OS Connectivity Fault Management (CFM), durante um upgrade unificado de software no serviço (ISSU), funciona quando o dispositivo de peer não é um roteador Juniper Networks de segurança.
15.1
A partir da versão 15.1 do Junos OS, a configuração de ISSU com CFM (802.1ag) é suportada apenas em roteadores MX e PTX com suporte a TLV.
12.3
A partir da versão 12.3 do Junos OS, para todas as interfaces configuradas em MPCs (Modular Port Concentrators) na Série MX 5G Plataformas de roteamento universal, você não precisa mais configurar a instrução para todos os circuitos De Camada 2 e Camada 2 nos quais você está executando no-control-word MEPs de CFM.
12.3
A partir da versão 12.3 do Junos OS, para todas as interfaces configuradas em MPCs (Modular Port Concentrators) na Série MX 5G Plataformas de roteamento universal, você não precisa mais configurar a instrução para todos os circuitos De Camada 2 e Camada 2 nos quais você está executando no-control-word MEPs de CFM.
12.3
A partir da versão 12.3 do Junos OS, para todas as interfaces configuradas em MPCs (Modular Port Concentrators) na Série MX 5G Plataformas de roteamento universal, você não precisa mais configurar a instrução para todos os circuitos De Camada 2 e Camada 2 nos quais você está executando no-control-word MEPs de CFM.