WCCP em Plataformas do Catalyst 6500 com manual de configuração da utilização elevada da CPU

Introdução

Este documento descreve como usar o Protocolo de Comunicação de Cache da Web (WCCP) na plataforma do Cisco Catalyst 6500 Series.

O WCCP foi projetado originalmente como um método interceptar o tráfego de web (HTTP) e dianteiro ele a um dispositivo do cache local, onde poderia ser servido a um cliente de uma Localização Local e conservar a largura de banda de WAN cara.

De uma perspectiva do usuário de rede, o WCCP é transparente porque é usado a nível de rede, sem nenhuma configuração especial pelo usuário, a fim identificar e reorientar o tráfego de web que atravessa um dispositivo da camada 3 (L3) a um dispositivo do cache local. Embora o WCCP fosse projetado originalmente para o tráfego de web, o método transparente da reorientação transformou-se um mecanismo muito útil para endereçar outros problemas com índice do volume alto sobre os links do volume baixo. Por este motivo, o suporte de protocolo adicional foi adicionado a umas versões de WCCP mais atrasadas. Estas Tecnologias adicionais incluem protocolos tais como o HTTP, o HTTPS, o FTP, o fluxo de vídeo, e o arquivo que põe em esconderijo Tecnologias, tais como o Common Internet File System (CIFS). Estas soluções da Cisco e Plataformas mais novas do apoio de Tecnologias, tais como o Wide Area File Services (WAFS), o Wide Area Application Services (WAAS), aplicativo orientaram os trabalhos em rede (AON), e os recursos avançados do Application and Content Networking Software (ACNS).

A adoção WCCP está aumentando como as empresas executam as ferramentas as mais atrasadas da produtividade tais como comunicações e o treinamento baseados em vídeo, assim como vive e vídeo por encomenda. Os esforços para controlar custos, tais como centros de dados consolidados, criam a necessidade para que o WCCP apoie serviços adicionais, extremamente altas da largura de banda.

Devido à importância do WCCP com redes ricas satisfeitas de hoje, algumas Plataformas, tais como o Catalyst 6500, executaram o desempenho hardware-ajudado com WCCP de modo que a carga de CPU exigida para o protocolo fosse reduzida. Este documento descreve como distribuir o WCCP no Catalyst 6500 a fim maximizar a utilização do hardware e reduzir a carga de CPU.

Pré-requisitos

Requisitos

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

• WCCP
• Cisco Catalyst 6500 Series Switch
• 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
• Cisco IOS Software Release 12.1(50)SY ou Mais Recente com Supervisor Engine 2T (Policy Feature Card 4)
• Cisco IOS Software Release 12.2(18)SXD1 ou Mais Recente com Supervisor Engine 720 (Policy Feature Card 3)

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Visão geral funcional WCCP

A funcionalidade que está referido genericamente enquanto o WCCP envolve realmente três componentes:

1. Funcionalidade executada somente no roteador ou no interruptor
2. Funcionalidade executada somente na entidade do processamento de tráfego, tal como um cache de web
3. WCCP executado em ambos os lados

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

1. O método de atribuição determina que tráfego WCCP e que dispositivo WCCP é escolhido para o destino do tráfego. Os dispositivos múltiplos dos suportes de protocolo WCCP aglomerados junto.
2. O método de redirecionamento para a frente o fluxo de tráfego ao dispositivo WCCP quando houver uma necessidade de mudar do trajeto de rede normal que o tráfego atravessava.
3. O método do retorno determina como o tráfego é enviado para trás ao roteador do dispositivo WCCP se o tráfego não poderia ser prestado serviços de manutenção. Nos casos onde o dispositivo WCCP presta serviços de manutenção ao pedido, os pacotes são retornados diretamente ao utilizador.

WCCP e Catalyst 6500

O apoio do Engine 2, do Supervisor Engine 32, e do Supervisor Engine 720 do Catalyst 6500 Supervisor estas características e métodos WCCP:

• Versão de WCCP 2 (WCCPv2)
• método de atribuição Mistura-baseado
• método de atribuição Máscara-baseado (hardware-acelerado)
• Método de redirecionamento do Generic Routing Encapsulation (GRE) L3 (hardware-acelerado no Supervisor Engine 32 e no Supervisor Engine 720)
• Método de redirecionamento da camada 2 (L2) (hardware-acelerado no Supervisor Engine 2, no Supervisor Engine 32, e no Supervisor Engine 720)
• Método do retorno GRE
• Método do retorno L2 com o Cisco IOS Software Release 12.2SXH (hardware-acelerado no Supervisor Engine 2, no Supervisor Engine 32, e no Supervisor Engine 720)

Para mais detalhes nestas características, refira configurar o WCCP no manual de configuração do Cisco IOS Software do Cisco 6500 Series, 12.2SX.

Método de atribuição WCCP

A atribuição WCCP determina que tráfego o protocolo WCCP reorienta e que entidade WCCP recebe o tráfego redirecionado.

Quando o WCCP é configurado em uma relação de um roteador e em uma entidade WCCP, as necessidades de reorientação do dispositivo (o Catalyst 6500) de saber que tráfego deve ser reorientada e onde o tráfego devem ser enviada. Todas as entidades WCCP dentro de um grupo de serviço aglomeram comunicam-se com o protocolo WCCP com o Catalyst 6500; contudo, um dispositivo WCCP é selecionado para representar o conjunto a fim controlar como o conjunto se 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 por que os pacotes são distribuídos entre os caches de web em um grupo de serviço. Um grupo de serviço é definido como uns muito-à-muitos relacionamento entre até 32 Router e 32 entidades WCCP. A negociação é pelo grupo de serviço; assim, os caches de web que participam em diversos grupos de serviço podem negociar um método de atribuição diferente para cada grupo de serviço. Os serviços atualmente disponíveis WCCP são:

