Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Monitoramento de CFM entre dispositivos CE e PE

Use este tópico para entender mais sobre o monitoramento de CFM entre dispositivos de borda do provedor e dispositivos de borda do cliente quando o dispositivo de borda do cliente não é um Juniper de segurança. Além disso, você pode entender mais sobre como TLVs de status da interface, TLVs de status de porta, ID TLV de chassi e proteção de conexão TLV ajudam no monitoramento da sua rede.

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 dispositivos CE conectados entre si por meio de um pseudo fio originado de seus respectivos dispositivos PE, ele emula o cenário como se dois dispositivos CE estivesse conectados diretamente. O CFM fornece sinalização de ponta a ponta, mesmo que PE1 e PE2 não sejam conectados por uma única rede, mas 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 a 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. A mudança de status do enlace entre PE1 e CE1 deve funcionar da mesma forma.

  • Quando há um problema de conectividade entre PE1 e PE2, ele aciona um enlace entre PE1 a CE1 e PE2 a CE2. Se o status da conexão for restabelecido, ele deve restaurar o status do enlace em ambas as extremidades

Configuring a CFM Action Profile to Asyncronus Notification

SUMMARY CFM UP-MEP on PE1 to PE2, monitors the connectivity between PE1 to PE2. Use of interface-status-tlv on these UP-MEP end points conveys the link status between PE1 to CE1 to PE2 and link-status between PE2 to CE2 to PE1. Action profile must be configured on PE1 to PE2 to drive asynchronous-notification towards respective CE devices . It is triggered when either adjacency-loss is detected or link-down is detected in the received interface-status-tlv.

  1. Enable asynchronous-notification at interface level

    For example

  2. Configure the action profile and the CFM event(s) to triggered this action profile at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level. You can configure more than one event in the action profile

    For example

    The action asynchronous-notification is not supported with events other than interface-status-tlv down, interface-status-tlv lower-layer-down and adjacency-loss. Any other events configured results in a commit error

    .
  3. Define the action to asynchronous-notification at the [edit protocols oam ethernet connectivity-fault-management action-profile profile-name] hierarchy level.
  4. Define the maintenance domain at the [edit protocols oam ethernet connectivity-fault-management] hierarchy level and specify the maintenance-association parameters

    For example

  5. Configure the generation of interface-status-tlv .it is required if asynchronous-notification configured based on interface-status-tlv.

    For example

  6. Define the maintenance association endpoint at the [edit protocols oam ethernet connectivity-fault-management maintenance-domain md-name maintenance-association ma-name] hierarchy level and specify the associated parameters.

    For example

  7. Set asynchronous-notification action profile at the RMEP level.

    For example,

Entender o monitoramento de CFM entre dispositivos CE e PE

Você pode habilitar o monitoramento de falhas de conectividade (CFM) entre dispositivos de borda do provedor e dispositivos de borda do cliente quando o dispositivo de borda do cliente não é um Juniper de segurança. Quando a interface está inovada, o CFM propaga o status da interface nas mensagens CC. A mensagem CC informa ao dispositivo de borda do cliente que o dispositivo de borda do provedor está ino mesmo.

