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 este 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 realizada 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, você deve primeiro configurar um domínio de manutenção e especificar o nome do domínio de manutenção. Você também pode especificar o formato do nome. Por exemplo, se você especificar o formato de nome para ser o formato de serviço de nome de domínio (DNS), você pode especificar o nome do domínio de manutenção como www.juniper.net. O formato de nome padrão é a cadeia de caracteres ASCII.

Nota:

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

Durante a criação do domínio de manutenção, você também pode especificar o nível de domínio de manutenção. O nível de domínio de manutenção indica a relação de aninhamento entre vários domínios de manutenção. O nível de domínio de manutenção está embutido em cada um dos quadros 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 ] hierarquia.
    Nota:

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

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

Configuração de pontos intermediários de manutenção (MIPs)

Os roteadores da Série MX oferecem suporte a pontos intermediários de manutenção (MIPs) para o protocolo Ethernet OAM 802.1ag CFM em um nível de domínio de ponte. Isso permite que você defina um domínio de manutenção para cada nível padrão. Os nomes de MIPs são criados como default-level-number no nível de [edit protocols oam ethernet connectivity-fault-management maintenance-domain] hierarquia. Use as bridge-domainopções, instancee mip-half-functionvirtual-switchMIP para especificar a configuração do MIP.

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

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

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

    Um domínio de ponte deve ser especificado apenas pelo nome se estiver configurado, incluindo a vlan-id declaração prevista na virtual-switch declaração. Se um domínio de ponte for configurado com uma variedade de IDs VLAN, os IDs VLAN devem ser explicitamente listados após o nome de 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 declaração no nível de [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name] 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 fuccionalidade de MIP em dois segmentos unidirecionais para melhorar a cobertura da rede, aumentando o número de MIPs que são monitorados. A metade da função MIP também responde a mensagens de loop-back e rastreamento de link para identificar falhas.
    Nota:

    Sempre que um MIP é 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 mip-half-function valor para todos os domínios de manutenção e associações de manutenção seja o mesmo.

Configuração de pontos intermediários da Associação de Manutenção na Série ACX

O ponto intermediário de manutenção (MIP) oferece recursos de monitoramento de pontos intermediários para serviços como a ponte de Camada 2, circuito de Camada 2 e VPN de Camada 2. Os roteadores ACX5048 e ACX5096 oferecem suporte a MIPs para o protocolo Ethernet OAM 802.1ag CFM. Use as opções de MIP de domínio de ponte e mip de meia função para especificar a configuração do MIP.

Nota:

Os roteadores ACX5048 e ACX5096 não oferecem suporte à configuração de MIP em serviços VPLS.

Nota:

O roteador ACX5448 não aceita MIP.

Nota:

Sempre que um MIP é 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 mip-half-function valor para todos os domínios de manutenção e associações de manutenção seja o 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 em 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 é configurado

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

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

Configuração do domínio da ponte de domínio de manutenção

Para configurar o domínio da ponte, inclua a vlans declaração no 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 mostram que os 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 de Camada 2 para a Série ACX.

Configuração da meia função MIP do domínio de manutenção

O MIP Half Function (MHF) divide a funcionalidade do MIP em dois segmentos unidirecionais, melhora a visibilidade com configuração mínima e melhora 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 é 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 do 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 declaração no nível de [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name] hierarquia.

Configuração dos pontos intermediários da Associação de Manutenção com domínio da 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 dos pontos intermediários da Associação de Manutenção com o Circuito Cross-Connect

Nos roteadores ACX5048 e ACX5096, você pode configurar o MIP com conexão cruzada (CCC). A seguir, uma amostra para configurar o MIP com CCC:

Configuração dos pontos intermediários da Associação de Manutenção com domínio de ponte quando o ponto final da Associação de Manutenção estiver configurado

Nos roteadores ACX5048 e ACX5096, você pode configurar o MIP com domínio de ponte quando um ponto final de 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:

Configurar os pontos intermediários de manutenção com o cross-connect de circuito quando o ponto final da Associação de Manutenção estiver configurado

Nos roteadores ACX5048 e ACX5096, você pode configurar o MIP com conexão cruzada de circuito (CCC) quando um ponto final de 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 a maintenance-association ma-name declaração no nível de [edit protocols oam ethernet connectivity-fault-management maintenance-domain domain-name] hierarquia.

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

  • Como uma seqüência de caracteres ASCII simples

  • Como identificador VLAN do VLAN, você associa principalmente à associação de manutenção

  • Como identificador de dois octets na faixa de 0 a 65.535

  • Como nome no formato especificado pela RFC 2685