* Os serviços dos configuráveis pelo usuário são executados no Catalyst 6500 com um comando interface level aplicado a uma direção de entrada ou de saída. As implicações da escolha de entrada ou de partida são discutidas mais tarde, mas de entrada é o método preferido porque uma lista da reorientação pode ser acoplada com o WCCP para o desempenho de hardware máximo.

Configurado uma vez para o WCCP, um roteador anuncia os métodos de atribuição apoiados para um grupo de serviço nas mensagens das comunicações WCCP. A ausência de tal mensagem implica que o Catalyst 6500 apoia o método de atribuição mistura-baseado padrão somente.

Uma vez a negociação entre o Catalyst 6500 e o dispositivo WCCP está completa, a entidade designada WCCP, com o WCCP, informa o Catalyst 6500 que tráfego deve ser reorientada e a que entidades WCCP o tráfego é atribuído. Como um exemplo, a entidade WCCP pode informar o Catalyst 6500 para reorientar todo o tráfego de web de uma sub-rede particular para pôr em esconderijo os motores 1 - 4 no grupo de serviço quando há mais de quatro dispositivos WCCP disponíveis.

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

1. a atribuição Mistura-baseada (padrão) utiliza um algoritmo de hash com base no software junto com diretrizes orientadoras do dispositivo WCCP-designado a fim determinar que dispositivo WCCP recebe o tráfego. Em uma plataforma do Supervisor Engine 32 ou do Supervisor Engine 720, os recursos do hardware do Netflow são usados a fim aplicar algum nível da assistência de hardware.
2. a atribuição Máscara-baseada utiliza as capacidades do hardware do Catalyst 6500, especificamente o Ternary Content Addressable Memory do Access Control List (ACL) (TCAM), a fim atribuir o tráfego às entidades WCCP. Este é o método preferido.

Todos os dispositivos dentro de um grupo de serviço 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. Refira recomendações de design WCCP para mais detalhes.

Detalhe Mistura-baseado do método de atribuição

O mecanismo mistura-baseado da atribuição confia em um algoritmo executado no software. A fim leverage o algoritmo de hash, o primeiro pacote em um fluxo particular é enviado do trajeto do hardware ao caminho de software onde a mistura é executada.

O software executa uma mistura XOR de vários componentes do fluxo e vem acima com uma mistura que rache os fluxos de tráfego às várias entidades WCCP. O mecanismo da mistura determina como o tráfego é distribuído entre as entidades disponíveis WCCP.

O resultado da mistura é programado na tabela do Netflow do hardware onde os pacotes subsequente nesse fluxo são enviados. Apesar dos campos disponíveis para picar pelo WCCP, a cinco-tupla completa é usada. Isto significa que o Netflow está posto na relação, modo fluxo completo quando o WCCP é permitido. Isto tem implicações nos outros recursos que podem exigir recursos do Netflow. Veja a seção dos defeitos WCCP para mais detalhes.

Uma pergunta comum sobre o WCCP no Catalyst 6500 é, “porque faz o aumento da utilização CPU quando eu permito o WCCP?” Quando as atribuições mistura-baseadas estão no uso, o processamento com base no software do pacote inicial em cada fluxo coloca uma carga no CPU e é o mais frequentemente a causa da utilização aumentada. Com o hardware de encaminhamento atualmente disponível do Policy Feature Card 3 (PFC3), se o WCCP está configurado como uma característica da saída ou se a atribuição mistura-baseada está no uso (ingresso ou saída), algum nível do processamento do software é exigido sempre.

O uso do método de atribuição mistura-baseado impacta estas características:

• Tabela do Netflow - O número de entradas apoiadas pelo PFC é limitado, e as mudanças da máscara do fluxo conectar o FULL-fluxo para a tabela inteira do Netflow.
• Utilização CPU - Há um aumento na utilização CPU porque o primeiro pacote em cada fluxo é software comutado.
• Desempenho - A taxa em que o tráfego é enviado ao CPU para a consulta é limitada de modo que o CPU seja protegido.
• Características do Netflow - Os outros recursos que usam recursos do Netflow puderam ser impactados se os recursos do Netflow são consumidos pelo WCCP.

As limitações e as implicações causadas pela exigência mistura-baseada da atribuição para o processamento do software são aplicáveis ao ingresso e ao tráfego de saída. O impacto no CPU pode ser agravado se a rede se está submetendo a testes padrão de tráfego atípicos, tais como um ataque de recusa de serviço (DOS). Em uma manifestação típica do ataque ou do worm, cada pacote enviado por um host é a um destino ou a uma porta nova, que façam com que cada pacote seja processado no software. Desde que o tráfego redirecionado WCCP está sendo enviado explicitamente ao CPU para o primeiro-pacote que processa, há uns métodos de proteção limitados. O uso de “nega” entradas ACL na relação pode limitar o que é enviado ao CPU; contudo, não há nenhum taxa-limitador ou outras proteções contra estes tipos de ataques.

Detalhe Máscara-baseado do método de atribuição

a atribuição Máscara-baseada é diferentemente dependente segurado de se está configurada no ingresso ou na saída.

Com atribuição máscara-baseada ingresso, a máscara é programada no ACL TCAM antes do encaminhamento de pacote, assim que o processamento da tabela e do software do Netflow não é precisado. A entidade WCCP escolhe um número de mistura-cubetas e atribui uma máscara de endereço e o dispositivo WCCP a cada cubeta. Uma vez que as atribuições estão completas, o supervisor programa uma entrada de TCAM e uma adjacência do hardware para cada cubeta e reorienta os pacotes que combinam a máscara de endereço ao dispositivo associado WCCP por meio de uma reescrita L2.

