WCCP em plataformas Catalyst 6500 com Guia de Configuração de Alta Utilização da CPU

Introduction

Este documento descreve como usar o Web Cache Communication Protocol (WCCP) na plataforma Cisco Catalyst 6500 Series.

O WCCP foi originalmente projetado como um método para interceptar o tráfego da Web (HTTP) e encaminhá-lo para um dispositivo de cache local, onde poderia ser servido a um cliente a partir de um local local e conservar a largura de banda da WAN cara.

Do ponto de vista do usuário da rede, o WCCP é transparente porque é usado no nível da rede, sem qualquer configuração especial do usuário, para identificar e redirecionar o tráfego da Web que atravessa um dispositivo de Camada 3 (L3) para um dispositivo de cache local. Embora o WCCP tenha sido originalmente projetado para o tráfego da Web, o método transparente de redirecionamento tornou-se um mecanismo muito útil para lidar com outros problemas com conteúdo de alto volume em links de baixo volume. Por esse motivo, o suporte adicional ao protocolo foi adicionado às versões mais recentes do WCCP. Essas tecnologias adicionais incluem protocolos como HTTP, HTTPS, FTP, transmissão de vídeo e tecnologias de cache de arquivos, como o CIFS (Common Internet File System). Essas tecnologias oferecem suporte a plataformas e soluções mais recentes da Cisco, como Wide Area File Services (WAFS), Wide Area Application Services (WAAS), Application Oriented Networking (AONs) e recursos aprimorados do Application and Content Networking Software (ACNS).

A adoção do WCCP está aumentando à medida que as empresas implementam as mais recentes ferramentas de produtividade, como comunicações baseadas em vídeo e treinamento, assim como vídeo ao vivo e sob demanda. Esforços para controlar custos, como data centers consolidados, criam a necessidade de o WCCP suportar serviços adicionais de largura de banda extremamente alta.

Devido à importância do WCCP com as redes ricas em conteúdo atuais, algumas plataformas, como o Catalyst 6500, implementaram o desempenho assistido por hardware com o WCCP de modo que a carga da CPU necessária para o protocolo seja reduzida. Este documento descreve como implantar o WCCP no Catalyst 6500 para maximizar a utilização do hardware e reduzir a carga da CPU.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• WCCP
• Switches Cisco Catalyst 6500 Series
• Cisco IOS® Software

Componentes Utilizados

As informações neste documento são baseadas nestas versões de software e hardware:

• Cisco Catalyst 6500 Series Switches
• Software Cisco IOS versão 12.1(50)SY ou posterior com mecanismo de supervisão 2T (Policy Feature Card 4)
• Software Cisco IOS versão 12.2(18)SXD1 ou posterior com Supervisor Engine 720 (Policy Feature Card 3)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Visão geral funcional do WCCP

A funcionalidade que é geralmente chamada de WCCP na verdade envolve três componentes:

1. Funcionalidade implementada somente no roteador ou switch
2. Funcionalidade implementada somente na entidade de processamento de tráfego, como um cache da Web
3. WCCP implementado em ambos os lados

Este documento examina estas três características operacionais do WCCP:

1. O método de atribuição determina qual tráfego WCCP e qual dispositivo WCCP são escolhidos para o destino do tráfego.O protocolo WCCP suporta vários dispositivos agrupados juntos.
2. O método de redirecionamento encaminha o fluxo de tráfego para o dispositivo WCCP quando há necessidade de alterar do caminho de rede normal que o tráfego estava atravessando.
3. O método return determina como o tráfego é enviado de volta ao roteador do dispositivo WCCP se o tráfego não pôde ser atendido. Nos casos em que o dispositivo WCCP atende à solicitação, os pacotes são retornados diretamente ao solicitante.

WCCP e Catalyst 6500

O Catalyst 6500 Supervisor Engine 2, Supervisor Engine 32 e Supervisor Engine 720 suportam esses recursos e métodos WCCP:

• WCCP versão 2 (WCCPv2)
• Método de atribuição baseado em hash
• Método de atribuição baseado em máscara (acelerado por hardware)
• Método de redirecionamento de encapsulamento de roteamento genérico (GRE - Generic Routing Encapsulation) de L3 (acelerado por hardware no Supervisor Engine 32 e no Supervisor Engine 720)
• Método de redirecionamento de Camada 2 (L2) (acelerado por hardware no Supervisor Engine 2, Supervisor Engine 32 e Supervisor Engine 720)
• método de retorno GRE
• Método de retorno L2 com o software Cisco IOS versão 12.2SXH (acelerado por hardware no mecanismo de supervisor 2, mecanismo de supervisor 32 e mecanismo de supervisor 720)

Para obter mais detalhes sobre esses recursos, consulte Configurando o WCCP no Cisco 6500 Series Cisco IOS Software Configuration Guide, 12.2SX.

Método de atribuição de WCCP

A atribuição de WCCP determina qual tráfego o protocolo WCCP redireciona e qual entidade WCCP recebe tráfego redirecionado.

Quando o WCCP é configurado em uma interface de um roteador e em uma entidade WCCP, o dispositivo de redirecionamento (o Catalyst 6500) precisa saber qual tráfego deve ser redirecionado e onde o tráfego deve ser enviado. As entidades WCCP dentro de um grupo de serviços se comunicam através do protocolo WCCP com o Catalyst 6500; no entanto, um dispositivo WCCP é selecionado para representar o cluster a fim de controlar como o cluster opera (pelo método de atribuição, pelo método de redirecionamento e assim por diante). O dispositivo e o roteador WCCP podem negociar o método pelo qual os pacotes são distribuídos entre os caches da Web em um grupo de serviços. Um grupo de serviços é definido como uma relação muitos para muitos entre até 32 roteadores e 32 entidades WCCP. A negociação é por grupo de serviços; assim, os caches da web que participam de vários grupos de serviços podem negociar um método de atribuição diferente para cada grupo de serviços. Os serviços WCCP atualmente disponíveis são:

* Os serviços configuráveis pelo usuário são implementados no Catalyst 6500 com um comando de nível de interface aplicado a uma direção de entrada ou de saída. As implicações da escolha de entrada ou saída são discutidas posteriormente, mas a entrada é o método preferido porque uma lista de redirecionamento pode ser combinada com o WCCP para o desempenho máximo de hardware.

Uma vez configurado para WCCP, um roteador anuncia os métodos de atribuição suportados para um grupo de serviços nas mensagens de comunicação do WCCP. A ausência de tal mensagem implica que o Catalyst 6500 suporta apenas o método de atribuição baseado em hash padrão.

Quando a negociação entre o Catalyst 6500 e o dispositivo WCCP for concluída, a entidade designada WCCP, por meio do WCCP, informará ao Catalyst 6500 qual tráfego será redirecionado e a qual entidade ou entidades WCCP o tráfego será atribuído. Como exemplo, a entidade WCCP pode informar ao Catalyst 6500 para redirecionar todo o tráfego da Web de uma sub-rede específica para os mecanismos de cache de 1 a 4 no grupo de serviços quando houver mais de quatro dispositivos WCCP disponíveis.

Há dois métodos de atribuição disponíveis para o WCCP:

1. A atribuição baseada em hash (padrão) utiliza um algoritmo de hash baseado em software junto com as diretrizes do dispositivo designado pelo WCCP para determinar qual dispositivo WCCP recebe tráfego. Em uma plataforma Supervisor Engine 32 ou Supervisor Engine 720, os recursos de hardware do NetFlow são usados para aplicar algum nível de assistência de hardware.
2. A atribuição baseada em máscara utiliza os recursos de hardware do Catalyst 6500, especificamente a TCAM (ternary content addressable memory) da lista de controle de acesso (ACL), para atribuir tráfego a entidades WCCP. Esse é o método preferido.

Todos os dispositivos em um grupo de serviços WCCP devem usar o mesmo método de atribuição. Os métodos de atribuição são configurados na entidade WCCP e aprendidos pelo Catalyst 6500. Consulte as Recomendações de Projeto do WCCP para obter mais detalhes.

Detalhe do método de atribuição baseado em hash

O mecanismo de atribuição baseado em hash depende de um algoritmo executado no software. Para aproveitar o algoritmo de hash, o primeiro pacote em um fluxo específico é enviado do caminho do hardware para o caminho do software onde o hash é executado.

O software executa um hash XOR de vários componentes do fluxo e gera um hash que divide os fluxos de tráfego para as várias entidades WCCP. O mecanismo de hash determina como o tráfego é distribuído entre as entidades WCCP disponíveis.

O resultado do hash é programado na tabela do NetFlow de hardware onde os pacotes subsequentes nesse fluxo são encaminhados. Independentemente dos campos disponíveis para hash pelo WCCP, são usadas cinco tuplas completas. Isso significa que o NetFlow é colocado na interface, no modo de fluxo completo quando o WCCP é ativado. Isso tem implicações em outros recursos que podem exigir recursos do NetFlow. Consulte a seção WCCP Defects para obter mais detalhes.

Uma pergunta comum sobre o WCCP no Catalyst 6500 é: "Por que a utilização da CPU aumenta quando eu habilito o WCCP?" Quando as atribuições baseadas em hash estão em uso, o processamento baseado em software do pacote inicial em cada fluxo coloca uma carga na CPU e é, com mais frequência, a causa do aumento da utilização. Com o hardware de encaminhamento da PFC3 (Policy Feature Card 3) atualmente disponível, se o WCCP estiver configurado como um recurso de saída ou se a atribuição baseada em hash estiver em uso (entrada ou saída), algum nível de processamento de software será sempre necessário.

O uso do método de atribuição baseado em hash afeta estes recursos:

• Tabela NetFlow - O número de entradas suportadas pela PFC é limitado e a máscara de fluxo muda para o fluxo completo da interface para toda a tabela do NetFlow.
• Utilização da CPU - Há um aumento na utilização da CPU à medida que o primeiro pacote em cada fluxo é comutado por software.
• Performance - A taxa na qual o tráfego é enviado à CPU para pesquisa é limitado de modo que a CPU é protegida.
• Recursos do NetFlow - Outros recursos que usam recursos do NetFlow podem ser afetados se os recursos do NetFlow forem consumidos pelo WCCP.

As limitações e implicações causadas pelo requisito de atribuição baseado em hash para processamento de software são aplicáveis ao tráfego de entrada e saída. O impacto na CPU pode ser exacerbado se a rede estiver passando por padrões de tráfego atípicos, como um ataque de negação de serviço (DoS). Em um ataque típico ou ataque de worm, cada pacote enviado por um host é para um novo destino ou porta, o que faz com que cada pacote seja processado no software. Como o tráfego redirecionado do WCCP está sendo enviado explicitamente para a CPU para o processamento do primeiro pacote, há métodos limitados de proteção. O uso de entradas de ACL 'deny' na interface pode limitar o que é enviado à CPU; no entanto, não há limitadores de taxa ou outras proteções contra esses tipos de ataques.

Detalhes do método de atribuição baseado em máscara

A atribuição baseada em máscara é tratada de forma diferente, dependendo se está configurada na entrada ou na saída.

Com a atribuição baseada em máscara de entrada, a máscara é programada na ACL TCAM antes do encaminhamento de pacotes, de modo que a tabela NetFlow e o processamento de software não são necessários. A entidade WCCP escolhe vários hash-buckets e atribui uma máscara de endereço e um dispositivo WCCP a cada bucket. Quando as atribuições estiverem concluídas, o supervisor programará uma entrada TCAM e uma adjacência de hardware para cada bucket e redirecionará os pacotes que correspondem à máscara de endereço para o dispositivo WCCP associado por meio de uma regravação L2.