O formato de nome curto padrão é uma seqüência 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 no 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 finais de manutenção (MEPs) em uma associação de manutenção. O MEP envia periodicamente mensagens multicast de verificação de continuidade. Os pacotes de protocolo de verificação de continuidade usam o valor do ethertype 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 (100ms) ou 10 milissegundos (10ms). O valor padrão é de 1 minuto. Por exemplo, se você especificar o intervalo de 1 minuto, o MEP envia as mensagens de verificação de continuidade a cada minuto para o MEP recebido.

    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 no Mecanismo de Encaminhamento de Pacotes por padrão. Você só pode desativar o PPM no mecanismo de encaminhamento de pacotes. Para desativar o PPM no mecanismo de encaminhamento de pacotes, use a no-delegate-processing declaração no nível de [edit routing-options ppm] hierarquia.

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

  • hold-interval— Frequência na qual o banco de dados MEP pode ser liberado, caso não ocorram atualizações. Os deputados que recebem usam as mensagens de verificação de continuidade para criar um banco de dados MEP de todos os deputados da associação de manutenção. A frequência é o número de minutos para esperar antes de liberar o banco de dados MEP se não houver atualizações. O valor padrão é de 10 minutos.

    Nota:

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

    A lógica do intervalo de espera executa um temporizador de votação por nível de sessão CFM (não por nível MEP remoto) onde a duração do tempo de votação é igual ao tempo de espera configurado. Quando o temporizador de votação expira, ele elimina todas as entradas MEP remotas autodiscoverizadas que estiveram no 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é que o próximo temporizante de votação expira. Portanto, a descarga remota de MEP 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 baixo. O valor pode ser de 3 a 256 unidades de dados de protocolo (PDUs). O valor padrão é de 3 PDUs.

Configuração de 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. Um MEP gera e responde periodicamente a mensagens multicast de verificação de continuidade. Os pacotes de protocolo de verificação de continuidade usam o valor do ethertype 0x8902 e o endereço MAC de destino multicast 01:80:c2:00:00:32. Os deputados que recebem usam as mensagens de verificação de continuidade (CCMs) para criar um banco de dados MEP de todos os deputados da associação de manutenção.

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

  1. Especifique o tempo para esperar minutos antes de liberar o banco de dados MEP, se não houver atualizações, com um valor de 1 minuto a 30.240 minutos. O valor padrão é de 10 minutos.
    Nota:

    O flushing baseado no temporizador de espera é aplicável apenas para MEPs remotos autodiscovered 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 baixo. O valor pode ser de 3 a 256 unidades de dados de protocolo (PDUs). O valor padrão é de 3 PDUs.

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

Um ponto final de associação de manutenção (MEP) refere-se ao limite 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 determinado serviço VPLS ou um domínio de ponte. Você pode configurar vários MEPs para uma única instância de identificação de domínio de manutenção e nome de associação de manutenção para monitorar serviços fornecidos por serviços de LAN privada virtual (VPLS), domínio de ponte, conexão cruzada de circuito (CCC) ou domínios IPv4.

Para instâncias de roteamento de VPNs de camada 2 (comutação local) e roteamento 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 dispositivos diferentes ou no mesmo dispositivo. Para oferecer suporte a vários MEPs em dois IFLs, serviços aprimorados de rede IP devem ser configurados para o chassi.

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

A medição de continuidade é fornecida por um protocolo de verificação de continuidade existente. A continuidade de cada MEP remoto é medida como a porcentagem de tempo em que o MEP remoto estava operacionalmente acima do tempo total habilitado administrativamente. 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 de habilitação administrativa é o tempo total durante o qual o MEP local está ativo. Você também pode reiniciar a medição de continuidade eliminando o tempo de atividade operacional atualmente medido e o tempo de habilitação administrativa.

Configuração de um ponto final de associação de manutenção (MEP)

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

  1. Especifique um 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. Habilite a descoberta automática de ponto final de manutenção para que o MEP possa aceitar mensagens de verificação de continuidade (CCMs) de todos os MEPs remotos da mesma associação de manutenção.
  3. Especifique a direção em que os pacotes CCM são transmitidos para o MEP. Você pode especificar para cima ou para baixo. Se você especificar a direção como mais alta, os CCMs são transmitidos de todas as interfaces lógicas que fazem parte da mesma ponte ou instância VPLS, exceto pela interface configurada no MEP. Se você especificar a direção como baixa, os CCMs são transmitidos apenas para fora da interface configurada no MEP.
    Nota:

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

    Nota:

    Começando com o Junos OS Release 12.3, para todas as interfaces configuradas em Concentradores modulares de portas (MPCs) em plataformas de roteamento universal 5G da Série MX, você não precisa mais configurar a no-control-word declaração para todas as VPNs de Camada 2 e circuitos de Camada 2 sobre os quais você está executando MEPs 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 no-control-word declaração no nível da [edit routing-instances routing-instance-name protocols l2vpn][edit protocols l2circuit neighbor neighbor-id interface interface-name] hierarquia quando configurar OS MEPs do CFM. Caso contrário, os pacotes 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, interface lógica ou interface de tronco. Nos roteadores da Série MX, o MEP pode ser conectado a um VLAN específico de uma interface de tronco.
  5. Especifique os bits de prioridade IEEE 802.1 que são usados por mensagens de verificação de continuidade e rastreamento de link. Você pode especificar um valor de até 7 como prioridade.
  6. Especifique o menor defeito de prioridade que gera um alarme de falha sempre que o CFM detecta um defeito. Os valores possíveis incluem: todos os defeitos, err-xcon, mac-rem-err-xcon, sem defeito, rem-err-xcon e xcon.
  7. Especifique o 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.

Configuração de um ponto final da Associação de Manutenção remota (MEP)

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

  1. Configure o MEP remoto especificando o ID 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 declaraçã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 no nível [edit protocols oam ethernet connectivity-fault-management] da hierarquia.
  3. Configure o MEP remoto para detectar a perda inicial de conectividade. Por padrão, o MEP não gera mensagens de defeito de perda de continuidade (LOC). Ao configurar a detect-loc declaração, é detectado um defeito de perda de continuidade (LOC) 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 manutenção. Se um defeito de LOC for detectado, uma mensagem de erro de syslog é gerada.
    Nota:

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