Se o WCCP é configurado como uma característica do ingresso, pode usar uma entrada da reorientar-adjacência ACL na tabela do hardware ACL. Uma vez o WCCP combina a entrada, usa uma adjacência apropriada a fim executar um ou outro uma reescrita L2 ou um encapsulamento de GRE. Assim, quando a atribuição da máscara é usada no ingresso, a reescrita L2 (Supervisor Engine 2, Supervisor Engine 32, e Supervisor Engine 720) e encapsulamento de GRE (Supervisor Engine 32 e Supervisor Engine 720 somente) são executados no hardware.

Se o WCCP é configurado como uma característica da saída, as reorientar-adjacências ACL não estão apoiadas no hardware porque os pacotes no fluxo têm sido distribuídos já pelo sistema. O primeiro pacote de um fluxo é enviado ao software para processar. Uma vez que a reorientar-adjacência apropriada é determinada, está programada no hardware do Netflow (em vez de ACL TCAM), onde os pontos de entrada a uma adjacência que execute um ou outro uma reescrita L2 ou um encapsulamento de GRE. Os pacotes subsequente no fluxo são reorientados no hardware pelo hardware do Netflow.

Nota: Se o WCCP é configurado como uma característica da saída, a atribuição da máscara exige o software que processa, que nega todo o benefício do método de atribuição máscara-baseado.

Das duas opções máscara-baseadas, somente a atribuição máscara-baseada ingresso permite a transmissão com base em hardware completa para a inicial e os pacotes subsequente. Toda a outra opção, tal como o uso da atribuição ou da saída mistura-baseada que processam, interruptor do software das causas do pacote inicial e hardware-Netflow comutou a transmissão dos pacotes subsequente.

Método do redirecionamento de WCCP

A entidade WCCP, não o Catalyst 6500, dita a mistura - as tabelas e a máscara/conjuntos de valores ao Catalyst 6500, assim que a configuração do método da reorientação são feitas nesse dispositivo, e não no Catalyst 6500 Switch. O Catalyst 6500 determina o melhor reorienta o método disponível, com base nas comunicações WCCP com a entidade/grupo WCCP. Esta negociação determina como o tráfego redirecionado é enviado ao dispositivo. Há duas opções da reorientação: L3 (GRE) e L2 (reescritas do MAC address).

Com WCCPv1, a única opção é a reorientação L3, igualmente conhecida como o encapsulamento de GRE. Com reorientação L3, cada pacote reorientado WCCP é encapsulado em um cabeçalho de GRE identificado por meio de um tipo de protocolo 0x883E seguido por um quatro-octeto que o WCCP reorienta o encabeçamento, que é enviado subseqüentemente ao dispositivo WCCP (tal como um motor do esconderijo).

Com a introdução de WCCPv2, a reorientação L2, igualmente conhecida como o redirecionamento de WCCP acelerado, foi adicionada a fim aproveitar-se de Plataformas do switching de hardware tais como o Catalyst 6500. Quando o WCCP usa a reorientação L2, o dispositivo e o Catalyst 6500 WCCP devem ser L2 adjacente (dentro do mesmo L2 VLAN). O tráfego L2 reorientado não usa o encapsulamento de GRE; em lugar de, o endereço de destino MAC é reescrito pelo Catalyst 6500 àquele da entidade L2-connected WCCP e enviado com o switching de hardware normal.

Nota: O método da transmissão ao dispositivo WCCP não pode ser o mesmo método que o dispositivo WCCP usa a fim enviar o tráfego de volta ao Catalyst 6500. O WCCP é usado a fim negociar um método dianteiro e do retorno que ambos os dispositivos apoiem. Veja o método do retorno WCCP.

(GRE) método de encaminhamento L3

A operação WCCP L3 envolve o uso do GRE como um método de encapsulamento. Os pacotes reorientados são encapsulados em um cabeçalho de GRE com um tipo de protocolo de 0x883e, junto com um encabeçamento do redirecionamento de WCCP 4-byte que inclua um ID de serviço e uma cubeta da mistura combinados (WCCPv2 somente). O uso do GRE permite o cliente WCCP de ser separado do Catalyst 6500 pelos saltos L3 (roteados) múltiplos.

Nesta encenação, as opções disponíveis para o redirecionamento de WCCP incluem:

1. Ingresso - (GRE) reorientação L3 + atribuição da mistura; isto exige o processamento do software.
2. Ingresso - (GRE) reorientação L3 + atribuição da máscara; isto exige o hardware completo que processa e está disponível somente no Supervisor Engine 32 ou no Supervisor Engine 720.
3. Saída - (GRE) reorientação L3 + atribuição da mistura; isto exige o processamento do software.
4. Saída - (GRE) reorientação L3 + atribuição da máscara; isto exige o processamento do software.

Ingresso - (GRE) reorientação L3 + atribuição da mistura

No Supervisor Engine 2, cada pacote GRE é enviado ao Multilayer Switch Feature Card (MSFC) para processar. Desde que o encapsulamento de GRE não é apoiado no hardware, o MSFC deve aplicar encabeçamentos GRE e WCCP, que força o interruptor do software para todo o tráfego.

Com o método de atribuição mistura-baseado, o Supervisor Engine 32 e o Supervisor Engine 720 para a frente o primeiro pacote de cada fluxo no software de modo que uma entrada de tabela do Netflow seja estabelecida. O pacote então é encapsulado no GRE (o encapsulamento e a transmissão do pacote inicial é feita no software) e enviado ao dispositivo WCCP.

