Application Notes: Proteção da CPU e Gerência do DmSwitch

Uso das proteções para evitar alto consumo de CPU e memória, bem
como acessos à gerência
 Application Notes: Proteção da CPU e Gerência do
DmSwitch
Uso das proteções para evitar alto consumo de CPU e memória, bem como acessos à
gerência
Documento de Uso Público. Compilado em 07/05/2010, Revisão 1.2

Parecer
Introdução
Protegendo o sistema
Pacotes por segundo, unicast
Pacotes broadcast e multicast
Pacotes com IP Options e DLF
Consumo de memória
Restrições de acesso à gerência
Management Client
LOGs de acesso
Filtros para bloquear gerência
Filtros para bloquear ICMP
Comunidades SNMPv2 e Autenticação SNMPv3
Uso de filtros e relação com protocolos de roteamento
Configurações recomendadas
Equipamentos DmSwitch 3000
Switches em camada L2
Switch-Routers operando em camada 2/3
Equipamentos DM4000
Switches em camada L2
Switch-Routers operando em camada 2/3
Interação entre os modos de proteção
Prioridades no encaminhamento pacotes para a CPU
Troubleshooting
Consumo de CPU e pacotes atingindo o kernel
Contadores de filtros
Considerações Finais

Parecer
As recomendações deste documento servem a todos os clientes de DmSwitch, e devem ser aplicadas como
forma de mitigar eventuais problemas. Caso os valores apresentados não estejam de acordo com a
realidade do cliente, deve-se contatar o Suporte DATACOM para que sejam estudados eventuais ajustes
específicos.

DATACOM 1 Documento de Uso Público

Neste documento, após a apresentação sobre proteções a eventuais problemas no nível Ethernet, serão
introduzidos tópicos de controle ao acesso de gerência. Ao término do documento estão disponíveis
configurações-padrão planejadas para DmSwitches em diferentes funções da rede.

Introdução
A natureza das redes de computadores traz a importância da proteção dos elementos que a compõe, de
forma a manter o bom funcionamento dela como um todo. Neste documento será introduzido o
funcionamento das proteções contra ataques, loops e/ou má configurações em pontos da rede que possam
vir a afetar a CPU controladora do DmSwitch. Não serão abordados aspectos de proteção dos hosts
conectados ao switch, pois o comutador de pacotes não será afetado mesmo com tráfego wire speed.

Dentre as proteções existentes pode-se citar aquelas para mitigar o poder destrutivo do excesso dos
seguintes tipos:

pacotes direcionados à CPU, por exemplo ICMP PING direcionados a um IP configurado no

equipamento;
pacotes broadcast em VLANs e portas, tais como ARP REQUEST;
pacotes multicast;
loops na rede, como pacotes Ethernet repetidos;
acessos indevidos à CPU do equipamento, através dos serviços de gerência.

Caso tais configurações de proteção não sejam realizadas, o equipamento funcionará normalmente.
Todavia, em situações com problemas mais sérios como um loop na rede ou mesmo algum outro evento
não desejado, podem ocorrer instabilidades. Entre tais instabilidades, são reconhecidas:

queda de serviços;
desconexão lógica de placas do chassis;
perda de tráfego por reprogramação de interfaces.

Portanto é recomendado a utilização dos valores indicados pela DATACOM na configuração dos
parâmetros explicados ao longo deste documento. Serão abordados os seguintes comandos:

cpu-dos-protection;
meter e filter para tráfego broadcast;
meter e filter para tráfego multicast;
terminal timeout;
filtros de hardware.

Este documento está voltado para a linha DmSwitch, mais especificamente nos seguintes modelos:

Dm3000
3224F1;
3224F2;
3224F3;
3324F1;

DATACOM 2 Documento de Uso Público

 3324F2;
3324F3;
DM4000 (Dm4001, Dm4004, Dm4008)
Gerencia:
MPU192;
Placas de interface:
ETH12GX;
ETH24GX;
ETH12GX+1x10GX;
ETH2x10GX;
ETH24GT;
ETH48GT.

Protegendo o sistema
O mecanismo de proteção é bastante sofisticado, porém pode ser explicado com a seguinte simplificação:
o comutador encaminhará os pacotes para a CPU assim que estes chegam, porém até um determinado
limiar; após, esses serão descartados a fim de evitar que o tempo de processamento seja tomado pelos
eventos externos.

Por existir uma significativa parcela de pacotes importantes para o switch dentre o grande fluxo sendo
recebido, os valores configurados não devem estar abaixo de um valor indicado. Caso estejam,
comportamentos indesejados podem ocorrer.

Pacotes por segundo, unicast

O parâmetro que controla o número de pacotes por segundo que será encaminhado à CPU ativa do
equipamento é o
cpu-dos-protection rate-limit

e aceita como entrada valores entre 1, para apenas 1 pacote por segundo, até 2 bilhões de pacotes por
segundo.

Valores considerados ideais seguem pela tabela a seguir.

Equipamento Valor para cpu-dos-protection

DmSwitch 3000 L2 150
DmSwitch 3000 L3 180
DmSwitch 4001 (L2/L3) 350
DmSwitch 4004 com MPU 192 (L2/L3) 750

DATACOM 3 Documento de Uso Público