Configuração de interfaces mep para oferecer suporte a medições de atraso do quadro Ethernet

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

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

  • OAM Ethernet configurado e CFM corretamente

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

  • Habilitado o daemon de gerenciamento de pacotes periódicos distribuídos (ppmd)

  • Evitamos tentar realizar a medição de atraso do quadro Ethernet em interfaces agregadas de Ethernet ou pseudowire, que não têm suporte

  • Certifique-se de que o tempotamping assistido por hardware seja suportado se esse recurso estiver configurado

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

Para configurar o tempotamping assistido por hardware:

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

    Para realizar a medição de atraso do quadro Ethernet, certifique-se de que a seguinte declaração de configuração NÃO esteja presente:

Configuração da proteção de serviços para VPWS por MPLS usando a interface MEP

Você pode habilitar a proteção de serviços para um serviço virtual de fio privado (VPWS) através do MPLS especificando um caminho de trabalho ou protegendo o caminho no MEP. A proteção de serviços oferece proteção de conexão de ponta a ponta do caminho de trabalho em caso de falha.

Para configurar a proteção de serviços, 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 a um caminho, você deve configurar a interface declaração para o MEP dentro da associação de manutenção e especificar o caminho como trabalho ou proteção.

Nota:

Se o caminho não for especificado, a sessão monitora o caminho ativo.

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

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

Opção

Descrição

working

Especifica o caminho de trabalho.

protect

Especifica o caminho de proteção.

Nesta configuração, habilitamos a proteção de serviços para o serviço VPWS. A sessão do 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 declaração. O nome do caminho de transporte protegido para a associação de manutenção está configurado e associado à associação de manutenção para o caminho de trabalho.

Para configurar a proteção de serviços 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 ] hierarquia.
    Nota:

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

  2. Especifique o nível de domínio de manutenção especificando o valor no nível [edit protocols oam ethernet connectivity-fault-management ] 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] de hierarquia.
  4. Especifique o nome da associação de manutenção usado para proteção de conexão e o nome do perfil de comutação de proteção automática (aps-profile) no nível [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] de hierarquia.
  5. Especifique o tempo de espera entre 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 ] hierarquia. A duração pode ser um dos seguintes valores: 10 minutos(10m), 1 minuto(1m), 10 segundos(1s), 1 segundo(1s), 100 milissegundos (100ms) ou 10 milissegundos (10ms). O valor padrão é de 1 minuto.
  6. Especifique um 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. Habilite a descoberta automática de ponto final de manutenção para que o MEP possa aceitar mensagens de verificação de continuidade (CCMs) de todos os MEPs remotos da mesma associação de manutenção.
  8. Especifique a direção em que os pacotes CCM são transmitidos para o MEP. Você pode especificar para cima ou para baixo. Se você especificar a direção como mais alta, os CCMs são transmitidos de todas as interfaces lógicas que fazem parte da mesma ponte ou instância VPLS, exceto pela interface configurada no MEP. Se você especificar a direção como baixa, os CCMs são transmitidos apenas para fora da interface configurada no MEP.
    Nota:

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

    Nota:

    Começando com o Junos OS Release 12.3, para todas as interfaces configuradas em Concentradores modulares de portas (MPCs) em plataformas de roteamento universal 5G da Série MX, você não precisa mais configurar a no-control-word declaração para todas as VPNs de Camada 2 e circuitos de Camada 2 sobre os quais você está executando MEPs 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 no-control-word declaração no nível da [edit routing-instances routing-instance-name protocols l2vpn][edit protocols l2circuit neighbor neighbor-id interface interface-name] hierarquia quando configurar OS MEPs do CFM. Caso contrário, os pacotes 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, interface lógica ou interface de tronco. Nos roteadores da Série MX, o MEP pode ser conectado a um VLAN específico 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] de hierarquia.
  11. Especifique o tempo de espera entre 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 ] hierarquia. A duração pode ser um dos seguintes valores: 10 minutos(10m), 1 minuto(1m), 10 segundos(1s), 1 segundo(1s), 100 milissegundos (100ms) ou 10 milissegundos (10ms). O valor padrão é de 1 minuto.
  12. Especifique um 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. Habilite a descoberta automática de ponto final de manutenção para que o MEP possa aceitar mensagens de verificação de continuidade (CCMs) de todos os MEPs remotos da mesma associação de manutenção.
  14. Especifique a direção em que os pacotes CCM são transmitidos para o MEP. Você pode especificar para cima ou para baixo. Se você especificar a direção como mais alta, os CCMs são transmitidos de todas as interfaces lógicas que fazem parte da mesma ponte ou instância VPLS, exceto pela interface configurada no MEP. Se você especificar a direção como baixa, os CCMs são transmitidos apenas para fora da interface configurada no MEP.
    Nota:

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

    Nota:

    Começando com o Junos OS Release 12.3, para todas as interfaces configuradas em Concentradores modulares de portas (MPCs) em plataformas de roteamento universal 5G da Série MX, você não precisa mais configurar a no-control-word declaração para todas as VPNs de Camada 2 e circuitos de Camada 2 sobre os quais você está executando MEPs 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 no-control-word declaração no nível da [edit routing-instances routing-instance-name protocols l2vpn][edit protocols l2circuit neighbor neighbor-id interface interface-name] hierarquia quando configurar OS MEPs do CFM. Caso contrário, os pacotes 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, interface lógica ou interface de tronco. Nos roteadores da Série MX, o MEP pode ser conectado a um VLAN específico de uma interface de tronco. Além disso, especifique o caminho de transporte como funcionando.