Você pode configurar o monitoramento de CFM usando uma das duas opções a seguir:

  • Status da interface TLV (Tipo, comprimento e valor)— Você pode habilitar o monitoramento do gerenciamento de falhas de conectividade (CFM) entre dispositivos de borda do provedor e dispositivos de borda do cliente quando o dispositivo de borda do cliente não é um dispositivo Juniper usando o Status da Interface TLV. Quando a interface está inovada, o CFM propaga o status da interface usando o status da interface TLV. O status da interface TLV indica o status da interface na qual o MEP transmite o CCM ou a interface mais próxima inferior no IETF RFC 2863 IF-MIB. Assim, o dispositivo de borda do cliente sabe que o dispositivo de borda do provedor está ino mesmo. Para configurar o monitoramento de CFM usando o Status da Interface TLV, use interface-status-tlv a instrução em [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check nível de hierarquia. Essa é a opção padrão.

  • RDI (Indicação de defeito remoto)— A partir da versão do Junos OS 17.3R1, você pode habilitar o monitoramento de falhas de conectividade (CFM) entre dispositivos de borda do provedor e dispositivos de borda do cliente quando o dispositivo de borda do cliente não é um dispositivo Juniper usando o bit de indicação de defeito remoto (RDI). Ao habilitar o monitoramento de CFM, o CFM propaga o status do dispositivo de borda do provedor por meio do bit de indicação de defeito remoto (RDI) nas mensagens CC. Assim, o dispositivo de borda do cliente sabe que o dispositivo de borda do provedor está ino mesmo. O bit RDI é limpo quando o serviço está de volta. Para configurar o monitoramento de CFM usando o bit RDI, use a interface-status-send-rdi instrução em [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-check nível de hierarquia. Essa opção é necessária se o dispositivo de borda do cliente não tiver suporte ao status da interface TLV.

Nota:

Quando a interface for definida como CCC e você tiver configurado RDI, o bit RDI será enviado. O CFM não monitora o status da interface. Se o CCC for definido quando a interface não estiver em espera, o bit de RDI será enviado com as mensagens CC caso tenha configurado RDI.

Caso de uso ativo multi-homing único usando bit de RDI

Considere a topologia a seguir, onde existem dois dispositivos de borda do provedor (PE1 e PE2) e dois dispositivos de borda do cliente (CE1 e CE2). PE1 está em estado ativo, enquanto PE2 está em estado de espera. O CFM down MEP está configurado entre PE e CE. O CFM detecta que o CCC foi baixado e, como o CFM down MEP está configurado, as mensagens CC geradas têm o bit RDI. As mensagens CC de PE2 a CE2 têm o bit RDI definido para indicar o estado bloqueado. Quando o PE2 torna-se ativo, o CCM é inocedido e o bit RDI é liberado das mensagens CC posteriores.

Caso de uso ativo/ativo do multihoming usando bit RDI

Considere a topologia onde existem dois dispositivos de borda do provedor (PE1 e PE2) e dois dispositivos de borda do cliente (CE1 e CE2). PE1 está em estado ativo, enquanto PE2 está em estado de espera. Se o CFM down MEP não estiver configurado entre PE e CE para monitorar a conectividade do enlace, as mensagens CC geradas não terão o bit RDI. O CFM down MEP está configurado entre PE e CE. O CFM detecta que o CCC foi baixado e, como o CFM down MEP está configurado, as mensagens CC geradas têm o bit RDI. As mensagens CC de PE2 a CE2 têm o bit RDI definido para indicar o estado bloqueado. Quando o PE2 torna-se ativo, o CCM é inocedido e o bit RDI é liberado das mensagens CC posteriores.

Configurando o status da porta TLV e o status da interface TLV

Visão geral dos TLVs

Tipo, comprimento e valor (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/ou opcional em uma PDU. Os TLVs não estão alinhados a nenhuma palavra ou limite de octeto específico. As TLVs se seguem sem nenhum preenchimento entre eles.

Tabela 1 mostra o formato TLV e indica se ele é obrigatório ou opcional.

Tabela 1: Formato de TLVs

Parâmetro

Octeto (sequência)

Descrição

Tipo

1

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.

Comprimento

2–3

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.

Valor

4

Comprimento especificado pelo campo Comprimento. Opcional. Não estará presente se o campo Tipo for 0 ou se o campo Comprimento for 0.

Vários TLVs para PDUs de CFM

Tabela 2 mostra um conjunto de TLVs definidas por IEEE 802.1ag para vários tipos de PDU CFM. Cada TLV pode ser identificado pelo valor exclusivo atribuído a seu campo de tipo. Alguns valores de campo de tipo são reservados.

Tabela 2: Valores de campo tipo para vários TLVs para PDUs CFM

TLV ou Organização

Campo de tipo

TLV final

0

ID TLV remetente

1

Status da porta TLV

2

TLV de dados

3

Interface Status TLV

4

Responder TLV de entrada

5

Responder Egress TLV

6

LTM Egress Identifier TLV

7

LTR Egress Identifier TLV

8

Reservado para IEEE 802.1

De 9 a 30 anos

TLV específico da organização

31

Definida por ITU-T Y.1731

De 32 a 63 anos

Reservado para IEEE 802.1

De 64 a 255 anos

Nem todos os TLV são aplicáveis a todos os tipos de PDUs de CFM.

  • TLVs aplicáveis à mensagem de verificação de continuidade (CCM):

    • TLV final

    • ID TLV remetente

    • Status da porta TLV

    • Interface Status TLV

    • TLV específico da organização

  • TLVs aplicáveis à mensagem de loopback (LBM):

    • TLV final

    • ID TLV remetente

    • TLV de dados

    • TLV específico da organização

  • TLVs aplicáveis para resposta de loopback (LBR):

    • TLV final

    • ID TLV remetente

    • TLV de dados

    • TLV específico da organização

  • TLVs aplicáveis à mensagem de linktrace (LTM):

    • TLV final

    • LTM Egress Identifier TLV

    • ID TLV remetente

    • TLV específico da organização

  • TLVs aplicáveis à resposta do linktrace (LTR):

    • TLV final

    • LTR Egress Identifier TLV

    • Responder TLV de entrada

    • Responder Egress TLV

    • ID TLV remetente

    • TLV específico da organização

No momento, os seguintes TLVs são suportados nas PDUs CFM aplicáveis:

  • TLV final

  • Responder TLV de entrada

  • Responder Egress TLV

  • LTR Egress Identifier TLV

  • LTM Egress Identifier TLV

  • TLV de dados

Suporte para TLVs opcionais adicionais

Os seguintes TLVs opcionais adicionais são suportados:

  • Status da porta TLV

  • Interface Status TLV

Os roteadores da série MX são de suporte à configuração do status da porta TLV e do status da interface TLV. Configurar o status da porta TLV permite ao operador controlar a transmissão do TLV do status da porta em PDUs CFM.

Nota:

Embora as declarações de configuração do status de porta TLV sejam visíveis na CLI nos M120 e M320 roteadores, o Status da Porta TLV não pode ser configurado nesses sistemas. O status da porta TLV só pode ser ativado em uma interface MEP se for uma interface lógica de ponte, o que não é possível nesses sistemas.

Para informações de configuração, consulte as seções a seguir:

Status da porta TLV

O status da porta TLV indica a capacidade da porta de ponte na qual o MEP transmissor reside para transmitir dados comuns, independentemente do status do MAC. O valor deste TLV é orientado pela variável enableRmepDefect MEP, conforme mostrado em Tabela 4 . O formato deste TLV é mostrado em Tabela 3 .

Qualquer alteração no valor de TLVs de status da porta aciona uma transmissão extra dessa ponte portas MEP CCMs.

Tabela 3: Formato TLV de status da porta

Parâmetro

Octeto (sequência)

Tipo = 2

1

Comprimento

2–3

Valor Tabela 4 (Ver)

4

Tabela 4: Valores de TLV do status da porta

Mnemônico

Dados comuns que passam livremente pela porta

Valor

psBlocked

Não: enableRmepDefect = falsa

1

psUp

Sim: enableRmepDefect = verdadeiro

2

A variável MEP é uma variável meleca que indica se os quadros na instância de serviço são monitorados pelas associações de manutenção caso esse MEP seja capacitado a passar por essa porta de ponte pelo protocolo da árvore de abrangia e pelo gerenciamento de enableRmepDefect topologia de VLAN. Ele está definido como VERDADEIRO se:

  • A porta da ponte é definida em um estado onde o tráfego pode passar por ela.

  • A porta da ponte está executando várias instâncias da árvore de abrangibilidade.

  • A interface MEP não está associada a um domínio de conexão.

Configurando o status da porta TLV

O Junos OS fornece suporte de configuração para o TLV de status da porta, permitindo que você controle a transmissão deste TLV em PDUs CCM. O Junos OS fornece essa configuração em nível de verificação de continuidade. Por padrão, o CCM não inclui o status da porta TLV. Para configurar o status da porta TLV, use a port-status-tlv instrução em [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] nível de hierarquia.

Nota:

A configuração de TLV de status de porta não é IEEE 802.1ag. O Junos OS fornece isso para dar mais flexibilidade ao operador; no entanto, ele recebe e processa CCMs com um TLV de status de porta, independentemente dessa configuração.

Um exemplo das declarações de configuração segue:

Não é possível habilitar a transmissão do TLV do status da porta nos dois casos a seguir:

  • Se a interface MEP da associação de manutenção não for do tipo bridge.

  • Se o MEP estiver configurado em uma interface física.

Exibindo o status da porta recebida TLV

O Junos OS economiza o último TLV de status de porta recebido de um MEP remoto. Se o valor do status da porta recebida não corresponder a um dos valores padrão indicados, o comando Tabela 4show o exibirá como "desconhecido". Você pode exibir o último TLV de status de porta salvo 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:

Exibindo o status da porta transmitida TLV

O Junos OS economiza o último TLV do status da porta transmitida de um MEP local. Caso a transmissão do TLV do status da porta não tenha sido ativada, o show comando exibirá "nenhum". Você pode exibir o último TLV de status da porta transmitida salvo 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:

Interface Status TLV

O status da interface TLV indica o status da interface na qual o MEP transmite o CCM ou a interface mais próxima inferior no IETF RFC 2863 IF-MIB. O formato deste TLV é mostrado em Tabela 5 . Os valores enumerados são mostrados em Tabela 6 .

Tabela 5: Formato TLV de status da interface

Parâmetro

Octeto (sequência)

Tipo = 4

1

Comprimento

2–3

Valor Tabela 6 (Ver)

4

Tabela 6: Valores de TLV do status da interface

Mnemônico

Interface Status

Valor

Isup

up

1

isDown

para baixo

2

isTestando

Teste

3

Isunknown

Desconhecido

4

isDormant

Dormente

5

isNotPresent

nãoPresente

6

isLowerLayerDown

lowerLayerDown

7

Nota:

Quando o status operacional de uma interface lógica muda do estado de down (valor de status de 2) para o estado da camada inferior (valor de status de 7) e vice-versa, a armadilha SNMP do LinkDown não é gerada. Por exemplo, se você configurar um pacote de interface Ethernet agregado com uma etiqueta VLAN e adicionar uma interface física que está operacionalmente no estado inferior ao pacote, o status operacional do pacote de interface lógica Ethernet agregado nesse ponto é a camada inferior (7). Se você tirar o MIC associado à interface offline, a armadilha LinkDown não será gerada quando a interface lógica muda da camada inferior para o estado inferior.

Da mesma forma, considere outro cenário amostral no qual uma interface física é adicionada a um pacote Ethernet agregado que tem tags VLAN e a interface lógica Ethernet agregada está desabilitada. Quando a interface lógica é desabilitada, o status operacional da interface lógica muda para baixo. Caso você desative a interface física que faz parte do pacote ethernet agregado, o status operacional da interface lógica de Ethernet agregada permanece inogressado. Se você reenvelar a interface lógica de Ethernet agregada, o status operacional dela muda de uma camada inferior para outra. A armadilha de SNMP do LinkDown não é gerada neste ponto.

Configurando o status da interface TLV

O Junos OS fornece suporte de configuração para o TLV de status da interface, permitindo que os operadores controlem a transmissão deste TLV em PDUs CCM por meio da configuração em nível de verificação de continuidade.

Nota:

Essa configuração não é ordenada pelo IEEE 802.1ag; em vez disso, é fornecido para dar mais flexibilidade ao operador. O Junos OS recebe e processa CCMs com o Status da Interface TLV, independentemente dessa configuração.

A configuração de TLV do status da interface é mostrada abaixo:

Nota:

O Junos OS tem suporte para a transmissão de apenas três de sete valores possíveis para o Status da Interface TLV. Os valores suportados são 1, 2 e 7. No entanto, o Junos OS é capaz de receber qualquer valor para o Status da Interface TLV.

Exibindo o status da interface recebida TLV

O Junos OS economiza o último TLV de status da interface recebido do MEP remoto. Se o valor do status da interface recebida não corresponder a um dos valores padrão indicados, o comando Tabela 5show exibirá "desconhecido".

Você pode exibir este último TLV de status da interface salvo 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:

Exibindo o status da interface transmitida TLV

O Junos OS economiza o último TLV de status da interface transmitida de um MEP local. Se a transmissão do status da interface TLV não tiver sido ativada, o show comando exibirá "nenhum".

Você pode exibir o último TLV de status da interface transmitida 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 exemplo a seguir:

Defeitos de status mac

O Junos OS fornece informações de defeito de status MAC, indicando que um ou mais dos MEPs remotos relataram uma falha em seu status de porta TLV ou TLV do status da interface. Ele indica "sim" se algum MEP remoto relatar que sua interface não é isUp (por exemplo, pelo menos uma interface de MEPs remota está indisponível) ou se todos os MEPs remotos relatarem um TLV de status de porta que contenha algum valor diferente do psUp (por exemplo, todas as portas de ponte mePs remotas não estão encaminhando dados). Existem dois comandos show que podem ser usado para exibir a indicação de defeitos de status do MAC.

Use o mep-database comando para exibir defeitos de status do MAC:

Use o interfaces comando para exibir defeitos de status do MAC:

Configuração do suporte ao perfil de ação MEP remoto

Com base nos valores interface-status-tlv dos pacotes CCM recebidos, uma ação específica, como, pode ser port-status-tlv realizada usando as interface-downaction-profile opções. Vários perfis de ação podem ser configurados no roteador, mas apenas um perfil de ação pode ser atribuído a um MEP remoto.

O perfil de ação pode ser configurado com pelo menos um evento para acionar a ação; mas a ação será acionada caso algum desses eventos ocorra. Não é necessário que todos os eventos configurados ocorram para action acionar.

Um perfil de ação só pode ser aplicado em nível de MEP remoto.

O exemplo a seguir mostra uma configuração de perfil de ação com comentários explicativos adicionados:

Monitoramento de um perfil de ação MEP remoto

Você pode usar o comando para exibir o status do perfil de ação de um show oam ethernet connectivity-fault-management mep-database MEP remoto, como no exemplo a seguir:

mostrar conectividade oam ethernet-fault-management mep-database remote-mep (Action Profile Event)

Configuração de ID TLV de chassi

Na versão 16.1R2 e posteriormente, você pode configurar o Junos OS para enviar o ID TLV do remetente junto com os pacotes. O ID TLV do remetente é um TLV opcional que é enviado em mensagens de verificação de continuidade (CCMs), mensagens de loopback e mensagens de rastreamento de enlace (LTMs), conforme especificado no padrão IEEE 802.1ag. O ID TLV de remetente contém a ID de chassi, que é o endereço MAC exclusivo, baseado em CFM do dispositivo, e o endereço IP de gerenciamento, que é um endereço IPv4 ou IPv6.

O valor do campo no TLV indica se o TLV contém ou não as informações de length ID do chassi. Os valores possíveis para o campo são zero () ou qualquer número válido, o que indica a ausência ou presença de informações de ID de chassi no length0 TLV, respectivamente.

Você pode permitir que o Junos OS envie o ID TLV do remetente em nível global usando o set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv comando. Se o ID TLV do remetente estiver configurado em nível global, o domínio de manutenção padrão, a associação de manutenção e a metade da função do ponto intermediário da associação de manutenção (MIP) herdam essa configuração.

Você também pode configurar o ID TLV do remetente nos seguintes níveis de hierarquia:

  • [edit protocols oam ethernet connectivity-fault-management].

  • [edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domain-name maintenance-association maintenance-association-name continuity-check].

A configuração de ID TLV do remetente em nível de associação de manutenção tem precedência sobre a configuração global.

Nota:

O ID TLV remetente é suportado apenas para PDUs 802.1ag e não é suportado para unidades de dados de protocolo de monitoramento de desempenho (PDUs).

Configurando o processamento de mensagens de descarga MAC no modo CET

No modo transporte ethernet de operadora (CET), os roteadores da Série MX são usados como roteadores de borda do provedor (PE) e o Nokia Siemens Networks A2200 Carrier Switches de ethernet (chamados de dispositivos de domínio E) que executarem protocolos baseados em padrão são usados no lado de acesso. Nos roteadores da Série MX, os pseudowires VPLS são configurados dinamicamente por meio do protocolo de distribuição de rótulos (LDP). Nos dispositivos de domínio E, as alterações de topologia são detectadas por meio de sessões de gerenciamento de falhas de conectividade (CFM) em execução entre os dispositivos de domínio E e os roteadores PE da Série MX. Os roteadores PE da Série MX podem derrubar a interface Ethernet da operadora caso haja perda de conectividade CFM. Isso aciona um descarga MAC local, bem como uma notificação de descarga MAC de protocolo de distribuição de rótulos (T-LDP) direcionada que é enviada em direção aos PEs remotos da Série MX para acioná-los.

No modo interoperável CET, os roteadores da Série MX precisam operar com os dispositivos de acesso Ethernet da Operadora Ax100 da Nokia Siemens Networks (chamados de dispositivos de domínio A) que executem protocolos legados. Os dispositivos Nokia Siemens Networks A4100 e A8100 atuam como um intermediário entre os roteadores PE da Série MX e os dispositivos de domínio A. Esses dispositivos intermediários realizam procedimentos de função de intertrabalhamento (IWF) para que sessões de gerenciamento de administração de operações (OAM) possam ser executados entre roteadores da Série MX e dispositivos de domínio A. Não há pseudowires VPLS entre os roteadores PE da Série MX e os dispositivos intermediários Nokia Siemens Networks A4100 e A8100, portanto, não há protocolo LDP em execução entre os roteadores PE para enviar notificações de alteração de topologia. Para comunicar mudanças de topologia, os roteadores da Série MX podem acionar um flush MAC e propaga-lo no núcleo. Os roteadores da Série MX podem usar perfis de ação com base no evento TLV (Connection Protection Type Length Value, Valor do comprimento do tipo de proteção da conexão). O perfil de ação revela a interface lógica da borda da operadora nos roteadores PE da Série MX, que acionará um descarga mac local e também propagará a mudança de topologia para o núcleo usando a notificação de LDP.

Para VPLS, não existe monitoramento de conectividade de ponta a ponta. Os anéis de acesso são monitorados independentemente executando CFM em vários pontos de extremidade (MEPs) nos caminhos de trabalho e proteção para cada um dos serviços entre os dispositivos de domínio E e os roteadores PE da Série MX, e entre os dispositivos de domínio A e os roteadores PE da Série MX o IWF hospedado pelos dispositivos Nokia Siemens Networks A-4100. Quando há uma falha de conectividade no caminho de trabalho, os dispositivos Ax200 da Nokia Siemens Networks realizam uma comover até o caminho de proteção, acionando uma notificação de mudança de topologia (na forma de TLVs carregados em CCM) a ser enviada no caminho ativo.

Figura 1: Topologia dual homed inter-op CETTopologia dual homed inter-op CET

Figura 1 descreve a topologia dual homed nos roteadores PE da Série MX conectados ao domínio A. Quando um dispositivo de domínio A aciona uma comover, ele começa a comover o tráfego de serviço para o novo caminho ativo. Essa mudança é comunicada nas PDUs (Protocol Data Units, unidades de dados do protocolo HELLO) enviadas por esse dispositivo de domínio A nos caminhos de trabalho e proteção. Quando o IWF no A4100 recie essas PDUs HELLO, ela as converte em mensagens CCM padrão e também introduz uma proteção de conexão TLV. O campo "Proteção em uso" da proteção de conexão TLV é codificado com o caminho ativo atualmente e está incluído na mensagem CCM. As mensagens CCM são recebidas pelos roteadores PE da Série MX por meio do VLAN spoke em A4100. No cenário homed duplo acima, um roteador PE da Série MX monitora o caminho de trabalho, e o outro roteador PE da série MX monitora o caminho de proteção.

Ocorre uma descarga MAC quando a sessão do CFM que monitora o caminho de trabalho detecta que o tráfego de serviço mudou para o caminho de proteção ou quando a sessão de CFM que monitora o caminho de proteção detecta que o tráfego de serviço foi transferido para o caminho de trabalho.

Figura 2: Topologia dual attached CET inter-opTopologia dual attached CET inter-op

Figura 2 descreve a topologia dupla conectada em roteadores PE da Série MX conectados ao domínio A. O mecanismo de descarga MAC usado neste caso também é o mesmo usado para o domínio A no cenário homed duplo (Figura 1). Entretanto, neste caso, ambas as sessões de CFM são hospedadas por apenas um roteador PE da Série MX. Quando o Ax100 no domínio A detecta alterações na topologia, o roteador PE da Série MX recebe a proteção de conexão TLV na mensagem CCM para os caminhos de trabalho e proteção com o valor de "Proteção em uso" indicando qual caminho é o ativo. Com base no evento gerado para a sessão de CFM, o roteador PE da Série MX derrubará a interface adequada que ativará um descarga de MAC local.

Configurando um perfil de ação de TLV de proteção de conexão

Um perfil de ação pode ser configurado para realizar a ação com base nos valores dos interface-downconnection-protection-tlv pacotes CCM recebidos.

O exemplo a seguir mostra uma configuração de perfil de ação com comentários explicativos adicionados:

Exemplo: Configurando um perfil de ação com base em TLVs de proteção de conexão

Este exemplo mostra como configurar um perfil de ação com base na proteção de conexão TLV com a finalidade de acionar descargas MAC com base em alterações de topologia em uma rede CET.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Junos OS Release 11.2 ou mais tarde

  • Roteador PE da série MX

Visão geral e topologia

A topologia física de uma rede CET que usa roteadores PE da série MX é mostrada em Figura 3

Topologia

Figura 3: Topologia da rede CETTopologia da rede CET

As definições a seguir descreverão o significado da abreviação do dispositivo e os termos usados em Figura 3 .

  • Dispositivo de borda do provedor (PE) — Um dispositivo ou um conjunto de dispositivos, na borda da rede do provedor que apresenta a visão do provedor do site do cliente.

  • Domínio E — a Nokia Siemens Networks Carrier Switches de ethernet que executar protocolos baseados em padrões e são usadas no lado de acesso.

  • Domínio A — Operadora de redes Nokia Siemens Switches de ethernet que executar protocolos legados.

Configuração

Procedimento

Procedimento passo a passo

Para configurar um perfil de ação com base na proteção da conexão TLV, pré-forme essas tarefas:

  1. Configurar um perfil de ação

  2. Se a proteção de conexão TLV for recebida com um valor "Proteção em uso" do SET, o TLV de proteção da conexão deve usar o caminho de proteção

  3. Se a proteção de conexão TLV for recebida com um valor de "proteção em uso" do RESET, a proteção de conexão TLV deve usar o caminho de trabalho

  4. Configure o perfil de ação para derrubar a interface

Resultados

Veja os resultados da configuração

Tabela de histórico de liberação
Versão
Descrição
17.3R1
A partir do Junos OS Release 17.3R1, você pode habilitar o monitoramento de falha de conectividade (CFM) entre dispositivos de borda do provedor e dispositivos de borda do cliente quando o dispositivo de borda do cliente não é um dispositivo Juniper usando o bit de indicação de defeito remoto (RDI).
16.1
Na versão 16.1R2 e posteriormente, você pode configurar o Junos OS para enviar o ID TLV do remetente junto com os pacotes.