O estabelecimento da entrada do Netflow impacta a utilização CPU, mas a transmissão de pacote subsequente é feita no hardware para o Supervisor Engine 720 e o Supervisor Engine 32. Os testes padrão de tráfego, especialmente o número de fluxos originais, ditam quanto o CPU é utilizado. Se os recursos do Netflow do Catalyst 6500 são consumidos, a seguir todo o tráfego está enviado no software.

Os recursos do Netflow do supervisor PFC diferem através das várias Plataformas. Atualmente, os recursos os maiores do Netflow estão disponíveis no PFC-3BXL na plataforma do Supervisor Engine 720.

Ingresso - (GRE) reorientação L3 + atribuição da máscara

No Supervisor Engine 2, cada pacote GRE é enviado ao MSFC para processar. Desde que o encapsulamento de GRE não é apoiado no hardware, o MSFC deve aplicar encabeçamentos GRE e WCCP, que força o interruptor do software para todo o tráfego.

Com o método de atribuição máscara-baseado, o Supervisor Engine 32 e o Supervisor Engine 720 para a frente a inicial e os pacotes subsequente no hardware, porque o GRE é apoiado nativamente, e a atribuição da máscara usam o hardware TCAM ACL enviando.

Saída - (GRE) reorientação L3 + atribuição da mistura

No Supervisor Engine 2, cada pacote é enviado ao MSFC para processar. Desde que o encapsulamento de GRE não é apoiado no hardware, o MSFC deve aplicar encabeçamentos GRE e WCCP, que força o interruptor do software para todo o tráfego.

Com o método de atribuição mistura-baseado com o Supervisor Engine 32 e o Supervisor Engine 720, o Catalyst 6500 para a frente o pacote inicial de cada fluxo no software de modo que a entrada de tabela do Netflow seja estabelecida. O pacote então é encapsulado no GRE e enviado à entidade WCCP.

O estabelecimento da entrada do Netflow impacta a utilização CPU, mas a transmissão de pacote subsequente é feita no hardware. Os testes padrão de tráfego, especialmente o número de fluxos originais, ditam quanto o CPU é utilizado. Se os recursos do Netflow do Catalyst 6500 são consumidos, a seguir todo o tráfego está enviado no software.

Os recursos do Netflow do supervisor PFC diferem através das várias Plataformas. Atualmente, os recursos os maiores do Netflow estão disponíveis no PFC-3BXL na plataforma do Supervisor Engine 720.

Saída - (GRE) reorientação L3 + atribuição da máscara

No Supervisor Engine 2, cada pacote é enviado ao MSFC para processar. Desde que o encapsulamento de GRE não é apoiado no hardware, o MSFC deve aplicar encabeçamentos GRE e WCCP, que força o interruptor do software para todo o tráfego.

Com o método de atribuição máscara-baseado com o Supervisor Engine 32 e o Supervisor Engine 720, o primeiro pacote de cada fluxo é software comutado de modo que a entrada de tabela do Netflow seja estabelecida. Nenhuns dos supervisores apoiam a adjacência da saída ACL que programa, que força este software que processa e usa recursos do Netflow (em vez do hardware ACL TCAM) para o pacote inicial em cada fluxo. O pacote então é encapsulado no GRE e enviado ao dispositivo WCCP.

O estabelecimento da entrada do Netflow impacta a utilização CPU, mas a transmissão de pacote subsequente é feita no hardware. Os testes padrão de tráfego, especialmente o número de fluxos originais, ditam quanto o CPU é utilizado. Se os recursos do Netflow do Catalyst 6500 são consumidos, a seguir todo o tráfego está enviado no software.

Os recursos do Netflow do supervisor PFC diferem através das várias Plataformas. Atualmente, os recursos os maiores do Netflow estão disponíveis no PFC-3BXL na plataforma do Supervisor Engine 720.

Método de encaminhamento L2

Com transmissão L2, as entidades WCCP (ACNS, WAFS, WAAS, e assim por diante) dentro de um grupo de serviço são parte da mesma sub-rede e são L2 junto ao Catalyst 6500. Isto permite o throughput elevado, reorientação da latência baixa do tráfego. A interface de ingresso (onde o WCCP é configurado) e a relação onde os dispositivos WCCP são encontrados devem estar em VLAN diferentes.

Nota: Com reorientação L2, o pacote é reescrito com o grupo do MAC de origem ao roteador e ao MAC de destino ajustados ao motor do esconderijo. A única desvantagem deste método de redirecionamento é que o motor do esconderijo deve ser L2 alcançável pelo Catalyst 6500 e deve residir em uma relação L3 diferente do que a relação configurada do ingresso WCCP.

Nota: O método da transmissão ao dispositivo WCCP não pode ser o mesmo método que o dispositivo WCCP usa a fim enviar o tráfego de volta ao Catalyst 6500. O WCCP é usado a fim negociar um método dianteiro e do retorno que ambos os dispositivos apoiem. Veja o método do retorno WCCP.

As opções disponíveis para o redirecionamento de WCCP nesta encenação incluem:

• Ingresso - Reorientação L2 + atribuição da mistura; isto exige o processamento do software.
• Ingresso - A reorientação L2 + a atribuição da máscara isto exigem o hardware completo que processa e são recomendadas.
• Saída - Reorientação L2 + atribuição da mistura; isto exige o processamento do software.
• Saída - Reorientação L2 + atribuição da máscara; isto exige o processamento do software.

Ingresso - L2 + atribuição da mistura

Quando configurado no ingresso com o L2 + a atribuição da mistura, tráfego WCCP enviam o primeiro pacote em cada fluxo para ser o software comutado, que cria uma entrada do Netflow na tabela do Netflow do hardware.

