Olá Julio,

Primeiramente é legal revermos o significado das filas para entendermos o objetivo de cada um dos comandos:

Falando dos swicthes familia Catalyst 3560, 3750 and 3550, SRR é o modo de enfileiramento (queue) usado para QoS.

SRR, que significa “shaped shared rouding”, é uma evolução ao modo de filas usado anteriormente chamado WRR (Weighted Round-robin).

Diferente do modo WRR, no modo SRR cada fila é esvaziada considerando uma determinada taxa, por um determinado periodo de tempo.

O SRR pode definido ser em dois modos, Shaping ou Sharing, ambos usados para controle da taxa de pacotes que é enviada.

- No modo Shaping, as filas possuem uma taxa garantida de banda, e elas são limitadas a essa banda definida. Elas não usam mais banda mesmo que o link esteja livre.

O modo Shaping produz um fluxo de dados mais equalizado e reduz picos durante picos de trafego.

- No modo Sharing, a as filas compartilham a banda disponivel entre elas de acordo com os pesos definidos para cada uma.

A banda é garantida a um nível mas não é limitada a este.

Sendo assim, ambos filas , tanto de Ingress como Egress, são gerenciadas pelo SRR, que controla a taxa de pacotes enviadas.

Podemos configurar os modos Shaping ou Sharing nas filas egress, porem nas filas Ingress somente o modo Sharing (que é o modo default) pode ser usado.

O switch Catalyst 3560 por exemplo, suporta 4 filas de saida (egress), e podem operar no modelo 4Q3T ou 1P3Q3Ts

4Q = 4 queues / 3T = 3 thresholds.

1P = 1 priority / 3Q = 3 queues / 3T = 3 threshould

Todas as 4 filas participam no modo SRR, ao menos que a opção “expedite” seja habilitada.

A fila expedite é a fila que chamados de “priority”, e esse é servida antes que as demais até a mesma esteja vazia.

Se “priority_queue” é usado em uma interface, a fila 1 será a fila pritority e ambos modos “shared ou shaped” serão sobrescritos nessa fila.

Para habilitar a opção de fila priority usamos o comando “priority-queue out” na interface.

Portanto o modo 1P3Q3T com comando priority-queue é o modo recomendado para trafego de Voz.

Esse link traz mais informações de Qos para os switches Catalyst 3560:

http://www.cisco.com/en/US/docs/switches/lan/catalyst3560/software/release/12.2_25_se/configuration/guide/swqos.pdf

Atc,

Rodrigo

Bom dia!

Bocê postou um doc sobre CEF,você teria um documento sobre alto processamento de CPU em switches e routers?

Dominique

Olá Dominique,

                Ainda não escrevi um documento falando desse assunto, acho que isso pode ser um bom motivador.

Mas falando um pouco do assunto, devido as diferentes arquiteturas e diferentes mecanismos de encaminhamento de pacotes nos roteadores e swicthes Cisco, a analise de HIGH CPU difere um pouco para cada plataforma. Tambem o output tipico do comando show process cpu pode diiferir bastante entre plataformas.

Os sintomas mais comuns para alta CPU são instabilidade na control-plane, e/ou pacotes que requerem ser verificados pela CPU, e caso esses sejam excessivos váo causar muitos "Interrupts" da CPU para processa-los.

Portanto vemos a utilização da CPU de duas fontes, por processos e interrupções.

Quando temos alta utilização por processos, precisamos ficar atentos a eventos recorrentes, como instabilidades na control-plane, processos tipo OSPF, BGP, ARP Input, IP Input, etc...

Quando temos utilização por Interrupções, as causas pode ser devido o sistema rodando com poucos recursos de hardware, ou encaminhados para serem roteados em software ao invés de hardware como por exemplo cef desabilitado, ou pacotes que necessitam atenção especial da CPU...

O output de show process cpu mostra a utilizaçao por process% / interrupts%, respectivamente:

ex --> CPU utilization for five seconds: 99%/90%; one minute: 9%; five minutes: 8%

Tipos de pacotes IP que são processados pela CPU:

- Broadcast (storms podem causar lentidão)

- Pacotes com IP-Options (Qos) habilitado

- Pacotes que requerem ICMP Redirect ou Unreachable, ex. TTL=1, ACL Deny etc.

- Pacotes que necessitam ser processados como ACL Logging habilitado.

---Causas comuns de alta utilização:

ACL log habilitado

Pacotes com TTL <2

Pacotes marcados com IP options (QoS)

Fragmentação IP

Features em software como criptografia, NBAR

Multicast RPF drops

Limitação nos recursos de hardware

Sempre importante observar se houve alguma mudança recente na rede, verificar mudanças nos graficos de utilização da rede, o que pode ter causado o evento do alto processamento, pois isso ajuda a direcionar o procedimento de troubleshooting.

Outra coisa importante é estar atento a questões de segurança, possivel ataque, virus etc...

Algumas recomendações gerais de troubleshooting:

=========================================

--- Verifique os niveis de CPU, e determine a origem do alto processamento.

Baseado no processo que esteja causando a utilização, diferentes direcionamentos no troubleshooting podem ser seguidos.

## sh process cpu | ex 0.00

## sh process cpu history

--- Verifique as estatisticas de utilização das interfaces

##sh interface | inc rate|line

##sh interface counters errors

##sh int | in Input|line

##sh interface switching

Esse comando é útil para identificar as interfaces com alta taxa de trafego.

Algum device pode estar enviando muito trafego que necessita ser processado em CPU. (verifique por exemplo se CEF esta realmente habilitado)

Identificado uma interface com trafego anormal, voce pode realizar um shutdown na referida interface e ver o resultado.

-- Verifique os contadores de quais tipos de pacotes aumentam mais:

##show ip traffic

--- Verifique eventos na LOG, flapping, erros

##sh log

--- Se disponível na plataforma, capture os pacotes que estão sendo enviados para a CPU

## Use netdr debug tool.

debug netdr capture rx

show netdr capture

Exemplos:

https://supportforums.cisco.com/docs/DOC-15608

https://supportforums.cisco.com/docs/DOC-14086

--- Se for L2, verifique um possivel problema de Spanning-tree

No caso de um possivel problema com spanning-tree, o comando abaixo irá mostrar os contadores de tx e rx, e as transições de estado.

Esses comando nos da uma visão do que esta acontecendo com o Spanning-tree e se ocorreram recentes TCN (Topology change notification).

Se for verificado muitos TCN's, isso pode causar instabilidade e consequente flooding de dados para a CPU.

##sh spanning-tree detail | inc ieee|occur|from|is exec

##sh spanning-tree summary

##sh spanning-tree vlan [vlan id] detail

Se estiver ocorrendo mudança de topologia spanning-tree com muita frequencia, segundos, isso seria algo para se focar.

--------------------------

Seguem alguns links recomendados sobre esse assunto.

Troubleshooting High CPU Utilization on Cisco Routers

http://www.cisco.com/warp/public/63/highcpu.html

Troubleshooting High CPU Utilization Due to the IP Input Process

http://www.cisco.com/warp/public/63/highcpu_ip_input.html

Troubleshooting High CPU Utilization Due to Interrupts

http://www.cisco.com/warp/public/63/highcpu_interrupts.html

Se você tiver alguma dúvida ou quiser informações de alguma plataforma especifica, me de um alo.

Atenciosamente

Rodrigo Delgadinho

Olá Carlos,

                 Redundancia de camada 2 é muito comum nas implementações, e o spanning-tree é um recurso que permite que a redundancia seja possível evitando “loop” e replicação infinita de pacotes em um dominio de broadcast. Lembrando que na camada 2 os pacotes não possuem um campo que controla o tempo de existencia, como o TTL de camada 3. Porém muitas implemetações sem os mecanismos de proteção adequados de spanning-tree, coloca em risco o negócio pois qualquer loop pode causar interrupção da rede, elevando a utilização, principalmente a CPU dos equipamentos.