Se o WCCP estiver configurado como um recurso de ingresso, ele poderá usar uma entrada de adjacência de redirecionamento de ACL na tabela de ACL de hardware. Quando o WCCP corresponde à entrada, ele usa uma adjacência apropriada para executar uma regravação de L2 ou um encapsulamento GRE. Assim, quando a atribuição de máscara é usada na entrada, tanto a regravação de L2 (Supervisor Engine 2, Supervisor Engine 32 e Supervisor Engine 720) quanto o encapsulamento de GRE (Supervisor Engine 32 e Supervisor Engine 720 somente) são executados no hardware.

Se o WCCP estiver configurado como um recurso de saída, as adjacências de redirecionamento de ACL não serão suportadas no hardware porque os pacotes no fluxo já foram roteados pelo sistema. O primeiro pacote de um fluxo é enviado ao software para processamento. Uma vez determinada a adjacência de redirecionamento adequada, ela é programada no hardware do NetFlow (em vez de TCAM da ACL), onde a entrada aponta para uma adjacência que executa uma regravação de L2 ou encapsulamento GRE. Os pacotes subsequentes no fluxo são redirecionados no hardware pelo hardware do NetFlow.

Note: Se o WCCP estiver configurado como um recurso de saída, a atribuição de máscara requer processamento de software, o que nega qualquer benefício do método de atribuição baseado em máscara.

Das duas opções baseadas em máscara, somente a atribuição baseada em máscara de entrada permite o encaminhamento baseado em hardware completo para pacotes iniciais e subsequentes. Qualquer outra opção, como o uso de atribuição baseada em hash ou processamento de saída, causa a comutação de software do pacote inicial e do encaminhamento comutado de hardware NetFlow dos pacotes subsequentes.

Método de redirecionamento de WCCP

A entidade WCCP, não o Catalyst 6500, dita as tabelas de hash e conjuntos de máscara/valor para o Catalyst 6500, portanto a configuração do método de redirecionamento é feita nesse dispositivo, e não no switch Catalyst 6500. O Catalyst 6500 determina o melhor método de redirecionamento disponível, com base nas comunicações WCCP com a entidade/grupo WCCP. Essa negociação determina como o tráfego redirecionado é encaminhado ao dispositivo. Há duas opções de redirecionamento: L3 (GRE) e L2 (regravações de endereço MAC).

Com o WCCPv1, a única opção é o redirecionamento L3, também conhecido como encapsulamento GRE. Com o redirecionamento L3, cada pacote redirecionado WCCP é encapsulado em um cabeçalho GRE marcado com um tipo de protocolo 0x883E seguido por um cabeçalho de redirecionamento WCCP de quatro octetos, que é enviado posteriormente para o dispositivo WCCP (como um mecanismo de cache).

Com a introdução do WCCPv2, o redirecionamento L2, também conhecido como redirecionamento WCCP acelerado, foi adicionado para aproveitar as plataformas de comutação de hardware como o Catalyst 6500. Quando o WCCP usa o redirecionamento L2, o dispositivo WCCP e o Catalyst 6500 devem ser adjacentes L2 (dentro da mesma VLAN L2). O tráfego L2 redirecionado não usa o encapsulamento GRE; em vez disso, o endereço de destino MAC é regravado pelo Catalyst 6500 para o da entidade WCCP conectada à L2 e encaminhado através de switching de hardware normal.

Note: O método de encaminhamento para o dispositivo WCCP pode não ser o mesmo método que o dispositivo WCCP usa para enviar o tráfego de volta ao Catalyst 6500. O WCCP é usado para negociar um método de encaminhamento e devolução suportado por ambos os dispositivos. Consulte Método de devolução WCCP.

Método de Encaminhamento L3 (GRE)

A operação L3 do WCCP envolve o uso do GRE como um método de encapsulamento. Os pacotes redirecionados são encapsulados em um cabeçalho GRE com um tipo de protocolo 0x883e, juntamente com um cabeçalho de redirecionamento WCCP de 4 bytes que inclui uma ID de serviço e um bucket de hash correspondentes (somente WCCPv2). O uso do GRE permite que o cliente WCCP seja separado do Catalyst 6500 por vários saltos L3 (roteados).

Neste cenário, as opções disponíveis para o redirecionamento WCCP incluem:

1. Entrada - redirecionamento L3 (GRE) + atribuição de hash; isso requer processamento de software.
2. Entrada - redirecionamento L3 (GRE) + atribuição de máscara; isso requer processamento de hardware completo e está disponível somente no Supervisor Engine 32 ou no Supervisor Engine 720.
3. Saída - redirecionamento L3 (GRE) + atribuição de hash; isso requer processamento de software.
4. Saída - redirecionamento L3 (GRE) + atribuição de máscara; isso requer processamento de software.

Entrada - Redirecionamento L3 (GRE) + Atribuição de hash

No Supervisor Engine 2, cada pacote GRE é enviado à placa de recurso de switch multicamada (MSFC) para processamento. Como o encapsulamento GRE não é suportado no hardware, o MSFC deve aplicar cabeçalhos GRE e WCCP, o que força a comutação de software para todo o tráfego.

Com o método de atribuição baseado em hash, o Supervisor Engine 32 e o Supervisor Engine 720 encaminham o primeiro pacote de cada fluxo no software para que uma entrada da tabela NetFlow seja estabelecida. O pacote é encapsulado em GRE (o encapsulamento e o encaminhamento do pacote inicial são feitos em software) e encaminhado para o dispositivo WCCP.