Nota: A fluxo-máscara do Netflow é ajustada para conectar o modo fluxo completo, que pôde impactar outras características do Netflow configuradas no interruptor.

Desde que o WCCP é um mecanismo apátrida, a informação não é mantida no software; um pouco, mantém-se no hardware como entradas na tabela do Netflow. O tráfego subsequente no fluxo está enviado no hardware enquanto uma entrada de tabela do Netflow existe.

O estabelecimento da entrada do Netflow impacta a utilização CPU, mas a transmissão de pacote subsequente é feita no hardware. Os testes padrão de tráfego, especialmente o número de fluxos originais, ditam quanto o CPU é utilizado. Se os recursos do Netflow do Catalyst 6500 são consumidos, a seguir todo o tráfego está enviado no software.

Os recursos do Netflow do supervisor PFC diferem através das várias Plataformas. Atualmente, os recursos os maiores do Netflow estão disponíveis no PFC-3BXL na plataforma do Supervisor Engine 720.

Ingresso - L2 + atribuição da máscara

Quando configurado no ingresso, o L2 + a atribuição da máscara são o método o mais eficiente WCCP apoiado no Catalyst 6500. Todo o tráfego é hardware comutado, incluindo o pacote inicial em cada fluxo. Nenhuma reorientação do software é exigida; a inicial e a transmissão de pacote subsequente são fornecidas pelo hardware.

Os recursos TCAM do hardware ACL do Catalyst 6500 estão usados a fim preprogram as entradas de hardware antes que todos os pacotes de WCCP estejam recebidos.

A fim usar este método e utilizar o switching de hardware completo, a entidade WCCP deve igualmente apoiar o L2 reorienta e o método de atribuição máscara-baseado. A configuração deste método é terminada na entidade WCCP, e o Catalyst 6500 negocia o melhor método durante as comunicações da inicial WCCP com a entidade/grupo WCCP.

Saída - L2 + atribuição da mistura

Com saída o L2 + a atribuição da mistura, tráfego WCCP enviam o primeiro pacote em cada fluxo para ser o software comutado, que cria uma entrada do Netflow na tabela do Netflow do hardware.

Nota: A fluxo-máscara do Netflow é ajustada para conectar o modo fluxo completo, que pôde impactar outras características do Netflow configuradas no interruptor.

Adicionalmente, quando configurada na direção de saída, uma consulta adicional do banco de informação de encaminhamento (FIB) é exigida no primeiro pacote do fluxo a fim determinar a adjacência associada com o CE, que exige a recirculação do pacote dentro do Catalyst 6500. Os pacotes subsequente são Netflow comutado no hardware.

O estabelecimento da entrada do Netflow impacta a utilização CPU, mas a transmissão de pacote subsequente é feita no hardware. Os testes padrão de tráfego, especialmente o número de fluxos originais, ditam quanto o CPU é utilizado. Se os recursos do Netflow do Catalyst 6500 são consumidos, a seguir todo o tráfego está enviado no software.

Os recursos do Netflow do supervisor PFC diferem através das várias Plataformas. Atualmente, os recursos os maiores do Netflow estão disponíveis no PFC-3BXL na plataforma do Supervisor Engine 720.

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

Quando configurado na direção de saída, o L2 + a atribuição da máscara comutam o primeiro pacote em cada fluxo no software, apenas como L2 + caso da atribuição da mistura. Os pacotes subsequente são Netflow comutado no hardware.

Nota: A fluxo-máscara do Netflow é ajustada para conectar o modo fluxo completo, que pôde impactar outras características do Netflow configuradas no interruptor.

O PFC2 e o PFC3 não apoiam a adjacência da saída ACL que programa, que força o software que processa para o pacote inicial em cada fluxo; os pacotes subsequente no fluxo são enviados no hardware.

O estabelecimento da entrada do Netflow impacta a utilização CPU, mas a transmissão de pacote subsequente é feita no hardware. Os testes padrão de tráfego, especialmente o número de fluxos originais, ditam quanto o CPU é utilizado. Se os recursos do Netflow do Catalyst 6500 são consumidos, a seguir todo o tráfego está enviado no software.

Os recursos do Netflow do supervisor PFC diferem através das várias Plataformas. Atualmente, os recursos os maiores do Netflow estão disponíveis no PFC-3BXL na plataforma do Supervisor Engine 720.

Método do retorno WCCP

A entidade WCCP pode prestar serviços de manutenção ao pedido

Quando o WCCP está usado para interceptar o tráfego e a entidade WCCP executa uma operação completa naqueles pacotes, os pacotes estão então prontos para ser enviado para trás ao cliente do dispositivo WCCP. Este tráfego normalmente processado, que é destinado de volta ao cliente na rede, não exige nenhum encapsulamento especial quando enviado fora do dispositivo WCCP para trás para o cliente.

Porque a intercepção WCCP conduziu ao pedido do cliente que está sendo prestado serviços de manutenção com sucesso (arquivo do esconderijo, córrego rachado do esconderijo, arquivo de WAAS), pode ser enviada para trás à rede como o tráfego normal com o endereço de destino nos pacotes que são o utilizador original. Este tráfego pode ser normalmente L3/switched pelo Catalyst 6500 se está no caminho de rede do dispositivo WCCP ao cliente; com um dispositivo anexado L2 WCCP, o tráfego está no caminho de rede. Nenhum encapsulamento é precisado a fim enviá-lo para trás do dispositivo WCCP ao Catalyst 6500 porque o destino é agora o cliente original em vez de um server no Internet ou no intranet. A rede então segura esta como todo o outro fluxo de tráfego IP e usa o encaminhamento de hardware no Catalyst 6500 a fim retornar o tráfego pedido ao cliente.