Configuração do protocolo de rastreamento de links no CFM

O protocolo de linktrace é usado para a descoberta de caminhos entre um par de pontos de manutenção. As mensagens de linktrace são acionadas por um administrador que usa o traceroute comando para verificar o caminho entre um par de MEPs sob a mesma associação de manutenção. As mensagens de linktrace também podem ser usadas para verificar o caminho entre um MEP e um MIP sob o mesmo domínio de manutenção. O protocolo de rastreamento de link permite configurar o tempo para esperar por uma resposta. Se nenhuma resposta for recebida para uma mensagem de solicitação de rastreamento de link, as entradas de solicitação e resposta serão excluídas após o término do intervalo. Você também pode configurar o número de entradas de resposta do linktrace a serem armazenadas para a solicitação de linktrace correspondente.

A operação de mensagens de solicitação e resposta de linktrace IEEE 802.1ag é semelhante à operação de comandos de Camada 3 traceroute . Para obter mais informações sobre o traceroute comando, consulte a Junos OS Administration Library for Routing Devices.

Para configurar o protocolo de rastreamento de link:

  1. Configure o tempo para esperar por uma resposta de rastreamento de link no nível [edit protocols oam ethernet connectivity-fault-management] de 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 de rastreamento de link a serem armazenadas por solicitação de rastreamento de link. Você pode especificar um valor de 1 a 500. O valor padrão é de 100.

Configuração de limitação de taxa de mensagens Ethernet OAM

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

Você pode aplicar limitação de taxa de mensagens Ethernet OAM em ambos os 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 CFM pertencente a todas as sessões.

  • Policiamento CFM em nível de sessão — usa um policial criado para policiar o tráfego CFM pertencente a uma sessão.

Para configurar o policiamento CFM em nível global, inclua a policer declaração e suas opções no 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 no nível da [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name level number maintenance-association ma-name] hierarquia.

O exemplo a seguir mostra um policial do CFM usado para limitar a taxa de CFM:

Caso 1: Policiamento CFM em nível global

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

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

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

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

Nota:

A configuração do policiador de nível de serviço para quaisquer duas sessões de CFM na mesma interface em níveis diferentes deve satisfazer as seguintes restrições se a direção das sessões for a mesma:

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

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

Um erro de confirmação ocorrerá se tal configuração for comprometida.

Nota:

Policiais com PBB e MIPs não são apoiados.

Configuração da interface de gerenciamento local da Ethernet

Visão geral da interface de gerenciamento local da Ethernet

As interfaces Gigabit Ethernet (ge), Ethernet de 10 Gigabits exe Ethernet agregada oferecemae suporte à Ethernet Local Management Interface (E-LMI).

Nota:

Nos roteadores da Série MX, o E-LMI é compatível com interfaces Gigabit Ethernet (ge), Ethernet de 10 Gigabits exe Ethernet agregada (ae) configuradas apenas em roteadores da Série MX com DPC.

A especificação E-LMI está disponível no Metro Ethernet Forum. Os procedimentos e protocolos E-LMI são usados para permitir a configuração automática da borda do cliente (CE) para oferecer suporte aos serviços Metro Ethernet. O protocolo E-LMI também fornece informações de status de interface de usuário para rede (UNI) e Ethernet virtual Connection (EVC) para o CE. As informações de UNI e EVC permitem a configuração automática da operação CE com base na configuração Metro Ethernet.

O protocolo E-LMI opera entre o dispositivo CE e o dispositivo de borda (PE) do provedor. Ele é executado apenas no link PE-CE e notifica o CE de status de conectividade e parâmetros de configuração dos serviços Ethernet disponíveis na porta CE. 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 nos 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), que é executado dentro da rede de provedores para coletar o status de OAM. O CFM é executado no nível de manutenção do provedor (UNI-N para UNI-N com até MEPs na UNI). O E-LMI depende do CFM para o status de ponta a ponta dos EVCs em domínios CFM (domínio SVLAN ou VPLS).

O protocolo E-LMI transmite 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 de atributos UNI e EVC ao CE:

    • Atributos da UNI:

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

      • Tipo de mapa CE-VLAN ID/EVC (agrupamento all-to-one, multiplexação de serviço com agrupamento ou sem agrupamento)

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

        • CM (modo de acoplamento)

        • CF (bandeira colorida)

        • CIR (taxa de informações comprometidas)

        • CBR (tamanho de explosão comprometido)

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

        • EBS (excesso de tamanho estourado)

    • Atributos de EVC:

      • ID de referência de EVC

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

      • Tipo de EVC (ponto a ponto ou multiponto para multiponto)

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

      • Perfil de largura de banda (sem suporte)

    • Mapa de ID/EVC CE-VLAN

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

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

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

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

    Nota:

    l2-circuit e l2vpn não são compatíveis.

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

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

    • Sessão de CFM de ponta a ponta entre ASNUS para monitorar o status de EVC.

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

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

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

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

