IP : Conversão de endereços de rede (NAT)

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

19 Setembro 2015 - Tradução por Computador
Outras Versões: Versão em PDFpdf | Tradução Manual (1 Julho 2009) | Inglês (22 Agosto 2015) | Feedback


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


Índice


Introdução

Quando existe problemas de conectividade de IP em um ambiente NAT, frequentemente há uma dificuldade para 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 de NAT usando ferramentas disponíveis nos Cisco routers. Este documento também mostra como executar o Troubleshooting básico do NAT e como evitar erros comuns ao Troubleshoot NAT.

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) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.

Convenções

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Como eliminar a possibilidade de NAT

Quando você tenta determinar a causa de um problema de conectividade IP, ajuda a ordenar para fora o NAT. Siga estes passos para verificar se o NAT está operando conforme o esperado:

  1. Com base na configuração, defina claramente o que o NAT deve alcançar. Neste ponto, é possível determinar que há um problema com a configuração. Para a ajuda com configurar o NAT refira configurar a tradução de endereço de rede: Obtenção começado.

  2. Verifique se as conversões corretas existem na tabela de conversão.

  3. Use os comandos show and debug verificar que a tradução está ocorrendo.

  4. A revisão em detalhe o que está acontecendo ao pacote e verifica que o Roteadores tem a informação de roteamento correto para mover avante o pacote.

Estão abaixo alguns exemplos de problema em que nós usamos as etapas acima para ajudar a determinar a causa do problema.

Exemplo de problema: É possível efetuar ping com um roteador, mas não com o outro

Neste diagrama da rede, Roteador4 pode sibilar o roteador 5 (172.16.6.5), mas não o roteador 7 (172.16.11.7):

13a.gif

Não há nenhum protocolo de roteamento que é executado em algum do Roteadores, e Roteador4 tem o roteador 6 como seu gateway padrão. O roteador 6 é configurado com NAT desse modo:

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 NAT está funcionando corretamente. Você sabe da configuração que o endereço IP de Um ou Mais Servidores Cisco ICM NT de Roteador4 (10.10.10.4) está suposto ser traduzido estaticamente a 172.16.6.14. Você pode usar o comando show ip nat translation no roteador 6 verificar que a tradução existe na tabela de tradução:

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

Agora, assegure-se de que esta tradução esteja ocorrendo quando tráfego IP das fontes de Roteador4. Você pode fazer isso de duas maneiras a partir do roteador 6: executando a depuração de NAT ou monitorando estatísticas de NAT com o comando show ip nat statistics. Porque os comandos debug devem sempre ser usados como um último recurso, comece com o comando show.

A intenção aqui é monitorar as batidas ao contrário de considera se está aumentando enquanto nós enviamos o tráfego de Roteador4. O contador de acertos aumenta sempre que uma conversão na tabela de conversão é usada para converter um endereço. Primeiramente, cancele as estatísticas, a seguir indique as estatísticas, tente-as sibilar o roteador 7 de Roteador4, e indique-as então as estatísticas outra vez.

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#

Depois que você usa o comando de 172.16.11.7 do sibilo em Roteador4, as estatísticas NAT no roteador 6 mostram como:

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 dos comandos show que o número de pressionamentos incrementou por cinco. Em um ping bem-sucedido a partir de um roteador Cisco, o número de hits deve aumentar dez vezes. Os cinco ecos do Internet Control Message Protocol (ICMP) enviados pelo roteador de origem (Roteador4) devem ser traduzidos, e os cinco pacotes de resposta de eco do roteador de destino (roteador 7) devem igualmente ser traduzidos, porque um total de dez batidas. Os cinco acessos perdidos são provavelmente devido às respostas de eco não terem sido traduzidas ou enviadas do Roteador 7.

Veja se você pode encontrar que nenhum roteador 7 da razão não enviaria a pacotes de resposta de eco a Roteador4. Primeira revisão que NAT está fazendo ao pacote. O 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 acontecer, o pacote recebido pelo Roteador 7 tem um endereço de origem de 172.16.6.14 e um endereço de destino de 172.16.11.7. O Roteador 7 precisa responder ao 172.16.6.14 e, já que o 172.16.6.14 não está conectado diretamente ao Roteador 7, ele precisa de uma rota para esta rede para responder. A tabela de roteamento do roteador 7's da verificação para verificar 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

