unable to access anything other than ping from behind a cisco 1921 router

[mmarosz1]

Hello, 
I am new to this community, and I am beginning to study for the CCNA exams. I apologize in advance for any 'un-educated' or 'un-necessary' questions, but with that said, I was hoping I could gain some knowledge/guidance with this problem i am having.

:here is the setup: 

I have a test network, and it has a cable modem connected to a netgear SOHO router/switch/wireless ap combo device.

I have my 'main pc', aka pc4, connected to the switch part of the netgear combo device, and it can access the internet (and anything else connected to the same switch) normally. the LAN side of the router part of the netgear combo device has an ip of 192.168.1.1.

Then, I purchased a cisco 1921 router, and I am trying to use it to make 2 separate networks in my test network.

I gave the cisco router's ge0/0 interface a static ip of 192.168.1.50, and I connected it to the switch part of the netgear combo device, .

Then, I gave the cisco router's ge0/1 interface a static ip of 10.10.10.1, and I connected it to a separate (unmanaged) switch.

Then, i connected a test pc, aka pc2, to this unmanaged switch.

:here is the question: 

I cannot access the internet from pc2, and i dont know why.

I thought i needed to setup local static routes from pc4 and pc2, so i did that, but im not sure if that made any difference.

eg, from each pc, and from the router itself (i connected with the serial console port and putty), I can ping each pc and each interface in the router.
but, i can only ping by IP address, not by name.

eg, from pc2, if I ping pc4 by ip address, pc4 replies normally all 4 times.

eg, from pc2, if I ping pc4 by pc name, i get an error, "ping request could not find host pc4", this error only appears once after a pause.

eg, from pc2, if I ping "google.com", in the 4 ping requests that are sent, i get these 2 errors, "request timed out", and "reply from 10.10.10.1: destination host unreachable".

i have read that "destination host unreachable" means a router in the path of the ping to its destination does not have a stored route to the destination, and the router replies with "destination host unreachable".

but then i also read that "request timed out" means that the ping request never got a reply, which may mean that the routers in the path to the destination did have routes to the destination, and they forwarded the ping request, but then something else happened that caused the ping request to get dropped on its return trip.

so, i dont know how i could get both of those errors in the same ping command.

I am quite stumped as to what to do next, and any help would be greatly appreciated.

-michael

[mmarosz1]

Hello Rick,

-I agree that i need to be able to ping successfully from the router before i bother trying to ping from pc2.

-Thank you for that explanation of the things the router does to choose which interface it uses to ping.

-i did not know about the "?", i used the "?", i got some help, and i found i can enter this,

ping google.com source 10.10.10.1

-and then it looked like it sent the ping from 10.10.10.1 instead of 192.168.1.50

-so that must be how that is done!

can i ask you this?

when you say the router checks dns (eg i guess because i asked it to ping a name instead of a number), is there any specific record of that happening, eg in a log file that can be checked anywhere?

-but, the problem with the router not getting on the internet or pinging cisco.com by name or by ip (but somehow still showing the ip as it fails?!),

-i entered this,

ip route 0.0.0.0 0.0.0.0 192.168.1.1

-then i entered this,

show ip route

-and it still says this,

gateway of last resort is not set

-As i see this more clearly, that is a big problem!

-so i entered a "save running-config startup-config" after running all these commands so i would not have to keep re-entering them

-then i restarted the router

==========

-then i entered "show run"

router1#show run
Building configuration...