O estabelecimento da entrada do NetFlow afeta a utilização da CPU, mas o encaminhamento de pacotes subsequente é feito no hardware do Supervisor Engine 720 e do Supervisor Engine 32. Os padrões de tráfego, especialmente o número de fluxos únicos, determinam quanto a CPU é utilizada. Se os recursos do NetFlow do Catalyst 6500 forem consumidos, todo o tráfego será encaminhado no software.

Os recursos do NetFlow do supervisor PFC diferem em várias plataformas. Atualmente, os maiores recursos do NetFlow estão disponíveis no PFC-3BXL na plataforma Supervisor Engine 720.

Entrada - Redirecionamento L3 (GRE) + Atribuição de máscara

No Supervisor Engine 2, cada pacote GRE é enviado ao MSFC para processamento. Como o encapsulamento GRE não é suportado no hardware, o MSFC deve aplicar cabeçalhos GRE e WCCP, o que força a comutação de software para todo o tráfego.

Com o método de atribuição baseado em máscara, o Supervisor Engine 32 e o Supervisor Engine 720 encaminham os pacotes iniciais e subsequentes no hardware, porque o GRE é suportado nativamente, e a atribuição de máscara usa o hardware TCAM da ACL para encaminhamento.

Saída - Redirecionamento L3 (GRE) + Atribuição de hash

No Supervisor Engine 2, cada pacote é enviado ao MSFC para processamento. Como o encapsulamento GRE não é suportado no hardware, o MSFC deve aplicar cabeçalhos GRE e WCCP, o que força a comutação de software para todo o tráfego.

Com o método de atribuição baseado em hash com o Supervisor Engine 32 e o Supervisor Engine 720, o Catalyst 6500 encaminha o pacote inicial de cada fluxo no software para que a entrada da tabela NetFlow seja estabelecida. O pacote é encapsulado em GRE e encaminhado à entidade WCCP.

O estabelecimento da entrada do NetFlow afeta a utilização da CPU, mas o encaminhamento de pacotes subsequente é feito no hardware. Os padrões de tráfego, especialmente o número de fluxos únicos, determinam quanto a CPU é utilizada. Se os recursos do NetFlow do Catalyst 6500 forem consumidos, todo o tráfego será encaminhado no software.

Os recursos do NetFlow do supervisor PFC diferem entre as várias plataformas. Atualmente, os maiores recursos do NetFlow estão disponíveis no PFC-3BXL na plataforma Supervisor Engine 720.

Saída - Redirecionamento L3 (GRE) + Atribuição de máscara

No Supervisor Engine 2, cada pacote é enviado ao MSFC para processamento. Como o encapsulamento GRE não é suportado no hardware, o MSFC deve aplicar cabeçalhos GRE e WCCP, o que força a comutação de software para todo o tráfego.

Com o método de atribuição baseado em máscara com o Supervisor Engine 32 e o Supervisor Engine 720, o primeiro pacote de cada fluxo é comutado por software para que a entrada da tabela NetFlow seja estabelecida. Nenhum dos supervisores suporta programação de adjacência de ACL de saída, que força esse processamento de software e usa recursos NetFlow (em vez de TCAM de ACL de hardware) para o pacote inicial em cada fluxo. O pacote é encapsulado em GRE e encaminhado ao dispositivo WCCP.

O estabelecimento da entrada do NetFlow afeta a utilização da CPU, mas o encaminhamento de pacotes subsequente é feito no hardware. Os padrões de tráfego, especialmente o número de fluxos únicos, determinam quanto a CPU é utilizada. Se os recursos do NetFlow do Catalyst 6500 forem consumidos, todo o tráfego será encaminhado no software.

Os recursos do NetFlow do supervisor PFC diferem entre as várias plataformas. Atualmente, os maiores recursos do NetFlow estão disponíveis no PFC-3BXL na plataforma Supervisor Engine 720.

Método de Encaminhamento L2

Com o encaminhamento L2, as entidades WCCP (ACNS, WAFS, WAAS, etc.) dentro de um grupo de serviços fazem parte da mesma sub-rede e são L2 adjacentes ao Catalyst 6500. Isso permite alto throughput, redirecionamento de tráfego de baixa latência. A interface de ingresso (onde o WCCP está configurado) e a interface onde os dispositivos WCCP estão localizados devem estar em VLANs diferentes.

Note: Com o redirecionamento L2, o pacote é regravado com o MAC de origem definido para o roteador e o MAC de destino definido para o mecanismo de cache. A única desvantagem desse método de redirecionamento é que o mecanismo de cache deve ser L2 alcançável pelo Catalyst 6500 e deve residir em uma interface L3 diferente da interface WCCP de entrada configurada.

Note: O método de encaminhamento para o dispositivo WCCP pode não ser o mesmo método que o dispositivo WCCP usa para enviar o tráfego de volta ao Catalyst 6500. O WCCP é usado para negociar um método de encaminhamento e devolução suportado por ambos os dispositivos. Consulte Método de devolução WCCP.

As opções disponíveis para o redirecionamento WCCP neste cenário incluem:

• Entrada - redirecionamento L2 + atribuição de hash; isso requer processamento de software.
• Ingresso - Redirecionamento L2 + atribuição de máscara que requer processamento de hardware completo e é recomendado.
• Saída - redirecionamento L2 + atribuição de hash; isso requer processamento de software.
• Saída - redirecionamento L2 + atribuição de máscara; isso requer processamento de software.

Entrada - L2 + Atribuição de hash

Quando configurado na entrada com atribuição de hash L2 +, o tráfego WCCP envia o primeiro pacote em cada fluxo para ser comutado por software, o que cria uma entrada NetFlow na tabela NetFlow de hardware.

Note: A máscara de fluxo do NetFlow é definida para o modo de fluxo completo da interface, o que pode afetar outros recursos do NetFlow configurados no switch.