A entidade WCCP não pode prestar serviços de manutenção ao pedido

Em alguns casos onde a entidade WCCP não pode executar a operação requisitada, o dispositivo WCCP pode precisar de enviar o tráfego de volta ao Catalyst 6500 e de preservar o destino original dos pacotes. Enviar este tráfego da entidade WCCP sem encapsulamento pode conduzir aos laços do tráfego. A fim esconder um serviço mal sucedido tente do cliente e envie os pacotes ao destino original a ser prestados serviços de manutenção, os pacotes deve permanecer inalterado, seja colocado de novo em seu trajeto de encaminhamento original, e enviado sem intercepção WCCP ao destino original.

No método do retorno WCCP, o WCCP pode ser usado para encapsular estes pacotes, envia-os de volta ao dispositivo que os interceptou no primeiro lugar, descasca todo o encapsulamento, e os coloca de novo no trajeto de encaminhamento de que foram interceptados. Estes pacotes precisam de ser enviados normalmente como se foram interceptados nunca pelo WCCP.

Os exemplos destes casos incluem:

• Põe em esconderijo o tráfego sobrecarregado, onde o tráfego está sendo contorneado
• Regras nos dispositivos do esconderijo que negam a entidade WCCP de prestar serviços de manutenção o tráfego
• Tráfego contorneado que está procurando um serviço não disponível no dispositivo

Neste tempo, este método do retorno pode ser feito somente com encapsulamento de GRE e não é apoiado ainda em nenhum hardware do Catalyst 6500. Se as grandes quantidades de tráfego são enviadas para trás ao Catalyst 6500 com este método, a utilização elevada da CPU pôde ocorrer porque este tráfego é processado no software. No Cisco IOS Software Release 12.1(18)SXH, há um método do retorno L2 apoiado pelo hardware do Catalyst 6500.

O GRE retorna

Nos Cisco IOS Software Release mais cedo do que 12.2(18)SXH, o único método do retorno apoiado para o Catalyst 6500 é encapsulamento de GRE. Além do que o cabeçalho de GRE adicionado ao tráfego de retorno, um encabeçamento WCCP é adicionado igualmente. Embora o GRE seja apoiado nativamente no hardware do Supervisor Engine 32 e do Supervisor Engine 720, este encabeçamento adicional conduz ao GRE não que é hardware ajudado. Note que o Catalyst 6500 e o dispositivo WCCP devem apoiar e negociar o método do retorno L2.

Nenhum suporte a hardware GRE existe no Supervisor Engine 2 para todo o GRE, ingresso, saída, ou retorno WCCP. A fim processar este tipo de-encapsulamento GRE, os programas de Cisco IOS Software a receber-adjacência do túnel GRE WCCP na interface ativada WCCP para apontar ao route processor (RP), que conduz ao processamento do software do tráfego de retorno.

O uso do reorienta lista no Catalyst 6500 a fim evitar o tráfego que pode precisar de ser retornado com o GRE é um método efetivo para reduzir os requisitos de processamento do software do tráfego que seriam enviados para trás da entidade WCCP. Isto é muito mais eficaz do que tendo o tráfego negado na entidade WCCP e forçando o para ser GRE encapsulado e enviado para trás ao Catalyst 6500.

Recorde que o grupo de serviço WCCP é escalável. Se o tráfego excedente é devido contorneado carregar, a seguir este tráfego está enviado para trás, que cria a carga de CPU no Catalyst 6500. A escamação ou mesmo overbuilding apropriado do grupo de serviço WCCP são o único método para evitar esta situação.

Realce do retorno L2

Em 12.2(18)SXH, uma opção permite que a entidade WCCP reescreva o MAC address L2 um pouco do que encapsula o tráfego de retorno. Este realce do retorno L2 (identificação de bug Cisco CSCuk59825) permite o processamento do hardware do tráfego retornado quando o WCCP é configurado para usar a reorientação do ingresso com atribuição da máscara.

Sumário de opções WCCP

Quando executado no Catalyst 6500, o WCCP oferece muitas opções de configuração, segundo as indicações desta tabela. Note que o dispositivo WCCP negocia estes opções e controles que as opções são usadas pelo Catalyst 6500. A configuração é feita no lado do dispositivo WCCP da conexão WCCP.

De uma perspectiva do hardware, todas as configurações de WCCP da saída exigem a utilização CPU do processamento e do impacto do software. O processamento do software está exigido igualmente no ingresso quando o método de atribuição mistura-baseado é usado e conduz ao mesmo impacto potencial na utilização CPU.

O método recomendada do desenvolvimento WCCP no Catalyst 6500 é a reorientação L2 com atribuição da máscara e, quando disponível, retorno L2.

Dica: Somente uma opção assegura o alto desempenho, transmissão com base em hardware completa: a reorientação L2 ingresso-baseada com atribuição da máscara no Supervisor Engine 2, no Supervisor Engine 32, e no Supervisor Engine 720.

Recomendações de design WCCP

Use estas recomendações de configuração assim que você pode determinar o melhor método do desenvolvimento WCCP para sua situação.

Resumo

Projete a rede tais que o ingresso WCCP pode ser usado como um método de redirecionamento. Um bom método de projeto é ter um switchblock pondo em esconderijo como parte de um hierárquico, a rede de distribuição L3; isto assegura-se de que o tráfego prestado serviços de manutenção WCCP possa ser identificado em algumas portas de ingresso principais.

