IP : Serviços de endereçamento IP

Verificando a Operação e Troubleshooting Básico do NAT

1 Julho 2009 - Tradução Manual
Outras Versões: Versão em PDFpdf | Tradução por Computador (21 Dezembro 2013) | Inglês (19 Dezembro 2013) | Feedback

Este documento contém animações em Flash.


Interativo: Este documento apresenta uma análise personalizada do seu dispositivo Cisco.

Índice

Introdução
Pré-requisitos
      Requisitos
      Componentes Utilizados
      Convenções
Como Eliminar a Possibilidade de Problemas de NAT
Estudo de Caso com Animação em Flash: É Possível Fazer Ping em um Host, Mas Não Telnet
Estudo de Caso com Animação em Flash: Não É Possível Fazer Ping Além do NAT
Exemplo de Problema: É Possível Fazer Ping em um Host, Mas Não em Outro
      Resumo do Problema
Exemplo de Problema: Dispositivos na Rede Externa Não Conseguem se Comunicar com Roteadores Internos
      Resumo do Problema
Listas de Verificação de Troubleshooting
      Conversão Não Instalada na Tabela de Conversões
      A Entrada de Conversão Correta Não Está Sendo Utilizada
      O NAT Está Operando Corretamente, Mas Ainda Há Problemas de Conectividade
      A Conversão de NAT da Porta 80 Não Funciona
      %NAT: System busy. Try later
      Tabelas de Conversão Grandes Aumentam o Uso da CPU
      % Public ip-address already mapped (Internal ip-address -> Public ip-address)
      Conclusão

Introdução

Quando você passa por problemas de conectividade de IP em um ambiente com NAT, geralmente é difícil determinar a causa do problema. Muitas vezes o NAT é culpado de maneira equivocada, quando na realidade há um problema estrutural. Este documento descreve como verificar a operação do NAT usando as ferramentas disponíveis nos roteadores Cisco. Este documento também mostra como executar o troubleshooting básico do NAT e como evitar erros comuns durante o troubleshooting.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

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. Se a sua rede estiver em um ambiente de produção, esteja ciente do impacto potencial de qualquer comando.

Convenções

Para obter mais informações sobre convenções de documentos, consulte as Convenções de Dicas Técnicas da Cisco.

Como Eliminar a Possibilidade de Problemas de NAT

Quando você tenta determinar a causa de um problema de conectividade de IP, é útil eliminar a possibilidade de problemas de NAT. Siga estes passos para verificar se o NAT está funcionando corretamente:

  1. Com base na configuração, defina claramente os objetivos do NAT. Neste ponto, é possível determinar que há um problema com a configuração. Para obter ajuda com a configuração do NAT, consulte Configurando a Tradução de Endereço de Rede: Introdução.

  2. Verifique se há conversões corretas na tabela de conversões.

  3. Use os comandos show e debug para verificar se a conversão está sendo efetuada.

  4. Analise detalhadamente o que acontece ao pacote e verifique se os roteadores possuem as informações corretas de roteamento para repassar o pacote adiante.

A seguir são mostrados alguns exemplos de problemas onde utilizamos os passos acima para ajudar na determinação da causa do problema.

Estudo de Caso com Animação em Flash: É Possível Fazer Ping em um Host, Mas Não Telnet

Clique aqui para ver uma animação em Flash de 7 minutos sobre por que um dispositivo pode fazer ping em um host, mas não consegue fazer telnet.

Estudo de Caso com Animação em Flash: Não É Possível Fazer Ping Além do NAT

Clique aqui para ver uma animação em Flash de 10 minutos sobre por que um dispositivo não consegue fazer ping além do NAT.

Exemplo de Problema: É Possível Fazer Ping em um Host, Mas Não em Outro

Neste diagrama de rede, Roteador 4 pode fazer ping em Roteador 5 (172.16.6.5), mas não em Roteador 7 (172.16.11.7):

13a.gif

Não há protocolos de roteamento em execução em nenhum dos roteadores, e Roteador 4 tem Roteador 6 como seu gateway padrão. Roteador 6 está configurado com o NAT desta forma:

Roteador 6

interface Ethernet0
 ip address 172.16.6.6 255.255.255.0
 ip directed-broadcast
 ip nat outside
 media-type 10BaseT
 !
interface Ethernet1
 ip address 10.10.10.6 255.255.255.0
 ip nat inside
 media-type 10BaseT
 !
interface Serial2.7 point-to-point
 ip address 172.16.11.6 255.255.255.0
 ip nat outside
 frame-relay interface-dlci 101
 !