Current configuration : 5577 bytes
!
version 15.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname router1
!
boot-start-marker
boot-end-marker
!
!
logging buffered 51200 warnings
enable secret 5 $1$yY34$yyXLY/suppuEusq3d7hTs.
enable password 22
!
no aaa new-model
clock timezone GMT -5 0
!
!
!
!
!
!
!
!
!
!
!
ip dhcp excluded-address 10.10.10.1
!
ip dhcp pool ccp-pool
import all
network 10.10.10.0 255.255.255.128
default-router 10.10.10.1
dns-server 192.168.1.100 192.168.1.1
lease 0 2
!
!
!
ip domain name yourdomain.com
ip name-server 192.168.1.1
ip name-server 192.168.1.100
ip cef
no ipv6 cef
multilink bundle-name authenticated
!
cts logging verbose
!
crypto pki trustpoint TP-self-signed-1801969825
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-1801969825
revocation-check none
rsakeypair TP-self-signed-1801969825
!
!
crypto pki certificate chain TP-self-signed-1801969825
certificate self-signed 01
3082022B 30820194 A0030201 02020101 300D0609 2A864886 F70D0101 05050030
31312F30 2D060355 04031326 494F532D 53656C66 2D536967 6E65642D 43657274
69666963 6174652D 31383031 39363938 3235301E 170D3138 30343234 31363232
30385A17 0D323030 31303130 30303030 305A3031 312F302D 06035504 03132649
4F532D53 656C662D 5369676E 65642D43 65727469 66696361 74652D31 38303139
36393832 3530819F 300D0609 2A864886 F70D0101 01050003 818D0030 81890281
810084B7 02BA01D8 6D1AD033 6D97A382 29F88F83 AD830DA0 FAB29F1C 7E2E0AC7
37CA9826 35A600F0 3031622E E3C4698F 33F84748 3F99CEE0 47098CE5 4A9AB4FE
8101A050 A32FF583 2999DEAC E70183BE 8F0D3F89 8CD03F3F 77E17186 FE1B1A15
AC893999 C657DD3F FE1A1182 D1920EE0 A5A0E482 AB17EFC8 D6D3E6A3 47CD82A4
83D10203 010001A3 53305130 0F060355 1D130101 FF040530 030101FF 301F0603
551D2304 18301680 1475D443 08E1D141 483DE73B 264BD53C 0872F7DB 76301D06
03551D0E 04160414 75D44308 E1D14148 3DE73B26 4BD53C08 72F7DB76 300D0609
2A864886 F70D0101 05050003 81810084 44781F37 39C517A5 2A091E35 34275504
A98C7C67 13A6B048 18099424 CD31B613 65D0E711 C3AF7005 BF5CF583 5E5C0DCB
B8A29752 CF1D4560 4DDED09D A001843E 72B83E9B 7063FD00 22B2B2F5 1D2E7800
0BCB0DE6 19596418 81F80C66 3561F076 8FA9AEF9 C774E94F AAEB12E5 E8E44BD2
A3F65D33 CEDD6E87 7ECD0D11 632431
quit
license udi pid CISCO1921/K9 sn FGL2217921M
!
!
username username privilege 15 secret 5 $1$YWxN$UHwecJPTcRRqbBrZc0ONu.
username radmin1 privilege 15 secret 5 $1$iBVn$GV.xMuDzS/Q3nu6kWR6GE.
username q privilege 15 secret 5 $1$xas9$L/cj5QVPtPCM7bElP3qxd.
!
redundancy
!
!
!
!
!
!
interface Embedded-Service-Engine0/0
no ip address
shutdown
!
interface GigabitEthernet0/0
description $ETH-LAN$$ETH-SW-LAUNCH$$INTF-INFO-GE 0/0$
ip address 192.168.1.50 255.255.255.0
ip nat outside
ip virtual-reassembly in
duplex auto
speed auto
no mop enabled
!
interface GigabitEthernet0/1
ip address 10.10.10.1 255.255.255.128
ip nat inside
ip virtual-reassembly in
duplex auto
speed auto
!
ip forward-protocol nd
!
ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 60 life 86400 requests 10000
!
ip nat inside source list 10 interface GigabitEthernet0/0 overload
ip default-network 192.168.1.0
ip default-network 0.0.0.0
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
!
!
access-list 10 permit 10.10.10.0 0.0.0.127
!
control-plane
!
!
banner exec ^C
% Password expiration warning.
-----------------------------------------------------------------------

Cisco Configuration Professional (Cisco CP) is installed on this device
and it provides the default username "cisco" for one-time use. If you have
already used the username "cisco" to login to the router and your IOS image
supports the "one-time" user option, then this username has already expired.
You will not be able to login to the router with this username after you exit
this session.

It is strongly suggested that you create a new username with a privilege level
of 15 using the following command.

username <myuser> privilege 15 secret 0 <mypassword>

Replace <myuser> and <mypassword> with the username and password you want to
use.

-----------------------------------------------------------------------
^C
banner login ^C
-----------------------------------------------------------------------
Cisco Configuration Professional (Cisco CP) is installed on this device.
This feature requires the one-time use of the username "cisco" with the
password "cisco". These default credentials have a privilege level of 15.

YOU MUST USE CISCO CP or the CISCO IOS CLI TO CHANGE THESE PUBLICLY-KNOWN
CREDENTIALS

Here are the Cisco IOS commands.

username <myuser> privilege 15 secret 0 <mypassword>
no username cisco

Replace <myuser> and <mypassword> with the username and password you want
to use.

