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

Transcrição

1 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

2 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. 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

3 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: Dm F1; 3224F2; 3224F3; 3324F1; DATACOM 2

4 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

5 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

6 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 match vlan **VLAN DESEJADA** meter 2 priority 7 Sintaxe para o DM4000: filter new action red-deny match destination-mac 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 Maiores informações sobre os endereços MAC de uso especial está disponível na RFC 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 L DmSwitch 3000 L DmSwitch DmSwitch 4004 com MPU 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 IP Router Alert Option e RFC IPv6 Router Alert Option). DATACOM 5

7 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

8 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 , a primeira liberação deve ser para este IP ou rede (assumindo uma rede /24): DmSwitch(config)#management ssh-client /24 DmSwitch(config)#show management ssh-client Management IP filter: SSH client: /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

9 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: 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 /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 , user admin2, Process ID 9639 DmSwitch# DATACOM 8

10 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 ( ), 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 /16. filter new action permit match source-ip match destination-ip host priority 10 filter new action deny match destination-ip host 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 /24 para o switch. filter new action permit match source-ip match destination-ip host 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 filter new action deny match destination-ip host 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

11 Caso necessite liberar o acesso de um roteador BGP, basta configurar o filtro corretamente. Considerando um peer com IP comunicando com o switch no IP filter new action permit match source-ip host match destination-ip host 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 /16. filter new action deny match protocol icmp match destination-ip DATACOM 10

12 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" 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

13 Exemplo de teste Configuração mínima, sem filtros nem CPU-DoS-Protection Configuração mínima, sem filtros, com CPU-DoS-Protection 180 Configuração com 2 meters para 4 filtros (2 filtros por VLAN), sem CPU-DoS-Protection Configuração com 2 meters para 4 filtros (2 filtros por VLAN) e CPU-DoS-Protection 180 Tempo de aprendizado e encaminhamento de tráfego (menor; média; máximo em para 10 execuções) ; ; ; ; ; ; ; ; 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

14 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

15 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 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 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 ( )** 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

16 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 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

17 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 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 ( )** 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

18 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 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

19 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: PID PROCESS STATUS 200 rx_pkt R TX S l2_shadow.0 S io_status S RX S interrupt S cpu_monitor R l3_arp S counter.0 S linkscan.0 S tx_pkt S 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

20 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: X: 0 ARP: EAPS: 0 GVRP: 0 IGMP: 0 IPv4: ICMP: 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: L3 Unknown Gateway: 268 LACP: 0 LLDP: 1812 Loopback Detection: OAM: 0 PVST: 0 DATACOM 19

21 Slow Protocols: 0 STP: 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 Filter 1 created. DM4000(config)#show filter Filter 1: enabled, priority 8 Actions: permit red-deny counter 1 Matches: source-ip host Meter: 1 Ingress: Eth2/1 to Eth4/24 DM4000(config)#show counter values id 1 ID Filter Upper Counter Value Lower Counter Value DM4000(config)# DATACOM 20

22 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