• Use 12.2(18)SXF7 ou um Cisco IOS Software mais novo.
• Identifique e reoriente o tráfego em interfaces de ingresso.
• Use os dispositivos WCCP que apoiam o L2 reorientam o método.
• Use os dispositivos WCCP que apoiam o método de atribuição máscara-baseado.
• Se possível, use uma lista da reorientação no Catalyst 6500 para o tráfego que não pode ser prestado serviços de manutenção pelo dispositivo WCCP.
• Temporizadores do Netflow da emenda com saída ou algumas configurações mistura-baseadas da atribuição com Supervisor Engine 720.
• Os dispositivos WCCP devem ter um ambiente L3 dedicado e a relação SVI/VLAN.

Além, o serviço avançado de Cisco recomenda estas considerações de projeto:

• Em um ambiente que não seja inteiramente L2 reoriente com atribuição da máscara, o Supervisor Engine 720 não execute melhor do que a plataforma do Supervisor Engine 2. Não promova o hardware e espere o melhor desempenho nesta situação.
• Para grande, as disposições da instalação central com requisitos de tráfego do volume alto, consideram um projeto com Policy-Based Routing (PBR) e o motor satisfeito do controle do modelo do interruptor de Cisco (CS) /Application (ACE) para a intercepção e a transmissão do tráfego.
• O WCCPv2 funciona como esperado sob circunstâncias perfeitas. Contudo, sob algumas circunstâncias, a utilização CPU no roteador pode alcançar os níveis altos que tornam o dispositivo inusável e que exigem o reload:
  
  
  • O WCCPv2 recua do modo de designação máscara-baseado L2 hardware-acelerado ingresso em todo o outro modo que exigir o CPU no MSFC.
  • O WCCP é configurado incorretamente (por exemplo, saída em vez do ingresso ou da mistura L2 em vez da atribuição da máscara).
• Todo o desenvolvimento do volume alto WCCP com Catalyst 6500 (pôr em esconderijo, fluir, WAAS, ou outras do “encenações da taxa tráfego elevado”) deve ser desempenho testado com tráfego ao vivo antes da distribuição do produto completa.

Recomendações adicionais

Use uma lista da reorientação no interruptor a fim evitar os pacotes que são enviados para trás ao Catalyst 6500. Se alguma regra dos dispositivos do esconderijo pode ser movida para o Catalyst 6500 enquanto uma lista da reorientação, isto pode fornecer o melhor desempenho de hardware.

Os recursos do Netflow na plataforma do Supervisor Engine 720 podem ser esgotados rapidamente se você usa qualquer método a não ser a atribuição da máscara ingress-L2. O Supervisor Engine 720 não fornece o melhor desempenho do que o Supervisor Engine 2 nenhum outro método.

Nos casos onde o Supervisor Engine 720 ou o Supervisor Engine 32 devem ser usados em um projeto não-otimizados, considere o uso do comando rápido da criação software-MODE do Netflow dos mls IP de modo que o processamento do Netflow do pacote da inicial WCCP possa ser acelerado. Isto remove os realces adicionados ao Netflow do Supervisor Engine 32 e do Supervisor Engine 720 e fornece o desempenho igual àquele do hardware do Netflow do Supervisor Engine 2.

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

• versão 2 do wccp
• IP address do número de listas do roteador do wccp
• o serviço roteador-lista-NUM do wccp numérico máscara-atribui

Use estes comandos a fim rever a utilização do Netflow e determinar se o WCCP se está usando acima das entradas do Netflow e se está usando o processamento do software:

• mostre a tabela-disputa do Netflow dos mls detalhada
• mostre o Netflow IP dos mls SW-instalado
• mostre o envelhecimento do Netflow dos mls
• mostre ao Netflow IP dos mls a contagem dinâmica
• mostre a contagem do Netflow IP dos mls
• mostre os mls IP
• mostre contadores do Netflow do fm

Se você experimenta questões de software WCCP porque os recursos do Netflow estão sendo consumidos, estes comandos puderam agressivelmente cancelar para fora entradas existentes e criar a sala para entradas novas. (Isto não ajuda se há simplesmente mais entradas do que há um espaço do Netflow.)

• mls que envelhecem o ponto inicial rápido 1 do tempo 3
• mls que envelhecem por muito tempo 64
• mls que envelhecem o normal 32
• criação software-MODE do Netflow dos mls IP rápida (este desabilita algumas mudanças do Netflow do Supervisor Engine 720 que não estavam no Supervisor Engine 2.)

Para evitar quedas de pacote de informação, as entidades WCCP devem reorientar o tráfego fora de uma relação que não seja a relação que o WCCP está configurado sobre. O Catalyst 6500 WCCP deixa cair pacotes nesta situação quando todas as circunstâncias são estadas conformes:

• Os clientes e a entidade WCCP estão na mesma relação L3.
• A política do redirecionamento de WCCP é aplicada nesta relação.
• O método do redirecionamento de GRE é usado.
• Reorientar a fragmentação de pacote de informação é exigida.
• O Supervisor Engine 720 é usado.

Esta situação é causada pelos mecanismos de proteção construídos dentro ao Catalyst 6500; o Cisco IOS Software tem as verificações que impedem que o pacote incorpore e deixe a mesma interface virtual do Cisco IOS Software onde poderia potencialmente dar laços e causar no comportamento indesejado. Mova dispositivos WCCP para seu próprio ambiente L3 dedicado a fim impedir isto.

a limitação USER-baseada da taxa (UBRL) e o WCCP não trabalham simultaneamente em uma relação devido às máscaras de fluxo. Há uma máscara de fluxo para cada relação para cada recursos de unicast. O WCCP exige o FULL-fluxo, e UBRL usa o SRC-somente ou o DST-somente.