Pacotes broadcast e multicast
Os pacotes broadcast naturalmente são encaminhados a todos os elementos pertencentes à VLAN que
foram enviados, inclusive a CPU do switch quando este contiver algum endereço IP nesta VLAN. Mesmo
os switches Layer 2, que não fazem roteamento IP, recebem estes pacotes pois é como aprendem os
respectivos endereços MAC que estão comunicando.

Para evitar que um número abusivo de pacotes broadcast possa influenciar o comportamento, são criadas
regras para limitar a ação destes.

Primeiramente, um meter é criado. Nele é configurado um limite em razão de kilo bits por segundo, e um
limite de rajada para os momentos que muitos pacotes chegam simultaneamente.
meter new remark Broadcast_CPU rate-limit **LIMITE ORDINÁRIO**
burst **LIMITE POR RAJADA**

Será criado um contador especial. A CLI informará um número, por exemplo:

Meter 1 created.

Com este número será criado o filtro para bloquear o tráfego broadcast.

Para o DmSwitch 3000, a sintaxe é:

filter new action permit out-action deny match destination-mac
host FF-FF-FF-FF-FF-FF match vlan **VLAN DESEJADA** meter 1

No DM4000, a sintaxe possui pequenas diferenças:

filter new action red-deny match destination-mac host
FF-FF-FF-FF-FF-FF match vlan **VLAN DESEJADA** meter 1

O novo filtro criado fará o comutador descartar quando o tráfego com destino ao MAC especial
FF-FF-FF-FF-FF-FF, destino único dos pacotes broadcast, ultrapassar os limites estipulados pelo meter.
Recomenda-se utilizar em todas as portas das VLANs que tenham um IP, inclusive em port-channels.

Mesmo para o caso onde existam muitas VLANs com IP, recomenda-se colocar a opção match vlan para
cada uma das VLANs, evitando que o comutador aja em VLANs em que seja necessário alto tráfego
broadcast, como numa VLAN de algum cliente que tenha esta necessidade. Em especial, recomenda-se o
uso de filtros nas VLANs com endereços IP.

NOTA IMPORTANTE: caso exista alguma VLAN (com IP) não protegida por estes filtros, não será
possível garantir que o elemento esteja protegido. É muito importante configurar estas proteções em todas
as VLANs criadas e com IP atribuído. Pode-se também utilizar a opção de range de VLANs num mesmo
filtro.

No caso de redes que utilizem multicast, é importante o controle destes protocolo que podem afetar a
CPU, se houver algum excesso. O procedimento é basicamente o mesmo realizado para o broadcast,
apenas com alterações no endereço MAC a ser conferido pelo filtro.

DATACOM 4 Documento de Uso Público

 meter new remark Multicast_CPU rate-limit **LIMITE ORDINÁRIO**
burst **LIMITE POR RAJADA**

Será criado um contador especial. A CLI informará um número, por exemplo:

Meter 2 created.

Com este número será criado o filtro para bloquear o tráfego multicast.

Sintaxe para o DmSwitch3000:

filter new action permit out-action deny match destination-mac
01-00-00-00-00-00 01-00-00-00-00-00 match vlan **VLAN DESEJADA** meter 2 priority 7

Sintaxe para o DM4000:

filter new action red-deny match destination-mac
01-00-00-00-00-00 01-00-00-00-00-00 match vlan **VLAN DESEJADA** meter 2 priority 7

Uma diferença importante no comando do multicast em relação ao do broadcast é o uso de máscara no

destination-mac: todos endereços MAC que começando com 01 são de multicast, por isso o uso da
máscara 01-00-00-00-00-00. Maiores informações sobre os endereços MAC de uso especial está
disponível na RFC 5342.

Os limites acima citados dependem da capacidade de cada equipamento. Abaixo é apresentada uma tabela
com indicações destes valores, conforme testes internos na DATACOM.

Equipamento Limite ordinário Limite por rajada

DmSwitch 3000 L2 128 128
DmSwitch 3000 L3 128 128
DmSwitch 4001 128 128
DmSwitch 4004 com MPU 192 128 128

IMPORTANTE: não é necessário criar outro meter para cada nova VLAN a ser protegida contra
excessos de Broadcast/Multicast. É importante que exista apenas um meter para cada tipo de tráfego, e
que os filtros estejam devidamente configurados. A criação de mais meters fará com que a CPU possa
receber mais pacotes do que o desejado para estes tipos de tráfego. Ou seja, deve-se usar o mesmo meter
como parâmetro em todos os filtros com mesmo intuito.

Pacotes com IP Options e DLF

Na arquitetura de comutação utilizada nas famílias DmSwitch 3000 e DM4000 é previsto que certos tipos
de pacotes sejam sempre encaminhados para análise na CPU, para que possam ser tratados de formas
diferenciadas. Algumas RFCs, inclusive, trazem este aspecto como algo desejável (vide RFC 2113 - IP
Router Alert Option e RFC 2711 - IPv6 Router Alert Option).

DATACOM 5 Documento de Uso Público

Porém nem todas as topologias possuem os mesmos requisitos, sejam por questões de desempenho ou de
segurança. Alguns documentos propostos (vide draft-rahman-rtg-router-alert-dangerous-00) chegam a
recomendar que estas RFC citadas acima sejam desconsideradas e obsoletadas.

Dentro da gama de opções da família DmSwitch, a partir do release 7.8.2, é possível configurar se o
switch deve ou não receber pacotes que requisitarem análise no chamado slow path, ou seja, a CPU. Tais
opções estão disponíveis apenas quando o equipamento não será utilizado para Roteamento IP, pois ao
habilitar a opção ip routing é necessário o recebimento dos pacotes para uma série de verificações.