ip nat pool test 172.16.11.70 172.16.11.71 prefix-length 24
ip nat inside source list 7 pool test
ip nat inside source static 10.10.10.4 172.16.6.14
 !
access-list 7 permit 10.10.50.4
access-list 7 permit 10.10.60.4
access-list 7 permit 10.10.70.4 

Primeiro, determine se o NAT está funcionando corretamente. A partir da configuração, você sabe que o endereço IP de Roteador 4 (10.10.10.4) deve ser convertido estaticamente para 172.16.6.14. Você pode utilizar o comando show ip nat translation em Roteador 6 para verificar se a conversão existe na tabela de conversões:

router-6# show ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.6.14        10.10.10.4         ---                ---

Agora, certifique-se de que essa conversão esteja ocorrendo quando Roteador 4 gera tráfego IP. Você pode fazer isso de duas formas em Roteador 6: executar o debug do NAT ou monitorar as estatísticas de NAT com o comando show ip nat statistics. Como os comandos debug devem sempre ser utilizados como última opção, comece com o comando show.

A intenção aqui é monitorar o contador de ocorrências para ver se ele aumenta à medida que enviamos tráfego a partir de Roteador 4. O contador de ocorrências é incrementado toda vez que uma conversão da tabela de conversões é utilizada para converter um endereço. Inicialmente, limpe as estatísticas, exiba-as, tente fazer um ping de Roteador 4 para Roteador 7 e, em seguida, exiba as estatísticas novamente.

router-6# clear ip nat statistics
router-6#
router-6# show ip nat statistics
 Total active translations: 1 (1 static, 0 dynamic; 0 extended)
 Outside interfaces:
 Ethernet0, Serial2.7
 Inside interfaces:
 Ethernet1
 Hits: 0  Misses: 0
 Expired translations: 0
 Dynamic mappings:
 -- Inside Source
 access-list 7 pool test refcount 0
 pool test: netmask 255.255.255.0
 start 172.16.11.70 end 172.16.11.71
 type generic, total addresses 2, allocated 0 (0%), misses 0
router-6#

Após você usar o comando ping 172.16.11.7 em Roteador 4, as estatísticas de NAT de Roteador 6 indicam:

router-6# show ip nat statistics
 Total active translations: 1 (1 static, 0 dynamic; 0 extended)
 Outside interfaces:
 Ethernet0, Serial2.7
 Inside interfaces:
 Ethernet1
 Hits: 5  Misses: 0
 Expired translations: 0
 Dynamic mappings:
 -- Inside Source
 access-list 7 pool test refcount 0
 pool test: netmask 255.255.255.0
 start 172.16.11.70 end 172.16.11.71
 type generic, total addresses 2, allocated 0 (0%), misses 0

Você pode ver a partir dos comandos show que o número de ocorrências foi incrementado em cinco. Em um ping com êxito a partir de um roteador Cisco, o número de ocorrências deve ser incrementado em dez. Os cinco ecos Internet Control Message Protocol (ICMP) enviados pelo roteador de origem (Roteador 4) e os cinco pacotes de resposta de eco do roteador de destino (Roteador 7) também devem ser convertidos, em um total de dez ocorrências. As cinco ocorrências perdidas são provavelmente devido às respostas de eco não terem sido convertidas ou enviadas por Roteador 7.

Procure descobrir algum motivo para Roteador 7 não enviar pacotes de resposta de eco a Roteador 4. Primeiramente, analise o que o NAT está fazendo ao pacote. Roteador 4 está enviando pacotes de eco ICMP com um endereço de origem 10.10.10.4 e um endereço de destino 172.16.11.7. Depois que o NAT for efetuado, o pacote recebido por Roteador 7 terá um endereço de origem de 172.16.6.14 e um endereço de destino de 172.16.11.7. Roteador 7 precisa responder a 172.16.6.14 e, já que 172.16.6.14 não está conectado diretamente a Roteador 7, ele precisa de uma rota para essa rede para responder. Verifique a tabela de roteamento de Roteador 7 para ver se a rota existe.

router-7# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 4 subnets
C       172.16.12.0 is directly connected, Serial0.8
C       172.16.9.0 is directly connected, Serial0.5
C       172.16.11.0 is directly connected, Serial0.6
C       172.16.5.0 is directly connected, Ethernet0

É possível observar que a tabela de roteamento de Roteador 7 não possui uma rota para 172.16.6.14. Uma vez que você adicione essa rota, o ping funcionará corretamente.

