Solved: Can ping a host but not a network from a PC.

StefanStefanR · ‎08-23-2023

Hello! Routers with red arrow are the ones that are using a basic static

default route of 0.0.0.0

to their respective neighbors. D1,D2,D3 are iBGP connected with no additional of

next-hop-self or update-source

commands. D2 and OfficeA-1 routers are connected via OSPF. OfficeA-1 is working like an OSPF Stub, sharing its connected routes with D2. D2 has redistributed OSPF routes into the iBGP but only 2 networks (VLAN 100 and VLAN 150) since these are the only networks with hosts inside, so

route-map

was used.

D3 has a static address towards OfficeB-2's network of

10.255.255.0/26

and D1 has a static route towards C3's network

192.168.3.0/24

Now I tested the pings and everything is working just fine. All routers can ping each other and each other's networks. So connectivity is totally fine.

Now the issues are the PC's themselves. Every PC can ping each other, e.g. PC4 from Vlan 150 can ping

PC6 10.255.255.1

address. PC4 can even ping the router's

default gateway

of each network BUT if PC4 tries to ping

10.255.255.0

network, it fails.

Same thing happens with LAN D network. PC's can ping the LAN D host which is

192.168.3.100

they can even ping the

default gateway of 192.168.3.1

BUT they cannot ping

192.168.3.0

network at all while their Routers actually can!

Is this a normal thing to happen when you are using static addresses that routers can ping every network but hosts PC's cannot ping a network of a static router BUT can ping a host inside? I am asking this because I may be asked this question in the future and I want to understand the best answer here to this problem.

An example code of what I get:

PC6> ping 192.168.100.1
84 bytes from 192.168.100.1 icmp_seq=1 ttl=252 time=8.179 ms
84 bytes from 192.168.100.1 icmp_seq=2 ttl=252 time=12.533 ms
84 bytes from 192.168.100.1 icmp_seq=3 ttl=252 time=10.613 ms
84 bytes from 192.168.100.1 icmp_seq=4 ttl=252 time=12.242 ms
84 bytes from 192.168.100.1 icmp_seq=5 ttl=252 time=10.556 ms

PC6> ping 192.168.100.0
192.168.100.0 icmp_seq=1 timeout
192.168.100.0 icmp_seq=2 timeout
192.168.100.0 icmp_seq=3 timeout
192.168.100.0 icmp_seq=4 timeout
192.168.100.0 icmp_seq=5 timeout

PC3> ping 10.255.255.0
10.255.255.0 icmp_seq=1 timeout
10.255.255.0 icmp_seq=2 timeout
10.255.255.0 icmp_seq=3 timeout
10.255.255.0 icmp_seq=4 timeout
10.255.255.0 icmp_seq=5 timeout

PC3> ping 10.255.255.1
10.255.255.1 icmp_seq=1 timeout
10.255.255.1 icmp_seq=2 timeout
84 bytes from 10.255.255.1 icmp_seq=3 ttl=60 time=39.897 ms
84 bytes from 10.255.255.1 icmp_seq=4 ttl=60 time=31.810 ms
84 bytes from 10.255.255.1 icmp_seq=5 ttl=60 time=29.574 ms

PC5> trace 10.255.255.1
trace to 10.255.255.1, 8 hops max, press Ctrl+C to stop
1 192.168.100.1 7.612 ms 42.945 ms 32.440 ms
2 10.10.100.2 25.112 ms 21.262 ms 13.278 ms
3 10.10.13.1 18.409 ms 20.546 ms 13.097 ms
4 10.10.14.2 30.443 ms 31.517 ms 23.095 ms
5 *10.255.255.1 25.539 ms (ICMP type:3, code:3, Destination port unreachable)

David Ruess · ‎08-23-2023

What you are seeing is likely normal behavior. When you ping the network address from the local device then al devices with IPs in that network will respond because they are a apart of that network. You wont be able to ping the network address from any other remote site or device because it doesn't sit on the local network.

I don't foresee any questions on an exams asking this.

You you could provide the output of a successful network ping from a router we may be able to help further.

