Guia de Troubleshooting de Cisco WAAS para a liberação 4.1.3 e mais atrasado
Capítulo: Pesquisando defeitos o WCCP
Este artigo descreve como pesquisar defeitos edições WCCP.
Artigo principal
Compreendendo a arquitetura e o fluxo de tráfego WAAS
Troubleshooting preliminar WAAS
Pesquisando defeitos a otimização
Pesquisando defeitos a aceleração do aplicativo
Pesquisando defeitos o CIFS AO
Pesquisando defeitos o HTTP AO
Pesquisando defeitos o EPM AO
Pesquisando defeitos o MAPI AO
Pesquisando defeitos o NFS AO
Pesquisando defeitos o SSL AO
Pesquisando defeitos o vídeo AO
Pesquisando defeitos o AO genérico
Pesquisando defeitos condições de sobrecarga
Pesquisando defeitos o WCCP
Pesquisando defeitos AppNav
Pesquisando defeitos o disco e os problemas de hardware
Pesquisando defeitos conjuntos Inline de série
Pesquisando defeitos o vWAAS
Pesquisando defeitos WAAS expresso
Pesquisando defeitos a integração NAM
Índice
- 1 Troubleshooting WCCP no roteador
- 2 pesquisando defeitos WCCP no WAE
- 3 pesquisando defeitos IDs configuráveis do serviço e intervalos variáveis na versão 4.4.1
Os seguintes sintomas indicam edições possíveis WCCP:
- O WAE não está recebendo o tráfego (poderia ser devido ao misconfiguration WCCP)
- Os utilizadores finais não podem alcançar seus aplicativos de servidor (poderia ser devido a blackholing do tráfego)
- A lentidão da rede quando o WCCP é permitido (poderia ser devido aos pacotes deixando cair do roteador ou ao uso alto do CPU de roteador)
- Uso excedentemente alto do CPU de roteador (poderia ser devido à reorientação no software em vez do hardware)
As edições WCCP podem resultar dos problemas com o roteador (ou a reorientação do dispositivo) ou do dispositivo WAE. É necessário olhar a configuração de WCCP no roteador e no dispositivo WAE. Primeiramente nós olharemos a configuração de WCCP no roteador, a seguir nós verificaremos a configuração de WCCP no WAE.
Pesquisando defeitos o WCCP no roteador
Esta seção cobre o Troubleshooting nos seguintes dispositivos:
Pesquisando defeitos o WCCP nos Catalyst 6500 Series Switch e o ISR e os 3700 Series Router
Comece a pesquisar defeitos verificando a intercepção WCCPv2 no interruptor ou no roteador usando o comando ios do wccp IP da mostra como segue:
Router# show ip wccp
Global WCCP information:
Router information:
Router Identifier: 10.88.81.242
Protocol Version: 2.0
Service Identifier: 61
Number of Service Group Clients: 1 <-----Client = WAE
Number of Service Group Routers: 1
Total Packets s/w Redirected: 68755 <-----Increments for software-based redirection
Process: 2 <-----
Fast: 0 <-----
CEF: 68753 <-----
Service mode: Open
Service access-list: -none-
Total Packets Dropped Closed: 0
Redirect access-list: -none-
Total Packets Denied Redirect: 0 <-----Match service group but not redirect list
Total Packets Unassigned: 0
Group access-list: -none-
Total Messages Denied to Group: 0
Total Authentication failures: 0 <-----Packets have incorrect service group password
Total Bypassed Packets Received: 0
--More--
Nas Plataformas que usam a reorientação software-baseada, verifique que os pacotes total s/w contadores reorientados estão incrementando na saída acima do comando. Nas Plataformas que usam a reorientação com base em hardware, estes contadores não devem incrementar muito. Se você está vendo que estes contadores incrementam significativamente em Plataformas com base em hardware, o WCCP poderia ser misconfigured no roteador (o WCCP GRE é no software à revelia), ou o roteador podido cair de volta à reorientação do software devido às edições dos recursos do hardware tais como ser executado fora dos recursos TCAM. Mais investigação é exigida se você vê estes contadores incrementar em uma plataforma com base em hardware, que poderia conduzir à alta utilização da CPU o uso.
Os pacotes total negados reorientam incrementos contrários para os pacotes que combinam o grupo de serviço mas não combinam a lista da reorientação.
As falhas de autenticação do total opõem incrementos para os pacotes que são recebidos com a senha incorreta do grupo de serviço.
No Roteadores onde o redirecionamento de WCCP é executado no software, continue verificando a intercepção WCCPv2 no roteador usando o comando ios do detalhe do wccp 61 IP da mostra como segue:
Router# show ip wccp 61 detail
WCCP Client information:
WCCP Client ID: 10.88.81.4
Protocol Version: 2.0
State: Usable <-----Should be Usable
Initial Hash Info: 00000000000000000000000000000000
00000000000000000000000000000000
Assigned Hash Info: FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Hash Allotment: 256 (100.00%) <-----Buckets handled by this WAE
Packets s/w Redirected: 2452
Connect Time: 01:19:46 <-----Time WAE has been in service group
Bypassed Packets
Process: 0
Fast: 0
CEF: 0
Verifique que o estado WAE no grupo de serviço 61 é útil. Verifique que as cubetas da mistura estão atribuídas ao WAE no campo da atribuição da mistura. A porcentagem diz lhe quanto das cubetas totais da mistura são seguradas por este WAE. A quantidade de tempo que o WAE esteve no grupo de serviço é relatada no campo do tempo de conexão. O método da atribuição da mistura deve ser usado com reorientação software-baseada.
Você pode determinar que WAE na exploração agrícola segurará um pedido particular usando o comando ios da SRC-porta da DST-porta SRC-IP DST-IP da mistura do serviço do wccp IP da mostra hidden no roteador como segue:
Router# show ip wccp 61 hash 0.0.0.0 10.88.81.10 0 0 WCCP hash information for: Primary Hash: Src IP: 10.88.81.10 Bucket: 9 WCCP Client: 10.88.81.12 <-----Target WAE
No Roteadores onde o redirecionamento de WCCP é executado no hardware, continue verificando a intercepção WCCPv2 no roteador usando o comando ios do detalhe do wccp 61 IP da mostra como segue:
Cat6k# sh ip wccp 61 detail WCCP Client information: WCCP Client ID: 10.88.80.135 Protocol Version: 2.0 State: Usable Redirection: L2 Packet Return: GRE <-----Use generic GRE for hardware-based platforms Packets Redirected: 0 Connect Time: 1d18h Assignment: MASK <-----Use Mask for hardware-based redirection Mask SrcAddr DstAddr SrcPort DstPort ---- ------- ------- ------- ------- 0000: 0x00001741 0x00000000 0x0000 0x0000 <-----Default mask Value SrcAddr DstAddr SrcPort DstPort CE-IP ----- ------- ------- ------- ------- ----- 0000: 0x00000000 0x00000000 0x0000 0x0000 0x0A585087 (10.88.80.135) 0001: 0x00000001 0x00000000 0x0000 0x0000 0x0A585087 (10.88.80.135) 0002: 0x00000040 0x00000000 0x0000 0x0000 0x0A585087 (10.88.80.135) 0003: 0x00000041 0x00000000 0x0000 0x0000 0x0A585087 (10.88.80.135)
Você quer ver o método da atribuição da máscara para o Roteadores que é capaz da reorientação do hardware.
A fim salvar recursos TCAM no roteador, considere alterar a máscara do padrão WCCP para serir seu ambiente de rede. Considere estas recomendações:
- Use o número o menor de bit de máscara possíveis ao usar o WCCP reorientam o ACL. Um número menor de bit de máscara quando usado conjuntamente com reorienta resultados ACL em uma mais baixa utilização de TCAM. Se há 1-2 clientes WCCP em um conjunto, use um bit. Se há 3-4 clientes WCCP, use 2 bit. Se há 5-8 clientes WCCP, a seguir use 3 bit e assim por diante.
- Nós não recomendamos usar a máscara padrão WAAS (0x1741). Para disposições do centro de dados, o objetivo é carregar o equilíbrio as instalações de filial no centro de dados um pouco do que clientes ou anfitriões. A máscara direita minimiza o centro de dados WAE que espreita e daqui escala o armazenamento. Por exemplo, use 0x100 a 0x7F00 para os centros de dados varejos que têm redes de filial de /24. Para grandes empresas com /16 pelo negócio, use 0x10000 a 0x7F0000 para carregar o equilíbrio os negócios no centro de dados empresarial. No escritório filial, o objetivo é equilibrar os clientes que obtêm seus IP address através do DHCP. O DHCP emite geralmente os endereços IP cliente que incrementam do mais baixo IP address na sub-rede. Aos melhores endereços IP atribuídos do equilíbrio DHCP com máscara, use 0x1 a 0x7F para considerar somente os mais baixos bit da ordem do endereço IP cliente para conseguir a melhor distribuição.
Os recursos TCAM consumidos por um WCCP reorientam a lista de acesso são um produto do índice desse ACL multiplicado contra a máscara de bit configurada WCCP. Consequentemente, há uma disputa entre o número de cubetas WCCP (que são criadas com base na máscara) e o número de entradas na reorientação ACL. Por exemplo, uma máscara de 0xF (4 bit) e de uns 200 que a linha reorienta a licença ACL pode conduzir a 3200 (2^4 x 200) entradas de TCAM. Reduzir a máscara a 0x7 (3 bit) reduz o uso TCAM por 50% (2^3 x 200 = 1600).
As Plataformas do Catalyst 6500 Series e do Cisco 7600 Series são capazes de segurar o redirecionamento de WCCP no software e no hardware. Se os pacotes estão sendo reorientados inadvertidamente no software, quando você espera a reorientação do hardware, poderia conduzir ao uso excedentemente alto do CPU de roteador.
Você pode inspecionar a informação de TCAM para determinar se a reorientação está sendo segurada no software ou no hardware. Use o comando ios do tcam da mostra como segue:
Cat6k# show tcam interface vlan 900 acl in ip
* Global Defaults not shared
Entries from Bank 0
Entries from Bank 1
permit tcp host 10.88.80.135 any
punt ip any any (8 matches) <-----Packets handled in software
Os fósforos do “pontapé” representam os pedidos não segurados no hardware. Esta situação podia ser causada pelos seguintes erros:
- Atribuição da mistura em vez da máscara
- Reorientação de partida em vez de entrada
- Redirect exclui dentro
- MAC address desconhecido WAE
- Usando um endereço de loopback para o destino genérico do túnel GRE
No exemplo seguinte, as entradas da política-rota mostram que o roteador está fazendo a reorientação completa do hardware:
Cat6k# show tcam interface vlan 900 acl in ip * Global Defaults not shared Entries from Bank 0 Entries from Bank 1 permit tcp host 10.88.80.135 any policy-route tcp any 0.0.0.0 255.255.232.190 (60 matches) <-----These entries show hardware redirection policy-route tcp any 0.0.0.1 255.255.232.190 (8 matches) policy-route tcp any 0.0.0.64 255.255.232.190 (16 matches) policy-route tcp any 0.0.0.65 255.255.232.190 (19 matches) policy-route tcp any 0.0.1.0 255.255.232.190 policy-route tcp any 0.0.1.1 255.255.232.190 policy-route tcp any 0.0.1.64 255.255.232.190 policy-route tcp any 0.0.1.65 255.255.232.190 policy-route tcp any 0.0.2.0 255.255.232.190 policy-route tcp any 0.0.2.1 255.255.232.190 policy-route tcp any 0.0.2.64 255.255.232.190 policy-route tcp any 0.0.2.65 255.255.232.190 (75 matches) policy-route tcp any 0.0.3.0 255.255.232.190 (222195 matches)
Aqui eu sou (HIA) do WAE devo incorporar a mesma relação que o WAE MAC está sabido completamente. Nós recomendamos que você usa uma interface de loopback e não diretamente uma interface conectada na lista do roteador WAE.
Pesquisando defeitos o WCCP nos 1000 Series Router ASR
Os comandos para pesquisar defeitos o WCCP nos 1000 Series Router de Cisco ASR são diferentes do outro Roteadores. Esta seção mostra a comandos que você pode se usar para obter a informação WCCP no ASR 1000.
Para indicar a informação do processador de rotas WCCP, use os comandos ative rp do wccp do software de plataforma da mostra como segue:
ASR1000# sh platform software wccp rp active Dynamic service 61 Priority: 34, Number of clients: 1 <-----Number of WAE clients Assign Method: Mask, Fwd Method: GRE, Ret Method: GRE <-----Assignment, forwarding, and return methods L4 proto: 6, Use Source Port: No, Is closed: No Dynamic service 62 Priority: 34, Number of clients: 1 <----- Assign Method: Mask, Fwd Method: GRE, Ret Method: GRE <----- L4 proto: 6, Use Source Port: No, Is closed: No
O exemplo seguinte mostra a comandos adicionais que você pode se usar para examinar a informação do Forwarding Processor:
ASR1000# sh platform software wccp fp active ? <0-255> service ID cache-info Show cache-engine info interface Show interface info statistics Show messaging statistics web-cache Web-cache type | Output modifiers <cr>
Para indicar reorientou estatísticas de pacote para cada relação, use os contadores de interface do wccp do software de plataforma da mostra comandam como segue:
ASR1000# sh platform software wccp interface counters
Interface GigabitEthernet0/1/2
Input Redirect Packets = 391
Output Redirect Packets = 0
Interface GigabitEthernet0/1/3
Input Redirect Packets = 1800
Output Redirect Packets = 0
Use os contadores do cache de web do wccp do software de plataforma da mostra comandam para indicar a informação de cache WCCP como segue:
ASR1000# sh platform software wccp web-cache counters
Service Group (0, 0) counters
unassigned_count = 0
dropped_closed_count = 0
bypass_count = 0
bypass_failed_count = 0
denied_count = 0
redirect_count = 0
Para indicar detalhes de baixo nível, use os comandos seguintes:
- mostre o resumo da relação F0 da plataforma assim
- mostre a relação do wccp f0 do software de plataforma
- debugar a configuração do wccp do software de plataforma
Para mais informação, veja o White Paper “distribuir e pesquisando defeitos a versão 2 do protocolo web cache control no Roteadores de serviços de agregação Cisco ASR série 1000”
Pesquisando defeitos o WCCP no WAE
Comece a pesquisar defeitos no WAE usando o comando do show wccp services. Você quer ver ambos os serviços 61 e 62 configurados, como segue:
WAE-612# show wccp services
Services configured on this File Engine
TCP Promiscuous 61
TCP Promiscuous 62
Verificação seguinte o estado WCCP usando o comando do show wccp status. Você quer ver que a versão de WCCP 2 está permitida e active como segue:
WAE-612# show wccp status WCCP version 2 is enabled and currently active
Olhe a informação da exploração agrícola WCCP usando o comando do largo-área-motor do wccp da mostra. Este comando mostra o número de WAEs na exploração agrícola, seus IP address, qual é a ligação WAE, o Roteadores que podem considerar o WAEs, e a outra informação, como segue:
WAE612# show wccp wide-area-engine
Wide Area Engine List for Service: TCP Promiscuous 61
Number of WAE's in the Cache farm: 3
Last Received Assignment Key IP address: 10.43.140.162 <-----All WAEs in farm should have same Key IP
Last Received Assignment Key Change Number: 17
Last WAE Change Number: 16
Assignment Made Flag = FALSE
IP address = 10.43.140.162 Lead WAE = YES Weight = 0
Routers seeing this Wide Area Engine(3)
10.43.140.161
10.43.140.166
10.43.140.168
IP address = 10.43.140.163 Lead WAE = NO Weight = 0
Routers seeing this Wide Area Engine(3)
10.43.140.161
10.43.140.166
10.43.140.168
IP address = 10.43.140.164 Lead WAE = NO Weight = 0
Routers seeing this Wide Area Engine(3)
10.43.140.161
10.43.140.166
10.43.140.168
. . .
Olhe a informação de roteador usando o comando do show wccp routers. Verifique que há uma comunicação bi-direcional com Roteadores WCCP-permitido e todo o Roteadores mostra o mesmos KeyIP e KeyCN (número de alteração), como segue:
WAE-612# show wccp routers
Router Information for Service: TCP Promiscuous 61
Routers Seeing this Wide Area Engine(1)
Router Id Sent To Recv ID KeyIP KeyCN MCN
10.43.140.161 10.43.140.161 00203A21 10.43.140.162 17 52 <-----Verify routers have same KeyIP and KeyCN
10.43.140.166 10.43.140.166 00203A23 10.43.140.162 17 53
10.43.140.168 10.43.140.165 00203A2D 10.43.140.162 17 25
Routers not Seeing this Wide Area Engine
-NONE-
Routers Notified of from other WAE's
-NONE-
Multicast Addresses Configured
-NONE-
. . .
Nos casos onde o WAE não é a camada 2-adjacent ao roteador, ou um endereço de loopback é usado, as rotas estáticas ou um gateway padrão são exigidos para apoiar o WCCP.
Para examinar a distribuição da cubeta da mistura no grupo de serviço, use o comando TCP-promíscuo do show wccp flows como segue:
wae# sh wccp flows tcp-promiscuous Flow counts for service: TCP Promiscuous 61 Bucket Flow Counts 0- 11: 0 0 0 0 0 0 0 0 0 0 0 0 12- 23: 0 0 0 0 0 0 0 0 0 0 0 0 24- 35: 0 0 0 0 0 0 0 0 0 0 0 0 36- 47: 0 0 0 0 0 0 0 0 0 0 0 0 48- 59: 0 0 0 0 0 0 0 0 0 0 0 0 60- 71: 0 0 0 0 0 0 0 0 0 0 0 0 72- 83: 0 0 0 0 0 0 0 0 0 0 0 0 84- 95: 0 0 0 0 0 0 0 0 0 0 0 0 96-107: 0 0 0 0 0 0 0 0 0 0 0 0 108-119: 0 0 0 0 0 0 0 0 0 0 0 0 120-131: 0 0 0 0 0 0 0 0 0 0 0 0 132-143: 0 0 0 0 0 0 0 0 0 0 0 0 144-155: 0 0 0 0 0 0 0 0 0 0 0 0 156-167: 0 0 0 0 0 0 0 0 0 0 0 0 168-179: 0 0 0 0 0 0 0 0 0 0 0 0 180-191: 0 0 0 0 0 0 0 0 0 0 0 0 192-203: 0 0 0 0 0 0 0 0 0 0 0 0 204-215: 0 0 0 0 0 0 0 0 0 0 0 0 216-227: 0 0 0 0 0 0 0 0 0 0 0 0 228-239: 0 0 0 0 0 0 0 0 0 3 0 0 240-251: 0 0 0 0 0 0 0 0 0 0 0 0 252-255: 0 0 0 0
Alternativamente, você pode usar a versão sumária do comando ver a informação similar, assim como contorneia a informação de fluxo:
wae# sh wccp flows tcp-promiscuous summary Flow summary for service: TCP Promiscuous 61 Total Buckets OURS = 256 0- 59: OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO 60-119: OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO 120-179: OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO 180-239: OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO OOOOOOOOOO 240-255: OOOOOOOOOO OOOOOO BYP = 0 0- 59: .......... .......... .......... .......... .......... .......... 60-119: .......... .......... .......... .......... .......... .......... 120-179: .......... .......... .......... .......... .......... .......... 180-239: .......... .......... .......... .......... .......... .......... 240-255: .......... ...... AWAY = 0 0- 59: .......... .......... .......... .......... .......... .......... 60-119: .......... .......... .......... .......... .......... .......... 120-179: .......... .......... .......... .......... .......... .......... 180-239: .......... .......... .......... .......... .......... .......... 240-255: .......... ...... . . .
Use o comando do gre do wccp da mostra indicar estatísticas do pacote GRE como segue:
WAE-612# show wccp gre Transparent GRE packets received: 5531561 <-----Increments for WCCP GRE redirection Transparent non-GRE packets received: 0 <-----Increments for WCCP L2 redirection Transparent non-GRE non-WCCP packets received: 0 <-----Increments for ACE or PBR redirection Total packets accepted: 5051 <-----Accepted for optimization; peer WAE found Invalid packets received: 0 Packets received with invalid service: 0 Packets received on a disabled service: 0 Packets received too small: 0 Packets dropped due to zero TTL: 0 Packets dropped due to bad buckets: 0 Packets dropped due to no redirect address: 0 Packets dropped due to loopback redirect: 0 Pass-through pkts dropped on assignment update:0 Connections bypassed due to load: 0 Packets sent back to router: 0 GRE packets sent to router (not bypass) 0 <-----Handled with WCCP negotiated return egress Packets sent to another WAE: 0 GRE fragments redirected: 0 GRE encapsulated fragments received: 0 Packets failed encapsulated reassembly: 0 Packets failed GRE encapsulation: 0 --More--
Se o redirecionamento de WCCP está trabalhando, qualquer um dos primeiros dois contadores deve incrementar.
O contador recebido transparente dos pacotes NON-GRE incrementa para os pacotes que são reorientados usando a camada 2 WCCP reorientam o método de encaminhamento.
O contador recebido transparente dos pacotes NON-GRE NON-WCCP incrementa para os pacotes que são reorientados por um método da intercepção NON-WCCP (tal como o ACE ou o PBR).
Os pacotes total aceitaram indicam contra os pacotes que são aceitados para a otimização porque a descoberta automática encontrou um par WAE.
Os pacotes GRE enviados ao contador do roteador (não desvio) indicam os pacotes que foram segurados usando o método do retorno negociado WCCP da saída.
Os pacotes enviados a um outro WAE indicam contra que a proteção do fluxo está ocorrendo quando um outro WAE é adicionado ao grupo de serviço e começa a segurar uma atribuição da cubeta que esteja sendo segurada previamente por um outro WAE.
Verifique que os métodos da saída que estão sendo usados são previstos usando o comando dos saída-métodos da mostra como segue:
WAE674# show egress-methods
Intercept method : WCCP
TCP Promiscuous 61 :
WCCP negotiated return method : WCCP GRE
Egress Method Egress Method
Destination Configured Used
----------- ---------------------- -------------
any WCCP Negotiated Return WCCP GRE <-----Verify these are expected
TCP Promiscuous 62 :
WCCP negotiated return method : WCCP GRE
Egress Method Egress Method
Destination Configured Used
----------- ---------------------- -------------
any WCCP Negotiated Return WCCP GRE <-----Verify these are expected
As más combinações do método da saída podem ocorrer sob as seguintes circunstâncias:
- O método do retorno negociado da saída é configurado, mas o WCCP negocia o método do retorno da camada 2 e somente o retorno GRE é apoiado por WAAS.
- O método genérico da saída GRE é configurado, mas o método da intercepção é a camada 2 e somente o WCCP GRE está apoiado como o método da intercepção quando a saída genérica GRE é configurada.
Em qualquer um destes casos, um alarme menor está levantado e cancelado quando a má combinação é resolvida mudando o método da saída ou a configuração de WCCP. Até que o alarme esteja cancelado, o IP padrão que envia o método da saída está usado.
O exemplo seguinte mostra o comando output quando uma má combinação existe:
WAE612# show egress-methods
Intercept method : WCCP
TCP Promiscuous 61 :
WCCP negotiated return method : WCCP GRE
Egress Method Egress Method
Destination Configured Used
----------- ---------------------- -------------
any Generic GRE IP Forwarding <-----Mismatch
WARNING: WCCP has negotiated WCCP L2 as the intercept method for <-----Warning if mismatch occurs
which generic GRE is not supported as an egress method
in this release. This device uses IP forwarding as the
egress method instead of the configured generic GRE
egress method.
TCP Promiscuous 62 :
WCCP negotiated return method : WCCP GRE
Egress Method Egress Method
Destination Configured Used
----------- ---------------------- -------------
any Generic GRE IP Forwarding <-----Mismatch
WARNING: WCCP has negotiated WCCP L2 as the intercept method for <-----Warning if mismatch occurs
which generic GRE is not supported as an egress method
in this release. This device uses IP forwarding as the
egress method instead of the configured generic GRE
egress method.
Para o Roteadores Sup720 ou Sup32 do Catalyst 6500, nós recomendamos usar o método genérico da saída GRE, que é processado no hardware. Adicionalmente, nós recomendamos usar um túnel multiponto para a facilidade da configuração, em vez de um túnel de Point-to-Point para cada WAE. Para os detalhes da configuração de túnel, refira a seção configurando uma interface do túnel GRE em um roteador no manual de configuração do Wide Area Application Services de Cisco.
Para ver as estatísticas do túnel GRE para cada roteador de intercepção, use o comando das estatísticas genérico-GRE da mostra como segue:
WAE# sh stat generic Tunnel Destination: 10.10.14.16 Tunnel Peer Status: N/A Tunnel Reference Count: 2 Packets dropped due to failed encapsulation: 0 Packets dropped due to no route found: 0 Packets sent: 0 Packets sent to tunnel interface that is down: 0 Packets fragmented: 0
A falha assegurar-se de que os pacotes de saída de um WAE não reintercepted pode conduzir a um laço da reorientação. Se um WAE detecta sua própria identificação retornada no campo de opções TCP, um laço da reorientação ocorreu e conduz ao seguinte mensagem do syslog:
%WAAS-SYS-3-900000: 137.34.79.11:1192 - 137.34.77.196:139 - opt_syn_rcv: Routing Loop detected - Packet has our own devid. Packet dropped.
Você pode procurar o arquivo de syslog.txt por exemplos deste erro usando o comando find como segue:
WAE-612# find match “Routing Loop” syslog.txt
Este erro igualmente aparece no TFO flui as estatísticas disponíveis nas estatísticas da mostra que filtram o comando como segue:
WAE-612# show statistics filtering . . . Syn packets dropped with our own id in the options: 8 <-----Indicates a redirection loop . . .
Se você está fazendo a reorientação de partida no roteador, porque o tráfego sae do roteador obterá reorientado de volta ao WAE, que redistribuirá o pacote para fora o roteador, causando um loop de roteamento. Se o centro de dados WAE e os server estão em VLAN diferentes e o ramo WAE e os clientes estão em VLANS diferente, você pode evitar um loop de roteamento usando a seguinte configuração de roteador no WAE VLAN:
ip wccp redirect exclude in
Se o WAE compartilha do mesmo VLAN com seus clientes ou server adjacentes, você pode evitar loop de roteamento usando o método do retorno negociado, ou o retorno genérico GRE para as Plataformas onde o redirecionamento de WCCP é executado no hardware. Ao usar o retorno genérico GRE, o WAE usa um túnel GRE ao tráfego de retorno ao roteador.
Pesquisando defeitos IDs configuráveis do serviço e intervalos variáveis na versão 4.4.1
NOTA: Os IDs configuráveis do serviço WCCP e os recursos de timeout variáveis da detecção de falha foram introduzidos na versão 4.4.1 WAAS. Esta seção não é aplicável a umas versões mais adiantadas WAAS.
Todo o WAEs em uma exploração agrícola WCCP deve usar os mesmos pares de IDs do serviço WCCP (o padrão é 61 e 62), e estes IDs devem combinar todo o Roteadores que está apoiando a exploração agrícola. Um WAE com os IDs diferentes do serviço WCCP do que aqueles configurados no Roteadores não é permitido juntar-se à exploração agrícola e do “o alarme inacessível existente roteador” é levantado. Igualmente, todo o WAEs em uma exploração agrícola deve usar o mesmo valor para o intervalo da detecção de falha. Um WAE levanta um alarme se você o configura com um valor combinando mal.
Se você vê um alarme que um WAE não pode se juntar a uma exploração agrícola WCCP, certifique-se dos IDs do serviço WCCP configurados no WAE e no Roteadores na exploração agrícola combinem. No WAEs, use o comando do largo-área-motor do wccp da mostra verificar os IDs configurados do serviço. No Roteadores, você pode usar o comando ios do wccp IP da mostra.
Para verificar se o WAE tem a Conectividade ao roteador, use o detalhe do show wccp services e mostre comandos detail do roteador do wccp.
Adicionalmente, você pode permitir o resultado do debug WCCP no WAE usando o evento WCCP ou comandos debug ip wccp packet IP debugar.
Se você vê do “um alarme menor inusável roteador” para um WAE, poder-se-ia significar que o grupo variável do valor de timeout da detecção de falha no WAE não está apoiado pelo roteador. Use o comando detail menor do alarme da mostra verificar se a razão para o alarme é do “má combinação intervalo de temporizador com roteador”:
WAE# show alarm minor detail
Minor Alarms:
-------------
Alarm ID Module/Submodule Instance
--------------- -------------------- ---------------
1 rtr_unusable WCCP/svc051/rtr2.192.9.161
Jan 11 23:18:41.885 UTC, Communication Alarm, #000005, 17000:17003
WCCP router 2.192.9.161 unusable for service id: 51 reason: Timer interval <-----Check reason
mismatch with router <-----
No WAE, verifique o intervalo configurado da detecção de falha como segue:
WAE# show wccp services detail
Service Details for TCP Promiscuous 61 Service
Service Enabled : Yes
Service Priority : 34
Service Protocol : 6
Application : Unknown
Service Flags (in Hex) : 501
Service Ports : 0 0 0 0
: 0 0 0 0
Security Enabled for Service : No
Multicast Enabled for Service : No
Weight for this Web-CE : 1
Negotiated forwarding method : GRE
Negotiated assignment method : HASH
Negotiated return method : GRE
Negotiated HIA interval : 2 second(s)
Negotiated failure-detection timeout : 30 second(s) <-----Failure detection timeout configured
. . .
No roteador, verifique se a Versão do IOS apoia o intervalo variável da detecção de falha. Em caso afirmativo, você pode verificar o ajuste configurado usando o comando detail do wccp xx IP da mostra, onde xx são o ID de serviço WCCP. Há três resultados possíveis:
- WAE está usando um intervalo da detecção de falha do padrão de 30 segundos e o roteador é configurado o mesmos ou não apoia o intervalo variável: As saídas de roteador não mostram nenhum detalhe sobre a configuração de timeout. Esta configuração opera-se muito bem.
- WAE está usando o intervalo não-padrão da detecção de falha de 9 ou 15 segundos e o roteador não apoiam o intervalo variável: O campo de estado mostra que “não útil” e o WAE não pode usar o roteador. Mude o intervalo da detecção de falha WAE ao valor padrão de 30 segundos usando o comando global configuration da detecção de falha 30 tcp do wccp.
- WAE está usando o intervalo não-padrão da detecção de falha de 9 ou de 15 segundos e do intervalo variável dos suportes de roteador: O campo do timeout de cliente mostra o intervalo configurado da detecção de falha, que combina o WAE. Esta configuração opera-se muito bem.
Se a exploração agrícola WCCP é instável devido ao não sincronismo de link, poderia ser porque o intervalo da detecção de falha WCCP é demasiado baixo.
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)