Resumo do Problema

Primeiro, você definiu claramente os objetivos do NAT. Em seguida, você verificou se a entrada de NAT estático existia na tabela de conversões e se ela era precisa. Você verificou que a conversão estava de fato ocorrendo ao monitorar as estatísticas do NAT. Lá você identificou um problema que o levou a verificar as informações de roteamento em Roteador 7, onde você descobriu que Roteador 7 precisava de uma rota para o endereço global interno de Roteador 4.

Observe que, neste ambiente simples de laboratório, é útil monitorar as estatísticas de NAT com o comando show ip nat statistics. Entretanto, em um ambiente de NAT mais complexo com diversas conversões sendo efetuadas, esse comando show deixa de ser útil. Nesse caso, talvez seja necessário executar debugs no roteador. O próximo cenário de problema demonstra a utilização dos comandos debug.

Exemplo de Problema: Dispositivos na Rede Externa Não Conseguem se Comunicar com Roteadores Internos

Nesse cenário, Roteador 4 pode efetuar o ping em Roteador 5 e em Roteador 7, mas os dispositivos na rede 10.10.50.0 não conseguem se comunicar com Roteador 5 ou Roteador 7 (no laboratório de teste, emulamos isso ao estabelecer a origem dos pings a partir da interface de loopback com o endereço IP 10.10.50.4). Veja o diagrama de rede:

13a.gif

Roteador 6

interface Ethernet0
 ip address 172.16.6.6 255.255.255.0
 ip directed-broadcast
 ip nat outside
 media-type 10BaseT
 !
interface Ethernet1
 ip address 10.10.10.6 255.255.255.0
 ip nat inside
 media-type 10BaseT
 !
interface Serial2.7 point-to-point
 ip address 172.16.11.6 255.255.255.0
 ip nat outside
 frame-relay interface-dlci 101
 !
ip nat pool test 172.16.11.70 172.16.11.71 prefix-length 24
ip nat inside source list 7 pool test
ip nat inside source static 10.10.10.4 172.16.6.14
 !
access-list 7 permit 10.10.50.4
access-list 7 permit 10.10.60.4
access-list 7 permit 10.10.70.4

Inicialmente, estabeleça claramente o comportamento esperado do NAT. A partir da configuração de Roteador 6, você sabe que o NAT deve converter dinamicamente o endereço 10.10.50.4 para o primeiro endereço disponível no pool "test" de NAT. O pool contém os endereços 172.16.11.70 e 172.16.11.71. A partir do que você aprendeu no problema acima, pode-se deduzir que os pacotes que os roteadores 5 e 7 recebem possuem endereço de origem 172.16.11.70 ou 172.16.11.71. Esses endereços estão na mesma sub-rede que Roteador 7. Por isso Roteador 7 deve ter uma rota conectada diretamente. No entanto, Roteador 5 precisa de uma rota até a sub-rede se ainda não tiver uma.

Você pode usar o comando show ip route para ver se a tabela de roteamento de Roteador 5 inclui 172.16.11.0:

router-5# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 4 subnets
C 172.16.9.0 is directly connected, Serial1
S 172.16.11.0 [1/0] via 172.16.6.6
C 172.16.6.0 is directly connected, Ethernet0
C 172.16.2.0 is directly connected, Serial0

Você pode usar o comando show ip route para ver se a tabela de roteamento de Roteador 7 lista 172.16.11.0 como uma sub-rede diretamente conectada:

router-7# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

     172.16.0.0/24 is subnetted, 5 subnets
C       172.16.12.0 is directly connected, Serial0.8
C       172.16.9.0 is directly connected, Serial0.5
C       172.16.11.0 is directly connected, Serial0.6
C       172.16.5.0 is directly connected, Ethernet0
S       172.16.6.0 [1/0] via 172.16.11.6

Agora que você estabeleceu claramente o que o NAT deve fazer, é hora de verificar se ele está funcionando corretamente. Comece ao verificar a tabela de conversões do NAT e se a conversão esperada existe. Como a conversão na qual você está interessado é criada dinamicamente, você precisa primeiro enviar tráfego IP proveniente do endereço apropriado. Após um ping proveniente de 10.10.50.4 ser enviado para 172.16.11.7, a tabela de conversões de Roteador 6 mostra o seguinte:

router-6# show ip nat translation
Pro Inside global      Inside local       Outside local      Outside global
--- 172.16.6.14        10.10.10.4         ---                ---
--- 172.16.11.70       10.10.50.4         ---                ---