São disponibilizadas duas opções:

cpu-dos-protection block l3-hdr-err : bloqueia os pacotes que seriam encaminhados à CPU por
questões de cabeçalho IP (l3 header), bem como pacotes IP com erro (p. ex. TTL expirado);
cpu-dos-protection block dlf : bloqueia o recebimento de DLF na CPU, quando pacotes unicast que
não possuem um MAC destino conhecido são replicados para todas as portas. O DLF continua sendo
encaminhado para as portas, não substitui o storm-control unicast.

Abaixo a lista não-extensiva dos pacotes bloqueados quando a opção de l3-hdr-err está ativa. Sem
habilitar esta opção no equipamento, eles podem ser encaminhados mesmo sem a VLAN possuir IP
configurado.

IP Options habilitadas, tais como IP Router Alert;

destino IP e/ou MAC multicast com qualquer opção no cabeçalho IP;
IP TTL expirado;
HSRP (Hot Standby Router Protocol, RFC 2281);
IGMP;

Quando o pacote possuir como destino o IP e/ou MAC da CPU, ele continuará sendo encaminhado
normalmente. Desta forma a gerência e demais usos possíveis continuam sendo viáveis. Pacotes broadcast
e multicast também são encaminhados se a VLAN possuir IP.

Consumo de memória
Não é propriamente uma questão referente a pacotes externos, como as apresentadas anteriormente, o
consumo elevado de memória também pode levar a instabilidades. Para evitar este problema a
recomendação é habilitar a desconexão por tempo sem resposta nos terminais de configuração.
terminal timeout TEMPO_EM_SEGUNDOS

Com este parâmetro de configuração, após o usuário que estiver conectado à interface de gerência do
switch ficar vários segundos sem nenhuma nova ação, ele será desconectado. Isso é muito importante
quando, por exemplo, um usuário conectado via telnet deixa sua sessão aberta por tempo indefinido.

Dado o número de usuários conectados via telnet, SSH, WEB, ou mesmo o uso do DmView, há um certo
consumo de memória. O terminal timeout traz a confiança de que este consumo não seja aumentado por
clientes inativos.

DATACOM 6 Documento de Uso Público

Este recurso está habilitado por padrão desde a versão 5.6 no DmSwitch 3000 e em todas as versões de
firmware do DmSwitch 4000, este comando já vem habilitado. O valor default usado é de 360 segundos e
isto pode ser verificado com o comando abaixo:
show terminal

Restrições de acesso à gerência

Outra preocupação importante para equipamentos de rede está relacionada a restrições de acesso à
gerência. É necessário limitar quem pode gerenciar o equipamento para minimizar as chances de um
não-autorizado conectar-se e alterar propriedades da rede.

Abaixo estão apresentadas algumas das proteções existentes no DmSwitch e o uso destas.

Management Client
Para isso, o DmSwitch implementa as listas de management, onde são informados quais IPs (tanto hosts
ou redes) possuem acesso a cada um dos serviços de gerência existentes.
DmSwitch#config
DmSwitch(config)#management
all-client Add IP addresses to SNMP, SSH, HTTP and Telnet groups
http-client Add IP addresses to the HTTP group
snmp-client Add IP addresses to the SNMP group
ssh-client Add IP addresses to the SSH group
telnet-client Add IP addresses to the Telnet group

DmSwitch(config)#

O controle dos usuários gerenciadores é realizado através deste comando. A lista é inicialmente vazia,
significando que os acessos são permitidos de quaisquer endereços IP.

Ao adicionar uma entrada na lista, automaticamente bloqueiam-se todos os acessos de outros endereços.
Logo, a primeira entrada a ser adicionada é aquela de onde se está gerenciando no momento.

Por exemplo, caso esteja gerenciando via SSH a partir do IP 192.168.0.2, a primeira liberação deve ser
para este IP ou rede (assumindo uma rede /24):
DmSwitch(config)#management ssh-client 192.168.0.2/24
DmSwitch(config)#show management ssh-client
Management IP filter:
SSH client:
192.168.0.2/24

Os acessos para outros serviços não foram bloqueados neste caso, pois foi alterado apenas o que diz
respeito aos acessos SSH. Para alterar o acesso de todos os serviços com uma única entrada, utiliza-se a
opção all-client.

DATACOM 7 Documento de Uso Público

Caso não tenha certeza de qual IP está utilizando para acessar o equipamento, o comando show managers
mostra os usuários conectados.
DmSwitch(config)#show managers
User on CLI Uptime Process ID Origin
admin 00:23:03 9639 192.168.0.2

Uma sugestão para casos onde não se tem certeza de que o acesso será liberado corretamente é programar
um reboot e então cancelar caso o acesso esteja correto após o comando.

Para programar um reboot em 3 minutos

DmSwitch#reboot in minutes 3
Reboot scheduled for 14:37:00 (hh:mm:ss)

Visualizando quanto tempo falta para o reboot

DmSwitch#show reboot
14:33:06: Rebooting in 3m54s (scheduled for 14:37:00)

Cancelando
DmSwitch#reboot cancel
Scheduled reboot canceled!

DmSwitch#show reboot
14:35:04: No reboots scheduled

Para remover uma entrada de lista de gerenciadores, o comando está dentro da lógica de configuração do
DmSwitch: basta configurar um no.
DmSwitch#configure
DmSwitch(config)#no management ssh-client 10.3.3.1/32
DmSwitch(config)#