O apoio WCCP foi adicionado para o Supervisor Engine 2 e o retorno L2 em 12.2(18)SXF5. Isto não estava no Supervisor Engine 720 até 12.2(18)SXH em abril /May 2007.

Somente a reorientação WCCP L2 PFC é apoiada com Server Load Balancing (SLB) do Cisco IOS Software; outras configurações de WCCP não são compatíveis, e o GRE não trabalha. O comando acelerado WCCP aplica-se somente ao Supervisor Engine 2/MSFC2. Sua finalidade é forçar o roteador a negociar a atribuição da máscara e o L2 reorienta, assim que significa que todo o redirecionamento de WCCP está feito no hardware. O Supervisor Engine 32 e o Supervisor Engine 720 negociam este sem a necessidade para este comando.

Soluções

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

ACNS

Para a reorientação padrão do cache transparente, recorde que a entidade WCCP fornece o roteador WCCP os métodos suportados e pode precisar de ser configurado para fazer assim. Para Cisco ACNS, este exemplo de configuração pede o L2-redirect aperfeiçoado e máscara-baseou métodos de atribuição:

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

   ContentEngine(config)# wccp version 2

2. Configurar uma lista do roteador que defina o Catalyst 6500s para se usar:
   
   

   ContentEngine(config)# wccp router-list 1 172.16.16.1

3. Configurar o serviço para usar os métodos da otimização:
   
   

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

Do lado do roteador, o projeto do Catalyst 6500 deve assegurar-se de que os dispositivos WCCP estejam em uma relação L3 dedicada que não esteja no caminho de tráfego atual (ingresso ou saída). Para o desempenho de hardware, os fluxos de tráfego devem ser de entrada capturado ao Catalyst 6500, mesmo se este exige a configuração de mais relações do que se uma única interface de saída foi escolhida. Um projeto ideal agregaria todo o tráfego antes de alcançar este dispositivo, e somente algumas relações exigiriam a configuração do ingresso WCCP.

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

1. Configurar o WCCPv2:
   
   

   6500Switch# ip wccp version {1 | 2}

2. Configurar um grupo de serviço WCCP.
   
   

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

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

A lista da reorientação é usada a fim identificar o tráfego que deve ser selecionado ou não selecionado para a reorientação. Recorde que este ACL pode ser executado no hardware, que é muita maneira de mais eficiente de impedir a reorientação para o tráfego que não pode ser prestado serviços de manutenção pelo dispositivo WCCP. Trafique que é enviado ao dispositivo e não pode ser prestado serviços de manutenção lá deve ser retornado a este Catalyst 6500 a fim ser posto de novo no caminho de tráfego original, que exige o processamento adicional. As Listas de acesso WCCP são padrão ou listas de acesso extendida.

Este exemplo mostra que todos os pedidos de 10.1.1.1 a 12.1.1.1 contorneiam o esconderijo e que todos pedidos restantes estão reorientados.

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

Configurar o método do ingresso WCCP em cada interface de ingresso que recebe o tráfego a ser reorientado:

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

Isto termina a configuração no dispositivo WCCP e no interruptor, assim que a reorientação do tráfego deve ocorrer neste momento.

As configurações de WCCP finais dos dispositivos olham como esta.

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 esta configuração, incorpore este comando:

Show ip wccp service detail

Para opções de configuração de WCCP adicionais, tais como o endereçamento do grupo usando o Multicast ou a Segurança adicional WCCP, refira configurar serviços do cache de web usando o WCCP.

Comandos show and debug WCCP IO

• mostre o número do serviço do wccp IP - fornece a contagem reorientada “pacotes total”. Esta contagem é o número de fluxos, ou as sessões, que são reorientadas.
• mostre o detalhe do número do serviço do wccp IP - fornece a contagem reorientada “pacotes”. A contagem é o número de fluxos, ou as sessões, que são reorientadas.
• mostre o detalhe do cache de web do wccp IP - fornece uma indicação de quantos fluxos, um pouco do que pacotes, estão usando a reorientação L2.
• clear ip wccp - restaura o contador para a informação reorientada “pacotes”.
• mostre a opinião do número do serviço do wccp IP - indica os dispositivos WCCP que são parte do grupo de serviço.
• mostre o serviço do número do serviço do wccp IP - indica a mistura, as portas, e a prioridade WCCP do serviço. Uns serviços mais prioritários estão batidos primeiramente quando os serviços múltiplos são configurados na relação.
• debugar eventos WCCP IP - pesquisa defeitos o estado do protocolo WCCP.
• debugar pacotes do wccp IP - revê as comunicações entre o pacote de WCCP que processa entidades.

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

• Se o WCCP ACL é processado completamente no hardware, os contadores WCCP não podem indicar contagens de pacote de informação exatos.
• Se o WCCP está usando a atribuição e recursos do hardware mistura-baseados do Netflow, os contadores WCCP podem refletir o número de fluxos em vez do número de pacotes.

Comandos do Netflow

Quando você tem as configurações de WCCP que exigem o uso de recursos do hardware do Netflow, use este o switching multicamada (MLS) e os comandos do Fabric Manager (FM) assim que você pode rever o estado dos recursos do Netflow:

• mostre a tabela-disputa do Netflow dos mls detalhada
• mostre o Netflow IP dos mls SW-instalado
• mostre o envelhecimento do Netflow dos mls
• mostre ao Netflow IP dos mls a contagem dinâmica
• mostre a contagem do Netflow IP dos mls
• mostre os mls IP
• mostre contadores do Netflow do fm

Defeitos WCCP

Esta tabela do Bug da Cisco ID e das definições apoia a recomendação geral para usar o Cisco IOS Software Release 12.2(18)SXF7 ou Mais Recente para o melhor apoio do WCCP.