-David

View solution in original post

David Ruess · ‎08-23-2023

What you are seeing is likely normal behavior. When you ping the network address from the local device then al devices with IPs in that network will respond because they are a apart of that network. You wont be able to ping the network address from any other remote site or device because it doesn't sit on the local network.

I don't foresee any questions on an exams asking this.

You you could provide the output of a successful network ping from a router we may be able to help further.

-David

StefanStefanR · ‎08-23-2023

Thank you for the response!

Yes that makes a lot of sense, I didn't think about it. All pings from every router are working and even if source is changed;

I noticed that only

Traceroute

command isn't working. The command ends when it reaches D3 router, my guess is that OfficeB-2 doesn't know how to respond to this so it sends a packet back to

default 0.0.0.0

and we see this result? Other than that, pings seem to be working just fine.

Since I understood this from what you said about static behavior, I had ran into another problem. I don't know if I should open another topic but I'll try to stick to this because it's a small issue.

My DHCP on OfficeA-1 is not working properly. It adds the address to

PC5 vlan 100

but it doesn't want to give IP address to

PC4 in vlan 150

Everything is configured as it should be. This was tested in Cisco packet tracer and worked without issues. But in GNS3 this is "half" working.

These are the commands used on OfficeA-1 router:

ip dhcp excluded-address 192.168.100.1 192.168.100.99
ip dhcp excluded-address 192.168.150.1 192.168.150.223
!
ip dhcp pool VLAN-100
network 192.168.100.0 255.255.255.0
default-router 192.168.100.1
!
ip dhcp pool VLAN-150
network 192.168.150.0 255.255.255.0
default-router 192.168.150.1
!

!
interface GigabitEthernet0/1.99
encapsulation dot1Q 99 native
ip address 192.168.99.1 255.255.255.0
!
interface GigabitEthernet0/1.100
encapsulation dot1Q 100
ip address 192.168.100.1 255.255.255.0
!
interface GigabitEthernet0/1.150
encapsulation dot1Q 150
ip address 192.168.150.1 255.255.255.0
!

This is what router is saying once "debug ip dhcp server packet" command is turned on:

*Aug 24 00:45:07.471: DHCPD: client's VPN is .
*Aug 24 00:45:07.472: DHCPD: No option 125
*Aug 24 00:45:07.472: DHCPD: Option 125 not present in the msg.
*Aug 24 00:45:07.472: DHCPD: DHCPDISCOVER received from client 0100.5079.6668.02 on interface GigabitEthernet0/1.150.
*Aug 24 00:45:07.472: DHCPD: Option 125 not present in the msg.
*Aug 24 00:45:07.473: DHCPD: Allocate an address without class information (192.168.150.0)
*Aug 24 00:45:07.476: DHCPD: Saving workspace (ID=0x3C000003)

*Aug 24 00:45:08.482: DHCPD: New packet workspace 0xE2B78A8 (ID=0x9A000004)
*Aug 24 00:45:08.482: DHCPD: client's VPN is .
*Aug 24 00:45:08.482: DHCPD: No option 125
*Aug 24 00:45:08.483: DHCPD: Option 125 not present in the msg.
*Aug 24 00:45:08.483: DHCPD: DHCPDISCOVER received from client 0100.5079.6668.02 on interface GigabitEthernet0/1.150.
*Aug 24 00:45:08.483: DHCPD: Option 125 not present in the msg.
*Aug 24 00:45:09.474: DHCPD: Reprocessing saved workspace (ID=0x3C000003)
*Aug 24 00:45:09.474: DHCPD: Option 125 not present in the msg.
*Aug 24 00:45:09.475: DHCPD: DHCPDISCOVER received from client 0100.5079.6668.02 on interface GigabitEthernet0/1.150.

