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.
A Cisco recomenda que você tenha conhecimento destes tópicos:
As informações neste documento são baseadas nestas versões de software e hardware:
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.
A funcionalidade que está referido genericamente enquanto o WCCP envolve realmente três componentes:
Este documento examina estas três características operacionais WCCP:
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:
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.
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:
Serviço WCCP | Protocolo |
cache de web | HTTP |
53 | Esconderijo DNS |
60 | FTP |
61 | WAAS - envie |
62 | WAAS - inverta |
70 | HTTPS |
80 | Real-Time Streaming Protocol (RTSP) |
81 | Servidor de mídia de Microsoft (MM) sobre UDP (MMSU) |
82 | MM sobre TCP (MMST) |
83 | RTSP usando UDP (RTSPU) |
89 | CIFS-esconderijo WAAS |
98 | Cache de web feito sob encomenda |
99 | Proxy reverso |
90-97 | Configuráveis pelo usuário * |
* 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:
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.
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:
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.
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.
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.
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.
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:
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.
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.
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.
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.
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.
As opções disponíveis para o redirecionamento de WCCP nesta encenação incluem:
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.
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.
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.
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.
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.
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.
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.
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.
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:
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.
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.
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.
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.
Reoriente o método | Atribuição Método |
Ingresso Saída |
Resultado de comutação |
L2 | Mistura | Ingresso | Processamento do software |
L2 (recomendado) | Máscara | Ingresso | Hardware completo que processa com ACL TCAM |
L2 | Mistura | Saída | Processamento do software |
L2 | Máscara | Saída | Processamento do software |
GRE | Mistura | Ingresso | Processamento do software |
GRE (PFC3 ou mais novo) | Máscara | Ingresso | Hardware completo que processa com FULL-fluxo do Netflow |
GRE | Mistura | Saída | Processamento do software |
GRE | Máscara | Saída | Processamento do software |
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.
Use estas recomendações de configuração assim que você pode determinar o melhor método do desenvolvimento WCCP para sua situação.
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.
Além, o serviço avançado de Cisco recomenda estas considerações de projeto:
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 é:
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:
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.)
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:
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.
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:
ContentEngine(config)# wccp version 2
ContentEngine(config)# wccp router-list 1 172.16.16.1
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:
6500Switch# ip wccp version {1 | 2}
6500Switch (config)# ip wccp service [accelerated] redirect-list access-listUse 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.
Dispositivo | Configuração |
Dispositivo WCCP | wccp version 2 |
Roteador WCCP: global |
ip wccp version 2 |
Roteador WCCP: cada interface de ingresso |
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.
Quando você usa o WCCP e o encaminhamento de hardware, alguns contadores não podem indicar como esperado:
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:
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.
ID de bug da Cisco | Resolvido no Cisco IOS Software Release | Detalhes |
CSCsd20327 | 12.2(18)SXF7 | O WCCP para o serviço 90 vai para cima e para baixo, e causa uma perda de serviço WCCP. Este problema ocorre quando os serviços 81, 82, e 90 são configurados. Os rastreamentos de pacotes indicam que o roteador pôde responder às mensagens de “Here_I_Am” do esconderijo com mensagens do “i_see_you” que contêm um endereço IP de destino incorreto. |
CSCsa77785 | 12.2(18)SXF6 | Um reload pôde ocorrer quando você usa a reorientação WCCP L2 e o modo de designação da máscara com um padrão host-baseado ACL enquanto um WCCP reorienta o ACL. |
CSCse69713 | 12.2(18)SXF6 | Quando todos os motores do esconderijo em um grupo de serviço WCCP são perdidos, o tráfego está processado no software em vez do comutado no hardware. |
CSCsd28870 | 12.2(18)SXF5 | Em um WCCP reoriente a lista ACL, os ACE que são configurados com a palavra-chave do log não são programados na tabela TCAM. |
CSCsb61021 | 12.2(18)SXF5 | A utilização elevada da CPU pôde ocorrer em um Supervisor Engine 720 ou em um Supervisor Engine 32 quando a característica da falsificação de IP está configurada em um motor do esconderijo e quando o redirecionamento de WCCP está configurado na direção de saída. os pacotes IP-falsificado do motor do esconderijo, com um destino do cliente ou do server, são comutados no software em vez do hardware. Como uma ação alternativa, use o serviço do wccp IP reorientam no comando para o de entrada e as interfaces externas. |
CSCsb21972 | 12.2(18)SXF2 | Com o WCCP e o NDE configurados, você pôde ver os retornos de monitoramento numerosos causados por erros de alinhamento, e a utilização CPU pôde ser inaceitavelmente alta. |
CSCeh85087 | 12.2(18)SXF | Quando há um configurado pelo usuário “deny ip any any” no WCCP reoriente o ACL e quando muitos grupos de serviço WCCP estão sendo prestados serviços de manutenção, o tráfego associado com alguns grupos de serviço não é reorientado aos CE Router. |
CSCeh56916 | 12.2(18)SXF | Quando um serviço WCCP está permitido, quando a atribuição da máscara é configurada como o método de atribuição, e quando cinco ou mais esconderijos estão no grupo de serviço, os mensagens de protocolo enviados ao esconderijo podem transbordar e causar a corrupção de memória e o reload. |
CSCsb18740 | 12.2(18)SXF e SXE6 | No modo de encaminhamento GRE-baseado, o WCCP usa desnecessariamente um esconderijo do software que aumente a utilização CPU MSFC. |
CSCsb26773 | 12.2(18)SXF | Um ACL de entrada pôde fazer com que o redirecionamento de WCCP falhe com a perda de todo o tráfego redirecionado. |
CSCsa90830 | 12.2(18)SXE2 | O tráfego ingresso-reorientado WCCP usa a tabela do Netflow para o switching de hardware quando o motor do esconderijo é configurado para a transmissão GRE com o modo de designação da máscara. Quando a tabela do Netflow está completa, a reorientação do ingresso WCCP falha. |
CSCec55429 | 12.2(18)SXE | A lista do grupo de serviço WCCP é feita a varredura na ordem em que os grupos de serviço são criados, um pouco do que pela prioridade. Se os serviços dinâmicos múltiplos WCCP são definidos, trafique que combina os critérios de seleção para mais de um grupo de serviço não está reorientado ao grupo de serviço com a prioridade mais alta. |
CSCuk50878 | 12.2(18)SXE | Em uma liberação onde a identificação de bug Cisco CSCec55429 fosse resolved, após um número de WCC “esconderijo perdeu” e os eventos encontrados “esconderijo” ocorreram para todos os esconderijos em um grupo de serviço, estes eventos podem ocorrer:
|
CSCsa67611 | 12.2(18)SXE | Os pacotes entrantes do Multiprotocol Label Switching (MPLS) que retiram em uma relação NON-MPLS (etiqueta ao caminho IP) em que uns recursos de emissor são configurados (por exemplo, saída ACL ou saída WCCP) não puderam ter os recursos de emissor aplicados. Este problema ocorre porque a consulta do emissor ACL é contorneada. |
CSCeh13292 | 12.2(18)SXD4 | A configuração do WCCPv2 em um Supervisor Engine 720 causa a utilização elevada da CPU. |
CSCeb28941 | 12.2(18)SXD1 | O Network Address Translation (NAT) não trabalha com o WCCP configurado. |
CSCed92290 | 12.2(17d)SXB2 | os pacotes WCCP-reorientados que não têm nenhuma entrada de cache do Address Resolution Protocol (ARP) do salto seguinte são processo comutado para gerar uma requisição ARP. Devido ao redirecionamento de WCCP, contudo, nenhuma requisição ARP é enviada, o cache ARP é povoado nunca para o salto seguinte, e os pacotes WCCP-reorientados subsequentes continuam a ser processo comutado. |
CSCuk59825 | 12.2(17d)SXF5 -Sup2 Whitney1.0 para Sup720 | Este suporte a hardware adicionado Cisco IOS Software Release para o tráfego de retorno L2. O request for comment (RFC) WCCP especifica o retorno L2 como uma capacidade opcional para a negociação entre o roteador e o esconderijo. Até aqui, o WCCP no Cisco IOS Software não permitiu a negociação desta capacidade porque o apoio do hardware requerido é ausente. Que o apoio é agora disponível, assim que a negociação do retorno L2 no intercâmbio de protocolo WCCP entre o roteador e esconderijo pode ser permitido. |