O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve uma visão geral do Resilient Ethernet Protocol (REP).
Observação: use o Cisco Feature Navigator para encontrar informações sobre suporte a plataformas e suporte a imagens de software da Cisco.
O REP é um protocolo que substitui o Spanning Tree Protocol (STP ou Protocolo de Estrutura Estendida) em alguns projetos de rede de Camada 2 específicos. A especificação mais atual do STP é o Multiple Spanning Tree (MST), definido no IEEE 802.1Q-2005. Os usuários que procuram uma alternativa ao MST têm as seguintes preocupações pertinentes:
Estes são alguns dos benefícios do REP:
Estas são algumas das limitações do REP:
O REP utiliza um segmento como um componente de rede mínimo. Um segmento é simplesmente um conjunto de portas encadeadas. Apenas duas portas podem integrar um dado segmento em uma ponte, e cada porta do segmento pode ter, no máximo, um vizinho externo. A definição do segmento deve ser totalmente configurada pelo usuário. As extremidades do segmento apresentam duas portas de borda, que também devem ser determinadas pelo usuário. O protocolo REP executado nos segmentos é o menor possível e garante apenas as seguintes propriedades:
A imagem 1 mostra um exemplo de um segmento que inclui seis portas espalhadas em quatro pontes. No diagrama, as portas de borda configuradas E1 e E2 estão representadas por um triângulo, e a porta com bloqueio lógico está representada por uma barra. Quando todas as portas estão operacionais, como representado à esquerda, uma única porta é bloqueada. Quando há uma falha na rede, como demonstrado no diagrama à direita, a porta com bloqueio lógico retorna ao estado de encaminhamento.
Quando o segmento está aberto, como representado na Imagem 1, ele nunca fornece conectividade entre suas duas portas de borda. Presume-se que a conectividade entre os switches de borda do REP ocorra fora do segmento (por STP). Se uma falha no segmento do REP for identificada, é possível gerar, por meio de configuração opcional, uma notificação de alteração de topologia (TCN) do STP, a fim acelerar a convergência.
Quando as duas portas de borda estão localizadas no mesmo switch, como mostrado na Imagem 2, o segmento é envolvido em um anel. Neste caso, há conectividade entre as portas de borda do segmento. Na realidade, esta configuração permite a criação de uma conexão redundante entre dois switches no segmento.
Se você usar combinações de segmentos abertos e fechados, como representado nas Imagens 1 e 2, poderá obter uma variedade de projetos de rede diferentes.
Quando uma porta está configurada para REP, ela passa pelos seguintes estados:
Uma porta não se torna operacional sob estas condições:
Como padrão, o REP envia pacotes de aviso a um endereço MAC da classe Unidade de Dados do Protocolo de Bridge (Bridge Protocol Data Unit ou BPDU) na VLAN nativa (sem marcas) para que sejam descartados pelos dispositivos que não executam o recurso. Cada PDU da LSL (Link Status Layer) inclui um número sequencial da PDU que é enviada e o número sequencial remoto da última PDU recebida. Isso garante transmissões seguras entre as portas. Cada vizinho mantém uma cópia de cada PDU enviado até que um ACK seja recebido. Se o ACK não for recebido, o envio é feito novamente após a expiração do temporizador.
O PDU em LSL contém:
Os pacotes em LSL são enviados a cada intervalo do aviso ou quando solicitados por um protocolo da camada superior. Quando o PDU em LSL é criado, ele preenche primeiramente seus próprios campos, como SegmentID e LocalPortID. Em seguida, ele verifica as filas dos protocolos das camadas superiores, como Block Port Advertisement (BPA) ou End Port Advertisement (EPA), para determinar se há dados adicionais que precisam ser enfileirados.
O HFL é o módulo do REP que possibilita a convergência rápida após falhas de link. Ele não envia PDUs para o endereço MAC da BPDU como LSL, mas envia PDUs multicast para um endereço MAC especial (0100.0ccc.ccce) na VLAN administrativa do REP. Assim, ele se dissemina no hardware de todos os switches do segmento.
O formato do pacote HFL é simples:
Até o momento, os únicos TLVs enviados por HFL são os BPAs.
Os BPAs são enviados por APs com o objetivo de comunicar quais as VLANs que bloqueiam, bem como suas prioridades de porta. Isso ajuda a notificar o segmento de falhas de link e garante que haja apenas um único AP por segmento por VLAN. Não é uma missão fácil.
Em uma topologia estável, as seleções de APs são simples. Uma porta conectada começa como um AP para todas as VLANs (bloqueada). Quando recebe um BPA de outra porta com prioridade mais alta, ela sabe que pode se desbloquear com segurança. Quando uma porta no segmento falha, este mesmo procedimento é usado para desbloquear as outras portas. Todas as portas com falha geram uma prioridade de porta mais alta (com um bit com falha na prioridade) do que os APs atuais, o que faz com que o AP atual seja desbloqueado.
Contudo, os problemas surgem quando o link volta a funcionar. Quando isso acontece, o bit com falha na prioridade é eliminado, e a prioridade volta ao normal. Mesmo que essa porta conheça sua nova prioridade, outras partes do segmento podem ter informações de BPA obsoletas dessa porta. O diagrama a seguir ilustra esse cenário:
No início desse cenário, a porta 7 está bloqueando e anuncia sua prioridade como 7. Em seguida, o link entre 11 e 12 apresenta falha, o que faz com que a porta 12 envie um BPA para indicar que está fazendo o bloqueio com sua prioridade 12. Antes que essas portas de bloqueio recebam o BPA da outra porta, a porta 12 volta a funcionar e fica operacional. Logo depois, a porta 12 recebe o BPA da porta 7 e, com isso, se desbloqueia. A porta 7 recebe, então, o BPA prescrito da porta 12 com a prioridade 12 e, por isso, se desbloqueia. Isso gera um loop. Essa condição de corrida é o motivo pelo qual o BPA utiliza chaves.
Cada porta calcula uma prioridade de porta com estas informações:
Fica claro, agora, por que as portas com falha são sempre selecionadas como APs no segmento. Quando uma porta passa de Com falha para Alternativa, ela gera um chave exclusiva com base na ID da porta e em um número aleatório. Esta chave é, então, enviada pela porta juntamente com a ID da porta. Um AP é desbloqueado somente se receber uma mensagem de uma porta bloqueada que inclua sua chave local. Esse mecanismo ajuda a evitar o cenário de condição de corrida descrito na seção anterior. A seguir, estão os diagramas que demonstram o que ocorre quando as portas tornam-se ativas ou inativas:
Quando ocorre uma falha de link em um segmento, um BPA é enviado para o resto do segmento por meio do HFL. Para que isso seja inteiramente eficaz, a VLAN administrativa deve estar ativa em todas as portas do segmento e entre as portas de borda externas ao segmento. O BPA também envia essas informações através do LSL, pois o HFL não pode garantir o transporte confiável. Se houver problemas com a entrega do HFL, o LSL garante que a nova convergência ocorra.
A porta final pode ser uma porta de borda ou uma porta com falha. Quando ambas as extremidades são portas de borda, o segmento é considerado completo e é possível realizar o balanceamento de carga da VLAN. Quando uma das extremidades do segmento é uma porta com falha, não é possível realizar o balanceamento de carga, visto que todas as portas estão abertas.
As portas finais enviam EPAs periodicamente que são, então, retransmitidos por meio de LSL. Estas são as mensagens enviadas:
Cada porta final envia um EPA periodicamente com informações sobre si mesma por LSL. Cada porta intermediária adiciona suas próprias informações e retransmite o EPA. Como essas mensagens são transmitidas em ambos os sentidos, cada switch que integra o REP reconhece todo o segmento. As informações contidas no EPA incluem:
Cada porta de borda envia uma mensagem de EPA de seleção especial com sua prioridade de borda e com uma chave especial (não relacionada à chave do BPA). A primeira porta a receber a mensagem insere nela sua prioridade de porta e a retransmite para o próximo switch. Cada switch ao longo do caminho compara sua própria prioridade de porta com a do EPA e a substitui por sua própria prioridade se a prioridade for maior. Quando a porta de borda recebe um EPA, ela compara sua prioridade de borda àquela que consta no EPA. Se o EPA recebido tiver uma prioridade mais alta, a porta de borda enviará sua próxima mensagem EPA com a chave para a borda principal. Com esse mecanismo, é possível obter dois resultados:
O balanceamento de carga de VLAN é obtido com dois APs diferentes que bloqueiam VLANs diferentes. A borda primária é e é responsável pelo AP em pelo menos um subconjunto das VLANs e envia uma mensagem EPA que informa à porta de prioridade mais alta para bloquear o restante. A informação sobre a porta intermediária com a prioridade mais alta já foi obtida na mensagem EPA de seleção. O tipo de mensagem gerada para esse fim é um TLV de comando EPA que contém um bitmap das VLANs que a porta com a prioridade mais alta precisa bloquear.
Cabeçalho do EPA:
TLV de seleção:
TLV de comando:
TLV de informação:
Abaixo, segue um exemplo de uma topologia adequada:
SwitchA#show rep topology
REP Segment 1
BridgeName PortName edge Role
---------------- ---------- ---- ----
SwitchA Fa0/2 Pri Alt
SwitchC Fa1/0/23 Open
SwitchC Fa1/0/2 Open
SwitchD Fa0/23 Open
SwitchD Fa0/2 Open
SwitchB Fa1/0/23 Sec Open
Abaixo, segue um exemplo que apresenta problemas:
SwitchA#show rep topology
REP Segment 1
Warning: REP detects a segment failure, topology may be incomplete
BridgeName PortName edge Role
---------------- ---------- ---- ----
SwitchA Fa0/2 Sec Open
SwitchC Fa1/0/23 Open
SwitchC Fa1/0/2 Fail
Abaixo, segue como a topologia era anteriormente:
SwitchA#show rep topology archive
REP Segment 1
BridgeName PortName edge Role
---------------- ---------- ---- ----
SwitchA Fa0/2 Pri Open
SwitchC Fa1/0/23 Open
SwitchC Fa1/0/2 Open
SwitchD Fa0/23 Open
SwitchD Fa0/2 Open
SwitchB Fa1/0/23 Sec Alt
Digite o comando a seguir para obter mais detalhes sobre o link com falha entre o SwitchC e o SwitchD:
SwitchA#show rep topology archive detail
REP Segment 1
<snip>
SwitchC, Fa1/0/2 (Intermediate)
Open Port, all vlans forwarding
Bridge MAC: 0017.5959.c680
Port Number: 004
Port Priority: 010
Neighbor Number: 3 / [-4]
SwitchD, Fa0/23 (Intermediate)
Open Port, all vlans forwarding
Bridge MAC: 0019.e73c.6f00
Port Number: 019
Port Priority: 000
Neighbor Number: 4 / [-3]
<snip>
Abaixo, é possível ver a topologia após a restauração do link:
SwitchA#show rep topology
REP Segment 1
BridgeName PortName edge Role
---------------- ---------- ---- ----
SwitchA Fa0/2 Pri Open
SwitchC Fa1/0/23 Open
SwitchC Fa1/0/2 Alt
SwitchD Fa0/23 Open
SwitchD Fa0/2 Open
SwitchB Fa1/0/23 Sec Open
Observe que a porta que falhou anteriormente permanece como o AP e continua a bloquear. Isso se deve às seleções de APs, que acontecem apenas entre as portas bloqueadas. Quando o link apresentou falha, todas as portas restantes da topologia foram abertas. Quando o link foi restaurado, o SwitchC e o SwitchD enviaram BPAs com suas prioridades. O SwitchC F1/0/2 tinha uma prioridade mais alta e, por isso, tornou-se o AP. Isso é mantido até que outra porta da topologia falhe ou até que uma apropriação seja executada.
Uma porta ALT bloqueia algumas ou todas as VLANs. Se houver uma falha no segmento REP, não haverá porta ALT; todas as portas estarão abertas. É assim que o REP é capaz de fornecer um caminho ativo para o tráfego de dados quando há uma falha.
Em um segmento REP completo (quando não há falhas), há uma porta ALT ou duas portas ALT. Se o balanceamento de carga de VLAN estiver ativo, há duas portas ALT no segmento: uma das portas ALT bloqueia um conjunto específico de VLANs , e a outra porta ALT, que está sempre na borda principal, bloqueia o conjunto complementar de VLANs. Se o balanceamento de carga de VLAN estiver desativado, há apenas uma porta ALT no segmento, que bloqueia todas as VLANs.
A ordem na qual as portas ficam on-line e as prioridades de porta incorporadas determinam qual porta no segmento se torna uma porta ALT. Se você quiser que uma porta específica seja a porta ALT, configure-a com a palavra-chave preferred. Aqui está um exemplo:
interface gig3/10
rep segment 3 edge preferred
Suponha que gig3/1 seja a borda principal e que você queira configurar o balanceamento de carga de VLAN:
interface gig3/1
rep segment 3 edge primary
rep block port preferred vlan 1-150
Com essa configuração, após a apropriação, a porta gig3/10 passa a bloquear as VLANs 1 até 150. Já a porta gig3/1 passa a ser uma porta ALT que bloqueia as VLANs 151 a 4094.
A apropriação é feita manualmente, com o comando rep preempt segment 3 ou automaticamente, ao configurar rep preempt delay <seconds> na porta de borda principal.
Quando um segmento é restaurado após uma falha de link, uma das duas portas adjacentes à falha assume a função de porta ALT. Então, após a apropriação, o local das portas ALT segue a especificação da configuração.
Insira este comando para verificar se há uma adjacência:
SwitchC#show interface fa1/0/23 rep
Interface Seg-id Type LinkOp Role
---------------------- ------ -------------- ----------- ----
FastEthernet1/0/23 1 TWO_WAY Open
Insira este comando para obter mais informações:
SwitchC#show interface fa1/0/23 rep detail
FastEthernet1/0/23 REP enabled
Segment-id: 1 (Segment)
PortID: 001900175959C680
Preferred flag: No
Operational Link Status: TWO_WAY
Current Key: 000400175959C6808335
Port Role: Open
Blocked VLAN: <empty>
Admin-vlan: 1
Preempt Delay Timer: disabled
Configured Load-balancing Block Port: none
Configured Load-balancing Block VLAN: none
STCN Propagate to: none
LSL PDU rx: 255547, tx: 184557
HFL PDU rx: 3, tx: 2
BPA TLV rx: 176096, tx: 2649
BPA (STCN, LSL) TLV rx: 0, tx: 0
BPA (STCN, HFL) TLV rx: 0, tx: 0
EPA-ELECTION TLV rx: 870, tx: 109
EPA-COMMAND TLV rx: 2, tx: 2
EPA-INFO TLV rx: 45732, tx: 45733
A maioria dos debugs geram muitos resultados para serem úteis. Abaixo, segue a lista completa (alguns estão disponíveis apenas com o serviço interno):
SwitchB#debug rep ?
all all debug options
bpa-event bpa events
bpasm BPA state machine
database protocol database
epasm EPA state machine
error protocol errors
failure-recovery switchover events
lslsm LSL state machine
misc miscellaneous
packet protocol PDU
prsm Port Role state machine
showcli show debug info
Abaixo, seguem alguns debugs úteis:
debug rep error - Esta depuração pode ser muito útil.
*Mar 5 05:01:11.530: REP LSL-OP Rx EXT Local (Fa0/23 seg:1, tc:1, frs:0) prio:
*Mar 5 05:01:11.530: 0x80 0x00 0x19 0x00 0x17 0x59 0x59 0xC6
*Mar 5 05:01:11.530: 0x80
*Mar 5 05:01:11.530: REP Flush from Fa0/23 to REP, sending msg
*Mar 5 05:01:11.530: REP LSL-OP Rx INT Local (Fa0/2 seg:1, tc:1, frs:0) prio:
*Mar 5 05:01:11.530: 0x80 0x00 0x19 0x00 0x17 0x59 0x59 0xC6
*Mar 5 05:01:11.530: 0x80
*Mar 5 05:01:11.530: REP Flush from Fa0/2 to REP, sending msg
4d05h: %LINK-3-UPDOWN: Interface FastEthernet0/2, changed state to up
4d05h: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet0/2,
changed state to up
*Mar 5 05:06:19.098: rep_pr Fa0/2 - pr: during state FAILED_PORT,
got event 5(no_ext_neighbor)
*Mar 5 05:06:19.098: @@@ rep_pr Fa0/2 - pr: FAILED_PORT ->
FAILED_PORT_NO_EXT_NEIGHBOR[Fa0/2]rep_pr_act_no_ext_neighbor@272:
PRSM->fp_no_ext_neighbor state
[Fa0/2]rep_pr_lsl_event_handler@448: REP_MSG_EXT_PEER_GONE rcvd
4d05h: %REP-4-LINKSTATUS: FastEthernet0/2 (segment 1) is operational
*Mar 5 05:06:22.236: rep_pr Fa0/2 - pr: during state FAILED_PORT_NO_EXT_
NEIGHBOR, got event 0(link_op)
*Mar 5 05:06:22.236: @@@ rep_pr Fa0/2 - pr:
FAILED_PORT_NO_EXT_NEIGHBOR ->
ALTERNATE_PORT[Fa0/2]rep_pr_act_ap@162: PRSM->alternate state
[Fa0/2]rep_pr_lsl_event_handler@431: REP_MSG_LINKOP_TRUE rcvd
*Mar 5 05:06:23.125: rep_pr Fa0/2 - pr: during state ALTERNATE_PORT,
got event 2(pre_empt_ind)
*Mar 5 05:06:23.133: @@@ rep_pr Fa0/2 - pr: ALTERNATE_PORT -> UNBLOCK_VLANS_ACT
*Mar 5 05:06:23.133: rep_pr Fa0/2 - pr: during state UNBLOCK_VLANS_ACT,
got event 3(no_local_block_vlan)
*Mar 5 05:06:23.133: @@@ rep_pr Fa0/2 - pr: UNBLOCK_VLANS_ACT ->
OPEN_PORT[Fa0/2]rep_pr_act_op@252: PRSM->active state
[Fa0/2]rep_pr_act_uva@222: PRSM unblock vlans
[Fa0/2]rep_pr_sm_prempt_ind@374: Posting pre empt indication
Abaixo, segue o resultado se uma porta ficar inoperante:
*Mar 5 04:48:31.463: rep_epa_non_edge Fa0/2 - epa-non-edge: during state
INTERMEDIATE_PORT, got event 1(lr_eq_fp)*Mar 5 04:48:31.463: @@@ rep_epa_non_
edge Fa0/2 - epa-non-edge: INTERMEDIATE_PORT -> FAILED_PORT[Fa0/2]rep_epa_non_
edge_act_failed_port@164: Trigger archiving
[Fa0/23]rep_epa_set_peer_archive_flag@1084: set arch flag
[Fa0/2]rep_epa_non_edge_act_failed_port@171: no edge, failed port
*Mar 5 04:48:35.473: rep_epa_non_edge Fa0/2 - epa-non-edge: during state
FAILED_PORT, got event 0(epa_hello_tmo)
*Mar 5 04:48:35.473: @@@ rep_epa_non_edge Fa0/2 - epa-non-edge: FAILED_PORT ->
FAILED_PORT[Fa0/2]rep_epa_non_edge_act_periodic_tx@90: archiving on port down
[Fa0/2]rep_epa_copy_topology@913: deip=0x3396F18,pe=0,se=1,fp=0,ap=0,op=2
[Fa0/23]rep_epa_non_edge_handle_info_tlv@1560: archiving on internal flag
[Fa0/23]rep_epa_copy_topology@913: deip=0x33961F0,pe=1,se=0,fp=0,ap=1,op=3
[Fa0/2]rep_epa_non_edge_act_periodic_tx@102: epa non edge, send info tlv
[Fa0/23]rep_epa_set_peer_archive_flag@1084: set arch flag
[Fa0/2]rep_epa_non_edge_handle_election_tlv@325: archiving on seg cfg change
[Fa0/2]rep_epa_copy_topology@913: deip=0x3396F18,pe=0,se=1,fp=0,ap=0,op=2
[Fa0/2]rep_epa_set_peer_archive_flag@1084: set arch flag
[Fa0/23]rep_epa_non_edge_handle_election_tlv@325: archiving on seg cfg change
[Fa0/23]rep_epa_copy_topology@913: deip=0x33961F0,pe=1,se=0,fp=0,ap=1,op=3
[Fa0/2]rep_epa_non_edge_handle_info_tlv@1560: archiving on internal flag
[Fa0/2]rep_epa_copy_topology@913: deip=0x3396F18,pe=0,se=1,fp=0,ap=0,op=2
Esta é a saída quando uma porta fica on-line:
*Mar 5 04:49:39.982: rep_epa_non_edge Fa0/2 - epa-non-edge: during state FAILED_PORT,
got event 2(lr_neq_fp)
*Mar 5 04:49:39.982: @@@ rep_epa_non_edge Fa0/2 - epa-non-edge: FAILED_PORT ->
INTERMEDIATE_PORT[Fa0/2]rep_epa_non_edge_stop_timer@123: epa non edge, stop the timer
[Fa0/2]rep_epa_copy_topology@913: deip=0x32E2FA4,pe=0,se=1,fp=0,ap=1,op=1
[Fa0/2]rep_epa_copy_to_stable_topology@1040: copy to stbl
[Fa0/23]rep_epa_copy_topology@913: deip=0x3ACFFB8,pe=1,se=0,fp=0,ap=0,op=4
[Fa0/23]rep_epa_copy_to_stable_topology@1040: copy to stbl
[Fa0/23]: BPA: Sending ext pak to bparx
[Fa0/2]: BPA: Enqueued internal pak
[Fa0/2]: BPA: Sending int msg to bparx
[Fa0/2]: BPA: Relay pak
[Fa0/2]: BPA: Enqueue ext pak
*Mar 5 04:44:23.857: rep_bpa_rx BPA RX sm: during state BPA_RX_IDLE,
got event 0(bpa_rx_bpa_msg)
*Mar 5 04:44:23.857: @@@ rep_bpa_rx BPA RX sm: BPA_RX_IDLE -> BPA_RX_IDLE
[Fa0/23]: BPA Rx sm: Received bpa: <internal> 0, <vlan_detail> 0
[Fa0/23]: BPA Rx sm: Role 2: TC 0; Internal 0; Frm Remote Segment 0
*Mar 5 04:44:23.857: rep_bpa_rx BPA RX sm: during state BPA_RX_IDLE,
got event 0 (bpa_rx_bpa_msg)
*Mar 5 04:44:23.857: @@@ rep_bpa_rx BPA RX sm: BPA_RX_IDLE -> BPA_RX_IDLE
[Fa0/2]: BPA Rx sm: Received bpa: <internal> 1, <vlan_detail> 0
[Fa0/2]: BPA Rx sm: Role 2: TC 0; Internal 1; Frm Remote Segment 0
*Mar 5 05:03:10.564: REP Fa0/23 seq:4411 ACK'ed (ref: 1)
*Mar 5 05:03:10.564: REP Fa0/23 seq:4412 ACK'ed (ref: 1)
*Mar 5 05:03:10.564: REP LSL: Fa0/23 rx expected seq# (4744),
process it (TLV: 0).
*Mar 5 05:03:10.782: REP Fa0/2 seq:440 ACK'ed (ref: 1)
Revisão | Data de publicação | Comentários |
---|---|---|
3.0 |
08-Mar-2024 |
Imagens e legendas atualizadas, SEO e formatação. |
2.0 |
20-Jan-2023 |
Formatação atualizada e alertas fixos do CCW. Recertificação. |
1.0 |
03-Jul-2013 |
Versão inicial |