Uma vez que o WCCP é um mecanismo stateless, as informações não são mantidas no software; em vez disso, ele é mantido no hardware como entradas na tabela NetFlow. O tráfego subsequente no fluxo é encaminhado no hardware, desde que exista uma entrada na tabela NetFlow.

O estabelecimento da entrada do NetFlow afeta a utilização da CPU, mas o encaminhamento de pacotes subsequente é feito no hardware. Os padrões de tráfego, especialmente o número de fluxos únicos, determinam quanto a CPU é utilizada. Se os recursos do NetFlow do Catalyst 6500 forem consumidos, todo o tráfego será encaminhado no software.

Os recursos do NetFlow do supervisor PFC diferem entre as várias plataformas. Atualmente, os maiores recursos do NetFlow estão disponíveis no PFC-3BXL na plataforma Supervisor Engine 720.

Entrada - L2 + Atribuição de Máscara

Quando configurado na entrada, a atribuição de máscara L2 + é o método WCCP mais eficiente suportado no Catalyst 6500. Todo o tráfego é comutado por hardware, incluindo o pacote inicial em cada fluxo. Não é necessário redirecionamento de software; o encaminhamento inicial e subsequente de pacotes é fornecido pelo hardware.

Os recursos de TCAM de ACL de hardware do Catalyst 6500 são usados para pré-programar as entradas de hardware antes de qualquer pacote WCCP ser recebido.

Para usar esse método e utilizar a comutação de hardware completa, a entidade WCCP também deve suportar o redirecionamento L2 e o método de atribuição baseado em máscara. A configuração desse método é concluída na entidade WCCP e o Catalyst 6500 negocia o melhor método durante as comunicações iniciais do WCCP com a entidade/grupo do WCCP.

Saída - L2 + Atribuição de hash

Com a atribuição de hash L2 + de saída, o tráfego WCCP envia o primeiro pacote em cada fluxo para ser comutado por software, o que cria uma entrada NetFlow na tabela NetFlow de hardware.

Note: A máscara de fluxo do NetFlow é definida para o modo de fluxo completo da interface, o que pode afetar outros recursos do NetFlow configurados no switch.

Além disso, quando configurado na direção de saída, uma pesquisa adicional de base de informações de encaminhamento (FIB) é necessária no primeiro pacote do fluxo para determinar a adjacência associada ao CE, que requer recirculação de pacotes no Catalyst 6500. Os pacotes subsequentes são comutados pelo NetFlow no hardware.

O estabelecimento da entrada do NetFlow afeta a utilização da CPU, mas o encaminhamento de pacotes subsequente é feito no hardware. Os padrões de tráfego, especialmente o número de fluxos únicos, determinam quanto a CPU é utilizada. Se os recursos do NetFlow do Catalyst 6500 forem consumidos, todo o tráfego será encaminhado no software.

Os recursos do NetFlow do supervisor PFC diferem entre as várias plataformas. Atualmente, os maiores recursos do NetFlow estão disponíveis no PFC-3BXL na plataforma Supervisor Engine 720.

Saída - L2 + Atribuição de máscara

Quando configurado na direção de saída, a atribuição de máscara L2 + comuta o primeiro pacote em cada fluxo no software, assim como o caso de atribuição de hash L2 +. Os pacotes subsequentes são comutados pelo NetFlow no hardware.

Note: A máscara de fluxo do NetFlow é definida para o modo de fluxo completo da interface, o que pode afetar outros recursos do NetFlow configurados no switch.

O PFC2 e o PFC3 não suportam programação de adjacência de ACL de saída, que força o processamento de software para o pacote inicial em cada fluxo; os pacotes subsequentes no fluxo são encaminhados no hardware.

O estabelecimento da entrada do NetFlow afeta a utilização da CPU, mas o encaminhamento de pacotes subsequente é feito no hardware. Os padrões de tráfego, especialmente o número de fluxos únicos, determinam quanto a CPU é utilizada. Se os recursos do NetFlow do Catalyst 6500 forem consumidos, todo o tráfego será encaminhado no software.

Os recursos do NetFlow do supervisor PFC diferem entre as várias plataformas. Atualmente, os maiores recursos do NetFlow estão disponíveis no PFC-3BXL na plataforma Supervisor Engine 720.

Método de devolução WCCP

A entidade WCCP pode atender à solicitação

Quando o WCCP é usado para interceptar tráfego e a entidade WCCP executa uma operação completa nesses pacotes, os pacotes estão prontos para serem enviados de volta ao cliente a partir do dispositivo WCCP. Esse tráfego normalmente processado, que é destinado de volta ao cliente na rede, não requer nenhum encapsulamento especial quando enviado do dispositivo WCCP de volta para o cliente.

Como a interceptação WCCP resultou no atendimento bem-sucedido da solicitação do cliente (arquivo do cache, fluxo dividido do cache, arquivo do WAAS), ela pode ser enviada de volta à rede como tráfego normal com o endereço de destino nos pacotes sendo o solicitante original. Esse tráfego pode ser normalmente L3/comutado pelo Catalyst 6500 se estiver no caminho de rede do dispositivo WCCP para o cliente; com um dispositivo WCCP L2 conectado, o tráfego está no caminho da rede. Nenhum encapsulamento é necessário para enviá-lo de volta do dispositivo WCCP para o Catalyst 6500 porque o destino agora é o cliente original em vez de um servidor na Internet ou intranet. Em seguida, a rede lida com isso como qualquer outro fluxo de tráfego IP e usa o encaminhamento de hardware no Catalyst 6500 para devolver o tráfego solicitado ao cliente.

A entidade WCCP não pode atender à solicitação