IF YOU DO NOT CHANGE THE PUBLICLY-KNOWN CREDENTIALS, YOU WILL NOT BE ABLE
TO LOG INTO THE DEVICE AGAIN AFTER YOU HAVE LOGGED OFF.

For more information about Cisco CP please follow the instructions in the
QUICK START GUIDE for your router or go to http://www.cisco.com/go/ciscocp
-----------------------------------------------------------------------
^C
!
line con 0
exec-timeout 0 0
login local
line aux 0
line 2
no activation-character
no exec
transport preferred none
transport output pad telnet rlogin lapb-ta mop udptn v120 ssh
stopbits 1
line vty 0 4
privilege level 15
password 11
login local
transport input telnet ssh
line vty 5 15
privilege level 15
password 11
login local
transport input telnet ssh
!
scheduler allocate 20000 1000
!
end

router1#

==========

[mmarosz1]

in case this information is helpful, i ran these nat, ping, and arp commands, too, 

again, i did this immediately after restarting the router

===========

router1#
router1#show ip nat statistics
Total active translations: 8 (0 static, 8 dynamic; 8 extended)
Peak translations: 12, occurred 00:00:24 ago
Outside interfaces:
GigabitEthernet0/0
Inside interfaces:
GigabitEthernet0/1
Hits: 121 Misses: 0
CEF Translated packets: 0, CEF Punted packets: 28
Expired translations: 30
Dynamic mappings:
-- Inside Source
[Id: 1] access-list 10 interface GigabitEthernet0/0 refcount 8

Total doors: 0
Appl doors: 0
Normal doors: 0
Queued Packets: 0
router1#
router1#
router1#show ip nat translation
Pro Inside global Inside local Outside local Outside global
tcp 192.168.1.50:53162 10.10.10.2:53162 13.35.78.7:443 13.35.78.7:443
tcp 192.168.1.50:53164 10.10.10.2:53164 13.35.78.33:443 13.35.78.33:443
tcp 192.168.1.50:53166 10.10.10.2:53166 13.249.183.36:443 13.249.183.36:443
tcp 192.168.1.50:53168 10.10.10.2:53168 13.35.78.7:443 13.35.78.7:443
tcp 192.168.1.50:53170 10.10.10.2:53170 13.249.183.45:443 13.249.183.45:443
tcp 192.168.1.50:53172 10.10.10.2:53172 13.35.78.48:443 13.35.78.48:443
udp 192.168.1.50:53570 10.10.10.2:53570 192.168.1.1:53 192.168.1.1:53
udp 192.168.1.50:56103 10.10.10.2:56103 192.168.1.1:53 192.168.1.1:53
udp 192.168.1.50:56860 10.10.10.2:56860 192.168.1.1:53 192.168.1.1:53
router1#

===========

router1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.10.1 - 700f.6a90.6e21 ARPA GigabitEthernet0/1
Internet 10.10.10.2 0 b4b5.2fcd.6f06 ARPA GigabitEthernet0/1
Internet 13.35.78.72 0 Incomplete ARPA
Internet 13.249.183.36 0 Incomplete ARPA
Internet 13.249.183.45 0 Incomplete ARPA
Internet 13.249.183.83 0 Incomplete ARPA
Internet 192.168.1.1 3 10da.431d.3e0b ARPA GigabitEthernet0/0
Internet 192.168.1.50 - 700f.6a90.6e20 ARPA GigabitEthernet0/0
Internet 192.168.1.100 0 Incomplete ARPA
router1#
router1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
router1#
router1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.10.1 - 700f.6a90.6e21 ARPA GigabitEthernet0/1
Internet 10.10.10.2 0 b4b5.2fcd.6f06 ARPA GigabitEthernet0/1
Internet 13.35.78.33 0 Incomplete ARPA
Internet 13.35.78.72 0 Incomplete ARPA
Internet 13.249.183.36 0 Incomplete ARPA
Internet 13.249.183.45 0 Incomplete ARPA
Internet 13.249.183.67 0 Incomplete ARPA
Internet 192.168.1.1 4 10da.431d.3e0b ARPA GigabitEthernet0/0
Internet 192.168.1.50 - 700f.6a90.6e20 ARPA GigabitEthernet0/0
Internet 192.168.1.100 0 Incomplete ARPA
router1#
router1#ping cisco.com
Translating "cisco.com"...domain server (192.168.1.1) [OK]

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 72.163.4.185, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
router1#
router1#show arp
Protocol Address Age (min) Hardware Addr Type Interface
Internet 10.10.10.1 - 700f.6a90.6e21 ARPA GigabitEthernet0/1
Internet 10.10.10.2 0 b4b5.2fcd.6f06 ARPA GigabitEthernet0/1
Internet 13.35.78.7 0 Incomplete ARPA
Internet 13.35.78.48 0 Incomplete ARPA
Internet 13.249.183.67 0 Incomplete ARPA
Internet 13.249.183.83 0 Incomplete ARPA
Internet 72.163.4.185 0 Incomplete ARPA
Internet 192.168.1.1 4 10da.431d.3e0b ARPA GigabitEthernet0/0
Internet 192.168.1.50 - 700f.6a90.6e20 ARPA GigabitEthernet0/0
router1#