Lembrando sempre que se não houver nenhuma entrada configurada, o acesso é liberado para qualquer
tentativa. Caso exista ao menos uma entrada, somente as listadas são permitidas.

A liberação e/ou bloqueio de acesso é realizado antes mesmo do aparecimento do banner de conexão. No
entanto, é fortemente recomendada a utilização de servidores TACACS+ ou RADIUS para autenticação.
Por estarem fora do escopo deste documento as configurações destes serviços não serão apresentados.

LOGs de acesso
Independentemente das configurações de controle à gerência, os logs permitem a realização de uma
pré-auditoria nos acessos ao equipamento.
DmSwitch#show log ram | include \(Session\)\|\(User\)
Jul 25 14:00:55 DmSwitch : <5> User admin authenticated by tacacs
Jul 25 14:00:56 DmSwitch : <5> Session opened from 192.168.0.2, user admin2, Process ID 9639
DmSwitch#

DATACOM 8 Documento de Uso Público

Nestas linhas verifica-se o horário do evento, conforme o relógio interno do sistema (Jul 25 14:00:56), o
usuário conectado (admin2), o serviço autenticador (tacacs), o IP de origem (192.168.0.2), e o Process ID
que o login criou no Sistema Operacional do switch.

Filtros para bloquear gerência

O bloqueio anteriormente citado, chamado management client, é realizado já no nível do Sistema
Operacional rodando na CPU do switch. Em casos como equipamentos ligados com IP de Internet, isso
pode não ser tão eficaz quanto necessário.

Quando falado em eficácia de bloqueio, refere-se não ao sentido de segurança, pois os acessos serão
bloqueados, mas sim de desempenho. Por ser tratado via software na CPU, cria-se um vetor de DoS
(Denial Of Service), ao passo que um atacante que consiga gerar muitos acessos inválidos em pouco
tempo (milhares em poucos segundos) pode levar a uma elevação no consumo do processador.

Para proteger os equipamentos diretamente na Internet, recomendamos a utilização de filtros controlados

por hardware. Estes filtros agirão em conjunto com o management client, porém em um nível anterior que
é o hardware. No entanto estes filtros não devem ser vistos como substituição completa à proteção do
management client que pode ser importante numa rede de gerência, liberando acesso apenas a alguns
equipamentos.

A idéia deste filtro é bloquear acessos ao IP do switch quando esses são originados de locais
desconhecidos ao administrador. Como no exemplo abaixo para DmSwitch 3000, serão bloqueados
quaisquer acessos que não sejam originados da rede 192.168.0.0/16.
filter new action permit match source-ip 192.168.0.0 255.255.0.0 match
destination-ip host 192.168.0.1 priority 10

filter new action deny match destination-ip host 192.168.0.1 priority 9

Caso seja necessário liberar o acesso de outra rede, basta adicionar a entrada de permit. A entrada de deny
necessita ser adicionada somente uma vez, para efetivamente bloquear. Reparar que a prioridade do filtro
permit foi configurada como maior do que a do deny. Esta é a forma de demonstrar ao hardware qual a
intenção (liberar os listados, descartar os demais).

Adicionando acesso da rede 10.3.3.0/24 para o switch.

filter new action permit match source-ip 10.3.3.0 255.255.255.0 match
destination-ip host 192.168.0.1 priority 10

Se for necessário bloquear algum outro IP pertencente à alguma VLAN, insira outra regra de deny. Por
exemplo, se o switch também possuir o IP 200.200.200.1.
filter new action deny match destination-ip host 200.200.200.1 priority 9

OBSERVAÇÃO: estas regras evitam o acesso à qualquer serviço ou protocolo do switch. Tarefas como
ping (ICMP), traceroute (ICMP, UDP) ou mesmo protocolos de roteamento como BGP poderão deixar de
funcionar se estas regras não estiverem devidamente configuradas.

DATACOM 9 Documento de Uso Público

Caso necessite liberar o acesso de um roteador BGP, basta configurar o filtro corretamente. Considerando
um peer com IP 200.200.200.2 comunicando com o switch no IP 200.200.200.1.
filter new action permit match source-ip host 200.200.200.2 match
destination-ip host 200.200.200.1 priority 11

Importante observar também que as prioridades, por serem configuradas diretamente no hardware,
possuem uma limitação quanto aos match realizados. Não é possível ter dois filtros com match que
analisem bits diferentes em uma mesma prioridade.

Os exemplos assim podem ser representados na tabela abaixo:

Prioridade Bits analisados (conforme os exemplos anteriores)

9 Destination IP, todos os bits do host
10 Primeiros 24 bits do Source IP, e todos bits do Destination IP
11 Todos bits do Source IP, todos bits do Destination IP

Por isso não será possível "compartilhar" uma prioridade com filtros que analisem outros bits. Caso seja
necessária uma regra nova, ela deve ser colocada em outra posição dos filtros. Lembrando sempre que a
prioridade mais alta é sempre a mais importante, e que todos os matches devem ser respeitados para a
regra agir (via um AND lógico).

Para questões de economia e simplicidade, regras que analisem os mesmos bits devem ser colocadas na
mesma prioridade. Não importa se alguma regra de mesma prioridade seja deny e outra seja permit, por
exemplo.

Filtros para bloquear ICMP

