Monitoramento do CFM entre dispositivos CE e PE
Use este tópico para entender mais sobre o monitoramento do CFM entre dispositivos de borda de provedores e dispositivos de borda do cliente quando o dispositivo de borda do cliente não é um dispositivo Juniper. Além disso, você pode entender mais sobre como as TLVs de status da interface, TLVs de status da porta, chassi ID TLV e proteção de conexão TLV ajudam no monitoramento de sua rede.
Notificação assíncronos do perfil de ação do CFM
A notificação assíncrona orientada pelo CFM permite a sincronização do status do enlace entre dois dispositivos CE conectados entre si por meio de um pseudo fio originário de seus respectivos dispositivos PE Ele emulao cenário como se dois dispositivos CE fossem conectados diretamente. O CFM fornece sinalização de ponta a ponta, mesmo que PE1 e PE2 não estejam conectados por meio de uma única rede, mas de 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íncrono 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íncronos.
-
Quando a ligação entre PE2 e CE2 cai, a ligação entre PE1 e CE1 também diminuiu. Quando o link for restaurar, ele deve restaurar o status do enlace PE1 para CE1 também. A mudança de status do enlace entre PE1 e CE1 deve funcionar da maneira semelhante.
-
Quando há um problema de conectividade entre PE1 e PE2, ele desencadeia uma ligação entre PE1 a CE1 e PE2 a CE2. Se o status da conexão for restaurar, ele deve restaurar o status do enlace em ambas as extremidades
Consulte também
Configuração de um perfil de ação do CFM para notificação de assíncrono
O UP-MEP do CFM em PE1 a PE2 monitora a conectividade entre PE1 e PE2. interface-status-tlv O uso desses pontos finais UP-MEP transmite o status da ligação entre PE1 a CE1 a PE2 e o status de enlace entre PE2 e CE2 a PE1. O perfil de ação deve ser configurado em PE1 a PE2 para conduzir a notificação assíncrono em direção aos respectivos dispositivos CE. Ele é acionado quando adjacência-perda é detectada ou a conexão para baixo é detectada no recebido interface-status-tlv.
Consulte também
Entenda o monitoramento do CFM entre dispositivos CE e PE
Você pode permitir o monitoramento de falhas de conectividade (CFM) entre dispositivos de borda de provedores e dispositivos de borda do cliente quando o dispositivo de borda do cliente não é um dispositivo Juniper. Quando a interface está baixa, 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á desativado.
Você pode configurar o monitoramento do CFM usando qualquer uma das duas opções a seguir:
Status da interface TLV (Tipo, comprimento e valor) — Você pode permitir 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 TLV da interface. Quando a interface está baixa, o CFM propaga o status da interface usando o status da interface TLV. O TLV de status de interface indica o status da interface na qual o MEP transmitindo o CCM está configurado, ou a interface mais baixa no IETF RFC 2863 IF-MIB. Assim, o dispositivo de borda do cliente está ciente de que o dispositivo de borda do provedor está desativado. Para configurar o monitoramento do CFM usando o Status TLV da interface, use a
interface-status-tlvdeclaração no nível de[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkhierarquia. Esta é a opção padrão.RDI (Indicação de defeito remoto)— A partir do Junos OS Release 17.3R1, você pode permitir 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 a indicação remota de defeito (RDI). Quando você habilita o monitoramento do CFM, o CFM propaga o status do dispositivo de borda do provedor por meio da indicação remota de defeito (RDI) nas mensagens CC. Assim, o dispositivo de borda do cliente está ciente de que o dispositivo de borda do provedor está desativado. A bit de RDI é liberada quando o serviço está de volta. Para configurar o monitoramento do CFM usando o bit RDI, use a
interface-status-send-rdideclaração no nível de[edit protocols oam ethernet connectivity-fault-management maintenance-domain maintenance-domainmaintenance-association maintenance-association continuity-checkhierarquia. Essa opção é necessária se o dispositivo de borda do cliente não oferece suporte ao Status TLV da interface.
Quando a interface é definida para ccc para baixo e você configurou RDI, então o bit RDI é enviado. O CFM não monitora o status da interface. Se o CCC estiver desativado quando a interface não estiver em espera, o bit RDI será enviado com as mensagens CC se você tiver configurado o RDI.
- Caso de uso multi homing ativo único usando bit RDI
- Caso de uso de multihoming ativo/ativo usando bit RDI
Caso de uso multi homing ativo único usando bit RDI
Considere a topologia a seguir onde existem dois dispositivos de borda de provedor (PE1 e PE2), bem como dois dispositivos de borda do cliente (CE1 e CE2). O PE1 está em estado ativo, enquanto o PE2 está em estado de espera. O MEP para baixo do CFM está configurado entre o PE e o CE. O CFM detecta que o CCC está desativado e, como o CFM para baixo MEP está configurado, as mensagens CC geradas têm o bit RDI. As mensagens CC de PE2 para CE2 têm o bit RDI definido para indicar o estado bloqueado. Quando o PE2 se torna ativo, o CCM é liberado e a bit de RDI é liberada das mensagens CC subseqüentes.
Caso de uso de multihoming ativo/ativo usando bit RDI
Considere a topologia em que existem dois dispositivos de borda de provedor (PE1 e PE2) e dois dispositivos de borda do cliente (CE1 e CE2). O PE1 está em estado ativo, enquanto o PE2 está em estado de espera. Se o MEP desativado pelo CFM não estiver configurado entre o PE e o CE para monitorar a conectividade do link, as mensagens CC geradas não terão o bit RDI. O MEP para baixo do CFM está configurado entre o PE e o CE. O CFM detecta que o CCC está desativado e, como o CFM para baixo MEP está configurado, as mensagens CC geradas têm o bit RDI. As mensagens CC de PE2 para CE2 têm o bit RDI definido para indicar o estado bloqueado. Quando o PE2 se torna ativo, o CCM é liberado e a bit de RDI é liberada das mensagens CC subseqüentes.
Consulte também
Configurando o status da porta TLV e o status da interface TLV
- Visão geral das TLVs
- Várias TLVs para PDUs do CFM
- Suporte para TLVs opcionais adicionais
- Defeitos de status MAC
- Configuração do suporte ao perfil de ação remoto de MEP
- Monitoramento de um perfil remoto de ação de mep
Visão geral das 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 comprimento variável e/ou informações opcionais em uma PDU. As TLVs não estão alinhadas a nenhuma palavra em particular ou limite de octet. As TLVs se seguem sem padding entre elas.
Tabela 1 mostra o formato TLV e indica se é necessário ou opcional.
Parâmetro |
Octet (sequência) |
Descrição |
|---|---|---|
Tipo |
1 |
Necessário. Se 0, não seguirão os campos de comprimento ou valor. Se não 0, pelo menos o campo Comprimento segue o campo Tipo. |
Comprimento |
2–3 |
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 octets, do campo Value. 0 no campo comprimento indica que não há campo de valor. |
Value |
4 |
Comprimento especificado pelo campo Comprimento. Opcional. Não está presente se o campo tipo é 0 ou se o campo de comprimento é 0. |
Várias TLVs para PDUs do CFM
Tabela 2 mostra um conjunto de TLVs definidas pelo IEEE 802.1ag para vários tipos de PDU cfm. Cada TLV pode ser identificado pelo valor único atribuído ao seu campo tipo. Alguns tipos de valores de campo são reservados.
TLV ou organização |
Tipo de campo |
|---|---|
TLV final |
0 |
ID TLV do remetente |
1 |
TLV de status da porta |
2 |
Data TLV |
3 |
Interface Status TLV |
4 |
Responda TLV de entrada |
5 |
Responda Egress TLV |
6 |
LTM Egress Identifier TLV |
7 |
LTR Egress Identifier TLV |
8 |
Reservado para IEEE 802.1 |
9 a 30 |
TLV específico da organização |
31 |
Definido por ITU-T Y.1731 |
32 a 63 |
Reservado para IEEE 802.1 |
64 a 255 |
Nem todo TLV é aplicável a todos os tipos de PDUs CFM.
TLVs aplicáveis à mensagem de verificação de continuidade (CCM):
TLV final
ID TLV do remetente
TLV de status da porta
Interface Status TLV
TLV específico da organização
TLVs aplicáveis à mensagem de loopback (LBM):
TLV final
ID TLV do remetente
Data TLV
TLV específico da organização
TLVs aplicáveis para resposta de loopback (LBR):
TLV final
ID TLV do remetente
Data TLV
TLV específico da organização
TLVs aplicáveis à mensagem de linktrace (LTM):
TLV final
LTM Egress Identifier TLV
ID TLV do remetente
TLV específico da organização
TLVs aplicáveis para resposta de linktrace (LTR):
TLV final
LTR Egress Identifier TLV
Responda TLV de entrada
Responda Egress TLV
ID TLV do remetente
TLV específico da organização
As TLVs a seguir são atualmente apoiadas nas PDUs CFM aplicáveis:
TLV final
Responda TLV de entrada
Responda Egress TLV
LTR Egress Identifier TLV
LTM Egress Identifier TLV
Data TLV
Suporte para TLVs opcionais adicionais
As seguintes TLVs opcionais adicionais são suportadas:
TLV de status da porta
Interface Status TLV
Os roteadores da Série MX oferecem suporte à configuração do status da porta TLV e do status da interface TLV. A configuração do TLV de status de porta permite que o operador controle a transmissão do TLV de status de porta em PDUs CFM.
Embora as declarações de configuração do TLV de status de porta sejam visíveis na CLI em roteadores M120 e M320, o Status da porta TLV não pode ser configurado nesses sistemas. O TLV de status de porta só pode ser habilitado em uma interface MEP se for uma interface lógica de ponte, o que não é possível nesses sistemas.
Para obter informações sobre configuração, veja as seguintes seções:
TLV de status da porta
O TLV de status de porta indica a capacidade da porta de ponte na qual o MEP transmissor reside para passar dados comuns, independentemente do status do MAC. O valor deste TLV é orientado pela variável enableRmepDefectMEP, conforme mostrado em Tabela 4. O formato deste TLV é mostrado em Tabela 3.
Qualquer mudança no valor das TLVs de status da porta desencadeia uma transmissão extra das portas mep CCMs da ponte.
Parâmetro |
Octet (sequência) |
|---|---|
Tipo = 2 |
1 |
Comprimento |
2–3 |
Valor (Ver Tabela 4) |
4 |
Mnemônico |
Dados comuns passando livremente pela porta |
Value |
|---|---|---|
psBlocked |
Não: |
1 |
psUp |
Sim: |
2 |
A variável enableRmepDefect MEP é uma variável booleana que indica se os quadros na instância de serviço monitorados pelas associações de manutenção se este MEP for habilitado a passar por essa porta de ponte pelo Protocolo Spanning Tree e pelo gerenciamento de topologia VLAN. É 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 abrangência.
A interface MEP não está associada a um domínio de ponte.
- Configurando o status da porta TLV
- Exibindo o TLV de status de porta recebida
- Exibindo o status da porta transmitida TLV
Configurando o status da porta TLV
O Junos OS oferece suporte de configuração para o Port Status TLV, permitindo que você controle a transmissão deste TLV em PDUs ccm. O Junos OS fornece essa configuração no nível de verificação de continuidade. Por padrão, o CCM não inclui o TLV de status de porta. Para configurar o TLV de status de porta, use a port-status-tlv declaração no nível de [edit protocols oam ethernet connectivity-fault-management maintenance-domain identifier maintenance-association identifier continuity-check] hierarquia.
A configuração do TLV de status da porta não é exigida pelo IEEE 802.1ag. O Junos OS fornece-o a fim de 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:
protocols {
oam {
ethernet {
connectivity-fault-management {
maintenance-domain identifier {
level number;
maintenance-association identifier {
continuity-check {
interval number,
loss-threshold number;
hold-interval number;
port-status-tlv; # Sets Port Status TLV
}
}
}
}
}
}
}
Você não pode habilitar a transmissão TLV de status de porta nos dois seguintes casos:
Se a interface de MEP sob a associação de manutenção não for do tipo bridge.
Se o MEP estiver configurado em uma interface física.
Exibindo o TLV de status de porta recebida
O Junos OS salva o último TLV de status de porta recebido de um MEP remoto. Se o valor de status de porta recebido não corresponder a um dos valores padrão listados Tabela 4, então o comando o show exibirá como "desconhecido". Você pode exibir o último TLV de status de porta recebido salvo 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:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none # RX PORT STATUS
Interface status TLV: none
Exibindo o status da porta transmitida TLV
O Junos OS salva o último TLV de status de porta transmitido de um MEP local. Se a transmissão do TLV de status de porta não tiver sido habilitada, o show comando não exibirá "nenhum". Você pode exibir o último TLV de status de porta transmitido salvo 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:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up # TX PORT STATUS
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none
Interface Status TLV
O TLV de status de interface indica o status da interface na qual o MEP transmitindo o CCM está configurado, ou a interface mais baixa no IETF RFC 2863 IF-MIB. O formato deste TLV é mostrado em Tabela 5. Os valores enumerados são mostrados em Tabela 6.
Parâmetro |
Octet (sequência) |
|---|---|
Tipo = 4 |
1 |
Comprimento |
2–3 |
Valor (Ver Tabela 6) |
4 |
Mnemônico |
Interface Status |
Value |
|---|---|---|
Isup |
em cima |
1 |
isDown |
abaixo |
2 |
isTesting |
teste |
3 |
é desconhecido |
desconhecido |
4 |
está dormente |
dormente |
5 |
isNotPresent |
nãoPresente |
6 |
isLowerLayerDown |
lowerLayerDown |
7 |
Quando o status operacional de uma interface lógica muda do estado baixo (valor de status de 2) para o estado inferior de camada baixa (valor de status de 7) e vice-versa, a armadilha SNMP LinkDown não é gerada. Por exemplo, se você configurar um pacote agregado de interface Ethernet com uma tag VLAN e adicionar uma interface física que está no estado operacionalmente para baixo para o pacote, o status operacional do pacote de interface lógica Ethernet agregado nesse ponto é menor camada para baixo (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 para baixo.
Da mesma forma, considere outro cenário de amostra em que uma interface física é adicionada a um pacote Ethernet agregado que tem tags VLAN e a interface lógica Ethernet agregada é desativada. Quando a interface lógica é desativada, o status operacional da interface lógica muda para baixo. Se você desativar a interface física que faz parte do pacote Ethernet agregado, o status operacional da interface lógica Ethernet agregada permanecerá desativado. Se você reenable a interface lógica Ethernet agregada, o status operacional da rede muda de baixo para baixo para camada baixa. A armadilha SNMP do LinkDown não é gerada neste momento.
- Configuração do status da interface TLV
- Exibindo o status de interface recebida TLV
- Exibindo o status da interface transmitida TLV
Configuração do status da interface TLV
O Junos OS oferece suporte de configuração para o Interface Status TLV, permitindo assim que os operadores controlem a transmissão deste TLV nas PDUs ccm através da configuração no nível de verificação de continuidade.
Essa configuração não é exigida pelo IEEE 802.1ag; em vez disso, ele é fornecido para dar mais flexibilidade ao operador. O Junos OS recebe e processa CCMs com o TLV de status da interface, independentemente dessa configuração.
A configuração TLV de status da interface é mostrada abaixo:
protocols {
oam {
ethernet {
connectivity-fault-management {
maintenance-domain identifier {
level number;
maintenance-association identifier {
continuity-check {
interval number;
loss-threshold number;
hold-interval number;
interface-status-tlv; # Sets the interface status TLV
}
}
}
}
}
}
}
O Junos OS oferece suporte à transmissão de apenas três dos sete valores possíveis para o Interface Status TLV. Os valores suportados são 1, 2 e 7. No entanto, o Junos OS é capaz de receber qualquer valor para o Interface Status TLV.
Exibindo o status de interface recebida TLV
O Junos OS salva o último TLV de status de interface recebido do MEP remoto. Se o valor de status de interface recebido não corresponder a um dos valores padrão listados Tabela 5, o show comando exibirá "desconhecido".
Você pode exibir este último TLV de status de interface salvo 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:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none # displays the Interface Status TLV state
Exibindo o status da interface transmitida TLV
O Junos OS salva o último TLV de status de interface transmitido de um MEP local. Se a transmissão do Status de Interface TLV não tiver sido habilitada, então o show comando exibirá "nenhum".
Você pode exibir o último TLV de status de interface transmitido 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:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 local-mep 2001 remote-mep 1001
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 100ms, Loss-threshold: 3 frames
MEP identifier: 2001, Direction: down, MAC address: 00:19:e2:b2:81:4a
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: ge-2/0/0.0, Interface status: Active, Link status: Up
Remote MEP identifier: 1001, State: ok
MAC address: 00:19:e2:b0:74:00, Type: Learned
Interface: ge-2/0/0.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: none
Defeitos de status MAC
O Junos OS fornece informações de defeito de status MAC, indicando que um ou mais dos MEPs remotos estão relatando uma falha em seu TLV de status de porta ou status de interface TLV. Ele indica "sim" se algum MEP remoto estiver relatando que sua interface não é IsUp (por exemplo, pelo menos uma interface de MEPs remota está indisponível) ou se todos os MEPs remotos estão relatando um TLV de status de porta que contém algum valor diferente do psUp (por exemplo, todas as portas de ponte de MEPs remotas não estão encaminhando dados). Existem dois show comandos que você pode usar para visualizar a indicação de defeitos de status MAC.
Use o mep-database comando para exibir defeitos de status mac:
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md6 maintenance-association ma6
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
MEP identifier: 500, Direction: down, MAC address: 00:05:85:73:7b:39
Auto-discovery: enabled, Priority: 0
Interface status TLV: up, Port status TLV: up
Interface name: xe-5/0/0.0, Interface status: Active, Link status: Up
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Some remote MEP's MAC in error state : yes # MAC Status Defects yes/no
Statistics:
CCMs sent : 1658
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
200 00:05:85:73:39:4a ok xe-5/0/0.0
Use o interfaces comando para exibir defeitos de status mac:
user@host> show oam ethernet connectivity-fault-management interfaces detail
Interface name: xe-5/0/0.0, Interface status: Active, Link status: Up
Maintenance domain name: md6, Format: string, Level: 6
Maintenance association name: ma6, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
Interface status TLV: up, Port status TLV: up
MEP identifier: 500, Direction: down, MAC address: 00:05:85:73:7b:39
MEP status: running
Defects:
Remote MEP not receiving CCM : no
Erroneous CCM received : no
Cross-connect CCM received : no
RDI sent by some MEP : no
Some remote MEP's MAC in error state : yes # MAC Status Defects yes/no
Statistics:
CCMs sent : 1328
CCMs received out of sequence : 0
LBMs sent : 0
Valid in-order LBRs received : 0
Valid out-of-order LBRs received : 0
LBRs received with corrupted data : 0
LBRs sent : 0
LTMs sent : 0
LTMs received : 0
LTRs sent : 0
LTRs received : 0
Sequence number of next LTM request : 0
1DMs sent : 0
Valid 1DMs received : 0
Invalid 1DMs received : 0
DMMs sent : 0
DMRs sent : 0
Valid DMRs received : 0
Invalid DMRs received : 0
Remote MEP count: 1
Identifier MAC address State Interface
200 00:05:85:73:39:4a ok xe-5/0/0.0
Configuração do suporte ao perfil de ação remoto de MEP
Com base nos valores e interface-status-tlvport-status-tlv nos pacotes CCM recebidos, uma ação específica, como interface-down, pode ser tomada usando as action-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á desencadeada se algum desses eventos ocorrer. Não é necessário que todos os eventos configurados ocorram para acionar action.
Um perfil de ação só pode ser aplicado no nível de MEP remoto.
O exemplo a seguir mostra uma configuração de perfil de ação com comentários explicativos adicionados:
[edit protocols oam ethernet connectivity-fault-management]
action-profile tlv-action {
event {
# If interface status tlv with value specified in the config is received
interface-status-tlv down|lower-layer-down;
# If port status tlv with value specified in the config is received
port-status-tlv blocked;
# If connectivity is lost to the peer */
adjacency-loss;
}
action {
# Bring the interface down */
interface-down;
}
default-actions interface-down;
}
# domains
maintenance-domain identifier {
# maintenance domain level (0-7)
level number;
# association
maintenance-association identifier {
mep identifier {
interface ge-x/y/z.w;
remote-mep identifier {
# Apply the action-profile for the remote MEP
action-profile tlv-action;
}
}
}
}
Monitoramento de um perfil remoto de ação de mep
Você pode usar o show oam ethernet connectivity-fault-management mep-database comando para visualizar o status de perfil de ação de um MEP remoto, como no exemplo a seguir:
mostrar oam conectividade-falha de conectividade ethernet gerenciamento mep-banco de dados remoto-mep (Evento de perfil de ação)
user@host> show oam ethernet connectivity-fault-management mep-database maintenance-domain md5 maintenance-association ma5 remote-mep 200
Maintenance domain name: md5, Format: string, Level: 5
Maintenance association name: ma5, Format: string
Continuity-check status: enabled, Interval: 1s, Loss-threshold: 3 frames
MEP identifier: 100, Direction: down, MAC address: 00:05:85:73:e8:ad
Auto-discovery: enabled, Priority: 0
Interface status TLV: none, Port status TLV: none # last status TLVs transmitted by the router
Interface name: ge-1/0/8.0, Interface status: Active, Link status: Up
Remote MEP identifier: 200, State: ok # displays the remote MEP name and state
MAC address: 00:05:85:73:96:1f, Type: Configured
Interface: ge-1/0/8.0
Last flapped: Never
Remote defect indication: false
Port status TLV: none
Interface status TLV: lower-layer-down
Action profile: juniper # displays remote MEP’s action profile identifier
Last event: Interface-status-tlv lower-layer-down # last remote MEP event
# to trigger action
Action: Interface-down, Time: 2009-03-27 14:25:10 PDT (00:00:02 ago)
# action occurrence time
Configurando chassi ID TLV
Na versão 16.1R2 e posterior, 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 link (LTMs), conforme especificado no padrão IEEE 802.1ag. O ID TLV do remetente contém o ID do chassi, que é o endereço MAC exclusivo baseado em CFM do dispositivo e o endereço IP de gerenciamento, que é um IPv4 ou um endereço IPv6.
O valor do length campo no TLV indica se o TLV contém ou não as informações de ID do chassi. Os valores possíveis para o length campo são zero (0) ou qualquer número válido, o que indica a ausência ou presença de informações de ID do chassi no TLV, respectivamente.
Você pode habilitar o Junos OS a enviar o ID TLV do remetente a 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 no nível global, então o domínio de manutenção padrão, a associação de manutenção e a metade da função de ponto intermediário (MIP) da associação de manutenção 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 no nível de associação de manutenção tem precedência sobre a configuração de nível global.
O ID TLV do remetente é suportado apenas para PDUs 802.1ag e não é suportado para unidades de dados de protocolo de monitoramento de desempenho (PDUs).
Consulte também
Configuração do processamento de mensagens MAC Flush no modo CET
No modo de transporte Ethernet (CET) de operadora, os roteadores da Série MX são usados como roteadores de borda de provedor (PE), e os switches de ethernet carrier A2200 da Nokia Siemens Networks (conhecidos como dispositivos de domínio E) que executam 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 através do protocolo de distribuição de rótulos (LDP). Nos dispositivos de domínio eletrônico, são detectadas alterações de topologia 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 MX Series PE. Os roteadores MX Series PE podem reduzir a interface Ethernet da operadora se houver perda de conectividade CFM. Isso aciona uma descarga MAC local, bem como uma notificação mac flush de protocolo de distribuição de rótulos (T-LDP) direcionada que é enviada em direção aos PEs remotos da Série MX para acionar o MAC flush neles.
No modo interoperacional CET, os roteadores da Série MX precisam interoperar com os dispositivos de acesso Ethernet Ax100 Carrier Ax100 da Nokia Aí aí (conhecidos como dispositivos de domínio A) que executam protocolos legados. Os dispositivos A4100 e A8100 da Nokia Siemens Networks atuam como um intermediário entre os roteadores MX Series PE e dispositivos de domínio A. Esses dispositivos intermediários executam procedimentos de função de intertrabalho (IWF) para que as sessões de gerenciamento de administração de operações (OAM) possam ser executadas entre roteadores da Série MX e dispositivos de domínio A. Não há pseudowires VPLS entre os roteadores MX Series PE e os dispositivos intermediários Nokia Siemens Networks A4100 e A8100, portanto não há nenhum protocolo LDP em execução entre os roteadores PE para enviar notificações de alteração de topologia. Para comunicar mudanças na topologia, os roteadores da Série MX podem acionar um MAC flush e propaga-lo no núcleo. Os roteadores da Série MX podem usar perfis de ação com base no evento de valor de comprimento do tipo de proteção de conexão (TLV). O perfil de ação reduz a interface lógica de borda de operadora nos roteadores MX Series PE, que acionará um flush MAC local e também propagará a mudança de topologia para o núcleo usando a notificação LDP.
Para VPLS, não há nenhuma conectividade de ponta a ponta monitorada. Os anéis de acesso são monitorados de forma independente, executando o CFM para baixo vários pontos finais (MEPs) nos caminhos de trabalho e proteção para cada um dos serviços entre os dispositivos de domínio E e os roteadores MX Series PE, e entre os dispositivos de domínio A e os roteadores MX Series PE, o IWF hospedado pelos dispositivos Nokia Anticorrupns Networks A-4100. Quando há uma falha de conectividade no caminho de trabalho, os dispositivos Nokia Siemens Networks Ax200 realizam uma transição para o caminho de proteção, desencadeando uma notificação de mudança de topologia (na forma de TLVs transportadas no CCM) a ser enviada no caminho ativo.
Figura 1 descreve a topologia dupla em roteadores MX Series PE conectados ao domínio A. Quando um dispositivo de domínio A aciona uma transição, ele começa a mudar o tráfego de serviços para o novo caminho ativo. Essa mudança é comunicada nas unidades de dados de protocolo HELLO (PDUs) enviadas por esse dispositivo de domínio A nos caminhos de trabalho e proteção. Quando o IWF no A4100 realiza essas PDUs HELLO, ela as converte em mensagens CCM padrão e também insere uma proteção de conexão TLV. O campo "Proteção em uso" da proteção de conexão TLV está codificado com o caminho ativo atualmente, e está incluído na mensagem CCM. As mensagens CCM são recebidas pelos roteadores MX Series PE através do spoke VLAN no A4100. No cenário de casa dupla acima, um roteador MX Series PE monitora o caminho de trabalho, e o outro roteador MX Series PE monitora o caminho de proteção.
Uma descarga MAC ocorre quando a sessão do CFM que está monitorando o caminho de trabalho detecta que o tráfego de serviços se moveu para o caminho de proteção ou quando a sessão do CFM que está monitorando o caminho de proteção detecta que o tráfego de serviço se moveu para o caminho de trabalho.
Figura 2 descreve a topologia dupla anexada em roteadores MX Series PE conectados ao domínio A. O mecanismo de flush MAC usado neste caso também é o mesmo usado para o domínio A no cenário de dupla casa (Figura 1). No entanto, neste caso, ambas as sessões do CFM são hospedadas por apenas um roteador MX Series PE. Quando o Ax100 no domínio A detecta mudanças 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 CFM, o roteador MX Series PE derrubará a interface apropriada que ativará uma descarga MAC local.
Configuração de um perfil de ação TLV de proteção de conexão
Um perfil de ação pode ser configurado para realizar a ação interface-down com base nos valores dos connection-protection-tlv pacotes CCM recebidos.
O exemplo a seguir mostra uma configuração de perfil de ação com comentários explicativos adicionados:
[edit protocols oam ethernet connectivity-fault-management]
action-profile <tlv-action> {
event {
# If a connection protection TLV with a “Protection-in-use” value of SET is received */
connection-protection-tlv <using-protection-path>;
# If a connection protection TLV with a “Protection-in-use” value of RESET is received */
connection-protection-tlv <using-working-path>;
}
action {
# Bring the interface down */
interface-down;
}
}
Consulte também
Exemplo: Configuração de 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 para fins de acionamento de flushes MAC com base em mudanças de topologia em uma rede CET.
Requisitos
Este exemplo usa os seguintes componentes de hardware e software:
Versão do Junos OS 11.2 ou posterior
Um roteador PE da série MX
Visão geral e topologia
A topologia física de uma rede CET usando roteadores MX série PE é mostrada em Figura 3
Topologia
As definições a seguir descrevem o significado da abreviação do dispositivo e dos termos usados em Figura 3.
Dispositivo de borda de provedor (PE) — um dispositivo ou conjunto de dispositivos na borda da rede do provedor que apresenta a visão do provedor sobre o site do cliente.
Domínio eletrônico — Switches de ethernet de operadora nokia Aísians Networks que executam protocolos baseados em padrão e são usados no lado de acesso.
Domínio A — Switches de ethernet de operadora da Nokia Siemens Networks que executam protocolos legados.
Configuração
Procedimento
Procedimento passo a passo
Para configurar um perfil de ação com base na proteção de conexão TLV, preforme essas tarefas:
Configure um perfil de ação
[edit protocols oam ethernet connectivity-fault-management] action-profile <tlv-action> { event {Se a proteção de conexão TLV for recebida com um valor "Proteção em uso" do SET, então a proteção de conexão TLV deve usar o caminho de proteção
connection-protection-tlv <using-protection-path>;
Se a proteção de conexão TLV for recebida com um valor "Proteção em uso" de RESET, então a proteção de conexão TLV deve usar o caminho de trabalho
connection-protection-tlv <using-working-path>; }
Configure o perfil de ação para reduzir a interface
action { /* Bring the interface down */ interface-down; } }
Resultados
Verifique os resultados da configuração
[edit protocols oam ethernet connectivity-fault-management]
action-profile <tlv-action> {
event {
connection-protection-tlv <using-protection-path>;
connection-protection-tlv <using-working-path>;
}
action {
interface-down;
}
}
Tabela de histórico de alterações
A compatibillidadde com o recurso dependerá da platadorma e versão utilizada. Use o Feature Explorer para saber se o recurso é compatível com sua plataforma.