===========

-i dont know how to thank you enough in words for your replies, they are very helpful

-michael

[Richard Burts]

Michael

As I look at the results of testing that you post I am puzzled to see addresses in your translation table and in the arp table that are not in your network

tcp 192.168.1.50:53162 10.10.10.2:53162 13.35.78.7:443 13.35.78.7:443
tcp 192.168.1.50:53164 10.10.10.2:53164 13.35.78.33:443 13.35.78.33:443
tcp 192.168.1.50:53166 10.10.10.2:53166 13.249.183.36:443 13.249.183.36:443
tcp 192.168.1.50:53168 10.10.10.2:53168 13.35.78.7:443 13.35.78.7:443
tcp 192.168.1.50:53170 10.10.10.2:53170 13.249.183.45:443 13.249.183.45:443
tcp 192.168.1.50:53172 10.10.10.2:53172 13.35.78.48:443 13.35.78.48:443

Internet 13.35.78.7 0 Incomplete ARPA
Internet 13.35.78.48 0 Incomplete ARPA
Internet 13.249.183.67 0 Incomplete ARPA
Internet 13.249.183.83 0 Incomplete ARPA
Internet 72.163.4.185 0 Incomplete ARPA

Do you have any insight into what they are?

[Richard Burts]

Michael

Thank you for the update. You ask if there is any specific record of the DNS lookup happening and I can answer that in two ways:

- for one thing look at this output

router1#ping cisco.com
Translating "cisco.com"...domain server (192.168.1.1) [OK]

the second line does, in fact, document the DNS lookup being done.

- the other way that I would answer is that it does matter whether there are any logs, or messages associated with the command, what really matters is whether the command has an IP address to work with. If there is an IP address then that is the proof that the DNS lookup was successful. 

As a side note I would offer this comment that when someone describes a problem as (for example) I can not access google.com, many of us immediately think in terms of the problem being some routing issue, or access list issue, or something like that. We need to remember that before we can do any routing we must have an IP address. If the DNS lookup is not successful then our access to the resource is going to fail. So the first step in investigating issues such as this should be to verify the DNS is working.

I am puzzled that the output still is saying that gateway of last resort is not set. I am wondering about these two commands

ip default-network 192.168.1.0
ip default-network 0.0.0.0