Em alguns casos em que a entidade WCCP não pode executar a operação solicitada, o dispositivo WCCP pode precisar enviar o tráfego de volta para o Catalyst 6500 e preservar o destino original dos pacotes. O encaminhamento desse tráfego da entidade WCCP sem encapsulamento pode resultar em loops de tráfego. Para ocultar uma tentativa de serviço malsucedida do cliente e enviar os pacotes para o destino original a ser atendido, os pacotes devem permanecer inalterados, ser colocados de volta em seu caminho de encaminhamento original e encaminhados sem interceptação WCCP para o destino original.

No método de devolução do WCCP, o WCCP pode ser usado para encapsular esses pacotes, enviá-los de volta ao dispositivo que os interceptou em primeiro lugar, retirar qualquer encapsulamento e colocá-los de volta no caminho de encaminhamento do qual foram interceptados. Esses pacotes precisam ser enviados normalmente como se nunca tivessem sido interceptados pelo WCCP.

Exemplos desses casos incluem:

• Tráfego sobrecarregado de cache, em que o tráfego está sendo ignorado
• Regras sobre dispositivos de cache que impedem a entidade WCCP de atender ao tráfego
• Tráfego ignorado que está procurando um serviço não disponível no dispositivo

No momento, esse método de devolução pode ser feito somente com encapsulamento GRE e ainda não é suportado em nenhum hardware Catalyst 6500. Se grandes quantidades de tráfego forem enviadas de volta ao Catalyst 6500 com esse método, a alta utilização da CPU poderá ocorrer porque esse tráfego é processado no software. No Cisco IOS Software Release 12.1(18)SXH, há um método de retorno de L2 suportado pelo hardware do Catalyst 6500.

Retorno GRE

Nas versões do software Cisco IOS anteriores à 12.2(18)SXH, o único método de retorno suportado para o Catalyst 6500 é o encapsulamento GRE. Além do cabeçalho GRE anexado ao tráfego de retorno, um cabeçalho WCCP também é anexado. Embora o GRE seja suportado nativamente no hardware do Supervisor Engine 32 e do Supervisor Engine 720, esse cabeçalho adicional faz com que o GRE não seja assistido por hardware. Observe que o Catalyst 6500 e o dispositivo WCCP devem suportar e negociar o método de retorno L2.

Não existe suporte de hardware GRE no Supervisor Engine 2 para qualquer devolução de GRE, entrada, saída ou WCCP. Para processar esse tipo de desencapsulamento de GRE, o software Cisco IOS programa a adjacência de recepção do túnel GRE WCCP na interface habilitada WCCP para apontar para o processador de rota (RP), que resulta no processamento de software do tráfego de retorno.

O uso de listas de redirecionamento no Catalyst 6500 para evitar o tráfego que pode precisar ser retornado por GRE é um método eficaz para reduzir os requisitos de processamento de software do tráfego que seria enviado de volta da entidade WCCP. Isso é muito mais eficaz do que ter tráfego negado na entidade WCCP e forçá-lo a ser encapsulado e enviado de volta para o Catalyst 6500.

Lembre-se de que o grupo de serviços WCCP é escalável. Se o excesso de tráfego for ignorado devido à carga, esse tráfego será enviado de volta, o que cria a carga da CPU no Catalyst 6500. O único método para evitar essa situação é o dimensionamento adequado ou até mesmo a sobrecriação do grupo de serviços WCCP.

Aprimoramento do retorno L2

Em 12.2(18)SXH, uma opção permite que a entidade WCCP regrave o endereço MAC L2 em vez de encapsular o tráfego de retorno. Essa melhoria de retorno de L2 (ID de bug Cisco CSCuk59825) permite o processamento de hardware do tráfego retornado quando o WCCP está configurado para usar o redirecionamento de entrada com atribuição de máscara.

Resumo das opções do WCCP

Quando implementado no Catalyst 6500, o WCCP oferece muitas opções de configuração, como mostrado nesta tabela. Observe que o dispositivo WCCP negocia essas opções e controla quais opções são usadas pelo Catalyst 6500. A configuração é feita no lado do dispositivo WCCP da conexão WCCP.

Do ponto de vista do hardware, todas as configurações de WCCP de saída exigem processamento de software e afetam a utilização da CPU. O processamento de software também é necessário na entrada quando o método de atribuição baseado em hash é usado e resulta no mesmo impacto potencial na utilização da CPU.

O método recomendado de implantação de WCCP no Catalyst 6500 é o redirecionamento L2 com atribuição de máscara e, quando disponível, retorno L2.

Tip: Apenas uma opção garante um alto desempenho, encaminhamento baseado em hardware completo: o redirecionamento L2 baseado em entrada com atribuição de máscara no Supervisor Engine 2, Supervisor Engine 32 e Supervisor Engine 720.

Recomendações de projeto do WCCP

Use essas recomendações de configuração para determinar o melhor método de implantação do WCCP para sua situação.

Summary

Projetar a rede de modo que a entrada do WCCP possa ser usada como um método de redirecionamento. Um bom método de projeto é ter um bloco de switch de cache como parte de uma rede de distribuição hierárquica de L3; isso garante que o tráfego com serviço WCCP possa ser identificado em algumas portas de entrada principais.

• Usar 12.2(18)SXF7 ou software Cisco IOS mais recente.
• Identificar e redirecionar o tráfego nas interfaces de entrada.
• Usar dispositivos WCCP que suportam o método de redirecionamento L2.
• Usar dispositivos WCCP que suportam o método de atribuição baseado em máscara.
• Se possível, use uma lista de redirecionamento no Catalyst 6500 para tráfego que não pode ser atendido pelo dispositivo WCCP.
• Ajuste os temporizadores do NetFlow com egresso ou qualquer configuração de atribuição baseada em hash com Supervisor Engine 720.
• Os dispositivos WCCP devem ter um ambiente L3 dedicado e uma interface SVI/VLAN.