Como a conversão esperada está na tabela de conversões, você sabe que os pacotes de eco ICMP estão sendo convertidos apropriadamente, mas e quanto aos pacotes de resposta de eco? Como foi mencionado anteriormente, você pode monitorar as estatísticas do NAT, mas isso não é muito útil em um ambiente complexo. Outra opção é executar a depuração de NAT no roteador com NAT (Roteador 6). Nesse caso, você deve ativar debug ip nat em Roteador 6 enquanto envia um ping proveniente de 10.10.50.4 e destinado a 172.16.11.7. Os resultados do comando debug são mostrados adiante.

Nota: Ao executar qualquer comando debug em um roteador, você poderá sobrecarregá-lo e fazer com que ele se torne inoperante. Tenha sempre muito cuidado e, se possível, jamais execute um comando debug em um roteador de produção crítica sem a supervisão de um engenheiro do Suporte Técnico da Cisco.

router-6# show log
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
       Console logging: level debugging, 39 messages logged
       Monitor logging: level debugging, 0 messages logged
       Buffer logging: level debugging, 39 messages logged
       Trap logging: level informational, 33 message lines logged

Log Buffer (4096 bytes):

05:32:23: NAT: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [70]
05:32:23: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [70]
05:32:25: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [71]
05:32:25: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [71]
05:32:27: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [72]
05:32:27: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [72]
05:32:29: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [73]
05:32:29: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [73]
05:32:31: NAT*: s=10.10.50.4->172.16.11.70, d=172.16.11.7 [74]
05:32:31: NAT*: s=172.16.11.7, d=172.16.11.70->10.10.50.4 [74]

Como você pode ver na saída do comando debug acima, a primeira linha mostra o endereço de origem 10.10.50.4 sendo convertido para 172.16.11.70. A segunda linha mostra o endereço de destino 172.16.11.70 sendo convertido de volta para 10.10.50.4. Esse padrão se repete por todo o restante do comando debug. Isso indica que Roteador 6 está convertendo pacotes em ambas as direções.

Agora analise mais detalhadamente o que deveria estar acontecendo. Roteador 4 envia um pacote originado em 10.10.50.4 e destinado a 172.16.11.7. Roteador 6 efetua o NAT no pacote e encaminha um pacote com origem em 172.16.11.70 e destino em 172.16.11.7. Roteador 7 envia uma resposta com origem em 172.16.11.7 e destino em 172.16.11.70. Roteador 6 efetua o NAT no pacote, o que resulta em um pacote com endereço de origem 172.16.11.7 e endereço de destino 10.10.50.4. Nesse ponto, Roteador 6 deve rotear o pacote para 10.10.50.4 com base nas informações que possui em sua tabela de roteamento. Você deve utilizar o comando show ip route para confirmar se Roteador 6 possui a rota necessária em sua tabela de roteamento.

router-6# show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route

Gateway of last resort is not set

172.16.0.0/24 is subnetted, 5 subnets
C 172.16.8.0 is directly connected, Serial1
C 172.16.10.0 is directly connected, Serial2.8
C 172.16.11.0 is directly connected, Serial2.7
C 172.16.6.0 is directly connected, Ethernet0
C 172.16.7.0 is directly connected, Serial0
10.0.0.0/24 is subnetted, 1 subnets
C 10.10.10.0 is directly connected, Ethernet1

Resumo do Problema

Primeiro, você definiu claramente os objetivos do NAT. Em segundo lugar, você verificou se as conversões necessárias existiam na tabela de conversões. Em terceiro lugar, você usou os comandos debug ou show para verificar se a conversão estava realmente sendo efetuada. Finalmente, você analisou detalhadamente o que estava acontecendo com o pacote e o que os roteadores precisam para encaminhá-lo ou respondê-lo.

Listas de Verificação de Troubleshooting

Agora que você já conhece um procedimento básico para identificar a causa de problemas de conectividade, aqui estão algumas listas de verificação para o troubleshooting de problemas comuns.

Conversão Não Instalada na Tabela de Conversões