Mesmo não sendo recomendado filtrar os pacotes ICMP, por ser uma peça importante para
troubleshooting e manutenção de redes bem como utilizado para descobrimento de MTU fim-a-fim
(Discover Path MTU), alguns administradores necessitam bloqueá-lo.

O modo correto é configurar um filtro e limitar o envio de ICMP, como abaixo.

filter new action deny match protocol icmp

Caso deseje-se bloquear apenas para uma determinada rede, a sintaxe é ligeiramente diferente. Como, por
exemplo, bloquear ICMP com destino à rede 192.168.0.0/16.
filter new action deny match protocol icmp match destination-ip 192.168.0.0 255.255.0.0

DATACOM 10 Documento de Uso Público

Comunidades SNMPv2 e Autenticação SNMPv3
SNMP, Simple Network Managament Protocol, é muito mais do que o nome sugere. Além das famosas
MIB de visualização de informações, é possível inclusive realizar operações através de OID específicos.
Ações tão poderosas tais como reiniciar o equipamento desejado.

A configuração padrão do switch vem com as comunidades public para leitura e private para
leitura-escrita. Recomenda-se que estas sejam alteradas para nomes únicos, tais como uma senha.
DmSwitch#configure
DmSwitch(config)#ip snmp-server community naoPublic ro
DmSwitch(config)#ip snmp-server community naoPrivate rw

Também é recomendado o uso, quando possível, do SNMP v3. Por ser uma revisão muito segura, ela é
considerada por alguns como "pesada". A configuração requer um usuário, suas permissões, uma
algoritmo e uma senha de autenticação, e um algoritmo e uma senha de privacidade.

Por exemplo, criando um usuário somente-leitura chamado usuario com autenticação MD5 senhaAuth e
privacidade AES com senha senhaPrivacy, ficaria da seguinte forma.
ip snmp-server user usuario ro md5 senhaAuth aes senhaPrivacy

O acesso de um cliente como Net-SNMP para estas informações seria como o abaixo.
snmpwalk -l authPriv -v 3 -u usuario -a MD5 -A"senhaAuth" -x AES -X"senhaPrivacy" 192.168.0.1

Uso de filtros e relação com protocolos de roteamento

Conforme relatado na seção Filtros para bloquear gerência, os filtros são implementados no hardware e
por isso podem afetar o funcionamento de protocolos. Os filtros referenciados neste documento não devem
afetar os protocolos de Camada 2 (pois estes trabalham em uma faixa de MACs específicos), porém
podem influenciar nos protocolos de roteamento (Camada 3, IP).

Nessa mesma seção referenciada foi apresentado que o BGP deve ser explicitamente liberado caso se
limite o acesso à gerência via filtros. O BGP trabalha estabelecendo uma sessão TCP entre os roteadores,
logo se o filtro bloquear a comunicação IP entre os dois elementos, o protocolo nunca sairá do estado
"Idle/Active". A correção foi mencionada anteriormente.

Protocolos como RIP e OSPF, por sua vez, agem por meio de pacotes multicast. Um dos primeiros filtros
apresentados neste documento é exatamente para controle destes pacotes. Através de testes específicos
realizados pela DATACOM, verificamos que o aprendizado das rotas não é prejudicado com os limites
informados neste documento.

DATACOM 11 Documento de Uso Público

 Tempo de aprendizado e encaminhamento de
Exemplo de teste tráfego (menor; média; máximo em para 10
execuções)
Configuração mínima, sem filtros nem
1054.273; 2203.625; 3088.574
CPU-DoS-Protection
Configuração mínima, sem filtros, com
1818.018; 1911.882; 2033.518
CPU-DoS-Protection 180
Configuração com 2 meters para 4 filtros (2
1835.32; 2647.131; 3180.46
filtros por VLAN), sem CPU-DoS-Protection
Configuração com 2 meters para 4 filtros (2
1841.206; 2354.475; 3062.217
filtros por VLAN) e CPU-DoS-Protection 180

Na tabela acima é verificado que sem proteções obtêm-se os melhores tempos. No entanto, ativando
proteções o tempo ainda continua aceitável. Em todos os testes foi comprovado que a rede OSPF
convergia completamente, sempre sem problemas.

Logo, o trade-off da solução traz tranquilidade na sua implementação, pois não ocorrem prejuízos na
utilização de filtros de hardware.

Configurações recomendadas
Ao longo deste documento são apresentadas diversas configurações e suas explicações. Um resumo mais
direto para alguns casos comuns de utilização do DmSwitch estão apresentados a seguir. Cada modelo de
equipamento está listado em uma subseção.

Ilustra-se a topologia explicando a diferença entre as camadas L2 e L3 na figura abaixo. Um roteador

encaminha pacotes de uma rede para a outra, enquanto o comutador (switch) apenas encaminha pacotes
dentro da mesma rede.

DATACOM 12 Documento de Uso Público

Equipamentos DmSwitch 3000
Exemplos para DmSwitch 3000 seguem a seguir.

Switches em camada L2
Um equipamento L2 deve limitar seus acessos à gerência, e controlar os fluxos de possíveis loops em suas
VLANs com IP. Limitar o tempo do terminal também é uma boa prática.
configure
!
cpu-dos-protection rate-limit 150
cpu-dos-protection block dlf
cpu-dos-protection block l3-hdr-err
!
management all-client **IP REDE GERENCIADORES**
!
meter new remark Broadcast_CPU rate-limit 128 burst 128
meter new remark Multicast_CPU rate-limit 128 burst 128
!