Além disso, o Cisco Advanced Service recomenda estas considerações de projeto:

• Em um ambiente que não é totalmente redirecionado de L2 com atribuição de máscara, o Supervisor Engine 720 não tem um desempenho melhor do que a plataforma do Supervisor Engine 2. Não atualize o hardware e espere um melhor desempenho nessa situação.
• Para implantações de locais centrais grandes com requisitos de tráfego de alto volume, considere um projeto com roteamento baseado em políticas (PBR) e Cisco Content Switching Model (CSM)/Application Control Engine (ACE) para interceptação e encaminhamento de tráfego.
• O WCCPv2 funciona como esperado em circunstâncias perfeitas. No entanto, em algumas circunstâncias, a utilização da CPU no roteador pode alcançar altos níveis que tornam o dispositivo inutilizável e exigem recarga:
  
  
  • O WCCPv2 recua do modo de atribuição baseado em máscara L2 acelerada por hardware de entrada para qualquer outro modo que exija a CPU no MSFC.
  • O WCCP está configurado incorretamente (por exemplo, saída em vez de entrada ou hash L2 em vez de atribuição de máscara).
• Qualquer implantação de WCCP de alto volume com o Catalyst 6500 (cache, streaming, WAAS ou outros cenários de "alta taxa de tráfego") deve ser testada com o tráfego ao vivo antes da implantação completa da produção.

Recomendações adicionais

Use uma lista de redirecionamento no switch para evitar que os pacotes sejam enviados de volta ao Catalyst 6500. Se qualquer regra dos dispositivos de cache puder ser movida para o Catalyst 6500 como uma lista de redirecionamento, isso pode fornecer melhor desempenho de hardware.

Os recursos do NetFlow na plataforma do Supervisor Engine 720 podem ser esgotados rapidamente se você usar qualquer método diferente da atribuição de máscara de L2 de entrada. O Supervisor Engine 720 não oferece melhor desempenho que o Supervisor Engine 2 com qualquer outro método.

Nos casos em que o Supervisor Engine 720 ou o Supervisor Engine 32 devem ser usados em um projeto não ideal, considere o uso do comando mls ip netflow create software-mode fast para que o processamento do NetFlow do pacote inicial do WCCP possa ser acelerado. Isso remove os aprimoramentos adicionados ao Supervisor Engine 32 e ao Supervisor Engine 720 NetFlow e fornece desempenho igual ao do hardware do NetFlow do Supervisor Engine 2.

A configuração de um Cisco Content Engine (CE) para atribuição de máscara é:

• wccp versão 2
• lista de roteadores wccp number ip-address
• wccp serviço router-list-num num mask-attribute

Use estes comandos para revisar a utilização do NetFlow e determinar se o WCCP está usando entradas NetFlow e está usando processamento de software:

• show mls netflow table-contention detailed
• show mls netflow ip sw-installed
• show mls netflow aging
• show mls netflow ip dynamic count
• show mls netflow ip count
• show mls ip
• show fm netflow counters

Se você tiver problemas com o software WCCP porque os recursos do NetFlow estão sendo consumidos, esses comandos podem limpar agressivamente as entradas existentes e criar espaço para novas entradas. (Isso não ajuda se houver simplesmente mais entradas do que espaço do NetFlow.)

• mls aging fast time 3 threshold 1
• mls aging long 64
• mls aging normal 32
• mls ip netflow create software-mode fast (isso desabilita algumas alterações do NetFlow do Supervisor Engine 720 que não estavam no Supervisor Engine 2.)

Para evitar descartes de pacotes, as entidades WCCP devem redirecionar o tráfego para fora de uma interface que não seja a interface na qual o WCCP está configurado. O Catalyst 6500 WCCP descarta pacotes nessa situação quando todas as condições são atendidas:

• Tanto os clientes quanto a entidade WCCP estão na mesma interface L3.
• A política de redirecionamento WCCP é aplicada nesta interface.
• O método de redirecionamento GRE é usado.
• É necessária a fragmentação do pacote de redirecionamento.
• O Supervisor Engine 720 é usado.

Essa situação é causada por mecanismos de proteção incorporados ao Catalyst 6500; o software Cisco IOS tem verificações que impedem que o pacote entre e saia da mesma interface virtual do software Cisco IOS, onde ele pode potencialmente fazer loop e causar comportamento indesejado. Mova os dispositivos WCCP para seu próprio ambiente L3 dedicado para evitar isso.

A limitação de taxa baseada no usuário (UBRL) e o WCCP não funcionam simultaneamente em uma interface por causa das máscaras de fluxo. Há uma máscara de fluxo para cada interface para cada recurso unicast. O WCCP requer fluxo completo e o UBRL usa somente src ou somente dst.

O suporte a WCCP foi adicionado para o Supervisor Engine 2 e retorno L2 em 12.2(18)SXF5. Isso não estava no Supervisor Engine 720 até 12.2(18)SXH em abril/Maio de 2007.

Somente o redirecionamento de PFC L2 do WCCP é suportado com o balanceamento de carga do servidor (SLB) do software Cisco IOS; outras configurações de WCCP não são compatíveis e o GRE não funciona. O comando acelerado do WCCP aplica-se somente ao Supervisor Engine 2/MSFC2. Seu objetivo é forçar o roteador a negociar a atribuição de máscara e o redirecionamento L2, o que significa que todo o redirecionamento de WCCP é feito no hardware. O Supervisor Engine 32 e o Supervisor Engine 720 negociam isso sem a necessidade desse comando.

Soluções

Note: Use a Command Lookup Tool ( somente clientes registrados) para obter mais informações sobre os comandos usados nesta seção.

ACNS