Se você descobrir que a conversão apropriada não é instalada na tabela de conversões, verifique se:

  • A configuração está correta. Fazer com que o NAT execute o que você quer pode algumas vezes ser complicado. Para obter ajuda com a configuração, consulte Configurando a Tradução de Endereço de Rede: Introdução.

  • Não existe nenhuma lista de acesso de entrada que impeça os pacotes de entrarem no roteador de NAT.

  • O roteador de NAT possui a rota adequada na tabela de roteamento caso o o pacote esteja trafegando de dentro para fora. Consulte Ordem de Operação do NAT para obter informações adicionais.

  • A lista de acesso referenciada pelo comando NAT permite todas as redes necessárias.

  • Há endereços suficientes no pool de NAT. Isso somente deverá ser um problema se o NAT não estiver configurado para condições de sobrecarga.

  • As interfaces de roteadores são apropriadamente definidas como NAT interno ou NAT externo.

  • No caso de conversão da carga de pacotes de DNS, certifique-se de que a conversão seja efetuada no endereço do cabeçalho IP do pacote. Se isso não acontecer, então o NAT não examinará a carga do pacote.

A Entrada de Conversão Correta Não Está Sendo Utilizada

Se a entrada de conversão correta estiver instalada na tabela de conversões, mas não for utilizada, verifique:

  • Verifique se existe alguma lista de acesso de entrada que impeça os pacotes de entrarem no roteador de NAT.

  • Para os pacotes que trafegam do interior para o exterior, verifique se há uma rota para o destino, pois ela é verificada antes da conversão. Consulte Ordem de Operação do NAT para obter informações adicionais.

O NAT Está Operando Corretamente, Mas Ainda Há Problemas de Conectividade

Se o NAT estiver operando corretamente, inicie o troubleshooting do problema de conectividade da seguinte forma:

  • Verifique a conectividade da Camada 2.

  • Verifique as informações de roteamento da Camada 3.

  • Procure filtros de pacotes que possam estar causando o problema.

A Conversão de NAT da Porta 80 Não Funciona

A conversão de NAT da porta 80 não funciona, mas a conversão das outras portas funciona normalmente.

Para resolver esse problema, execute estes passos:

  1. Execute os comandos debug ip nat translations e debug ip packet para ver se as conversões estão corretas e se a entrada de conversão correta está instalada na tabela de conversões.

  2. Verifique se o servidor responde.

  3. Desabilite o servidor HTTP.

  4. Limpe as tabelas de NAT e ARP.

%NAT: System busy. Try later

A mensagem de erro %NAT: System busy. Try later é exibida quando um comando show relacionado ao NAT ou um comando show running-config ou write memory é executado. Esse problema ocorre devido ao aumento do tamanho da tabela de NAT. Quando o tamanho da tabela de NAT aumenta, o roteador fica sem memória.

Reinicie o roteador para resolver esse problema. Se a mensagem de erro for exibida quando o HSRP SNAT estiver configurado, execute estes comandos para resolver o problema:

Router(config)#standby delay minimum 20 reload 20
Router(config)#standby 2 preempt delay minimum 20 reload 20 sync 10

Tabelas de Conversão Grandes Aumentam o Uso da CPU

Um host pode enviar centenas de conversões, o que, por sua vez, gera um uso elevado da CPU. Em outras palavras, isso pode tornar a tabela tão grande que pode fazer a CPU trabalhar com 100 por cento de sua capacidade. O comando ip nat translation max-entries 300 estabelece o limite de 300 por host ou um limite agregado da quantidade de conversões no roteador. A solução é utilizar o comando ip nat translation max-entries all-hosts 300.

% Public ip-address already mapped (Internal ip-address -> Public ip-address)

Esta mensagem é exibida quando você tenta configurar dois endereços IP internos em um endereço IP público que escutam nas mesmas portas.

% X.X.X.X already mapped (172.30.62.101 -> X.X.X.X)

Para fazer o NAT dos endereços IP públicos para dois enereços IP internos, use dois endereços IP públicos no DNS.

Conclusão

Os problemas acima indicam que o NAT nem sempre é o motivo dos problemas de conectividade de IP. Em muitos casos, a causa não é o NAT e requer investigação adicional. Este documento explica os passos básicos que devem ser seguidos durante o troubleshooting e a verificação da operação do NAT. Esses passos incluem:

  • Definir claramente os objetivos do NAT.

  • Verificar se existem conversões corretas na tabela de conversões.

  • Usar os comandos show e debug para verificar se a conversão está sendo efetuada.

  • Analisar detalhadamente o que acontece ao pacote e verificar se os roteadores possuem as informações corretas de roteamento para repassar o pacote adiante.


Discussões relacionadas da comunidade de suporte da Cisco

A Comunidade de Suporte da Cisco é um fórum onde você pode perguntar e responder, oferecer sugestões e colaborar com colegas.


Document ID: 8605