Nota:

Os roteadores da Série ACX não oferecem suporte a E-LMI para serviços de Camada 2 (ponte).

Configuração da 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 a visão geral do gerenciamento de falhas de conectividade OAM da IEEE 802.1ag.

Atribuição do protocolo OAM a um EVC

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

Você pode definir o número de UNIs remotas no EVC usando a remote-uni-count number declaração no nível de [edit protocols oam ethernet evcs evcs-protocol] hierarquia. O remote-uni-count padrão é 1. Configurar um valor superior a 1 torna o EVC multipoint para multipoint. Se você inserir um valor maior do que o número real de endpoints, o status de EVC será exibido como parcialmente ativo, mesmo se todos os endpoints estiverem ativos. Se você inserir um remote-uni-count número menor do que o número real de endpoints, o status será exibido como ativo, mesmo que todos os endpoints não estejam ativos.

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

Habilitação de E-LMI em uma interface e mapeamento de IDs CE VLAN para um EVC

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

Você pode definir o contador de status para contar erros consecutivos usando a status-counter count declaração no nível de [edit protocols oam ethernet lmi] 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 no nível da [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 a interface name declaração no nível hierárquico [edit protocols oam ethernet lmi] . Somente ge, xee ae as interfaces são compatíveis. Você pode usar a opção de interface uni-id para especificar um nome para a UNI. Se uni-id não estiver configurado, ele fica inadimplente com a variável nome de interface name.

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

Para especificar o EVC que uma interface usa, use a evc evc-id declaração no nível de [edit protocols oam ethernet lmi interface name] hierarquia. Você pode especificar uma interface como a interface de EVC padrão usando a default-evc declaração no nível de [edit protocols oam ethernet lmi interface name evc evc-id] hierarquia. Todos os VIDs que não são mapeados para nenhum outro EVCs são mapeados para este EVC. Apenas 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 declaração no nível de [edit protocols oam ethernet lmi interface name evc evc-id] hierarquia.

Configuração E-LMI de exemplo

Topologia de exemplo

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

Figura 2: Configuração E-LMI para EVC ponto a ponto (SVLAN) monitorada pelo CFMConfiguração E-LMI para EVC ponto a ponto (SVLAN) monitorada pelo CFM

Configuração de PE1

Configuração de PE2

Configuração de duas UNIs compartilhando o mesmo EVC

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

Você pode criar um perfil de ação de gerenciamento de falhas de conectividade (CFM) para definir bandeiras e limites de eventos a serem monitorados. Você também pode especificar a ação a ser tomada quando algum dos eventos configurados ocorrer. Quando os eventos CFM ocorrem, o roteador realiza a ação correspondente com base em 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 de associação de manutenção remota (MEP) falhar.

Nota:

Você não pode configurar várias ações neste momento. Apenas uma ação pode ser configurada. Essa limitação afeta tanto as declarações quanto clear-action as action declarações.

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

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

    Associar um perfil de ação com a ação interface-down em uma sessão up MEP CFM em execução por uma interface de cross-connect (CCC) de circuito (l2circuit/l2vpn) não é recomendável e pode resultar em uma situação de impasse.

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

Com o crescimento das redes, existe uma exigência de monitorar um grande número de serviços usando o CFM. Para monitorar cada serviço, é necessária uma sessão por interface lógica de serviço. Se os serviços forem 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 do CFM pode monitorar vários serviços.

Além disso, existem cenários em que o dispositivo de interface de usuário para rede (UNI) precisa ser derrubado com base em sessões na interface lógica da interface de rede para rede (NNI). Aqui, a interface lógica NNI refere-se à interface de núcleo e interface física UNI refere-se à interface de acesso hospedando 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 de provedor (PE). Cada serviço usa uma interface lógica. Um conjunto de serviços ou interfaces lógicas (coloridos em amarelo) são destinados a um roteador CE e um conjunto de serviços ou interfaces lógicas coloridos em vermelho são destinados a outro roteador CE. Para monitorar cada serviço, você precisa de sessões dedicadas de ponto final de associação de manutenção (MEP) para cada serviço. Você pode reduzir o serviço derrubando a interface lógica de serviço sempre que a sessão diminuir. No entanto, essa abordagem não é escalável se tivermos um grande número de serviços. Monitorar a sessão do CFM na interface física também não é viável porque vários roteadores CE podem estar conectados e os serviços a outro roteador CE podem ser interrompidos. Para resolver essa questão 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 CFM configurada em uma única interface lógica.

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

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

  • Para derrubar um grupo de interfaces lógicas, todas com a mesma porta-mãe quando a sessão de monitoramento ccm está sendo executada em uma das interfaces lógicas, mas em uma porta-mãe diferente.

  • Para derrubar um grupo de interfaces lógicas quando a sessão de monitoramento do CCM estiver sendo executada em uma das interfaces lógicas, todas pertencentes à mesma porta-mãe.

  • Para derrubar a porta, quando a sessão de monitoramento CCM estiver sendo executada em uma das interfaces lógicas de uma porta-mãe diferente.

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

  • Reduz a exigência de recursos em redes escalonadas onde vários serviços precisam ser monitorados.

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

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

Para monitorar vários serviços ou IFLs usando a sessão 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 precisam ser derrubadas. Uma interface lógica é representada por uma combinação dointerface-device-name.unit-list As etapas a seguir explicam o procedimento para derrubar um grupo de interfaces lógicas quando e interface-device-name /ou unit-list são especificadas.

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

    Por exemplo,

    Nota:

    A ação interface-group-down não será suportada com eventos que não sejam perda de adjacência e RDI. Quaisquer outros eventos configurados resultam em um erro de confirmação.

  2. No modo de configuração, no 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 um erro de confirmação.

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

    Por exemplo,

  4. Na definição do edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-nameendpoint da associação de manutenção e dos parâmetros associados.

    Por exemplo,

  5. Se o perfil de ação tiver interface-group-down ação configurado, é obrigatório configurar o interface-group nível RMEP. No modo de configuração, inclua a [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-nameinterface-group declaração para derrubar o grupo de interface marcado com o perfil de ação como interface-group-down.

    Por exemplo,

    Nota:

    Se a interface-group configuração não estiver incluída na configuração RMEP. A configuração resulta em erro de confirmação.

  6. Uma interface lógica é representada por uma combinação dointerface-device-name.unit-list 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-nameunit-list deve ser configurado. Se o nome do dispositivo de interface não estiver configurado, a interface MEP é considerada como o nome do dispositivo e a interface lógica nesse dispositivo é derrubada.

    • Se o unit-list parâmetro exceder o limite recomendado, ocorre um erro de confirmação.

    • Se o nome do dispositivo de interface não for especificado no interface-group, os números de interface lógica mencionados unit-list para a interface física são reduzidos.

    • Se a lista de unidades não for especificada, os interface-groupIFLs são derrubados para a interface configurada.

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

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

Você pode habilitar o modo de gerenciamento aprimorado de falhas de conectividade (CFM) para permitir a implantação eficaz do Ethernet OAM em redes de escalonamento. Ao ativar o modo CFM aprimorado, o Junos OS oferece suporte a 32.000 pontos finais de associação de manutenção (MEPs) e pontos intermediários de manutenção (MIPs) cada um por chassi para domínios de ponte, VPLS, L2VPN e CCC. Em versões anteriores, o Junos OS oferece suporte a 8.000 MEPs e 8000 MIPS por chassi. Se você não habilitar CFM aprimorado, o Junos OS continua a oferecer 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. Se o modo de serviços de rede não enhanced-ipestiver, e você tiver habilitado o CFM aprimorado, a seguinte mensagem de aviso 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 de [edit protocols oam ethernet connectivity-fault-management] hierarquia.
  2. Habilite a implantação eficaz do Ethernet OAM habilitando o modo CFM aprimorado.
  3. Comprometa a mudança de modo. Uma mensagem de aviso é exibida pedindo que você reinicie o CFM. Se você não reiniciar o CFM, o CFM é reiniciado automaticamente pelo Junos OS.
  4. Para verificar se o modo CFM aprimorado foi configurado, use o show oam ethernet connectivity-fault-management state comando.

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

IEEE 802.1ag CFM OAM Suporte 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 Frame Relay) pela infraestrutura de IP/MPLS compartilhada do provedor de serviços. O roteador de borda do provedor de serviços (PE) deve ter uma interface com encapsulamento de circuito cross-connect (CCC) para mudar o tráfego de borda do cliente (CE) para a rede pública.

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

Recursos do CFM suportados em circuitos VPN de Camada 2

Os recursos do CFM suportados em circuitos L2VPN são os seguintes:

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

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

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

  • Suporte para o protocolo de medição de atraso de Ethernet Y1731.

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

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 Figura 4) pode ser configurado nas interfaces lógicas voltadas para CE dos roteadores de borda de provedores PE1 e PE2. Para monitorar o circuito de apego CE-PE, um CFM down MEP pode ser configurado nas interfaces lógicas do cliente de CE1-PE1 e CE2-PE2 (Nível 0 pol Figura 4).