DATACOM 13 Documento de Uso Público

 filter new action permit out-action deny match destination-mac
host FF-FF-FF-FF-FF-FF vlan **VLAN DESEJADA** meter 1
filter new action permit out-action deny match destination-mac
01-00-00-00-00-00 01-00-00-00-00-00 vlan **VLAN DESEJADA** meter 2
!
terminal timeout 600
!
end

Switch-Routers operando em camada 2/3

Roteadores L3 estão, em muitos casos, acessíveis na Internet. Devem então estar filtrando em hardware
acessos à sua gerência, bem como utilizar o CPU-DoS-Protection para mitigar problemas de CPU quando
muitos pacotes são destinados à ela.

Equipamentos mistos necessitam atenção especial, por apresentarem os requisitos dos dois modelos.
configure
!
cpu-dos-protection rate-limit 180
!
meter new remark Broadcast_CPU rate-limit 128 burst 128
meter new remark Multicast_CPU rate-limit 128 burst 128
!
filter new action permit out-action deny match destination-mac
host FF-FF-FF-FF-FF-FF vlan **VLAN DESEJADA** meter 1
filter new action permit out-action deny match destination-mac
01-00-00-00-00-00 01-00-00-00-00-00 vlan **VLAN DESEJADA** meter 2
!
management all-client **IP REDE GERENCIADORES**
!

!
! Filtro abaixo, para cada rede gerenciadora e para cada IP que se desejar
! permitir gerência da caixa.
!
filter new action permit match source-ip **IP REDE GERENCIADORES** **MÁSCARA DA
REDE DOS GERENCIADORES, EM NOTAÇÃO DECIMAL COM PONTOS (255.255.255.)** match
destination-ip host **IP GERÊNCIA** priority 8

!
! Filtro abaixo, para quantos IPs existirem.
!
filter new action deny match destination-ip host **IP GERÊNCIA** priority 7

!
ip snmp-server community **COMUNIDADE SOMENTE-LEITURA** ro
ip snmp-server community **COMUNIDADE ESCRITA-LEITURA** rw
!
terminal timeout 600
!
end

DATACOM 14 Documento de Uso Público

Caso existam várias VLANS com endereços IP, é importante que todos estes IPs estejam cadastrados nos
filtros. Cada filtro que estiver olhando os mesmos BITS pode compartilhar a mesma PRIORIDADE. Vide
tabela na seção Filtros para bloquear gerência, onde também encontram-se exemplos mais detalhados.

Equipamentos DM4000
A família DM4000 possui pequenas diferenças nos seus filtros, que são demonstrados abaixo.

Switches em camada L2
Um equipamento L2 deve limitar seus acessos à gerência, e controlar os fluxos de possíveis loops em suas
VLANs com IP. Limitar o tempo do terminal também é uma boa prática.
configure
!
cpu-dos-protection block dlf
cpu-dos-protection block l3-hdr-err
! DM4001:
cpu-dos-protection rate-limit 350
! DM4004:
cpu-dos-protection rate-limit 750
!
management all-client **IP REDE GERENCIADORES**
!
meter new remark Broadcast_CPU rate-limit 128 burst 128
meter new remark Multicast_CPU rate-limit 128 burst 128
!
filter new action red-deny match destination-mac host
FF-FF-FF-FF-FF-FF match vlan **VLAN DESEJADA** meter 1
filter new action permit out-action deny match destination-mac
01-00-00-00-00-00 01-00-00-00-00-00 vlan **VLAN DESEJADA** meter 2
!
terminal timeout 600
!
end

Switch-Routers operando em camada 2/3

Roteadores L3 estão, em muitos casos, acessíveis na Internet. Devem então estar filtrando em hardware
acessos à sua gerência, bem como utilizar o CPU-DoS-Protection para mitigar problemas de CPU quando
muitos pacotes são destinados à ela.

Equipamentos mistos necessitam atenção especial, por apresentarem os requisitos dos dois modelos.
configure
!
! DM4001:
cpu-dos-protection rate-limit 350
! DM4004:
cpu-dos-protection rate-limit 750
!
management all-client **IP REDE GERENCIADORES**

DATACOM 15 Documento de Uso Público

 !
meter new remark Broadcast_CPU rate-limit 128 burst 128
meter new remark Multicast_CPU rate-limit 128 burst 128
!
filter new action red-deny match destination-mac host
FF-FF-FF-FF-FF-FF match vlan **VLAN DESEJADA** meter 1
filter new action permit out-action deny match destination-mac
01-00-00-00-00-00 01-00-00-00-00-00 vlan **VLAN DESEJADA** meter 2
!
management all-client **IP REDE GERENCIADORES**
!

!
! Filtro abaixo, para cada rede gerenciadora e para cada IP que se desejar
! permitir gerência da caixa.
!
filter new action permit match source-ip **IP REDE GERENCIADORES** **MÁSCARA DA
REDE DOS GERENCIADORES, EM NOTAÇÃO DECIMAL COM PONTOS (255.255.255.)** match
destination-ip host **IP GERÊNCIA** priority 8

!
! Filtro abaixo, para quantos IPs existirem.
!
filter new action red-deny match destination-ip host **IP GERÊNCIA** priority 7

!
ip snmp-server community **COMUNIDADE SOMENTE-LEITURA** ro
ip snmp-server community **COMUNIDADE ESCRITA-LEITURA** rw
!
terminal timeout 600
!
end