*Aug 24 00:45:09.475: DHCPD: Option 125 not present in the msg.
*Aug 24 00:45:09.475: DHCPD: Sending DHCPOFFER to client 0100.5079.6668.02 (192.168.150.225).
*Aug 24 00:45:09.476: DHCPD: Option 125 not present in the msg.
*Aug 24 00:45:09.476: DHCPD: no option 125
*Aug 24 00:45:09.476: DHCPD: src nbma addr as zero
*Aug 24 00:45:09.477: DHCPD: creating ARP entry (192.168.150.225, 0050.7966.6802, vrf default).
*Aug 24 00:45:09.478: DHCPD: unicasting BOOTREPLY to client 0050.7966.6802 (192.168.150.225).

*Aug 24 00:45:11.462: DHCPD: client's VPN is .
*Aug 24 00:45:11.462: DHCPD: No option 125
*Aug 24 00:45:11.463: DHCPD: Option 125 not present in the msg.
*Aug 24 00:45:11.463: DHCPD: DHCPDISCOVER received from client 0100.5079.6668.02 on interface GigabitEthernet0/1.150.
*Aug 24 00:45:11.463: DHCPD: Option 125 not present in the msg.
*Aug 24 00:45:11.464: DHCPD: Sending DHCPOFFER to client 0100.5079.6668.02 (192.168.150.225).
*Aug 24 00:45:11.464: DHCPD: Option 125 not present in the msg.
*Aug 24 00:45:11.465: DHCPD: no option 125
*Aug 24 00:45:11.465: DHCPD: src nbma addr as zero
*Aug 24 00:45:11.465: DHCPD: ARP entry exists (192.168.150.225, 0050.7966.6802).

*Aug 24 00:45:11.466: DHCPD: unicasting BOOTREPLY to client 0050.7966.6802 (192.168.150.225).

As you can see from the message, he wants to give him .225 instead of .224 which is the first available. Sometimes message states it's .224.

Switch_3 config:

interface GigabitEthernet0/0
switchport access vlan 150
switchport mode access
media-type rj45
negotiation auto
spanning-tree portfast edge
!
interface GigabitEthernet0/1
switchport trunk encapsulation dot1q
switchport trunk native vlan 99
switchport mode trunk
media-type rj45
negotiation auto
!
interface GigabitEthernet0/2
switchport access vlan 100
switchport mode access
media-type rj45
negotiation auto
spanning-tree portfast edge
!

interface Vlan99
ip address 192.168.99.2 255.255.255.0
!
interface Vlan100
no ip address
!
interface Vlan150
no ip address
!
ip default-gateway 192.168.99.1
ip forward-protocol nd
!

Truly sorry for a huge reply message!

David Ruess · ‎08-23-2023

Hmmmm,

I have not seen that one before.

Can you provide the output of the command:

show interfaces GigabitEthernet0/1.150 | incl bia

If that doesn't yield results then try it with the interface and not subinterface.

-David

StefanStefanR · ‎08-24-2023

Hello, This is the output of your command;

I was thinking that maybe HDD used in these VIOS are not the right type? I had to for an example, change the HDD disk interface to

Virtio

from "none" for the Switch devices because they weren't saving VLAN configuration at all on

startup-config

command.

Okay, I somehow did fix this DHCP issue. For some reasons now when I excluded only

192.168.150.1 192.168.150.99 instead of 192.168.150.223, dhcp

works. I have no clue why .223 is not working.

Now both PC4 and PC5 have a connection. I tried to change back to

192.168.150.223

and no, this is where it crashes. The only issue here is that PC5 gets the 100th address but PC4 always gets .101 no matter what. Router doesn't want to give him the .100 which is the next usable one. But this is okay by me, I don't mind it. I checked the arp table because maybe it's saved there but no.

I think this is GNS3 issue with the vm's of devices or something else. Like, yesterday I had a trouble configuring a iBGP. For some reasons D1 router had a rib-failure of his directly connected links with a message: ''higher admin distance''. He didn't report his direct links with

0.0.0.0 as a next-hop

but rather with the neighbor ip addresses. So I had to remove the whole bgp from each router and restart the process again and now it's working fine.

David Ruess · ‎08-24-2023

Glad you were able to get it resolved. Sucks you had to rebuild the lab but I guess it helps whit practice.