Configuração do CFM para pacotes encapsulados de CCC

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

Configuração de gerenciamento de falhas de conectividade para interoperabilidade durante atualizações unificadas de software em serviço

A partir do lançamento do 17.1, o gerenciamento de falhas de conectividade (CFM) do Junos OS, durante uma atualização unificada de software em serviço (ISSU), funciona quando o dispositivo peer não é um roteador da Juniper Networks. Interoperando com o roteador de outro fornecedor, o roteador Juniper Networks retém informações de sessão e continua a transmitir PDUs de mensagem de verificação de continuidade (CCM) durante o ISSU unificado. O gerenciamento de falhas de conectividade continua a operar.

Este recurso exige que as seguintes condições sejam atendidas:

  • Os keepalives do mecanismo de encaminhamento de pacotes devem ser habilitados para fornecer transmissão em linha de CCMs. O recurso não funciona quando os CCMs são transmitidos 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 do CFM durante um ISSU unificado é suportada nos seguintes MPCs: MPC1, MPC2, MPC2-NG, MPC3-NG, MPC5 e MPC6.

Para permitir a interoperabilidade do CFM com dispositivos de terceiros em um ISSU unificado:

  1. Habilite keepalives em linha.
  2. Definir o intervalo CCM para 1 segundo.

Configuração de ISSU unificada para 802.1ag CFM

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

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

Nota:

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