Caso existam várias VLANS com endereços IP, é importante que todos estes IPs estejam cadastrados nos
filtros. Cada filtro que estiver olhando os mesmos BITS pode compartilhar a mesma PRIORIDADE. Vide
tabela na seção Filtros para bloquear gerência, onde também encontram-se exemplos mais detalhados.

Interação entre os modos de proteção

Algumas notas são necessárias sobre a interação entre os modos de proteção disponíveis na família
DmSwitch. Em especial, sobre o uso de filtros e cpu-dos-protection.

Ao longo do documento foram demonstrados usos destas duas ferramentas, porém um leitor poderia
perguntar-se, por quê não utilizar somente uma das proteções? Por quê um método não é eficaz sem o
apoio do outro?

Ambos métodos são eficazes individualmente, porém o uso em conjunto trata cobre uma gama maior de
eventos. Enquanto a cpu-dos-protection evita que muitos pacotes cheguem à CPU, sobrecarregando os
processos de tratamento de mensagens, os filtros de broadcast e multicast evitam que mensagens
importantes de controle (exemplo são protocolos L2, STP, EAPS) sejam enfileiradas concorrendo com
tratamentos secundários (ARP para hosts desconhecidos, por exemplo).

DATACOM 16 Documento de Uso Público

Existem outros controladores, não relacionados com a gerência, como por exemplo o storm-control nas
interfaces. O storm-control limita os seguintes tráfegos:

broadcast;
multicast;
unicast para MACs destino desconhecidos.

Ressaltamos que este controle é por interface, independente de VLAN e para todos os dados que
estiverem trafegando por este meio. Logo, valores muito baixos para o controle afetarão diretamente o
funcionamento das VLANs ali comunicando.

Por padrão, o storm-control vem habilitado e com um limite de 500 pacotes por segundo. Para alterar,
deve-se entrar na interface e ajustar individualmente cada um dos limitadores.

O bloqueio de pacotes l3 header error e DLF para equipamentos L2 é ativado opcionalmente, não vindo
por padrão para manter compatibilidade com o comportamento anterior à versão 7.8.2. Cada topologia
requer uma análise do impacto para ativar esta configuração, devendo ser realizada com o devido cuidado
para evitar interrupções no serviço disponibilizado.

Prioridades no encaminhamento pacotes para a CPU

Redes com controle de QoS, e ajustes nas filas disponibilizadas para cada tipo de tráfego, são beneficiadas
por uma técnica de controle na prioridade dos pacotes do comutador para a CPU. Esta técnica, cpu
protocol priority, é suportada em toda família DmSwitch.
DmSwitch#show cpu protocol priority

CPU Protocols Priorities:

L2-protocol: 7
Unknown: 7
Tunnel: 5
Default: 7

Os pacotes são divididos em quatro grupos, acima listados. Eles significam, respectivamente, pacotes de:

controle L2 (i.e., STP, EAPS);

origem/destino desconhecido (i.e., Destination Lookup Failure, L3 para host não na hosts-table);
tunelamento/tunelados;
tráfego padrão.

O número ao lado do grupo representa qual fila 802.1P que será atribuida no campo CoS do pacote
quando este for enviado para a CPU. Caso esta informação de CoS tenha sido modificada na
topologia geral da rede, em casos onde filas específicas estão configuradas para certos serviços, a
alteração é através do menu de configuração.

DATACOM 17 Documento de Uso Público

 DmSwitch(config)#cpu protocol priority
l2-protocol Configure priority to l2 protocols packets
unknown Configure priority to unknown source/destination packets
tunnel Configure priority to tunneled packets
default Configure the default packet priority

Pacotes IP da gerência são considerados tráfego default nesta tabela. Esta informação não altera o
comportamento de pacotes que não tenham como origem ou destino a CPU.

Troubleshooting
Eventualmente pode-se fazer necessário o uso de técnicas para Troubleshooting, de forma a compreender
melhor o comportamento da rede. Dentre as técnicas disponíveis, estão as visualizações do consumo de
CPU e dos logs. Outras visualizações, como os contadores dos pacotes alcançando a CPU ou mesmo
contadores individuais por filtro, também estão disponíveis.

Primeiramente, é proposto um hipotético cenário onde o equipamento está sob um ataque de flood
originado na Internet. Isso pode ser inicialmente verificado caso encontre-se lentidão na gerência do
mesmo ou através de sistemas de monitoramento.

Consumo de CPU e pacotes atingindo o kernel

Verificando o comando show cpu usage, vemos o consumo da CPU.
DmSwitch#show cpu usage

(STATUS: S=sleeping R=running W=waiting)

%CPU
5Sec 1Min 5Min
CPU TOTAL USAGE: 92.88 99.41 40.23

PID PROCESS STATUS

200 rx_pkt R 49.06 57.81 16.70
215 TX S 14.98 17.29 4.85
195 l2_shadow.0 S 6.18 4.57 5.03
232 io_status S 5.99 0.96 1.02
216 RX S 4.49 5.19 1.53
193 interrupt S 3.56 4.57 1.41
228 cpu_monitor R 3.56 3.21 3.20
208 l3_arp S 1.69 1.21 1.01
196 counter.0 S 1.50 1.88 1.86
201 linkscan.0 S 1.31 1.36 1.22
197 tx_pkt S 0.56 0.56 0.35
...

O consumo está elevado, maior do que o limear de 90\%. Através dos logs, investiga-se se este evento é
recente e intermitente.

