Application Notes: EAPS
Ethernet Automatic Protection Switching
Application Notes: EAPS
Ethernet Automatic Protection Switching
Documento de Uso Público. Data 15/07/2010, Revisão 1.2
Parecer
Introdução
Firmware
Desenvolvimento
Exemplo 1: EAPS com uma instância
Analisando e entendo os logs
Analisando e entendo os debugs
Exemplo 2: EAPS com duas instância
Exemplo 3: EAPS no EDD
Considerações Finais
Parecer
Este documento explica o funcionamento do EAPS (Ethernet Automatic Protection Switching) e mostra
como analisar os debugs e logs, para depurar as causas de problemas em caso de falha.
Introdução
O EAPS é um protocolo de proteção contra loop em topologias no formato de anel, onde um switch,
chamado de master, será o controlador da rede. Este switch possui as mesmas configurações de EAPS dos
demais equipamentos do anel, diferenciando-se apenas pela designação de master e que possui a função de
enviar BPDUs de controle a cada segundo ou milisegundo, chamado de hellotime. Esta BPDU é enviada
através de uma das interfaces do master, designada como "porta primária". Estes pacotes de controle serão
recebidos por cada equipamento que compõem o anel em sequência até chegarem na porta de recepção do
master, designada porta secundária. Se por algum motivo os pacotes de controle não chegarem nesta
interface secundária em um período de tempo máximo chamado failtime esta porta secundária será
desbloqueada. Quando o anel está completo e funcional, esta porta permanece com link UP porém em
estado bloqueado, não aprendendo endereços MAC nem enviando tráfego por ela.
O master é quem detém todas as ações do anel, é ele quem dita o sentido do tráfego, e é para ele que
importa os tempos de hellotime e failtime. No transit não importará se a ordem das portas não estiverem
no mesmo sentido do master, fazendo com que ele apenas receba a BPDU em uma das portas e encaminhe
pela outra, sendo esta primary ou secondary. É claro que para se manter uma organização, e facilitar na
depuração de problemas, o ideal é manter a configuração das portas em um mesmo sentido.
DATACOM
1
Documento de Uso Público
Para otimizar a convergência do protocolo EAPS os equipamentos intermediários, designados transit,
enviam uma BPDU especial para o master em caso de falha de qualquer link, fazendo com que a
convergência seja de aproximadamente 50ms. Este tempo pode variar, de acordo com as configurações
utilizadas nos switches, como por exemplo a quantidade de vlans ou tipo de interface em uso.
Se o EAPS for o único protocolo de proteção utilizado no switch, todas as vlans (exceto a de controle)
deverão estar protegidas pelo EAPS. Caso contrário, se uma VLAN não protegida for criada no anel, o
mesmo entrará em loop.
Um artifício muito utilizado, para balaceamento de carga no anel, é a criação de duas instâncias de EAPS,
cada uma em um sentido do anel. Desta forma uma instância protege um grupo de vlans, e a outra as
demais. A porta primária de uma instância do EAPS será a secundária da outra, e vice-versa. Esta é uma
forma de otimizar a capacidade do anel, podendo-se ter até o dobro da capacidade de cada link, como
por-exemplo num anel de 1 Gbps pode-se transportar até 2 Gbps, dependendo também dos pontos de
entrada de tráfego. Isto pois neste caso tem-se um link de 1 Gbps full duplex.
Topologia:
Firmware
Version
Date
7.8.6
14/07/2010
DATACOM
2
Documento de Uso Público
Podem haver algumas diferenças nos logs e debugs de firmwares anteriores a 7.8.2. Nesta versão
foram feitas melhorias, que deixaram os logs e debugs mais completos e claros.
Desenvolvimento
Capacidade de instâncias, de acordo com o modelo:
Modelo Instâncias
Dm3000
16
Dm4000
64
Exemplo 1: EAPS com uma instância
Neste primeiro exemplo será demonstrada uma topologia, onde quatro switches dm3000 estão ligados em
anel, e protegidos por uma intância de EAPS. Baseados nesta topologia, mostra-se a utilização dos debugs,
para troubleshooting e as configurações necessárias para utilização do EAPS.
DATACOM
3
Documento de Uso Público
Configuração:
interface vlan 4094
name CONTROL_EAPS1
set-member tagged ethernet range 1/27 1/28
!
vlan-group 1
vlan-group 1 vlan range 1 4093
!
eaps 1
eaps 1 mode master
eaps 1 name EAPS1
eaps 1 port primary ethernet 1/28
eaps 1 port secondary ethernet 1/27
eaps 1 control-vlan id 4094
eaps 1 protected-vlans vlan-group 1
!
As configurações de hellotime e failtime, por default, são de 1 segundo e 3 segundos,
respectivamente. Estas configurações podem ser visualizadas como demonstrado abaixo:
DM3000_A#show eaps detail
Domain ID:
Domain Name:
State:
Mode:
Hello Timer interval:
Fail Timer interval:
Pre-forwarding Timer:
Last update from:
Last seq. number received:
Primary port:
Secondary port:
Control VLAN ID:
Protected VLAN group IDs:
1
EAPS1
Complete
Master
1.0 sec
3.0 sec
6 sec (learned) Remaining:
00:04:DF:12:8A:29, Eth 1/27,
4512
Eth1/28
Port status:
Eth1/27
Port status:
4094
1
0 sec
Fri Jun 25 17:08:22 2010
Up
Blocked
Este comando "show eaps detail", mostra as informações completas de cada instância do EAPS, bem
como número da instância, nome do domínio, estado do EAPS, se é master ou transit, hellotime e
failtime, pre-forwarding timer, horário da última BPDU recebida, ID da última BPDU, portas
primária e secundária, vlan de controle e vlan-groups protegidos.
Uma forma mais simplificada para analisar-se o estado do EAPS é com um "show eaps":
DM3000_A#show eaps
EAPS information:
Mode: M - Master
T - Transit
ID
-1
DATACOM
Domain
--------------EAPS1
State
--------------Complete
4
Mode
---M
Pri
Port
-----1/28
Sec
Port
-----1/27
Ctrl
VLAN
---4094
Protected
Groups/VLANs
-----------1/4093
Documento de Uso Público
Para alterar a configuração padrão de hellotime e failtime para milessegundos, deve-se configurar em
"0" segundos e então selecionar quantos milesegundos.
DM3000_A#configure
DM3000_A(config)#eaps 1 failtime <?>
0-60 Number of seconds
DM3000_A(config)#eaps 1 failtime 0 milliseconds <?>
0-900 Fraction of seconds (valid only for seconds equal to zero)
DM3000_A(config)#eaps 1 hellotime 0 milliseconds <?>
0-900 Fraction of seconds (valid only for seconds equal to zero)
Analisando e entendo os logs
Logs do master:
Quando alguma inerface do anel mudar seu estado para down, o master recebe um aviso:
Jun 25 17:28:34 DM3000_106 : <4> EAPS 1 (EAPS1): LINK DOWN packet received on Eth 1/27
Se um pacote for perdido, o master irá registrar 1 failcount e o ID do pacote perdido. Esta
mensagem também pode ser gerada para o atraso no recebimento de um pacote de controle
acima do esperado:
Jun 25 17:28:33 DM3000_106 : <4> EAPS 1 (EAPS1): Possible control packet loss (FailCount=1.0s, Seq=5612)
Caso 3 pacotes sejam perdidos na sequência, no failtime padrão, o EAPS irá falhar:
Jun
Jun
Jun
Jun
Jun
28
28
28
28
28
11:11:14
11:11:15
11:11:16
11:11:16
11:11:27
DM3000_106
DM3000_106
DM3000_106
DM3000_106
DM3000_106
:
:
:
:
:
<4>
<4>
<4>
<4>
<6>
EAPS
EAPS
EAPS
EAPS
EAPS
1
1
1
1
1
(EAPS1): Possible control packet loss (FailCount=1.0s, Seq=14668)
(EAPS1): Possible control packet loss (FailCount=2.0s, Seq=14669)
(EAPS1): Possible control packet loss (FailCount=3.0s, Seq=14670)
(EAPS1) changed to state FAILED.
(EAPS1) changed to state COMPLETE.
Logs do transit:
Quando um ou vários pacotes são perdidos, é registrado um log com o primeiro pacote perdido da
sequência. Quando voltar a receber os pacotes, então é registrado um log com o primerio pacote da
sequencia recebido.
Jun 28 11:11:13 DM3000L2_104 : <4> EAPS 1: Possible HEALTH CHECK packet loss (Seq=14668)
Jun 28 11:11:27 DM3000L2_104 : <4> EAPS 1: Got HEALTH CHECK packet (Seq=14681)
Analisando e entendo os debugs
Debug eaps do master:
Utilizando o "debug eaps", pode-se ver os pacotes sendo recebidos pela interface 1/27 e sendo
enviados pela 1/28. Pode-se observar que a BPDU de número 14668 é enviada, mas não é recebida.
Após a perda de três pacotes, o estado muda de complete para failed, e a porta secundária (1/27) é
desbloqueada. Ocorre então um flush nas tabelas L2 e L3, onde os endereços MAC das portas
primária e secundária são apagados e reaprendidos. Quando o master voltar a receber as BPDUs, o
estado irá voltar para complete, a porta secundária é bloqueada e é feito um novo flush nas tabelas L2
e L3 das portas envolvidas no anel.
DATACOM
5
Documento de Uso Público
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
11:11:11.914999
11:11:11.921823
11:11:13.015012
11:11:14.116302
11:11:14.117561
11:11:15.215032
11:11:15.216186
11:11:16.315016
11:11:16.316162
11:11:16.424822
11:11:16.425806
11:11:16.426825
11:11:16.428090
11:11:16.429247
11:11:17.565043
11:11:18.665045
11:11:19.765057
11:11:20.865043
11:11:21.965055
11:11:23.065051
11:11:24.165055
11:11:25.265031
11:11:26.365055
11:11:27.465042
11:11:27.481463
11:11:27.481716
11:11:27.482646
11:11:27.483524
11:11:27.484510
11:11:27.485753
11:11:27.511262
11:11:28.565056
11:11:28.573336
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Complete
Seq=14667
(EAPS1) <Eth 1/27>: Rx Type=HEALTH_CHECK
State=Complete
Seq=14667
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Complete
Seq=14668
(EAPS1): Warning: Possible control packet loss (FailCount=1.0s, Seq=14668)
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Complete
Seq=14669
(EAPS1): Warning: Possible control packet loss (FailCount=2.0s, Seq=14669)
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Complete
Seq=14670
(EAPS1): Warning: Possible control packet loss (FailCount=3.0s, Seq=14670)
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Complete
Seq=14671
(EAPS1) State Change: Complete -> Failed
(EAPS1) <Eth 1/27>: Unblocked
(EAPS1) <Eth 1/28>: Tx Type=RING_DOWN
State=Failed
Seq=14671
(EAPS1) <Eth 1/27>: Tx Type=RING_DOWN
State=Failed
Seq=14671
(EAPS1) <Eth 1/28>: L2/L3 Table Flush
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
Seq=14672
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
Seq=14673
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
Seq=14674
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
Seq=14675
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
Seq=14676
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
Seq=14677
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
Seq=14678
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
Seq=14679
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
Seq=14680
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
Seq=14681
(EAPS1) <Eth 1/27>: Rx Type=HEALTH_CHECK
State=Failed
Seq=14681
(EAPS1) State Change: Failed -> Complete
(EAPS1) <Eth 1/27>: Blocked
(EAPS1) <Eth 1/28>: Unblocked
(EAPS1) <Eth 1/28>: Tx Type=RING_UP
State=Complete
Seq=14681
(EAPS1) <Eth 1/27>: L2/L3 Table Flush
(EAPS1) <Eth 1/27>: Rx Type=RING_UP
State=Complete
Seq=14681
(EAPS1) <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Complete
Seq=14682
(EAPS1) <Eth 1/27>: Rx Type=HEALTH_CHECK
State=Complete
Seq=14682
Debug eaps do transit:
O debug no switch TRANSIT é bem semelhante sendo que a única diferença é que não existe bloqueio
e desbloqueio de portas.
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
Jun
28
28
28
28
28
28
28
28
28
28
28
28
28
28
28
11:11:11.919190
11:11:11.919671
11:11:13.511686
11:11:16.429254
11:11:16.429734
11:11:16.430934
11:11:16.469446
11:11:27.470075
11:11:27.470539
11:11:27.478744
11:11:27.489374
11:11:27.489850
11:11:27.491048
11:11:27.526352
11:11:28.570019
:
:
:
:
:
:
:
:
:
:
:
:
:
:
:
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
EAPS
1 <Eth 1/27>: Rx Type=HEALTH_CHECK
State=Complete
1 <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Complete
1: Warning: possible HEALTH CHECK packet loss (Seq=14668)
1 <Eth 1/28>: Rx Type=RING_DOWN
State=Failed
1 <Eth 1/27>: Tx Type=RING_DOWN
State=Failed
1 <Eth 1/28>: L2/L3 Table Flush
1 <Eth 1/27>: L2/L3 Table Flush
1 <Eth 1/27>: Rx Type=HEALTH_CHECK
State=Failed
1: Got HEALTH CHECK packet (Seq=14681)
1 <Eth 1/28>: Tx Type=HEALTH_CHECK
State=Failed
1 <Eth 1/27>: Rx Type=RING_UP
State=Complete
1 <Eth 1/28>: Tx Type=RING_UP
State=Complete
1 <Eth 1/28>: L2/L3 Table Flush
1 <Eth 1/27>: L2/L3 Table Flush
1 <Eth 1/27>: Rx Type=HEALTH_CHECK
State=Complete
Seq=14667
Seq=14667
Seq=14671
Seq=14671
Seq=14681
Seq=14681
Seq=14681
Seq=14681
Seq=14682
Exemplo 2: EAPS com duas instância
Como já mencionado neste documento, a utilização de duas instâncias em um anel é uma forma de ampliar
a capacidade do anel. Analisando-se a topologia abaixo, caso fosse utilizada apenas uma instância, todo o
tráfego dos switches B, C e D se somariam no link final, entre A e B, ou A e D. Usando duas instâncias,
podemos fazer uma balanceamento deste tráfego, encaminhando parte do tráfego do switch C no sentido
de D e outra parte no sentido de B. E até mesmo encaminhar algum tráfego de B ou D pelo sentido inverso
(caminho mais longo), caso o link ligado diretamente ao master já esteja no limite de sua capacidade.
DATACOM
6
Documento de Uso Público
A necessidade de refazer o balanceamento do tráfego, quando o link atinge seu limite, é muito comum.
Para isto basta saber as vlans que necessitarão o redirecionamento no anel, e então movê-las para o
vlan-group protegido pela outra instância e fazer um "clear mac-address-table", para fazer um flush
forçado nas tabelas de L2, fazendo-se com que os endereços MAC sejam aprendidos de acordo com o
novo sentido do anel. Para esta alteração, todo procedimento é realizado no MASTER, não necessitando
qualquer interação nos switches TRANSIT. O ideal é que depois de executada a manobra, por uma questão
de organização, se padronize as configurações, deixando todos membros do anel com as mesmas
configurações.
Configuração:
interface vlan 4093
name CONTROL_EAPS2
set-member tagged ethernet range 1/27 1/28
!
interface vlan 4094
name CONTROL_EAPS1
set-member tagged ethernet range 1/27 1/28
!
vlan-group 1
vlan-group 1 vlan range 1 2000
vlan-group 2
vlan-group 2 vlan range 2001 4092
!
DATACOM
7
Documento de Uso Público
eaps
eaps
eaps
eaps
eaps
eaps
eaps
!
eaps
eaps
eaps
eaps
eaps
eaps
eaps
1
1
1
1
1
1
1
mode master
name EAPS1
port primary ethernet 1/28
port secondary ethernet 1/27
control-vlan id 4094
protected-vlans vlan-group 1
2
2
2
2
2
2
2
mode master
name EAPS2
port primary ethernet 1/27
port secondary ethernet 1/28
control-vlan id 4093
protected-vlans vlan-group 2
DM3000_A#show eaps
EAPS information:
Mode: M - Master
T - Transit
ID
-1
2
Domain
--------------EAPS1
EAPS2
State
--------------Complete
Complete
Mode
---M
M
Pri
Port
-----1/28
1/27
Sec
Port
-----1/27
1/28
Ctrl
VLAN
---4094
4093
Protected
Groups/VLANs
-----------1/1999
1/2092
Exemplo 3: EAPS no EDD
A utilização do EAPS na linha de equipamentos EDD (Ethernet Demarcation Device) é feita da mesma
forma que nos switches, porém neste equipamento existe uma feature diferente conhecida como
"hw-forwarding", que visa melhorar a performance da convergência do anel. Como já foi explicado, cada
switch membro do anel recebe a BPDU e trata este pacote na CPU. Esta configuração de "hw-forwarding"
desabilita o tratamento desta BPDU pela CPU, enviando estes pacotes como um DLF e evitando o delay
de processamento da CPU. A única questão é que na utilização desta funcionalidade deve-se cuidar as
limitações de storm-control das portas, que por default no EDD são de 256Kbs. Então se o tráfego DLF
estiver perto deste limite, estas BPDUs poderão ser perdidas e causar a abertura do anel, o que ocasionaria
um loop na rede. Outra questão a ser salientada é que esta limitação de DLF é feita em Kbps e não em
pacotes como nos switches. Desta forma, esta limitação fica amarrada ao tamanho dos pacotes que estão
trafegando na rede.
Assim, se o "hw-forwarding" for utilizado, aconselha-se desabilitar o storm-control das portas do anel ou
aumentar este limite para uma capacidade compatível com o fluxo de tráfego desta rede. Neste caso, é
importante utilizar o "cpu-dos-protect" para limitar o tráfego que é encaminhado para CPU, pois como as
proteções das portas estarão desabilitadas pode-se ter uma sobrecarga no tráfego encaminhado para CPU.
Por exemplo:
DATACOM
8
Documento de Uso Público
Se forem enviados frames de 64B, então 64*8=512b, multiplicados pelo número de pacotes (300 por
exemplo) 512*300=153,6Kbs.
Configuração do "hw-forwarding" (a configuração deve ser aplicada em todo o anel):
EDD#configure
EDD(config)#eaps
control-vlan
failtime
hellotime
hw-forwarding
mode
name
port
protected-vlans
<enter>
1 <?>
Configure the control VLAN for the domain
Maximum time to wait for health-check packets
Health-check packet transmission period
HW forwarding of packets in transit mode
Configure the switch mode for the domain
Rename the EAPS domain
Configure the domain member ports
Add protected VLANs to the domain
Create a new EAPS domain
EDD-2(config)#eaps 1 hw-forwarding <?>
<enter> no further known parameters
Para desabilitar o storm-control:
EDD#configure
EDD(config)#interface ethernet 5
EDD-2(config-if-eth-1/5)#no switchport storm-control <?>
broadcast Disable broadcast storm control
dlf
Disable storm control for Destination Lookup Failure packets (unicast/multicast)
rate
Set the kbit/s limit to default value
EDD(config-if-eth-1/5)#no switchport storm-control dlf <?>
<enter> no further known parameters
Considerações Finais
Não existe uma limitação quanto ao número máximo de switches que podem ser utilizados em um anel
EAPS. Em uma rede controlada pode-se observar que o envio e recebimento das BPDUs é muito eficiente,
mesmo em um anel com uma grande quantidade de switches. Porém, salienta-se que em uma topologia
onde existem muitos clientes conectados, passando diversos tipos de tráfego, não é possível prever o
comportamento da CPU de cada switch membro deste anel se houverem endereços IP nelas ou mesmo na
gerência. Se por acaso um switch estiver tratando muitos pacotes na CPU, ou estiver em loop, ele pode
atrasar o envio das BPDUs, causando a abertura do anel sendo que o anel está completo. Então quanto
maior o anel, maior a probabilidade ocorrerem atrasos na entrega e processamento de pacotes de controle
do EAPS.
Em condições normais um Dm3000 leva em média 6.0ms para tratar uma BPDU, sendo que isto inclui
recebê-la, tratá-la e encaminhar para interface correta. Se a CPU estiver sob ataque e num extremos
consumo de 100% levará em média 150ms para fazer a mesma operação, podendo levar até 550ms como
pior caso. Este tempo deve ser levado em consideração na hora do planjamento da topologia, considerando
que se dois switches atingirem o pior caso ao mesmo tempo, uma BPDU será perdida. A solução para
casos onde existem vários switches em um mesmo anel é aumentar o failtime assim como adotar as
medidas de proteção descritas em outro documento.No EDD os tempos são de 5.3ms em condições
normais e 3.5ms utilizando o hw-forwarding. No dm4004 os tempos são de 5.3ms para condições normais.
DATACOM
9
Documento de Uso Público
Com estes tempos normais conhecidos, sabe-se que não há problemas para criar anéis grandes como com
50 elementos, por exemplo, desde que tomados os cuidados necessários.
As configurações e comandos demonstrados no documento são válidas tanto para a linha de switches
Dm3000, Dm4000, quanto para o EDD.
DATACOM
10
Documento de Uso Público