Durante um ISSU unificado, o plano de controle pode cair por vários segundos e fazer com que os pacotes de verificação de continuidade do CFM caiam. Isso pode fazer com que o MEP remoto detecte uma perda de conectividade e marque o MEP como baixo. Para manter o MEP ativo durante um ISSU unificado, o limite de perda TLV comunica o valor limite mínimo que o MEP recebe para manter o MEP ativo. O MEP recebendo analisa o TLV e atualiza o valor do limite de perda, mas somente se o novo valor limite for maior do que o valor limite configurado localmente.

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

Tabela 2 mostra o formato TLV de limite de perda.

Tabela 2: Formato TLV de limite de perda

Parâmetro

Octet (sequência)

Descrição

Type=31

1

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

Length=12

2

Necessário se o campo Tipo não for 0. Não está presente se o campo Tipo for 0. Os 16 bits do campo de comprimento indicam o tamanho, em octetes, do campo Value. 0 no campo de comprimento indica que não há campo de valor.

OUI

3

Opcional. Identificador exclusivo de organização (OUI), que é controlado pelo IEEE e normalmente é o primeiro bytes de um endereço MAC (Juniper OUI 0x009069).

Subtipo

1

Opcional. Subtipo definido pela organização.

Value

4

Opcional. Valor limite de perda.

Bandeira

4

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

Bit1-31 (reservado)

O Junos OS fornece suporte de configuração para a convey-loss-threshold declaração, permitindo que você controle a transmissão do TLV limiar de perda em PDUs de mensagens de verificação de continuidade. A convey-loss-threshold declaração especifica que o limite de perda TLV deve ser transmitido como parte das mensagens de verificação de continuidade. Se a convey-loss-threshold declaração não for especificada, as mensagens de verificação de continuidade transmitirão este TLV somente quando um ISSU unificado estiver em andamento. O Junos OS fornece essa configuração no nível de verificação de continuidade. Por padrão, as mensagens de verificação de continuidade não incluem o TLV do limite de perda.

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

Para o MEP remoto, o limite de perda TLV só é transmitido durante o ISSU unificado se a convey-loss-threshold declaração não estiver configurada. Os switches MEP remotos voltam ao limite de perda padrão se nenhum limite de perda TLV for recebido ou o TLV tiver um valor de limite padrão de 3.

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

O Junos OS salva o último TLV de limite de perda recebido do MEP remoto. Você pode exibir o último TLV de limite de perda economizado que é recebido pelo MEP remoto, usando o show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier comando, como no seguinte exemplo:

O Junos OS salva o último TLV de limite de perda transmitido de um MEP local. Você pode exibir o último limiar de perda transmitido TLV e o limiar de perda efetiva (operacional) para o MEP remoto, usando o show oam ethernet connectivity-fault-management mep-database maintenance-domain identifier maintenance-association identifier local-mep identifier remote-mep identifier comando, como no seguinte exemplo:

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

O Junos OS versão 16.1R1 e posterior oferece suporte ao monitoramento de desempenho em conformidade com a especificação técnica MEF 36. Especificação técnica MEF 36 especifica o MIB de monitoramento de desempenho. O MIB de monitoramento de desempenho é necessário para gerenciar implementações de operações de serviço, administração e manutenção (OAM) que satisfaçam os requisitos e a estrutura de OAM de serviço especificados no 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 declaração no nível hierárquico [edit protocols oam ethernet cfm performance-monitoring] .

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

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

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

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

  • O valor máximo configurável para a caixa de limiar inferior é de 4.294.967.294.

  • A razão de perda de quadros (FLR) é excluída em medições de perda durante o período de indisponibilidade apenas para medição de perda sintética. Em caso de medição de perda, o FLR é incluído mesmo durante um período de indisponibilidade.

  • Durante um período de perda de continuidade (adjacência para baixo), embora as PDUs SOAM não sejam enviadas, os cálculos de FLR e disponibilidade não sejam interrompidos. Esses cálculos são realizados com a suposição de perda de 100%.

  • O número de PDUs SOAM enviados durante o primeiro intervalo de medição pode ser menor do que o esperado. Isso se deve a um atraso na detecção do estado de adjacência no nível da sessão de monitoramento de desempenho.

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

Amortecimento do desempenho do CFM Monitorando armadilhas e notificações para evitar congestionamentos do NMS

Você pode reduzir o desempenho monitorando armadilhas e notificações geradas sempre que ocorre um evento de travessia de limiares para evitar congestionamentos do sistema de gerenciamento de rede (NMS).

A umidade limita o número de armadilhas jnxSoamPmThresholdCrossingAlarm enviadas ao NMS resumindo as ocorrências de flap por um período de tempo, conhecida como o temporizador de armadilha de retalho, e envia uma única notificação jnxSoamPmThresholdFlapAlarm para o NMS. Você pode configurar a duração do temporizar o aba para qualquer valor de 1 a 360 segundos.

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

  • Pelo menos uma aba ocorreu quando o temporizador de retalho expirou.

  • Você mudou o valor do temporizou o aba trap, o que fez com que o temporizante parasse.

Você pode habilitar o amortecimento em nível global para o iterador ou permitir o amortecimento no tipo de limiar individual do iterador. Por exemplo, para permitir 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 permitir o amortecimento em um tipo de limiar específico, para o avg-fd-twoway-threshold, use 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 desabilitar o amortecimento.

Exemplo: Configuração do Ethernet CFM em interfaces físicas

