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 de porta, TLVs ID do Chassis e TLVs de proteção de conexão ajudam no monitoramento de sua rede.
Notificação assíncronos do perfil de ação do CFM
A notificação assíncronos 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 dispositivosPE. Ele emula o 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 cai . Quando o enlace é restabelecido, ele restaurao status deligação entre PE1 e CE1. A mudança de status do enlace entre PE1 e CE1 deve funcionar de maneirasemelhante.
-
Quando há um problema de conectividade entre PE1 e PE2, ele aciona uma ligação entre PE1 e CE1 e PE2 e CE2. Se o status da conexão for restaurar, ele deve restaurar o status do enlace em ambas as extremidades.
Consulte também
Configure um perfil de ação do CFM para a notificação de Asyncronus
O UP-MEP do CFM sobre PE1 e PE2 monitora a conectividade entre PE1 e PE2. Esses interface-status-tlv pontos finais UP-MEP transmitem o status da ligação entre PE1, CE1e PE2, bem como entre PE2, CE2e PE1. Você deve configurar o perfil de ação no PE1 para PE2 para conduzir notificações assíncronos em direção aos respectivos dispositivos CE. O perfil de ação desencadeia essas notificações quando o sistema detecta perda de adjacência ou uma condição de baixa de enlace no recebido interface-status-tlv.
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 cai, o CFM propaga o status da interface nas mensagens CC. A mensagem CC notifica o dispositivo de borda do cliente de 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 cai, o CFM propaga o status da interface usando o status da interface TLV. O Status de Interface TLV indica o status da interface que hospeda o MEP transmitindo o CCM, ou indica a interface mais baixa no IETF RFC 2863 IF-MIB. Assim, o dispositivo de borda do cliente descobre 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. Essa configuração é a opção padrão.RDI (Indicação de defeito remoto)— 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 bit RDI. Quando você habilita o monitoramento do CFM, o CFM propaga o status do dispositivo de borda do provedor por meio do bit RDI nas mensagens CC, o que informa ao dispositivo de borda do cliente 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 você define a interface para ccc para baixo e configura RDI, o dispositivo envia o bit RDI. O CFM não monitora o status da interface.
Se você definir o CCC desativado enquanto a interface não estiver em espera e configurar o RDI, o dispositivo inclui o bit RDI em mensagens CC.
- Caso de uso multi homing ativo único usando bit RDI
- Caso de uso ativo/ativo multi-homing usando bit RDI
Caso de uso multi homing ativo único usando bit RDI
Considere a topologia a seguir, que inclui dois dispositivos de borda de provedor (PE1 e PE2) e dois dispositivos de borda do cliente (CE1 e CE2). O PE1 opera no estado ativo, enquanto o PE2 permanece no estado de espera. Quando você configura o CFM para baixo MEP entre o PE e o CE, o CFM detecta que o CCC está desativado e o sistema inclui o bit de RDI nas mensagens CC. 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 sistema elimina o status do CCM e remove a bit de RDI das mensagens CC subsequentes.
Caso de uso ativo/ativo multi-homing usando bit RDI
Considere a topologia a seguir, que inclui dois dispositivos de borda de provedor (PE1 e PE2) e dois dispositivos de borda do cliente (CE1 e CE2). O PE1 opera no estado ativo, enquanto o PE2 permanece no estado de espera. Quando você não configura o CFM para baixo MEP entre o PE e o CE para monitorar a conectividade do link, o sistema não inclui o bit RDI nas mensagens CC. Quando você configura o CFM para baixo MEP entre o PE e o CE, o CFM detecta que o CCC está desativado e o sistema inclui o bit de RDI nas mensagens CC. 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 sistema elimina o status do CCM e remove a bit de RDI das mensagens CC subsequentes.
Consulte também
Configureo status da porta e 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
- Configure o suporte de perfil de ação remoto para MEP
- Monitore um perfil de ação remoto 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 |
Este campo é necessário. Se o valor for 0, não seguirão outros campos (Comprimento ou valor). Se o valor não for 0, o campo Comprimento deve seguir. |
Comprimento |
2–3 |
Este campo só é necessário se o campo Tipo não for 0. Não está presente se o campo Tipo é 0. Os 16 bits do campo de comprimento indicam o tamanho, em octets, do campo Value. Um valor de campo de comprimento de 0 significa que não há campo de Valor. |
Value |
4 |
O comprimento deste campo é especificado pelo campo Comprimento. Ele é opcional e não estará presente se o campo Tipo for 0 ou se o campo de comprimento for 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 Type. Alguns valores de campo do Tipo estã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.
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. Ele indica se os quadros na instância de serviço monitorada pelas associações de manutenção do MEP podem passar pela porta da ponte usando o protocolo Spanning Tree e o 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.
- Configure o status da porta TLV
- Exibir o TLV de status da porta recebida
- Exibir o status da porta transmitida TLV
Configure 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 do 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 essa configuração para oferecer mais flexibilidade ao operador; no entanto, ele recebe e processa CCMs com um TLV de status de porta, independentemente da 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.
Exibir o TLV de status da 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
Exibir 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.
- Configure Interface Status TLV
- Exibir o status de interface recebida TLV
- Exibir o status da interface transmitida TLV
Configure Interface Status 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.
Exibir 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
Exibir 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 que indicam quando os MEPs remotos relatam falhas em seu TLV de status de porta ou status de interface TLV. O sistema indica "sim" se, um ou mais MEPs remotos informarem que sua interface não está "ativa" (por exemplo, quando a interface de um MEP remoto está indisponível) ou se, todos os MEPs remotos relatarem um TLV de status de porta com algum valor que não seja "Up" (por exemplo, quando todas as portas de ponte de MEPs remotas não estão encaminhando dados). Você pode visualizar a indicação de defeitos de status MAC usando dois show comandos.
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
Configure o suporte de perfil de ação remoto para 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 um ou mais eventos, e a ação desencadeia quando qualquer um desses eventos ocorre. Não é necessário que todos os eventos configurados sejam acionados 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;
}
}
}
}
Monitore um perfil de ação remoto 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
Configure Chassis ID TLV
Você pode configurar o Junos OS para enviar o Sender ID TLV junto com os pacotes. O Sender ID TLV é 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 Sender ID TLV 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 Sender ID TLV a nível global usando o set protocols oam ethernet connectivity-fault-management sendid-tlv send-chassis-tlv comando. Se o Sender ID TLV 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 Sender ID TLV 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 do Sender ID TLV no maintenance-association nível tem precedência sobre a configuração de nível global.
O Sender ID TLV é suportado apenas para PDUs 802.1ag e não é suportado para unidades de dados de protocolo de monitoramento de desempenho (PDUs).
Consulte também
Configure o 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.
Configure 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: Configure 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 do 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.