Datacom - EAPS, Funcionamento, Troubleshooting e Aplicação
Datacom - EAPS, Funcionamento, Troubleshooting e Aplicação
Datacom - EAPS, Funcionamento, Troubleshooting e Aplicação
Application Notes
Versão 2.3
Junho de 2014
Documento Público
Sumário
1.Introdução...................................................................................................................................................... 5
2.Conceitos de operação.................................................................................................................................. 5
2.1Portas do domínio................................................................................................................................... 5
2.1.1Primária.......................................................................................................................................... 5
2.1.2Secundária...................................................................................................................................... 5
2.2VLAN de controle.................................................................................................................................... 5
2.3VLANs protegidas................................................................................................................................... 5
2.4Modo de operação.................................................................................................................................. 5
2.4.1Master............................................................................................................................................. 5
2.4.2Transit............................................................................................................................................. 5
2.5Timers..................................................................................................................................................... 6
2.5.1Hellotime......................................................................................................................................... 6
2.5.2Failtime........................................................................................................................................... 6
2.6Failtime Action........................................................................................................................................ 6
2.6.1Open-secondary-port...................................................................................................................... 6
2.6.2Send-alert....................................................................................................................................... 6
2.7Estados do protocolo.............................................................................................................................. 6
2.8Interação com outros protocolos............................................................................................................. 6
2.9EAPS hardware forwarding no EDD....................................................................................................... 7
3.Quantidade de domínios suportados............................................................................................................. 7
4.Funcionamento.............................................................................................................................................. 7
4.1Situação normal de operação................................................................................................................. 7
4.2Queda de link no Transit......................................................................................................................... 7
4.3Retorno do link no Transit....................................................................................................................... 9
5.Exemplo de aplicação.................................................................................................................................. 10
5.1Configurações....................................................................................................................................... 11
5.2Comandos de verificação..................................................................................................................... 12
5.3Troubleshooting.................................................................................................................................... 13
5.3.1Perda do link entre os switches Transit 2 e 3................................................................................13
5.3.2Perda das PDUs Healt-Check com ataque na CPU do Transit 2..................................................13
5.3.3Debugs......................................................................................................................................... 15
5.4Cenário com balanceamento de tráfego...............................................................................................17
5.5Configurações....................................................................................................................................... 18
6.Conclusão.................................................................................................................................................... 21
7.Referências.................................................................................................................................................. 22
Documento público
2
Figuras
Figura 1: Domínio EAPS completo................................................................................................................... 8
Figura 2: Domínio EAPS com perda de link...................................................................................................... 8
Figura 3: Domínio EAPS com perda de link 2................................................................................................... 9
Figura 4: Domínio EAPS com retorno do link................................................................................................. 10
Figura 5: Exemplo de Aplicação..................................................................................................................... 10
Figura 6: Balanceamento de tráfego do domínio 0.........................................................................................18
Figura 7: Balanceamento de tráfego do domínio 1.........................................................................................18
Tabelas
Tabela 1: Estados do protocolo......................................................................................................................... 6
Tabela 2: Quantidade de domínios EAPS......................................................................................................... 7
Documento público
3
Glossário
CLI Command Line Interface
CPU Central Processing Unit
DLF Destination Lookup Failure
EAPS Ethernet Automatic Protection Switching
EDD Ethernet Demarcation Device
HW Hardware
MAC Media Access Control
PDU Protocol Data Unit
RRPP Rapid Ring Protection Protocol
STP Spanning Tree Protocol
VLAN Virtual Local Area Network
Documento público
4
1. Introdução
O EAPS é um protocolo para resiliência de redes com topologia em anel. Foi criado com intenção de
diminuir o tempo de convergência em comparação com o protocolo xSTP. Diferentemente do xSTP, no
EAPS o tempo de convergência não depende do número de nós. O protocolo é especificado na RFC 3619.
Segundo a norma o tempo de convergência é menor que 1 segundo podendo ser muitas vezes menor que
100 milissegundos. A tecnologia não limita o número de switches no anel e o tempo de convergência é
independente do número de switches. O que limita o tempo de convergência é a propagação das PDUs na
rede e o tratamento das mesmas nas CPUs dos switches do domínio.
2. Conceitos de operação
Um domínio EAPS existe somente em um anel Ethernet. Cada domínio possui somente um nó master
designado , e todos os outros nós são denominados Transit. Os switches do anel deverão ter duas portas
conectadas para ser formado um anel, uma porta será designada primária e a outra secundária.
2.1.1 Primária
É a porta que define por onde o tráfego irá ser comutado em caso do anel estar completo, além de
originar as PDUs de controle do domínio EAPS.
2.1.2 Secundária
No nó master, quando o anel está completo, a porta secundária permanece com link up, porém em
estado de bloqueio, não aprendendo endereços MAC e não enviando tráfego por ela. Neste estado somente
os protocolos de controle serão recebidos e tratados na CPU do switch.
2.4.1 Master
O switch master é quem controla as ações do anel, ditando o sentido do tráfego. Além disso, possui
a função de enviar PDUs de controle aos outros equipamentos da topologia. Os tempos de hellotime e
failtime tem relevância somente para ele.
2.4.2 Transit
Os switches transit recebem as PDUs de controle em uma das portas (primária ou secundária),
encaminhando pela outra porta do domínio. Para otimizar a convergência do protocolo EAPS o transit envia
a PDU de Link-Down para o master em caso de falha de qualquer porta configura no domínio.
Documento público
5
2.5 Timers
O EAPS possui somente dois timers, sendo eles Hellotime e Failtime.
2.5.1 Hellotime
O intervalo de tempo em que cada PDU de controle é enviada pelo master aos outros nós do domínio
EAPS varia de milissegundos até um minuto.
2.5.2 Failtime
Período de tempo máximo que a PDU healt-check, partindo da porta primária do master, poderá levar
para percorrer todo o anel até retornar a sua porta secundária. Caso o failtime expire o switch master
executará uma das ações mencionadas no item 2.6 conforme a configuração feita no master. O failtime
pode ser configurado no intervalo de milissegundos até um minuto.
2.6.1 Open-secondary-port
Utilizando este modo de configuração, após o timer de failtime expirar, o switch master muda seu estado
para falha “FAILED” desbloqueando a porta secundária.
2.6.2 Send-alert
Utilizando este modo de configuração, após o timer de failtime expirar, o switch master envia a PDU
Query-Link-Status nas suas portas primária e secundária a fim de perguntar para os switches Transit se
existe alguma falha em algum link. Se o Transit possuir falha responderá para o master com a PDU Link-
Down. O master recebendo a PDU Link-Down alterará o status do domínio EAPS para Failed
desbloqueando a porta secundária. Caso não receba a PDU Link-Down manterá a porta secundária
bloqueada.
Estado Descrição
IDLE Domínio EAPS no master/transit não está sendo executado ainda.
COMPLETE Switch master está com sua operação normal.
FAILED Switch master está em estado de falha.
Links-UP Switch transit está com suas duas portas UP.
Link-Down Switch transit está com uma ou duas portas DOWN.
PREFORWARDING Switch transit está em transição para Links-UP após ter perdido algum link.
INIT Switch master está com status de inicialização.
Modelo Domínios
DM2100 - EDD 4
DM3000 16
DM4000 64
DM4100 64
4. Funcionamento
Após demonstrar os conceitos de operação do protocolo será abordado o seu funcionamento com
exemplos em situações pertinentes ao protocolo.
Documento público
7
Figura 1: Domínio EAPS completo
Ao ocorrer uma falha de link no switch Transit 2, ele envia na VLAN de controle a PDU Link-Down com
intenção de avisar o switch master que houve uma falha de link. Cada switch Transit recebe a PDU em uma
porta do domínio, encaminha para a CPU e após tratá-la encaminha para a outra porta do domínio.
Quando a PDU Link-Down chega no master ele altera o status do domínio EAPS para Failed,
desbloqueia a porta secundária, faz o flush da sua tabela MAC e envia a PDU Ring-Down-Flush-FDB na
Documento público
8
VLAN de controle a fim de avisar todos os switches Transit a necessidade de realizar o flush na tabela MAC.
Após estes procedimentos o tráfego estará funcional novamente.
Documento público
9
Figura 4: Domínio EAPS com retorno do link
5. Exemplo de aplicação
Neste exemplo será demonstrado um cenário com quatro switches da linha DmSwitch em uma topologia
de anel, protegidos por uma domínio do protocolo EAPS. Baseado neste cenário será demonstrado as
configurações necessárias e os comandos disponíveis para troubleshooting.
Documento público
10
5.1 Configurações
Switch Master
Switch Transit 1
Switch Transit 2
Documento público
11
Switch Transit 3
Master#show eaps
EAPS information:
Mode: M - Master
T - Transit
Documento público
12
5.3 Troubleshooting
A linha DmSwitch possui o recurso de registro de enventos “logs” e debugs do EAPS para auxiliar o
troubleshooting. Neste capítulo será feito a análise de logs e debugs gerados em duas situações de falha,
sendo elas perda do link entre os switches Transit 2 e 3 e um ataque na CPU do switch Transit 2. O cenário
utilizado será o mesmo do item 4.
Dec 4 10:44:35 Transit2 : <5> EAPS 0 (sentido_horario) <Eth 1/ 2>: Link Down
Dec 4 10:44:35 Transit2 : <5> Interface Ethernet 1/2 changed state to down
(shutdown)
Dec 4 10:44:35 Transit2 : <5> EAPS <Eth 1/ 7>: Unblocked
Dec 4 10:44:35 Transit2 : <4> EAPS 0 (sentido_horario): RX RING DOWN FLUSH
generated by 00:04:DF:18:41:DF.
Dec 4 10:44:35 Transit2 : <5> EAPS <Eth 1/ 2>: Blocked
Os logs demonstram que o switch Transit 3 detecta a falha no link na porta 1/2 e depois recebe a PDU
Ring-Down-Flush-FDB enviada pelo master do domínio. Ao receber esta PDU o switch fará o flush da tabela
MAC.
Dec 4 10:44:35 Transit3 : <5> EAPS 0 (sentido_horario) <Eth 1/ 2>: Link Down
Dec 4 10:44:35 Transit3 : <5> Interface Ethernet 1/2 changed state to down
Dec 4 10:44:35 Transit3 : <4> EAPS 0 (sentido_horario): RX RING DOWN FLUSH
generated by 00:04:DF:18:41:DF.
Dec 4 10:44:35 Transit3 : <5> EAPS <Eth 1/ 1>: Unblocked
Dec 4 10:44:35 Transit3 : <5> EAPS <Eth 1/ 2>: Blocked
Os logs demonstram que o switch Transit 1 só recebe a PDU Ring-Down-Flush-FDB enviada pelo
master do domínio. Ao receber esta PDU o switch fará o flush da tabela MAC.
Os logs demonstram que o switch master altera o seu status de complete para failed após receber a
PDU de Link-Down desbloqueando a porta secundária 3/24.
Documento público
13
Master#show eaps detail
Domain ID: 0
Domain Name: sentido_horario
State: Complete (1 h, 32 m, 44 s) (FailTimer Expired)
Mode: Master
Packet Mode: Standard
Hello Timer interval: 1.0 sec
Fail Timer interval: 3.0 sec
Action after Fail Timer expiry: send-alert
Pre-forwarding Timer: 15 sec (learned) Remaining: 0 sec
Last update from: 00:04:DF:18:41:DF, Eth 3/24, Wed Dec 4 19:07:43
2013
Last seq. number received: 54670
Primary port: Eth3/23 (Up)
Secondary port: Eth3/24 (Blocked: EAPS)
Control VLAN ID: 4093
Protected VLAN group IDs: 1
Nos logs abaixo se nota que o switch começa a perder as PDUs de Healt-Check até que perde a
terceira em sequência que faz com que o failtimer expire e o master envie a PDU Query-Link-Status devido
a configuração do send-alert.
O switch Transit 2 não loga que recebeu a PDU Query-Link-Status por estar com a CPU alta e ainda
registra que perdeu algumas PDUs Healt-Check. A perda pode ser verificada pelo número de sequência das
PDUs.
Documento público
14
Dec 4 19:07:30 Transit2 : <4> EAPS 0 (sentido_horario): Got HEALTH CHECK
packet (Seq=54657)
Dec 4 19:07:43 Transit2 : <5> Total CPU usage (99.70%) remained above the
threshold of 90% during 15 seconds: rx_pkt(27.3%), netifd_s2c(22.3%),
pktc_rq7(16.0%)
Dec 4 19:07:47 Transit2 : <4> EAPS 0 (sentido_horario): Possible HEALTH CHECK
packet loss (Seq=54671)
Dec 4 19:07:57 Transit2 : <5> Total CPU usage (29.60%) remained below the
threshold of 90% during 15 seconds
O switch Transit 3 loga que perdeu uma PDU Healt-Check e recebeu uma PDU atrasada “Got HEALT
CHECK” além da PDU Query-Link-Status.
5.3.3 Debugs
Os debugs demonstram de uma forma mais detalhada a alteração de status e o recebimento e envio das
PDUs do protocolo.
O exemplo utiliza como base o cenário do item 4 onde foi forçado a perda do link entre o switch Transit 2
e 3 descrito no item 4.3.1 deste documento.
Nos switches é possível ver as PDUs recebidas e enviadas com o seu status, alteraçoes de status do
protocolo, flush da tabela MAC, entre outros.
Switch Master
Documento público
15
Dec 5 13:47:47.312165 : EAPS 0 (sentido_horario) <Eth 3/23>: Tx
Type=HEALTH_CHECK State=Failed Seq=56253
Dec 5 13:47:48.314007 : EAPS 0 (sentido_horario) <Eth 3/23>: Tx
Type=HEALTH_CHECK State=Failed Seq=56254
Dec 5 13:47:49.315884 : EAPS 0 (sentido_horario) <Eth 3/23>: Tx
Type=HEALTH_CHECK State=Failed Seq=56255
Switch Transit 1
Switch Transit 2
Documento público
16
generated by 00:04:DF:18:41:DF.
Dec 5 13:47:45.466455 : EAPS 0 (sentido_horario) <Eth 1/ 7>: L2/L3 Table
Flush
Dec 5 13:47:45.468199 : EAPS 0 (sentido_horario) <Eth 1/ 2>: L2/L3 Table
Flush
Dec 5 13:47:46.312264 : EAPS 0 (sentido_horario) <Eth 1/ 7>: Rx
Type=HEALTH_CHECK State=Failed Seq=56252
Dec 5 13:47:46.312317 : EAPS 0 (sentido_horario) <Eth 1/ 2>: Tx
Type=HEALTH_CHECK State=Failed Seq=56252
Dec 5 13:47:47.314359 : EAPS 0 (sentido_horario) <Eth 1/ 7>: Rx
Type=HEALTH_CHECK State=Failed Seq=56253
Dec 5 13:47:47.314411 : EAPS 0 (sentido_horario) <Eth 1/ 2>: Tx
Type=HEALTH_CHECK State=Failed Seq=56253
Switch Transit 3
Documento público
17
Figura 6: Balanceamento de tráfego do domínio 0
O EAPS do domínio 1 protegerá e comutará o tráfego das VLANs 2046 a 4092 que pertencem ao grupo
de VLANs 2. O tráfego será comutado no sentido , Transit 1, Transit 2 e Transit 3.
5.5 Configurações
Switch Master
Documento público
18
eaps 0
eaps 0 mode master
eaps 0 name sentido_horario
eaps 0 failtime action send-alert
eaps 0 port primary ethernet 3/23
eaps 0 port secondary ethernet 3/24
eaps 0 control-vlan id 4093
eaps 0 protected-vlans vlan-group 1
!
eaps 1
eaps 1 mode master
eaps 1 name sentido_anti-horario
eaps 1 failtime action send-alert
eaps 1 port primary ethernet 3/24
eaps 1 port secondary ethernet 3/23
eaps 1 control-vlan id 4094
eaps 1 protected-vlans vlan-group 2
Switch Transit 1
Switch Transit 2
Documento público
19
eaps 0 name sentido_horario
eaps 0 failtime action send-alert
eaps 0 port primary ethernet 1/7
eaps 0 port secondary ethernet 1/2
eaps 0 control-vlan id 4093
eaps 0 protected-vlans vlan-group 1
!
eaps 1
eaps 1 name sentido_anti-horario
eaps 1 failtime action send-alert
eaps 1 port primary ethernet 1/2
eaps 1 port secondary ethernet 1/7
eaps 1 control-vlan id 4094
eaps 1 protected-vlans vlan-group 2
Switch Transit 3
Documento público
20
6. Conclusão
Não existe limitação quanto ao número máximo de switches que podem ser utilizados em um domínio
EAPS. Em uma rede controlada, pode-se observar que o envio e recebimento das PDUs é eficiente, mesmo
em um anel com uma grande quantidade de elementos.
Porém, observa-se que, em uma topologia onde existem muitos clientes conectados, com diversos tipos
de tráfego, não é possível prever o comportamento da CPU de cada switch membro do domínio EAPS. Isso,
principalmente, se houver endereços IP configurados em distintas VLANs ou mesmo na gerência.
Se um switch estiver tratando muitos pacotes na CPU, poderá atrasar o envio das PDUs, o que
ocasionará a abertura do anel mesmo que não possua falha em algum link, o que torna importante
configurar o failtime action com a opção send-alert nos domínios EAPS. Quanto maior o anel maior a
probabilidade de ocorrer atrasos na entrega e processamento de PDUs do protocolo.
Em condições normais, um switch DM3000 leva em média 6ms (milissegundos) para tratar uma PDU,
sendo que isto inclui recebê-la, tratá-la e encaminhar para interface de saída. Se a CPU estiver sob ataque
com consumo de 100%, levará em média 150ms para fazer a mesma operação, podendo levar até 550ms
no pior caso. Esse tempo deve ser levado em consideração na hora do planejamento da rede. No EDD os
tempos são de 5,3ms em condições normais de uso da CPU e ao utilizar o "hw-forwarding" será de acordo
com o tempo de comutação em hardware, próximos a 5us (microssegundos). No DM4004 os tempos são de
5,3ms para condições normais.
Com as medidas relatas neste documento é possível definir a quantidade de elementos em um domínio
EAPS de acordo com o tempo de convergência desejado. Supondo um cenário com condições ideais de
processamento com 10 nós no domínio EAPS a convergência será de 50 milissegundos, não levando em
conta atraso na propagação das PDUs ocasionados por links com maior latência de transmissão, como por
exemplo links de rádio.
Documento público
21
7. Referências
RFC 3619 (http://tools.ietf.org/html/rfc3619)
RFC 3619 Versão 1.3 Draft (http://tools.ietf.org/html/draft-shah-extreme-rfc3619bis-02)
Documento público
22