Datacom - EAPS, funcionamento, troubleshooting e aplicação

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 Portas do domínio

As informações da porta primária e secundária são importantes no swich master. No transit, não importa
a ordem das portas (primária e secundária). No entanto para manter a organização e facilitar o
troubleshooting, o ideal é manter a configuração das portas em um mesmo sentido (recebendo dados pela
primária e encaminhando pela 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.2 VLAN de controle

Para cada domínio EAPS deverá ser criada uma VLAN de controle. As PDUs relativas ao domínio serão
comutadas para esta VLAN. As portas primária e secundária deverão ser membros tagged dessa VLAN.
2.3 VLANs protegidas

Todas as VLANs exceto a de controle deverão ser protegidas pelo EAPS a fim de evitar loop. O loop
acontecerá caso uma nova VLAN seja criada no anel e não esteja protegida. As VLANs são protegidas na
linha DmSwitch através de VLAN Groups.
2.4 Modo de operação
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 Failtime Action

Após expirar o timer de failtime o master poderá tomar duas ações diferentes, sendo elas open-
secondary-port (default) ou send-alert.
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.
2.7 Estados do protocolo

O EAPS possui alguns estados que para devida compreensão do seu funcionamento é importante saber
qual sua finalidade.
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.
Tabela 1: Estados do protocolo
2.8 Interação com outros protocolos

Na linha DmSwitch quando foi implementado o protocolos EAPS não foi previsto a interação de outros
protocolos de bloqueio de link (Por Exemplo: OAM, Link-Flap e Loopback-Detection) com o EAPS. A partir
do firmware 11.2 foi incluído o comando “eaps <domain_id> port-block-aware” para realizar esta interação,
este comando está por padrão desabilitado nos domínios EAPS. Nos firmwares superiores a 13.0 será
Documento público
6
removido o comando tornando a interação entre os protocolos ativa não podendo ser desabilitado.
2.9 EAPS hardware forwarding no EDD

A utilização do EAPS na linha de switches EDD é feita da mesma forma que as demais linhas DmSwitch.
No entanto existe uma funcionalidade do EAPS que somente é presente na linha EDD chamada de "hw-
forwarding". Esta funcionalidade tem o objetivo de melhorar a performance de convergência no anel. Como
já explicado anteriormente, cada switch do domínio EAPS recebe as PDUs na CPU para tratar e
encaminhar para uma determinada porta. A configuração de "hw-forwarding" desabilita o tratamento das
PDUs pela CPU enviando estes pacotes como DLF, evitando o atraso de processamento e
encaminhamento feito pela CPU do equipamento. Para habilitar esta funcionalidade deverá ser removido a
configuração de storm-control nas interfaces do anel EAPS utilizando o comando “no switchport storm-
control dlf”.
Apesar do benefício na convergência do anel EAPS, não se recomenda o uso da funcionalidade "hw-
forwarding", pois é necessário retirar a proteção de storm-control DLF a qual protege a rede do
encaminhamento de pacotes unicast por flood durante o aprendizado de MACs nos equipamentos
envolvidos. Além disso, perdem-se os registro de eventos relativas às PDUs de controle do EAPS, as quais
não estão sendo processadas. A configuração do hw-forwarding é feito por domínio EAPS.
eaps <ID_domínio_EAPS> hw-forwarding
3. Quantidade de domínios suportados

A linha DmSwitch possui limites de domínios EAPS diferentes de acordo com os modelos. Segue a
tabela com a relação de modelo e quantidade de domínios suportados.
Modelo Domínios
DM2100 - EDD 4
DM3000 16
DM4000 64
DM4100 64
Tabela 2: Quantidade de domínios EAPS
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.
4.1 Situação normal de operação

O master envia a PDU Healt-Check na sua porta primária regularmente a cada um segundo por padrão.
Cada switch Transit recebe a PDU em uma de suas portas, encaminha para a CPU para ser tratado e
depois encaminha para a outra porta do domínio EAPS. Após a PDU chegar na porta secundária do master,
o master bloqueia a porta secundária. Quando o status do master está completo e for recebido a PDU Healt-
Check é resetado o fail-timer. Este timer é utilizado para determinar se o failtime foi atingido, que por padrão
é três segundos. Com os valores do hellotime e failtime padrão poderia ser perdido duas PDUs Healt-Check
até ser tomado uma das ações do failtime mencionadas no item 2.6.
4.2 Queda de link no Transit
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.
Figura 2: Domínio EAPS com perda de link
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.
Figura 3: Domínio EAPS com perda de link 2
4.3 Retorno do link no Transit

Mesmo o EAPS estando em estado de falha, o switch master continua enviando regulamente a PDU
Healt-Check na sua porta primária para agilizar a convergência quando o link que está em falha voltar a
operar normalmente. A próxima PDU Healt-Check que chegar na porta secundária após o link ser
restabelecido fará com que o master mude o status do domínio para complete, realizando os procedimentos
de bloqueio da porta secundária, flush da sua tabela MAC e envio da PDU Ring-Up-Flush-FDB para os nós
Transit instruindo-os a fazer o flush da tabela MAC com intenção de reaprender a topologia.
Durante o tempo entre o Transit detectar que o link foi estabelecido e o master detectar que o anel foi
restabelecido, a porta secundária do master estará desbloqueada, ocasionando loop. Para prevenir loop, o
Transit bloqueia a porta que estava em falha e entra no estado de "preforwarding. Quando o Transit está no
status preforwarding e recebe a PDU (Ring-UP-Flush-FDB) instruindo-o para fazer o flush da tabela MAC,
ele faz o flush da tabela MAC, desbloqueia a porta e altera o seu status para operacional (Links-UP).
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.
Figura 5: Exemplo de Aplicação
Documento público
10
5.1 Configurações
Switch Master
interface vlan 4093

set-member tagged ethernet range 3/23 3/24
!
vlan-group 1
vlan-group 1 vlan range 1 4092
vlan-group 1 vlan 4094
!
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
Switch Transit 1
interface vlan 4093

set-member tagged ethernet 4/1
!
vlan-group 1
!
eaps 0
Switch Transit 2
interface vlan 4093

!
vlan-group 1
!
eaps 0
Documento público
11
Switch Transit 3
interface vlan 4093

!
vlan-group 1
!
eaps 0
5.2 Comandos de verificação

O comando de verificação “show eaps” mostra as informações referente aos domínios EAPS. Na saída
do comando é possível verificar o status do protocolo, além das configurações do equipamento por domínio.
Master#show eaps
EAPS information:
Mode: M - Master
T - Transit
Pri Sec Ctrl Protected

ID Domain State Mode Port Port VLAN Groups/VLANs
-- --------------- --------------- ---- ------ ------ ---- ------------
0 sentido_horario Complete M 3/23 3/24 4093 1/4093
Existe a opção “detail” do comando que demonstra informações importantes adicionais, como tempo
desde a última alteração de status do protocolo, de quem e quando foi recebido a última PDU Healt-Check e
os estados das portas primária e secundária em relação ao bloqueio da porta. As portas podem estar
operacionais “UP” ou bloqueada por algum protocolo. Portas bloqueadas recebem PDUs de protocolos, mas
não aprendem MACs ou encaminham tráfego. No caso de um domínio EAPS estar completo o master
manterá a porta secundária bloqueada “Blocked: EAPS”.
Master#show eaps detail

Domain ID: 0
Domain Name: sentido_horario
State: Complete (1 h, 32 m, 16 s)
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, Tue Dec 3 11:19:55
2013
Last seq. number received: 5884
Primary port: Eth3/23 (Up)
Secondary port: Eth3/24 (Blocked: EAPS)
Control VLAN ID: 4093
Protected VLAN group IDs: 1
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.
5.3.1 Perda do link entre os switches Transit 2 e 3

Os logs demonstram que o switch Transit 2 detecta a falha no link devido a execução do comando
shutdown 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 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 : <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.
Dec 4 10:44:35 Master : <4> EAPS 0 (sentido_horario): change state to FAILED.

Reason: Frame RX Link Down.
Dec 4 10:44:35 Master : <4> EAPS 0 (sentido_horario): changed to state
FAILED.
Dec 4 10:44:35 Master : <5> EAPS <Eth 3/24>: Unblocked
5.3.2 Perda das PDUs Healt-Check com ataque na CPU do Transit 2

O switch Transit 2 receberá um ataque com tráfego possuindo 802.1p 7 a fim de concorrer com o
protocolo EAPS em uma VLAN que possui IP no switch.
Após a falha o switch master sinaliza que o domínio está completo, no entanto o failtimer expirou
“Failtimer Expired”.
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.
Dec 4 19:07:32 Master : <4> EAPS 0 (sentido_horario): Possible control packet

loss (FailCount=1.0s, Seq= 54658)
Dec 4 19:07:47 Master : <4> EAPS 0 (sentido_horario): FailTime reached,
querying other nodes via QUERY LINK STATUS PDU
O switch Transit 1 loga que recebeu a PDU Query-Link-Status
Dec 4 19:07:47 Transit1 : <4> EAPS 0 (sentido_horario): QUERY LINK STATUS

packet received
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.
Dec 4 19:07:30 Transit3 : <4> EAPS 0 (sentido_horario): Got HEALTH CHECK

packet (Seq=54657)
Dec 4 19:07:47 Transit3 : <4> EAPS 0 (sentido_horario): QUERY LINK STATUS
packet received
Dec 4 19:07:47 Transit3 : <4> EAPS 0 (sentido_horario): Possible HEALTH CHECK
packet loss (Seq=54671)
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
Dec 5 13:47:45.308517 : EAPS 0 (sentido_horario) <Eth 3/23>: Tx

Type=HEALTH_CHECK State=Complete Seq=56251
Dec 5 13:47:45.311754 : EAPS 0 (sentido_horario) <Eth 3/24>: Rx
Type=LINK_DOWN State=Links-Down Seq=0
Dec 5 13:47:45.453991 : EAPS 0 (sentido_horario): change state to FAILED.
Reason: Frame RX Link Down.
Dec 5 13:47:45.454164 : EAPS 0 (sentido_horario): State Change: Complete ->

Failed
Dec 5 13:47:45.454186 : EAPS 0 (sentido_horario): changed to state FAILED.
Dec 5 13:47:45.454276 : EAPS 0 (sentido_horario) <Eth 3/24>: Unblocked

Dec 5 13:47:45.454296 : EAPS <Eth 3/24>: Unblocked
Type=RING_DOWN State=Failed Seq=56251
Dec 5 13:47:45.463409 : EAPS 0 (sentido_horario) <Eth 3/23>: L2/L3 Table
Flush
Type=HEALTH_CHECK State=Failed Seq=56252
Documento público
15
Switch Transit 1
Dec 5 13:47:45.309611 : EAPS 0 (sentido_horario) <Eth 4/ 1>: Rx

Dec 5 13:47:45.309653 : EAPS 0 (sentido_horario) <Eth 4/ 8>: Tx
Dec 5 13:47:45.464113 : EAPS 0 (sentido_horario): RX RING DOWN FLUSH
Dec 5 13:47:45.464291 : EAPS 0 (sentido_horario) <Eth 4/ 1>: L2/L3 Table

Flush
Flush
Switch Transit 2

Dec 5 13:47:45.440608 : EAPS 0 (sentido_horario) <Eth 1/ 2>: Link Down
Dec 5 13:47:45.440803 : EAPS 0 (sentido_horario): State Change: Links-Up ->
Links-Down
Flush
Dec 5 13:47:45.454810 : EAPS 0 (sentido_horario) <Eth 1/ 7>: Unblocked
Dec 5 13:47:45.454889 : EAPS <Eth 1/ 7>: Unblocked
Dec 5 13:47:45.465459 : EAPS 0 (sentido_horario) <Eth 1/ 2>: Blocked
Dec 5 13:47:45.465544 : EAPS <Eth 1/ 2>: Blocked
Documento público
16
Flush
Flush
Switch Transit 3

Dec 5 13:47:45.453629 : EAPS 0 (sentido_horario) <Eth 1/ 2>: Link Down
Dec 5 13:47:45.453846 : EAPS 0 (sentido_horario): State Change: Links-Up ->
Links-Down
Flush
Dec 5 13:47:45.463234 : EAPS 0 (sentido_horario) <Eth 1/ 1>: Unblocked

Flush
Flush
Dec 5 13:47:45.474894 : EAPS <Eth 1/ 1>: Unblocked
Dec 5 13:47:45.478988 : EAPS 0 (sentido_horario) <Eth 1/ 2>: Blocked
Dec 5 13:47:45.481489 : EAPS <Eth 1/ 2>: Blocked
5.4 Cenário com balanceamento de tráfego

Um recurso muito utilizado para balanceamento de carga no anel, é a criação dois domínios de EAPS,
cada um em um sentido do anel. Dessa forma, um domínio protege um grupo de VLANs e o outro, as
demais. Para isso, a porta primária de um domínio do EAPS será a secundária da outra, e vice-versa.
Assim, pode-se otimizar o uso obtendo até o dobro da capacidade do anel. Por exemplo, com uso do
balanceamento de carga num anel de 1 Gbps, pode-se transportar até 2 Gbps, utilizando link full duplex.
No exemplo proposto o EAPS do domínio 0 protegerá e comutará o tráfego das VLANs 1 a 2045 que
pertencem ao grupo de VLANs 1. O tráfego será comutado no sentido Master, Transit 3, Transit 2 e Transit
1.
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.
Figura 7: Balanceamento de tráfego do domínio 1
5.5 Configurações
Switch Master
interface vlan range 4093 4094

!
vlan-group 1
vlan-group 2
!
Documento público
18
eaps 0
eaps 0 mode master
!
eaps 1
eaps 1 mode master
eaps 1 name sentido_anti-horario
Switch Transit 1

!
vlan-group 1
vlan-group 2
!
eaps 0
!
eaps 1
Switch Transit 2

!
vlan-group 1
vlan-group 2
!
eaps 0
Documento público
19
!
eaps 1
Switch Transit 3

!
vlan-group 1
vlan-group 2
!
eaps 0
!
eaps 1
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

Datacom - EAPS, funcionamento, troubleshooting e aplicação

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Datacom - EAPS, funcionamento, troubleshooting e aplicação

Enviado por

Direitos autorais:

Formatos disponíveis

EAPS

Funcionamento, troubleshooting e aplicação.

2.1 Portas do domínio

2.2 VLAN de controle

2.3 VLANs protegidas

2.4 Modo de operação

2.6 Failtime Action

2.7 Estados do protocolo

Tabela 1: Estados do protocolo

2.8 Interação com outros protocolos

2.9 EAPS hardware forwarding no EDD

eaps <ID_domínio_EAPS> hw-forwarding

3. Quantidade de domínios suportados

Tabela 2: Quantidade de domínios EAPS

4.1 Situação normal de operação

4.2 Queda de link no Transit

Figura 2: Domínio EAPS com perda de link

Figura 3: Domínio EAPS com perda de link 2

4.3 Retorno do link no Transit

Figura 5: Exemplo de Aplicação

interface vlan 4093

interface vlan 4093

interface vlan 4093

interface vlan 4093

5.2 Comandos de verificação

Pri Sec Ctrl Protected

Master#show eaps detail

5.3.1 Perda do link entre os switches Transit 2 e 3

Dec 4 10:44:35 Transit1 : <4> EAPS 0 (sentido_horario): RX RING DOWN FLUSH

Dec 4 10:44:35 Master : <4> EAPS 0 (sentido_horario): change state to FAILED.

5.3.2 Perda das PDUs Healt-Check com ataque na CPU do Transit 2

Dec 4 19:07:32 Master : <4> EAPS 0 (sentido_horario): Possible control packet

O switch Transit 1 loga que recebeu a PDU Query-Link-Status

Dec 4 19:07:47 Transit1 : <4> EAPS 0 (sentido_horario): QUERY LINK STATUS

Dec 4 19:07:30 Transit3 : <4> EAPS 0 (sentido_horario): Got HEALTH CHECK

Dec 5 13:47:45.308517 : EAPS 0 (sentido_horario) <Eth 3/23>: Tx

Dec 5 13:47:45.454164 : EAPS 0 (sentido_horario): State Change: Complete ->

Dec 5 13:47:45.454276 : EAPS 0 (sentido_horario) <Eth 3/24>: Unblocked

Dec 5 13:47:45.309611 : EAPS 0 (sentido_horario) <Eth 4/ 1>: Rx

Dec 5 13:47:45.464291 : EAPS 0 (sentido_horario) <Eth 4/ 1>: L2/L3 Table

Dec 5 13:47:45.310401 : EAPS 0 (sentido_horario) <Eth 1/ 7>: Rx

Dec 5 13:47:45.310811 : EAPS 0 (sentido_horario) <Eth 1/ 2>: Rx

Dec 5 13:47:45.464054 : EAPS 0 (sentido_horario) <Eth 1/ 2>: L2/L3 Table

5.4 Cenário com balanceamento de tráfego

Figura 7: Balanceamento de tráfego do domínio 1

interface vlan range 4093 4094

interface vlan range 4093 4094

interface vlan range 4093 4094

interface vlan range 4093 4094

Você também pode gostar