Para o redirecionamento de cache transparente padrão, lembre-se de que a entidade WCCP fornece ao roteador WCCP os métodos suportados e pode precisar ser configurada para isso. Para o Cisco ACNS, este exemplo de configuração solicita os métodos otimizados de redirecionamento L2 e atribuição baseada em máscara:

1. Assegure-se de que você tenha WCCPv2 para as otimizações do Catalyst 6500:
   
   

   ContentEngine(config)# wccp version 2

2. Configure uma lista de roteadores que defina os Catalyst 6500s a serem usados:
   
   

   ContentEngine(config)# wccp router-list 1 172.16.16.1

3. Configure o serviço para usar os métodos de otimização:
   
   

   ContentEngine(config)# wccp service router-list-num 1 l2-redirect mask assign

Do lado do roteador, o design do Catalyst 6500 deve garantir que os dispositivos WCCP estejam em uma interface L3 dedicada que não esteja no caminho de tráfego atual (entrada ou saída). Para desempenho de hardware, os fluxos de tráfego devem ser capturados na entrada do Catalyst 6500, mesmo que isso exija a configuração de mais interfaces do que se uma única interface de saída fosse escolhida. Um projeto ideal agregaria todo o tráfego antes de alcançar esse dispositivo, e somente algumas interfaces exigiriam a configuração de entrada do WCCP.

A configuração do WCCP no Catalyst 6500 deve ser:

1. Configurar o WCCPv2:
   
   

   6500Switch# ip wccp version {1 | 2}

2. Configure um grupo de serviços WCCP.
   
   

   6500Switch (config)# ip wccp service [accelerated] redirect-list access-list

   Use o comando acelerado somente para plataformas do Supervisor Engine 2 com o software Cisco IOS 12.1E.

A lista de redirecionamento é usada para identificar o tráfego que deve ser selecionado ou não para redirecionamento. Lembre-se de que essa ACL pode ser executada no hardware, que é uma maneira muito mais eficiente de evitar o redirecionamento para o tráfego que não pode ser atendido pelo dispositivo WCCP. O tráfego que é enviado ao dispositivo e não pode ser atendido deve ser retornado a este Catalyst 6500 para ser colocado de volta no caminho de tráfego original, que requer processamento adicional. As listas de acesso WCCP são listas de acesso padrão ou estendidas.

Este exemplo mostra que qualquer solicitação de 10.1.1.1 a 12.1.1.1 ignora o cache e que todas as outras solicitações são redirecionadas.

6500Switch(config)# ip wccp service redirect-list 120
6500Switch(config)# access-list 120 deny tcp host 10.1.1.1 any
6500Switch(config)# access-list 120 deny tcp any host 12.1.1.1
6500Switch(config)# access-list 120 permit ip any any

Configure o método WCCP de entrada em cada interface de entrada que recebe o tráfego a ser redirecionado:

Router(config-if)# ip wccp service redirect in

Isso conclui a configuração no dispositivo WCCP e no switch, de modo que o redirecionamento de tráfego deve ocorrer nesse ponto.

As configurações WCCP finais dos dispositivos são assim.

wccp version 2
wccp router-list 1 router-ip-addresses
wccp service router-list-num 1 l2-redirect mask assign

ip wccp version 2
ip wccp service redirect-list 120
access-list 120 deny tcp ...
access-list 120 deny udp ...
access-list 120 permit ip any any

ip wccp redirect service in

Para verificar essa configuração, insira este comando:

Show ip wccp service detail

Para opções de configuração de WCCP adicionais, como endereçamento de grupo usando multicast ou segurança de WCCP adicional, consulte Configuração de Serviços de Cache da Web usando WCCP.

Comandos show e debug do WCCP IOS

• show ip wccp service-number - fornece a contagem 'Total de pacotes redirecionados'. Essa contagem é o número de fluxos, ou sessões, que são redirecionados.
• show ip wccp service-number detail - fornece a contagem de "Pacotes Redirecionados". A contagem é o número de fluxos, ou sessões, que são redirecionados.
• show ip wccp web-cache detail - fornece uma indicação de quantos fluxos, em vez de pacotes, estão usando o redirecionamento L2.
• clear ip wccp - redefine o contador para as informações de 'Pacotes Redirecionados'.
• show ip wccp service-number view - exibe os dispositivos WCCP que fazem parte do grupo de serviços.
• show ip wccp service-number service - exibe o hash, as portas e a prioridade WCCP do serviço. Os serviços de prioridade mais alta são atingidos primeiro quando vários serviços são configurados na interface.
• debug ip wccp events - soluciona problemas do estado do protocolo WCCP.
• debug ip wccp packets - revisa as comunicações entre as entidades de processamento de pacotes do WCCP.

Quando você usa o WCCP e o encaminhamento de hardware, alguns contadores podem não ser exibidos como esperado:

• Se a ACL WCCP for processada completamente no hardware, os contadores WCCP podem não exibir contagens precisas de pacotes.
• Se o WCCP estiver usando a atribuição baseada em hash e os recursos de hardware do NetFlow, os contadores do WCCP podem refletir o número de fluxos em vez do número de pacotes.

Comandos do NetFlow

Quando você tiver configurações WCCP que exigem o uso de recursos de hardware NetFlow, use estes comandos de switching multicamada (MLS) e Fabric Manager (FM) para que você possa rever o status dos recursos do NetFlow:

• show mls netflow table-contention detailed
• show mls netflow ip sw-installed
• show mls netflow aging
• show mls netflow ip dynamic count
• show mls netflow ip count
• show mls ip
• show fm netflow counters

Defeitos do WCCP

Esta tabela de IDs de bug e resoluções da Cisco suporta a recomendação geral de usar o Cisco IOS Software Release 12.2(18)SXF7 ou posterior para obter o melhor suporte do WCCP.

Histórico de revisões