Analiza przypadku 1
Rys. 1. pokazuje, że ping z hostów PC1 i PC2 w sieci 192.168.0.0/16 do serwerów Svr1 i Svr2 w sieci zewnętrznej, zakończył się niepowodzeniem.
Aby rozpocząć rozwiązywanie problemu należy wydać polecenie show ip nat translations , aby zobaczyć, czy w tabeli NAT znajdują się jakieś translacje. Wynik na rys. 1 pokazuje, że w tabeli nie ma żadnych translacji.
Polecenie show ip nat statistics jest używane do określania, czy jakiekolwiek translacje miały miejsce. Identyfikuje także interfejsy, pomiędzy którymi translacja powinna się odbywać. Jak pokazano w wyniku na rys. 2, liczniki NAT są ustawione na 0, co oznacza brak wystąpienia jakichkolwiek translacji. Porównując wynik z topologią przedstawioną na rys. 1, należy zauważyć, że interfejsy routera są niepoprawnie zdefiniowane jako "NAT inside" lub "NAT outside". Niepoprawną konfigurację można także zweryfikować przy użyciu polecenia show running-config .
Przed zastosowaniem poprawnej konfiguracji, bieżąca konfiguracja interfejsu NAT powinna zostać skasowana z interfejsu.
Po poprawnym zdefiniowany interfejsów: wewnętrznego (NAT inside) i zewnętrznego (NAT outside), kolejny ping z PC1 do Svr1 nie dochodzi. Użycie polecenia show ip nat translations oraz show ip nat statistics po raz kolejny wskazuje na to, że w dalszym ciągu nie dochodzi do jakichkolwiek translacji.
Jak pokazano na rys. 3, użycie polecenia show access-lists pozwala określić, czy ACL w komendzie NAT dopuszcza wszystkie potrzebne sieci. Badanie wyniku wskazuje na to, że użyto niewłaściwej maski blankietowej w ACL definiującej adresy podlegające translacji. Maska blankietowa przepuszcza wyłącznie podsieć 192.168.0.0/24. Lista dostępowa powinna najpierw zostać usunięta a następnie skonfigurowana z użyciem właściwej maski blankietowej.
Po poprawieniu konfiguracji, kolejny ping wysłany z PC1 do Svr1 wraca pomyślnie. Jak pokazano na rys. 4, polecenia show ip nat translations oraz show ip nat statistics są tu wykorzystane do zweryfikowania, czy zachodzą translacje.