DATACOM 18 Documento de Uso Público

 DmSwitch#show log ram tail
Jul 30 11:54:21 DmSwitch : <5> Interface Ethernet 1/22 changed state to up
Jul 30 11:54:21 DmSwitch : <5> Interface Ethernet 1/22 changed state to down
Jul 30 11:54:39 DmSwitch : <5> Interface Ethernet 1/1 changed state to up
Jul 30 11:54:42 DmSwitch : <5> Interface Ethernet 1/22 changed state to up
Jul 30 12:01:52 DmSwitch : <5> Interface Ethernet 1/1 changed state to down
Jul 30 12:02:39 DmSwitch : <5> Interface Ethernet 1/22 changed state to down
Jul 30 12:03:14 DmSwitch : <2> CPU usage > 90.00% (rx_pkt 59.96%; TX 16.39%; RX 6.33%)
Jul 30 12:03:22 DmSwitch : <5> Interface Ethernet 1/1 changed state to up
Jul 30 12:03:31 DmSwitch : <5> Interface Ethernet 1/22 changed state to up
Jul 30 12:04:35 DmSwitch : <2> CPU usage < 90.00%
DmSwitch#

No log constam vários eventos, que podem ser importantes para o caso ou não. Os eventos nas portas 1/1 e
1/22 não importam para o consumo de CPU pelo processo rx_pkt, que durou cerca de 81 segundos (entre
12:03:14 e 12:04:34).

O processo rx_pkt, como o nome já explica, trata do recebimento de pacotes pelo kernel do DmSwitch.
Como este é um processo genérico, há um comando que permite a visualização dos totais de pacotes
recebidos. Esta é a função do show cpu packets.
DmSwitch#show cpu packets
CPU Received Packets:
--------------------------------------------
802.1X: 0
ARP: 26944
EAPS: 0
GVRP: 0
IGMP: 0
IPv4: 30115
ICMP: 13839
SSH: 0
Telnet: 341
TACACS: 0
RADIUS: 0
TFTP: 0
SNMP: 5451
SNTP: 0
HTTP: 0
DHCP: 0
DNS: 0
PIM: 0
RIP: 0
OSPF: 8779
BGP: 0
L2 Protocol Tunnelling: 0
L2 Unknown Source: 0
L3 Unknown Destination: 13756
L3 Unknown Gateway: 268
LACP: 0
LLDP: 1812
Loopback Detection: 46955
OAM: 0
PVST: 0

DATACOM 19 Documento de Uso Público

 Slow Protocols: 0
STP: 21411
VTP: 185
DmSwitch#

Existem dezenas de pacotes diferentes listados, o que facilita a interpretação dos mais diferentes cenários.
Por serem contadores incrementais ao longo do tempo, existe um comando para zerar os contadores. É
uma boa forma de saber quantos pacotes foram recebidos entre um clear e outro, possibilitando a
realização do cálculo de delta. O comando é clear cpu packets.

Contadores de filtros
Cada filtro pode, individualmente, ter contadores para demonstrar quantos pacotes ou bytes foram tratados
pelos match ali configurados. O DmSwitch3000 permite apenas que sejam contabilizados os pacotes,
enquanto a família DM4000 permite ambas análises.

No DmSwitch3000, a criação e alteração de um filtro é simples. Considerando os filtros já criados neste

documento, pode-se atrelar um contador a um filtro em específico.
DmSwitch(config)#counter new
Counter 1 created.
DmSwitch(config)#filter 1 action counter 1
DmSwitch(config)#

Na família DM4000 a criação do counter, do meter e do filtro ficam ligeiramente diferentes. O contador
possuirá, na verdade, dois contadores (upper e lower). Ou seja, se o filtro permitiu o pacote marcará no
contador green, caso tenha negado será no contador red. Estes parâmetros são configuráveis.
DM4000(config)#counter new mode upper green lower red type packets
Counter 1 created.
DM4000(config)#meter new mode flow burst 64 rate-limit 64
Meter 1 created.
DM4000(config)#filter new meter 1 action counter 1 action permit action red-deny
match source-ip host 10.3.3.1
Filter 1 created.
DM4000(config)#show filter
Filter 1: enabled, priority 8
Actions: permit
red-deny
counter 1
Matches: source-ip host 10.3.3.1
Meter: 1
Ingress: Eth2/1 to Eth4/24

DM4000(config)#show counter values id 1

ID Filter Upper Counter Value Lower Counter Value
---- ------ -------------------------- --------------------------
1 1 23 0
DM4000(config)#

DATACOM 20 Documento de Uso Público

Considerações Finais
Com as informações apresentadas neste documento é possível ajustar a quantidade de pacotes por segundo
que chegarão na CPU do equipamento. Este número, que poderá influenciar em redes muito
movimentadas, não altera o comportamento do comutador de pacotes, apenas a proteção da CPU de
controle. Ou seja, valores fora dos limiares indicados poderão influenciar a gerência do equipamento ou
causar instabilidades, porém, caso contrário, não devem ser causadores de retardo na comunicação
intra-nodos.

Foram também demonstradas as capacidades de controle ao acesso à gerência do equipamento, muito

importante para evitar que terceiros não-autorizados façam alterações de configuração. Ao final do
documento são informadas algumas políticas recomendadas para equipamentos DmSwitch em diferentes
funções de uma rede.

DATACOM 21 Documento de Uso Público