I would not think that they cause any issue. But you do not need them and I suggest that you remove them and then post the output of show ip route so that we can see the result. (you would remove them by using these

no ip default-network 192.168.1.0
no ip default-network 0.0.0.0

One other suggestion is that at least while we are investigating that you change the syslog level from warnings to debug. As you look at the logs there might be some information that could be helpful.

[mmarosz1]

Hello Rick,

it seems that getting rid of these lines fixed the problem!

ip default-network 192.168.1.0

ip default-network 0.0.0.0

I removed them, i ran "show ip route", and this time it showed a gateway of last resort.

..thank you for clarifying the syntax for removing them, too, i am beginning to see some of the method behind the ios syntax.

Then i could ping cisco.com from the router, and from pc2, and I could get on the internet normally from pc2.

Here is the show ip route after removing those lines:

==========

router1#show ip route

Codes: L - local, C - connected, S - static, 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

       i - IS-IS, su - IS-IS summary, 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, H - NHRP, l - LISP

       a - application route

       + - replicated route, % - next hop override

Gateway of last resort is 192.168.1.1 to network 0.0.0.0

S*    0.0.0.0/0 [1/0] via 192.168.1.1

      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks

C        10.10.10.0/25 is directly connected, GigabitEthernet0/1

L        10.10.10.1/32 is directly connected, GigabitEthernet0/1

      192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks

C        192.168.1.0/24 is directly connected, GigabitEthernet0/0

L        192.168.1.50/32 is directly connected, GigabitEthernet0/0

router1#

==========

I don't know where those 2 lines came from.

I don't know how else they could have gotten in the startup config unless I entered them at some point.

Is there any other way they could have gotten into the startup config unless i entered them?

If there is no other way they could have gotten into the config file, then I must have entered them at the command prompt at some point thinking it would help, or they were the result of me trying to use the GUI web-based interface thing.

Either way, I am grateful for those lines being there because they helped show me how useful the show run command is.

note: i found the "show running-config | include whatever" option, which is very nice when checking the running config or the startup config.

eg, i can enter "show running-config | include default-", and then see just the lines i'm looking for.

So this problem is solved, and i cannot thank you enough. There was more than one thing in that solution....why have i not joined this forum earlier?!

However, i don't know what to do next,

1. not only do i not want this conversation to end, but
2. i'm having other problems i'm hoping i can continue this post for, or make other posts for, and
3. I want to provide the information you asked for too.

-so i'm going to put the other problems, and that more detail in separate posts, eg, to try to keep each post under a mile long.

[mmarosz1]

-these are the several other problems that have appeared:

==========

(this is not a problem)

The router interface can ping anything on the internet by ip or by name.

pc2 can ping anything on the internet by ip or by name.

pc4 can ping anything on the internet by ip or by name.

==========

(this is not a problem)

pc2 can ping pc4 by ip, and this is the output:

C:\>ping 192.168.1.21 -n 2

Pinging 192.168.1.21 with 32 bytes of data:

Reply from 192.168.1.21: bytes=32 time=1ms TTL=127

Reply from 192.168.1.21: bytes=32 time=1ms TTL=127

==========

(this is a problem)

pc2 cannot ping pc4 by name, the error is:

Ping request could not find host home-pc4. Please check the name and try again.

==========

(this is a problem)

pc4 cannot ping pc2 by name, the error is:

Ping request could not find host win10-pc2. Please check the name and try again.

==========

(this is a problem, i think...)

pc4 cannot ping pc2 by ip in the same way that pc2 can ping pc4 by ip.

when pc4 pings pc2 by ip, the error is/was:

request timed out

-but then i tried again, and then the ping worked (and i could not recreate the "request timed out" error)?!

-im thinking the request timed out error is not worth thinking about more now, BUT...its worth noting that i was using a regular command prompt and i had cleared the screen several times, so i could not just look back in the log and see if that had actually happened.

If i had used a 'router approach', i would have been able to do that!

Either way, even though the ping from pc4 to pc2 seems to be working, this was the output:

-notice how this is not like when pc2 pings pc4.

-when pc4 pings pc2, the reply is from 192.168.1.50 instead of from 10.10.10.2.

C:\>ping 10.10.10.2 -n 2

Pinging 10.10.10.2 with 32 bytes of data:

Reply from 192.168.1.50: bytes=32 time=1ms TTL=127

Reply from 192.168.1.50: bytes=32 time=1ms TTL=127

Ping statistics for 10.10.10.2:

    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 1ms, Maximum = 1ms, Average = 1ms

==========

note: the same thing happens when pc4 tries to ping the router's 10.10.10.1 interface

here is that output:

C:\>ping 10.10.10.1 -n 2

Pinging 10.10.10.1 with 32 bytes of data:

Reply from 192.168.1.50: bytes=32 time=1ms TTL=255

Reply from 192.168.1.50: bytes=32 time=1ms TTL=255

Ping statistics for 10.10.10.1:

    Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 1ms, Maximum = 1ms, Average = 1ms

==========

[mmarosz1]

About the addresses in the show ip nat translation table and the show arp table that were not on any of my networks:

I don't know what they are exactly.

It seems they have something to do with "Amazon content delivery network".

Does this output shed any light on that?

Before fixing the problem, from pc4 i pinged, and ran nslookup and tracert on the first one of those unknown ip addresses, and this is what i got:

C:\>ping 13.35.78.7

Pinging 13.35.78.7 with 32 bytes of data:

Reply from 13.35.78.7: bytes=32 time=20ms TTL=244

Reply from 13.35.78.7: bytes=32 time=14ms TTL=244

Reply from 13.35.78.7: bytes=32 time=13ms TTL=244

Reply from 13.35.78.7: bytes=32 time=17ms TTL=244

Ping statistics for 13.35.78.7:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

Approximate round trip times in milli-seconds:

    Minimum = 13ms, Maximum = 20ms, Average = 16ms

C:\>nslookup 13.35.78.7

Server:  UnKnown

Address:  192.168.1.1

Name:    server-13-35-78-7.bos50.r.cloudfront.net

Address:  13.35.78.7

C:\>tracert 13.35.78.7

Tracing route to server-13-35-78-7.bos50.r.cloudfront.net [13.35.78.7]

over a maximum of 30 hops:

  1    <1 ms    <1 ms    <1 ms  192.168.1.1

  2     8 ms     9 ms     7 ms  96.120.66.245

  3    11 ms     7 ms     8 ms  96.108.103.81

  4     9 ms    13 ms     9 ms  be-327-ar01.chartford.ct.hartford.comcast.net [96.108.71.181]

  5    13 ms    13 ms    14 ms  be-2-ar01.needham.ma.boston.comcast.net [68.87.147.149]

  6    13 ms    12 ms    13 ms  be-1003-pe02.onesummer.ma.ibone.comcast.net [68.86.90.173]

  7    14 ms    14 ms    13 ms  23.30.206.34

  8     *        *        *     Request timed out.

  9     *        *        *     Request timed out.

 10     *        *        *     Request timed out.

 11     *        *        *     Request timed out.

 12     *        *        *     Request timed out.

 13     *        *        *     Request timed out.

 14     *        *        *     Request timed out.

 15    13 ms    13 ms    13 ms  server-13-35-78-7.bos50.r.cloudfront.net [13.35.78.7]

Trace complete.

C:\>

-then i googled "cloudfront.net", and google said " Amazon CloudFront is a fast content delivery network (CDN) service "

-then, on the router, i (accidentally) typed "ipconfig" (i thought i was typing on the other computer's keyboard?!) and hit enter, and it said this:

==========

router1#ipconfig

Translating "ipconfig"...domain server (192.168.1.1) [OK]

Trying ipconfig.yourdomain.com (54.221.207.100)...

% Connection timed out; remote host not responding

router1#

==========

-so i did nslookup with that ip from pc4, and it said this:

C:\>nslookup 54.221.207.100

Server:  UnKnown

Address:  192.168.1.1

Name:    ec2-54-221-207-100.compute-1.amazonaws.com

Address:  54.221.207.100

==========

So, could it be that the ping from my cisco router got past my netgear router to some other router on my isp's network (my isp is xfinity/comcast cable), and my isp uses amazon web services?

Would the arp cache on the netgear router be helpful?

i looked on the netgear router for a way to see it's arp cache, but i could not find a way to do that with its interface.

i looked online for a way to do that, and one post in a netgear forum mentioned getting that functionality after upgrading the router's firmware, but to be cautious, i dont want to do that to that router, so unfortunately that may prevent answering this question fully.

this is the arp cache from the cisco router after removing those 2 default-network lines.

There are no longer any unknown ip addresses in it

==========

router1#show ip arp

Protocol  Address          Age (min)  Hardware Addr   Type   Interface

Internet  10.10.10.1              -   700f.6a90.6e21  ARPA   GigabitEthernet0/1

Internet  10.10.10.2              3   b4b5.2fcd.6f06  ARPA   GigabitEthernet0/1

Internet  192.168.1.1             0   10da.431d.3e0b  ARPA   GigabitEthernet0/0

Internet  192.168.1.50            -   700f.6a90.6e20  ARPA   GigabitEthernet0/0

Internet  192.168.1.100           0   Incomplete      ARPA

router1#

==========

There are still many unknown ip addresses showing up in the nat translation table, especially after going on internet sites.

Is that normal?

Is it helpful to figure out what these ip addresses are (it seems there is varying degrees of worth in just about everything)?

note: i ran "show ip nat translation" before going to an internet site, and then again after going to an internet site.

here is that output:

==========

router1#show ip nat translation

Pro Inside global      Inside local       Outside local      Outside global

tcp 192.168.1.50:58538 10.10.10.2:58538   52.242.211.89:443  52.242.211.89:443

udp 192.168.1.50:63430 10.10.10.2:63430   192.168.1.1:53     192.168.1.1:53

router1#

router1#

router1#

router1#show ip nat translation

Pro Inside global      Inside local       Outside local      Outside global

udp 192.168.1.50:49297 10.10.10.2:49297   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:49298 10.10.10.2:49298   172.217.6.227:443  172.217.6.227:443

udp 192.168.1.50:49388 10.10.10.2:49388   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:49770 10.10.10.2:49770   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:50134 10.10.10.2:50134   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:50497 10.10.10.2:50497   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:50692 10.10.10.2:50692   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:50884 10.10.10.2:50884   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:50966 10.10.10.2:50966   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:50967 10.10.10.2:50967   172.217.11.34:443  172.217.11.34:443

udp 192.168.1.50:51204 10.10.10.2:51204   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:51205 10.10.10.2:51205   172.217.10.66:443  172.217.10.66:443

udp 192.168.1.50:51292 10.10.10.2:51292   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:51440 10.10.10.2:51440   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:52280 10.10.10.2:52280   192.168.1.1:53     192.168.1.1:53

udp 192.168.1.50:52281 10.10.10.2:52281   172.217.10.66:443  172.217.10.66:443

udp 192.168.1.50:52536 10.10.10.2:52536   192.168.1.1:53     192.168.1.1:53

 --More--

==========

[mmarosz1]

About the logging of any dns events question:

regarding these lines:

router1#ping cisco.com

Translating "cisco.com"...domain server (192.168.1.1) [OK]

You point out that the 2nd line that says "translating...OK" is just like an entry in a log file.

I never thought about it like that, but now that you mention it, it is right there!

You mentioned the syslog level being set to warnings or debug.

I have to find out more about that.

It seems it could help answer my DNS questions, or at least help me 'see/frame' the questions better!

To make sure I understand the importance of the "translating...OK" line,

Before i removed the [default-network] lines and i was having the problems from pc2, when i tried to ping anything remote, it would not always have the "translating...OK" line.

Does the absence of that line always mean the dns lookup failed?

eg, if i had not already pinged a certain URL, it seemed to always show the "translating...OK" line, and then the ping would fail.

But then if i pinged the same URL a 2nd time, the ping would still fail, but it would not also show the "translating...OK" line.

Is that difference important, and it is always a definitive yes or no to the "did a dns lookup take place" question?

eg, this is that output:

==========

router1#ping google.com

Translating "google.com"...domain server (192.168.1.1) [OK]

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.217.12.142, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

router1#

router1#

router1#

router1#ping google.com

Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 172.217.12.142, timeout is 2 seconds:

.....

Success rate is 0 percent (0/5)

router1#

==========

Its hard to pin point the exact question, but I think I see a point you are making when you point out 'main types' of problems to look for.

eg,

-is there an ACL?

-are DNS servers and clients configured correctly?

-is a DNS lookup being attempted?

-if it a DNS lookup did happen, did it get an IP address?

-then routing can begin/continue...

It's a lot to think about (let alone type!).

Your reminder/insight into separating connection problems into separate 'stages' rang a loud bell about what ive read about dns, and im going to (..do my best to) remember that.

I guess my first question would be about the importance of the presence or absence of the "translating...OK" line.

::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::

other than all that, i tried to help too by posting a possible (at least partial) answer to someone else's post about the cisco packet tracer program (i just started using that)...

...and I anxiously await your reply!

I'm on the verge of seeing a complete picture of a small routed network, and that will be invaluable when taking the next step!

thank you again,

Michael

::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::: ::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::::::::::::::::::

[Richard Burts]

Michael

Addressing some of your questions:

- you asked this

I guess my first question would be about the importance of the presence or absence of the "translating...OK" line.

You were asking for something that demonstrated that DNS lookup was being done. This line is the easy way to demonstrate this. On its own I would not consider this line to be particularly important. And the more important proof I would suggest is that when you issue the command ping <some name> and what comes back is sending ping to <IP address> then you have proof that DNS is working. But if that line were missing then it would not necessarily mean that there was a problem with DNS. In fact you provide a very good observation

eg, if i had not already pinged a certain URL, it seemed to always show the "translating...OK" line, and then the ping would fail. But then if i pinged the same URL a 2nd time, the ping would still fail, but it would not also show the "translating...OK" line.

So I would say that presence of "translating...OK" is proof for DNS and its absence is not necessarily a sign of a problem.

- you ask about logging levels. Cisco has 7 levels of severity for log messages ranging from very critical to informational, and debugging. People will sometimes set the logging level to a higher level so that they do not see as many messages, and this is more common on devices in production networks, and especially when the log messages are being sent to a logging server in the network. I believe that for someone trying to learn about networking the more messages you may see the better, and especially we need to see all available messages when we are investigating something that is not working.

[Richard Burts]

Michael

Addressing some questions from another of your posts:

- There are addresses in the nat translation table and the arp table that are outside of your network. That would be common in the translation table and not common in the arp table. Generally the arp table would be addresses that are locally connected. Remember that one of the basic behaviors of a host in an IP network is that when sending to a locally connected device you arp for it and when sending to a remote device you send it to your default gateway. So remote address in the arp table are not usual. I believe that the explanation about this is based on the default network commands that you removed. Remember that the show ip route output showed the default route specifying the interface and not the next hop. The result of this is that the router treated all remote addresses as if they were locally connected on that interface, and so it arped for them all. So in a sense having remote addresses in the arp table was a hint about what the problem was. And note that after removing the default network commands that the remote addresses in the arp table went away.

- you did a very logical (and effective) investigation of those addresses to determine that they related to the Amazon content delivery network. Good for you!

- you ask if the arp cache on the netgear would be useful. I do not believe that it would. In looking at the issue we tried to localize where the problem was, and pretty clearly the problem was on the 1921 router. So seeing the arp cache from netgear was not relevant. 

- you ask if it would have been helpful to know where the remote addresses were. While it was interesting to discover that they related to Amazon, I do not believe that this fact was actually important to identifying the issue. It was important to know that there were remote addresses where there should not be. But not especially important to know where those addresses were.

[Richard Burts]

Michael

Trying to clear up the last of the questions in your posts.

- there is a problem that neither pc can ping the other pc by name. Clearly this is an issue with DNS resolution. Am I correct in remembering that the pc are configured to get their DNS from 192.168.1.1 and 192.168.1.100 (and that 192.168.1.100 is not operating at this point)? So an important question is whether 192.168.1.1 has a DNS entry for win10-pc2 and for home-pc4? The secondary question would be when 192.168.1.100 is in service will it have entries for those names?

- what appears to be a problem when pc4 pings pc2 is really not a problem. Remember that you have configured the router so that any traffic from the 10.10.10.0 network going out the 192.168.1.50 interface gets translated. So the ping from pc4 gets to pc2 and pc2 generates a response, and the response source address gets translated. So the ping really is working ok.

If it bothers you that the source address of the response is not what you expect, or if there is some other reason why you really want the source address to not get translated if it is going to something in the 192.168.1.0 network the address translation can be changed. It makes the configuration of address translation slightly more complex. As currently configured the access list used to control address translation says that all traffic with source address in 10.10.10.0 gets translated. We would need to remove that access list and create a new extended access list which would deny all traffic from 10.10.10.0 to 192.168.1.0 and then permit all traffic from 10.10.10.0 to any address.

[Richard Burts]

Thanks for the update. I am glad to know that removing those 2 lines fixed the problem. It is hard to know for sure how they got into the config. It is possible that something in the gui inserted them. It is possible that you inserted them when you saw a reference to them in some documentation. I would say that it is not especially important how they got into the config and more important that it is working now.

You are asking other questions which I will respond to later.

[mmarosz1]

that's awesome, Rick, thank you! 

[mmarosz1]

Hello Rick, 
I am posting this because i know it has been a couple days and I do not want you to think I am not going to reply.

I start a new full time job this Friday (I just got the call today)! and today I spent a

lot of time thanking people who have helped me find this job. 

I am going to get to that as soon as time allows tomorrow.

I have found out several things working with each pc's hosts files, and i found i cannot control the netgear router's dns server, and that (along with the fact that it can only do nat for the 192.168.1.0 network and not also the 10.10.10.0 network) seems to limit what i can do.

and i am not sure if the cisco router can be a dns server, and i have not setup the win2016 server as a dns server yet.

-Michael

[Richard Burts · Accepted solution]

Michael

Congratulations on the new job. I hope it works out well for you. Take your time thinking about the issues we have been discussing and when appropriate you can post again. For followup on these things you can continue this discussion. But at some point it might be good to start a new discussion. As discussions get longer it becomes more difficult to keep the context clear and in a new discussion there is more possibility that other participants might offer their comments. And if you do start a new discussion you can use the private message capability to send me a link to the new discussion so that I can be sure to engage in it.

It is quite common for the Internet Service Provider equipment to do address translation only for the subnet of the connected device. And quite common that the ISP device would not provide DNS resolution for your locally connected devices. So it is a normal practice that you would do address translation on your router for your other subnets. You can configure the router to act as a DNS server. And if you have only a few devices you want to resolve names for it could be appropriate to do that on the router. But as the local network gets larger and more complex it would be better to have DNS on some device other than your router.