Options
NAT Trouble...
CompUBug
Member Posts: 46 ■■□□□□□□□□
in CCNA & CCENT
90% of the time when I try to ping PC to PC on my NAT setup it will fail, 10% of the time it will work.
I slowed down the simulation in packet tracer to follow the packet and what happens is when the packet is on the RETURN trip to its destination, when it arrives at that networks switch, it just stops and the switch broadcast STP packets to every PC. Whats wrong here?
I slowed down the simulation in packet tracer to follow the packet and what happens is when the packet is on the RETURN trip to its destination, when it arrives at that networks switch, it just stops and the switch broadcast STP packets to every PC. Whats wrong here?
Comments
-
Optionsfluk3d Member Posts: 141 ■■■□□□□□□□can you post your config?"Imagination is more important than knowledge." - Albert Einstein
-
OptionsCompUBug Member Posts: 46 ■■□□□□□□□□Router 1
Router#show run Building configuration... Current configuration : 741 bytes ! version 12.4 no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption ! hostname Router ! ! ! ! ! ! ! ! ! ! ! ! ! ! spanning-tree mode pvst ! ! ! ! interface FastEthernet0/0 ip address 10.10.10.1 255.255.255.240 ip nat inside duplex auto speed auto ! interface FastEthernet0/1 no ip address duplex auto speed auto shutdown ! interface Serial0/1/0 ip address 176.154.89.1 255.255.255.0 ip nat outside clock rate 2000000 ! interface Vlan1 no ip address shutdown ! ip nat inside source list 1 interface Serial0/1/0 overload ip classless ip route 0.0.0.0 0.0.0.0 Serial0/1/0 ! ! access-list 1 permit 10.10.10.0 0.0.0.255 ! ! ! ! ! line con 0 line vty 0 4 login ! ! ! end
Router 2Router#show run Building configuration... Current configuration : 725 bytes ! version 12.4 no service timestamps log datetime msec no service timestamps debug datetime msec no service password-encryption ! hostname Router ! ! ! ! ! ! ! ! ! ! ! ! ! ! spanning-tree mode pvst ! ! ! ! interface FastEthernet0/0 ip address 192.168.10.1 255.255.255.240 ip nat inside duplex auto speed auto ! interface FastEthernet0/1 no ip address duplex auto speed auto shutdown ! interface Serial0/1/0 ip address 176.154.89.2 255.255.255.0 ip nat outside ! interface Vlan1 no ip address shutdown ! ip nat inside source list 1 interface Serial0/1/0 overload ip classless ip route 0.0.0.0 0.0.0.0 Serial0/1/0 ! ! access-list 1 permit 192.168.10.0 0.0.0.255 ! ! ! ! ! line con 0 line vty 0 4 login ! ! ! end
-
Optionspcgizzmo Member Posts: 127Sounds like the problem is in the switch and not the routers. What is the switch config?
-
OptionsCompUBug Member Posts: 46 ■■□□□□□□□□no configs have been done on the switch. It happens with both switches too - and I have removed / reinstalled the switches as well.
-
Optionsfluk3d Member Posts: 141 ■■■□□□□□□□no configs have been done on the switch. It happens with both switches too - and I have removed / reinstalled the switches as well.
Have you tried deleting the vlan.dat database on the switch and just doing a factory restore?"Imagination is more important than knowledge." - Albert Einstein -
OptionsMAC_Addy Member Posts: 1,740 ■■■■□□□□□□Have you tried deleting the vlan.dat database on the switch and just doing a factory restore?2017 Certification Goals:
CCNP R/S -
OptionsCompUBug Member Posts: 46 ■■□□□□□□□□Just tried that, same results - also added the 176.154.89.0 network to access-list 1... no effect.
-
OptionsMAC_Addy Member Posts: 1,740 ■■■■□□□□□□Try changing the speed/duplex. I've had many problems with them being set on auto.2017 Certification Goals:
CCNP R/S -
Optionsmella060 Member Posts: 198 ■■■□□□□□□□it just stops and the switch broadcast STP packets to every PC. Whats wrong here?
I don't know if this will help, but have you tried configuring spanning tree portfast on the port connected to the PC ? -
Optionsgosh1976 Member Posts: 441packet tracer is buggy. If you start fresh and rebuild the network it will probably work fine.
-
Optionsmbrdmyr Registered Users Posts: 3 ■□□□□□□□□□Where is your NAT pool? I see the access list, but there isnt a pool for it to translate to. If you are, in fact using NAT, you can issue the show ip nat translations command to see if anything is being translated. but if you are not actually using the NAT, then I would check if you have trunk links going to the routers from the switches or the switchport accesses.
And I did notice that someone said that packet tracer is buggy, which is 100% correct. Save what you are working on, close it and reopen, see if that fixes anything. I had trouble deleting a command on a router, when I closed it and reopened it, I was able to delete the command right away.
Good Luck! -
Optionsfluk3d Member Posts: 141 ■■■□□□□□□□Where is your NAT pool? I see the access list, but there isnt a pool for it to translate to. If you are, in fact using NAT, you can issue the show ip nat translations command to see if anything is being translated. but if you are not actually using the NAT, then I would check if you have trunk links going to the routers from the switches or the switchport accesses.
And I did notice that someone said that packet tracer is buggy, which is 100% correct. Save what you are working on, close it and reopen, see if that fixes anything. I had trouble deleting a command on a router, when I closed it and reopened it, I was able to delete the command right away.
Good Luck!
The NAT pool is defined by access list 1 with PAT correct me if I'm wrong"Imagination is more important than knowledge." - Albert Einstein -
Optionsciscoman2012 Member Posts: 313Try changing the speed/duplex. I've had many problems with them being set on auto.
I agree. I've had problems like this where everything looks correct but doesn't work. I'd also hard code the speed (100) and duplex (full) on the switch ports connected to the router as well as the router itself. -
OptionsChevelle Member Posts: 2 ■■■□□□□□□□You access-lists are wrong.
interface FastEthernet0/0 ip address 10.10.10.1 255.255.255.240 ip nat inside duplex auto speed auto ! access-list 1 permit 10.10.10.0 0.0.0.255
interface FastEthernet0/0 ip address 192.168.10.1 255.255.255.240 ip nat inside duplex auto speed auto ! access-list 1 permit 192.168.10.0 0.0.0.255
-
Optionsboredgamelad Member Posts: 365 ■■■■□□□□□□Alright, I dumped this in packet tracer and made a few assumptions. I configured PC1 and PC2 as 10.10.10.2 and 192.168.10.2, respectively. I also assumed you were pinging from PC1's command line to 192.168.10.2.
Here are the translation tables as the first packet passes through both routers. The failure occurs when R1 drops the packet as returned by R2.
R1:Router#show ip nat trans Pro Inside global Inside local Outside local Outside global icmp 176.154.89.1:9 10.10.10.2:9 192.168.10.2:9 192.168.10.2:9
R2:Router#show ip nat trans Pro Inside global Inside local Outside local Outside global icmp 176.154.89.2:9 192.168.10.2:9 176.154.89.1:9 176.154.89.1:9
First, R1 translates 10.10.10.2 to 176.154.89.1. The packet is then forwarded out S0/1/0 with the following source and destination addresses:
Source: 176.154.89.1
Destination: 192.168.1.2
This is important to note because the echo-request that is sent by R1 has a destination of 192.168.1.2, so any echo-replies received should come from that address as well.
Everything will proceed fine until the packet is returned by R2 to R1. When R2 receives the echo-reply from PC2, it translates 192.168.1.2 to 176.154.89.2 and sends a packet out S0/1/0 with the following:
Source: 172.154.89.2
Destination: 172.154.89.1
Do you see the problem? R1 is expecting a reply from 192.168.1.2, but the above packet has a source IP address of 172.154.89.2.
The router tries to match the incoming packet to its NAT translation table. As you can see, there's no entry for 176.154.89.2 on R1's translation table, so it attempts to process it like any normal packet. And, since R1 hasn't sent an echo-request to 176.154.89.2, ICMP drops the echo-reply.
==========
Note that if you're using PT's simulation mode, a really handy tool is to look in the Event List on the upper right side of packet tracer and click on the colored box next to the event you want to examine further. You can then view what happens as the packet is received and passed up/down each layer, at each step of the way. In this instance you'll see the following on layer 3:1. The packet is coming from an outside network. The router looks up its NAT table for necessary translations. 2. The NAT table does not have a matched entry for this packet. It passes the packet through without translations. 3. The destination IP address matches the IP address of one of the interfaces. The router dispatches the packet to the upper layer. 4. The packet is an ICMP packet. The ICMP process processes it. 5. The ICMP process received an Echo Reply message. 6. The ICMP process has not sent an ICMP message with this identification recently. It drops the message.
When I first started my Cisco studies I found this extremely useful for understanding how data is processed at each layer. -
Optionsboredgamelad Member Posts: 365 ■■■■□□□□□□Oh wait, it's failing at the switches for you? Hm, now, that's different than what I'm experiencing.
-
OptionsCompUBug Member Posts: 46 ■■□□□□□□□□boredgamelad wrote: »Oh wait, it's failing at the switches for you? Hm, now, that's different than what I'm experiencing.
Yeah. The Routers forward it just fine BOTH DIRECTIONS but the switches 90% of the time **** the packet and broadcast STP packets to every node and 10% of the time forward the packet to the destination for a successful ping even though I didn't change anything.
I pinged both ways but I used global addresses and not local addresses as if I used a local address it should be dropped as the Router on the opposite side shouldn't know where to find that address (as it should be listed as a global address)