Como detectar ?

• 1)       Habilite mac-address move notification (habilitado por default nos switches 3750/3560/2960, porém desabilitado por default nos 6500/7600);

      mac-address-table notification mac-move

- Habilitado verifique na log do switch por mac-address “flapping”  entre diferentes portas ou interfaces – essas portas estão participando do loop.

- Encontrado um mac address que esteja “flapping”, procure pela origem desse mac, verificando na tabela mac por onde ele esta sendo aprendido.

- Verifique se não existe algum link que esteja transicionando up/down, causando TCNs (topology change notification) e recovergencia do SPT.

• 2)       Verifique TCNs – quando um loop esta ocorrendo você verá muitos TCNs. Comece pelo switch root SPT:

show spanning-tree detail | inc ieee|occurr|from|is exec

- Esse commando irá mostrar a porta , a quantidade de TCNs recebido e o horario do último TCN. Procure a porta que esteja com grande incidencia de mudanças de topologia e com tempo baixo da ultima notificação.

- Caminhe na rede verificando até chegar na porta de acesso, ou até o switch que esteja gerando esses TCNs; Encontrado a porta que esta recebendo esses TCNs, você poderá desabilita´-la para restabilizar a rede.

- Se vocë encontrar um switch gerando esses TCNs, você pode verificar por duas portas que estejam no status de FORWARDING na mesma VLAN.  Desabilite uma porta para eliminar o loop. Nesse caso interessante verificar se o link não esta Unidirecional ou se existem excessivos flaps.

• 3)       Procure por uma interface que esteja com mais trafego

show interface | inc up|rate

- Quando um loop ocorre, geralmente você verá algumas interfaces com muito trafego de output e baixo trafego de Input, e uma única interface com alto Input e baixo output.

- Verifique a porta com algo trafego de Input, caminhe na rede até chegar na porta de acesso, e desabilite-a.

- Se a porta com alto trafego de input te levar a um loop, você precisará verificar o status do SPT até você encontrar o switch que possui a portas que não deveriam estar em FORWARDING, causando o loop.

                Como recomendação em qualquer rede l2 com caminhos redundantes, é antes de uma ativação de um novo link, ou uplink, implementar as melhores praticas de spanning-tree para se evitar ou mitigar o risco de um impacto caso ocorra. Dentre esses mecanismos eu detaco:

                 - Ter definido um root de spanning-tree com a devida prioridade.

                 - Considerar habilitar root-guard nas portas uplinks do Core para os switches de distribuição e da distruição para o acesso.

                - Habilitar loop guard em todos switches de distribuição e acesso.

                - Habilitar proteção UDLD – evita problemas com links unidirecionais.

          Segue um link no site da Cisco com informações sobre o tema:

http://www.cisco.com/en/US/tech/tk389/tk621/technologies_tech_note09186a00800951ac.shtml#brid_loop

            Espero ter ajudado.

Sds,

Rodrigo

Olá Oseias,

O que eu conheço sobre o SNTP (Simple Network Time Protocol), é que esse é uma variante do conhecido NTP, mas o SNTP não implementa todas as funções que o NTP. 

A cisco implementa na sua grande maioria de equipamentos o NTPv3.

O mecanismo que eu uso para ver se uma determinada feature é suportada em algum produto é o feature navigator. Você encontra na url:  www.cisco.com/go/fn

Procurei no Feature Navigator mas não encontrei suporte SNTP para switchs 3750.

Espero ter ajudado.

Sds,

Rodrigo

Bom dia Rodrigo,

Me ajudou sim, eu tinha já procurado também e não tinha achado nada nesse sentido e o nosso servidor só trabalha com o SNTP.

Rodrigo, foi um prazer e obrigado "PELOS ESCLARECIMENTOS".