Você pode ver que a tabela de roteamento do roteador 7 não tem uma rota para 172.16.6.14. Uma vez que você adiciona esta rota, sibile trabalhos muito bem.

Resumo de problema

Você definiu primeiramente que NAT foi suposto para realizar. Em seguida, você verificou se a entrada NAT estática existia na tabela de tradução e se era precisa. Você verificou que a conversão de fato estava ocorrendo, por monitorar as estatísticas do NAT. Lá você encontrou um problema que o conduzisse verificar a informação de roteamento no roteador 7, onde você encontrou que o roteador 7 precisou uma rota ao endereço global interno do roteador 4.

Note que neste ambiente simples de laboratório, é útil monitorar estatísticas NAT com o comando show ip nat statistics. Contudo, em mais ambiente complexo NAT com diversas traduções que ocorrem, este comando show é já não útil. Nesse caso, pode ser necessário executar depurações no roteador. O próximo cenário de problema demonstra a utilização de comandos debug.

Exemplo de problema: Fora dos dispositivos da rede não é possível se comunicar com roteadores internos

Nesse cenário, o Roteador 4 pode efetuar o ping do Roteador 5 e do Roteador 7, mas os dispositivos na rede 10.10.50.0 não conseguem se comunicar com o Roteador 5 ou o Roteador 7 (no laboratório de teste, emulamos isso determinando a origem dos pings a partir da interface de loopback com o endereço IP de 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 

Primeiramente, indique claramente o comportamento esperado do NAT. Da configuração do roteador 6, você sabe que o NAT está suposto traduzir dinamicamente 10.10.50.4 ao primeiro endereço disponível no conjunto NAT “teste”. O pool contém os endereços 172.16.11.70 e 172.16.11.71. A partir do que foi aprendido no problema acima, pode-se deduzir que os pacotes que os roteadores 5 e 7 recebem, ou possuem endereço fonte 172.16.11.70 ou 172.16.11.71. Esses endereços estão na mesma sub-rede que o Roteador 7, por isso o Roteador 7 deve ter uma rota conectada diretamente, no entanto o Roteador 5 precisa de uma rota até a sub-rede se ainda não tiver uma.

Você pode usar o comando show ip route ver que a tabela de roteamento do roteador 5 alista 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 ver que a tabela de roteamento do roteador 7 alista 172.16.11.0 como diretamente uma sub-rede 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ê se certificou sobre o que NAT deve fazer, é hora de verificar se ele está funcionando corretamente. Comece verificando a tabela de tradução NAT e se a tradução esperada existe. Desde que a tradução que você está interessado é criada dentro dinamicamente, você deve primeiramente enviar o tráfego IP originado do endereço apropriado. Depois que um sibilo enviado, originado de 10.10.50.4 e destinado a 172.16.11.7, a tabela de tradução no roteador 6 mostra este:

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 mencionado acima, você não pode monitorar as estatísticas NAT, mas isso não é muito útil em um ambiente completo. Outra opção é executar a depuração de NAT no roteador NAT (Roteador 6). Neste caso, você deve girar sobre debuga o IP nat no roteador 6 quando você enviar um sibilo originado de 10.10.50.4 destinou a 172.16.11.7. Os resultados debugar estão abaixo.

Nota: Quando você usa todo o comando debug em um roteador, você poderia sobrecarregar o roteador que faz com que se torne inoperável. Use sempre o cuidado extremo, e se possível nunca executado debugar em um roteador de produção crítica sem a supervisão de um engenheiro de suporte técnico de 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 se pode ver da saída do comando debug acima, a primeira linha mostra o endereço de origem 10.10.50.4 sendo traduzido para 172.16.11.70. A segunda linha mostra o endereço de destino de 172.16.11.70 que está sendo traduzido de volta a 10.10.50.4. Esse padrão se repete por todo o restante da depuração. Isso indica que o Roteador 6 está convertendo os pacotes em ambas as direções.

Reveja agora com maiores detalhes exatamente o que deve acontecer. Roteador4 envia uns pacotes de origem de 10.10.50.4 destinou para 172.16.11.7. O roteador 6 efetua NAT no pacote e encaminha um pacote com origem 172.16.11.70 e destino 172.16.11.7. O Roteador 7 envia uma resposta com uma origem 172.16.11.7 e um destino 172.16.11.70. O roteador 6 executa o NAT no pacote, que conduz a um pacote com endereço de origem 172.16.11.7 e endereço de destino 10.10.50.4. Neste momento o roteador que 6 deve distribuir o pacote a 10.10.50.4 baseou na informação tem em sua tabela de roteamento. Você precisa de usar o comando show ip route confirmar que o roteador 6 tem 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 de problema

Primeiro, você definiu claramente qual NAT deveria ser executado. 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 or show verificados que a tradução estava ocorrendo realmente. Finalmente, você analisou detalhadamente o que estava acontecendo com o pacote e o que os roteadores precisam para desviá-lo ou respondê-lo.

Troubleshooting de Listas de Verificação

Agora que você tem um procedimento básico para encontrar as causas do problema de conectividade, estão aqui algumas listas de verificação para pesquisar defeitos problemas comuns.

Tradução não instalada na tabela de tradução

Se descobrir que a tradução apropriada não é instalada na tabela de tradução, verifique se:

  • A configuração está correta. Conseguir o NAT realizar o que você quer pode às vezes ser complicado. Para alguma ajuda da configuração, refira configurar a tradução de endereço de rede: Obtenção começado.

  • Não há nenhuma listas de acessos de entrada que negam os pacotes de entrar no roteador NAT.

  • O roteador NAT possui a rota adequada na tabela de roteamento, se o pacote está trafegando de dentro para fora. Refira o ordem de operação NAT para mais informação.

  • A lista de acessos provida pelo comando nat permite todas as redes necessárias.

  • Existem endereços suficientes no pool NAT. Isso somente deverá ser um problema se NAT não estiver configurada para sobrecarga.

  • As interfaces de roteadores são apropriadamente definidas como NAT interna ou NAT externa.

  • No caso de traduzir o payload de pacotes do Domain Name System (DNS), certifique-se de que a tradução ocorre no endereço no cabeçalho IP do pacote. Se isso não acontecer, então o NAT não examinará o payload do pacote.

A entrada de tradução correta não está sendo usada

Se a entrada da tradução correspondente é instalada na tabela de tradução, mas não usada, verifique estes:

  • Verifique que não há nenhuma listas de acessos de entrada que negam os pacotes de entrar no roteador NAT.

  • Para os pacotes que trafegam do interior para o exterior, verifique se há uma rota para o destino, pois esta é verificada antes da tradução. Refira o ordem de operação NAT para mais informação.

Operação correta da NAT, mas ainda há problemas de conectividade

Se o NAT se está operando corretamente, comece a pesquisar defeitos o problema de conectividade como segue:

  • Verifique a Conectividade da camada 2.

  • Verifique as informações de roteamento do Layer 3.

  • Pesquise filtros de pacote que possam estar causando o problema.

A tradução NAT para a porta 80 não trabalha

A tradução NAT para a porta 80 não trabalha, mas o transalation para outros trabalhos das portas normalmente.

Para resolver esse problema, siga estas etapas:

  1. Execute as traduções e os comandos debug ip packet nat debugar IP a fim ver se as traduções estão corretas e a entrada da tradução correspondente está instalada na tabela de tradução.

  2. Verifique que o server responde.

  3. Desabilite o Server do HTTP.

  4. Cancele o NAT e as tabelas ARP.

%NAT: Sistema ocupado. Tentativa mais tarde

O %NAT: Sistema ocupado. Um Mensagem de Erro mais atrasado da tentativa aparece quando um comando show se relacionou ao NAT ou uma executar-configuração ou um comando write memory da mostra são executados. Esta edição é devido ao aumento no tamanho da tabela NAT. Quando o tamanho da tabela NAT aumenta, o roteador é executado fora da memória.

Recarregue o roteador a fim resolver esta edição. Se o Mensagem de Erro aparece quando o HSRP SNAT está configurado, configurar estes comandos a fim resolver a edição:

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

A grande tabela de tradução aumenta o CPU

Um host pode enviar centenas de traduções, que conduza por sua vez à alta utilização da CPU o uso. Ou seja pode fazer a tabela tão grande que faz com que o CPU seja executado em 100 por cento. O comando nat das MAX-entradas 300 da tradução IP faz os 300 pelo limite do host ou um limite agregado da quantidade de traduções no roteador. A ação alternativa é usar o comando nat dos todo-anfitriões 300 das MAX-entradas da tradução IP.

% do endereço IP público já traçado (endereço IP interno - > endereço IP público)

Esta mensagem aparece quando você tenta configurar dois endereços IP internos a um endereço IP público que escuta nas mesmas portas.

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

O NAT o endereço IP público a dois endereços IP internos, usa dois endereços IP públicos no DNS.

Nenhumas entradas na tabela ARP

Este é um resultado da opção do nenhum-pseudônimo que é usada nas entradas NAT. A opção do nenhum-pseudônimo significa que o roteador não responde para os endereços e não instala uma entrada de ARP. Se um outro roteador usa um conjunto NAT como um conjunto global interno que consista em endereços em uma sub-rede conectada, um pseudônimo é gerado para esse endereço de modo que o roteador possa responder a requisições de protocolo de resolução de endereço (ARP) para aqueles endereços. Isto faz com que o roteador tenha entradas de ARP para os endereços falsificados.

Conclusão

Os problemas acima indicam que a NAT nem sempre é o motivo dos problemas de conectividade do IP. Em muitos casos, a causa é algo a não ser o NAT e exige investigações adicionais. Esse documento explica as etapas básicas a serem executadas durante o Troubleshooting e a verificação da operação do NAT. Essas etapas incluem:

  • Defina claramente que NAT é suposto para conseguir.

  • Verifique que as traduções correspondente existem na tabela de tradução.

  • Use os comandos show and debug verificar que a tradução está ocorrendo.

  • A revisão em detalhe o que está acontecendo ao pacote e verifica que o Roteadores tem a informação de roteamento correto para mover avante o pacote.

Token ruim 0, TOK_NUMBER querido|TOK_PUNCT

Este Mensagem de Erro é apenas um mensagem informativa e não tem nenhum impacto no comportamento normal do dispositivo.

Bad token 0, wanted TOK_NUMBER|TOK_PUNCT

O erro significa que tentativas NAT de fazer um reparo da camada 4 no endereço em um FTP aberto, e não pode encontrar os endereços IP de Um ou Mais Servidores Cisco ICM NT que precise de traduzir no pacote.

A razão pela qual a mensagem inclui tokens é que os endereços IP de Um ou Mais Servidores Cisco ICM NT no pacote estão encontrados procurando um token, ou um grupo de símbolos, no pacote IP, a fim encontrar os detalhes necessários traduzir.

Quando uma sessão de FTP é iniciada, negocia dois canais, um comando channel e um canal de dados. Estes são ambos os endereços IP de Um ou Mais Servidores Cisco ICM NT com números de porta diferentes. O cliente de FTP e o server negociam um segundo canal de dados para transferir arquivos. O pacote trocado através do canal de controle tem o formato “PORTA, i, i, i, i, p, p”, onde i, i, i, i é os quatro bytes de um endereço IP de Um ou Mais Servidores Cisco ICM NT e de um p, p especifica a porta. Tentativas NAT para combinar este teste padrão e para traduzir caso necessário a /porta do endereço. O NAT deve traduzir os métodos de endereçamento de ambos os canais. O NAT faz a varredura para números no córrego do comando até que pense que encontrou um comando port que exija a tradução. Tenta analisar gramaticalmente para fora a tradução, que calcula com o teste padrão como descrita mais cedo.

Se o pacote é corrompido ou o servidor FTP ou o cliente têm comandos malforming, o NAT não pode corretamente calcular a tradução e gera esse erro. Uma sugestão é ajustar o cliente de FTP à “voz passiva” de modo que inicie ambos os canais. Isto ajuda às vezes com o FTP com o NAT.

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.


Informações Relacionadas


Document ID: 8605