Este exemplo mostra a configuração do gerenciamento de falhas de conectividade Ethernet (CFM) em interfaces físicas.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Junos OS Versão 9.3 ou posterior.

Visão geral

O CFM pode ser usado para monitorar o enlace físico entre dois roteadores. Essa funcionalidade é semelhante à do protocolo IEEE 802.3ah LFM.

No Junos OS Release 9.3 e posterior, o CFM também oferece suporte a interfaces Ethernet agregadas. Em interfaces configuradas em Concentradores modulares de portas (MPCs) e placas de interface modular (MICs) em roteadores da Série MX, o CFM não tem suporte em links agregados não registrados de membros da Ethernet. MPCs e MICs oferecem suporte ao CFM em interfaces lógicas Ethernet agregadas e não registradas.

Nota:

As configurações neste 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 link Gigabit Ethernet ponto a ponto. A ligação entre esses dois roteadores é monitorada usando CFM. Isso é mostrado em Figura 5. O limite único é um "down mep" na terminologia CFM.

Figura 5: Ethernet CFM em interfaces físicasEthernet CFM em interfaces físicas

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

Configuração rápida de CLI

Roteador 1

Configure a interface e o CFM:

A configuração no Roteador 2 espelha a do 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 listados no CLI Explorer.

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

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

Nota:

As configurações neste 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 a ligação entre PE1 e PE2 e nível 5 de uma porta voltada para CE para a outra. O cliente está usando CFM nível 7. Os limites são marcados com terminologia CFM "up mep" e "down mep" na figura.

Figura 6: Ethernet CFM sobre uma rede de ponteEthernet CFM sobre uma rede de ponte

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

CFM em L2-CE1

CFM em L2-CE2

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

CFM no PE1

CFM sobre PE2

Exemplo: Configuração de Ethernet CFM por VPLS

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

Nota:

As configurações neste 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 CFM "up mep" e "down mep" na figura.

Figura 7: OAM Ethernet com VPLSOAM Ethernet 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 do VLAN é necessária para alternar os pacotes corretamente entre essas interfaces. A normalização oferece suporte ao mapeamento automático de VLANs e realiza operações em tags VLAN para alcançar a tradução desejada. Veja a configuração de um VLAN normalizado para tradução ou marcação de marcação.

Nota:

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

  • Caminho de recebimento de pacotes:

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

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

  • Caminho de transmissão de pacotes:

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

    • Para mePs para baixo, os pacotes são transmitidos na interface na qual o MEP está configurado.

    • Nos roteadores da série MX, para aumentar os MEPs, os pacotes devem ser inundados para outras interfaces na instância de roteamento VPLS. O roteador cria uma rota de inundação ligada a uma inundação próxima hop (com todas as interfaces para inundação) e, em seguida, obtemos os pacotes a serem encaminhados com esta rota de inundação.

A seguir, as configurações do VPLS e do CFM nos roteadores de provedores de serviços.

Configuração do PE1

Configuração do PE2

Configuração do roteador P

Apenas MPLS, nenhum CFM precisava:

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íncronos do perfil de ação do CFM

SUMMARY 

A notificação assíncronos orientada pelo CFM permite a sincronização do status do enlace entre dois dispositivos CE

conectados uns aos outros por meio de um pseudo fio originário de seus respectivos dispositivos PE. Ele emula

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

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

Conectividade de camada 2 entre PE1 e PE2

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

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

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

  • Quando a ligação entre PE2 e CE2 cai, a ligação entre PE1 e CE1 também diminuiu.

    Quando o enlace for restaurar, ele deve restaurar o status do enlace PE1 para CE1 também. A mudança de status do enlace entre

    PE1 a CE1 deve funcionar da mesma maneira.

    • Quando há um problema de conectividade entre PE1 e PE2, ele aciona uma ligação entre PE1 e CE1

      e PE2 a CE2. Se o status de conexão for restaurar, 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 do lançamento do 17.1, o gerenciamento de falhas de conectividade (CFM) do Junos OS, durante uma atualização unificada de software em serviço (ISSU), funciona quando o dispositivo peer não é um roteador da Juniper Networks.
15.1
A partir do Junos OS Release 15.1, a configuração de ISSU com CFM (802.1ag) é suportada apenas em roteadores MX e PTX que oferecem suporte a TLV.
12.3
Começando com o Junos OS Release 12.3, para todas as interfaces configuradas em Concentradores modulares de portas (MPCs) em plataformas de roteamento universal 5G da Série MX, você não precisa mais configurar a no-control-word declaração para todas as VPNs de Camada 2 e circuitos de Camada 2 sobre os quais você está executando MEPs CFM.
12.3
Começando com o Junos OS Release 12.3, para todas as interfaces configuradas em Concentradores modulares de portas (MPCs) em plataformas de roteamento universal 5G da Série MX, você não precisa mais configurar a no-control-word declaração para todas as VPNs de Camada 2 e circuitos de Camada 2 sobre os quais você está executando MEPs CFM.
12.3
Começando com o Junos OS Release 12.3, para todas as interfaces configuradas em Concentradores modulares de portas (MPCs) em plataformas de roteamento universal 5G da Série MX, você não precisa mais configurar a no-control-word declaração para todas as VPNs de Camada 2 e circuitos de Camada 2 sobre os quais você está executando MEPs CFM.