What happens when pinging a subnet address?

[roesch4alc]

Hello!

I´m wondering, what actually happens when someone is pinging a subnetwork address. For example 192.168.0.0 (Network=192.168.0.0/24). From the networks perspective, what can one expect, when doing this? Always no answer? What could be the reason/explanation, if certain devices are replying? In this case, the ping is initiated from a different network connected via Routers.

Thanks.

[Jaderson Pessoa]

Hello,

If someone is pinging from a subnetwork from a different network. Both networks will use their own gateways to send this traffic. If they have route to establish connection both will have successfull on the anwser (without firewall/acl to control traffic of course).

But if they are at the same network, they will use own broadcast to attempt looking for a device that is able to respond the request.

[roesch4alc]

Hello,

did you read my question carefully? I asked, what happens when I ping not a host in the subnet, but the subnet address itself.

Thanks.

[Richard Burts]

I believe that this is what will happen:

- some device in a remote subnet executes ping 192.168.0.0 and since the destination is remote it sends the IP packet to its default gateway.

- that gateway device looks in its routing table for an entry for 192.168.0.0 and makes the appropriate forwarding decision.

- routers along the path look in their routing table for an entry for 192.168.0.0 and make appropriate forwarding decisions.

- the ping request arrives at the router where 192.168.0.0/24 is a locally connected subnet.

- since there is not any device with address 192.168.0.0 there is no response to the ping request.

It would be a different situation if the ping were to the subnet broadcast address. But since the question was clearly about ping to the subnet address the answer is that there is no response.

HTH

Rick

[Jaderson Pessoa]

If you ping in subnet itself you will have response, for exemple:


your network is: 192.168.1.0/24

NETWORK ADDRESS
192.168.0 255.255.255.0 << PING HERE WILL WORK
FIRST VALID IP ADDRESS
192.168.1.1 255.255.255.0

LAST VALID IP ADDRESS
192.168.1.254 255.255.255.0

BROADCAST
192.168.1.255 255.255.0 << PING HERE WILL WORK

BOTH PINGS WILL RESPOND TO YOU.

Looks this exemple:

interface Vlan6
description 9th Floor Vlan
ip address 172.17.157.1 255.255.255.0

SW11#ping 172.17.157.0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.157.0, timeout is 2 seconds:

Reply to request 0 from 172.17.157.176, 1 ms
Reply to request 0 from 172.17.157.4, 3 ms
Reply to request 0 from 172.17.157.171, 1 ms
Reply to request 0 from 172.17.157.195, 1 ms


SW11#ping172.17.157.255
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.157.255, timeout is 2 seconds:

Reply to request 0 from 172.17.157.176, 1 ms
Reply to request 0 from 172.17.157.4, 4 ms
Reply to request 0 from 172.17.157.171, 1 ms
Reply to request 0 from 172.17.157.99, 1 ms
Reply to request 0 from 172.17.157.195, 1 ms
Reply to request 0 from 172.17.157.249, 1 ms
Reply to request 0 from 172.17.157.204, 1 ms

[Richard Burts]

@Jaderson Pessoa presents some interesting results of ping from a switch to the local subnet address. Can you clarify whether this is a real Cisco Catalyst switch or is some one of the emulators? If a Cisco Catalyst then which one? Do you get the same results if you ping a network address of a subnet that is remote to this switch (not a subnet that is locally connected on this switch)?

I know that historically some devices treated the network address as a broadcast address. It appears that this switch has that behavior. I find it interesting that the ping results are different when the ping is to the network address 172.17.157.0 receives 4 responses while ping to the broadcast address 172.17.157.255 receives 7 responses. So some devices on this subnet have the behavior of treating the network address as a broadcast address and some do not. 

If this switch does forward a ping to a remote network subnet address, then the question becomes what will the remote router do? Does the remote router have the behavior of treating the network address as a broadcast?  Would it would take a ping request from a remote source to the local subnet address and forward it to the local subnet? And part of that consideration would be on the remote router whether ip directed-broadcast is enabled or not.

HTH

Rick

[Jaderson Pessoa]

@Richard Burts 

@Jaderson Pessoa presents some interesting results of ping from a switch to the local subnet address. Can you clarify whether this is a real Cisco Catalyst switch or is some one of the emulators? If a Cisco Catalyst then which one? Do you get the same results if you ping a network address of a subnet that is remote to this switch (not a subnet that is locally connected on this switch)?

R: This is a real device, it is our core switch that manage our network, C9300, if i ping from other switch the network management locally (network and broadcast) i get response. 

I know that historically some devices treated the network address as a broadcast address. It appears that this switch has that behavior. I find it interesting that the ping results are different when the ping is to the network address 172.17.157.0 receives 4 responses while ping to the broadcast address 172.17.157.255 receives 7 responses. So some devices on this subnet have the behavior of treating the network address as a broadcast address and some do not. 

R: This is a few part of the result, i get more information about, but i just copy party of them. Look an other test in other model.

MYPLSW05#show ver | inc Cisco
Cisco IOS Software, C2960X Software (C2960X-UNIVERSALK9-M), Version 15.2(2)E8, RELEASE SOFTWARE (fc1)
Copyright (c) 1986-2018 by Cisco Systems, Inc.

MYPLSW05#show ip int bri | ex un
Interface IP-Address OK? Method Status Protocol
Vlan26 172.17.156.90 YES NVRAM up up
SAOPLCASW05#show run int vlan 26
Building configuration...

Current configuration : 66 bytes
!
interface Vlan26
ip address 172.17.156.90 255.255.255.192
end

MYPLSW05#ping 172.17.156.64
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.156.64, timeout is 2 seconds:

Reply to request 0 from 172.17.156.65, 21 ms
Reply to request 0 from 172.17.156.73, 21 ms
Reply to request 0 from 172.17.156.74, 21 ms
Reply to request 0 from 172.17.156.72, 21 ms
Reply to request 0 from 172.17.156.70, 21 ms
Reply to request 1 from 172.17.156.72, 3 ms
Reply to request 1 from 172.17.156.71, 17 ms
Reply to request 1 from 172.17.156.81, 3 ms
Reply to request 1 from 172.17.156.68, 3 ms
Reply to request 1 from 172.17.156.88, 3 ms
Reply to request 1 from 172.17.156.78, 3 ms
Reply to request 1 from 172.17.156.98, 3 ms
Reply to request 1 from 172.17.156.93, 3 ms
Reply to request 1 from 172.17.156.76, 3 ms
Reply to request 1 from 172.17.156.77, 3 ms
Reply to request 1 from 172.17.156.86, 3 ms
Reply to request 1 from 172.17.156.65, 3 ms
Reply to request 1 from 172.17.156.70, 3 ms
Reply to request 1 from 172.17.156.74, 3 ms
Reply to request 1 from 172.17.156.73, 3 ms
Reply to request 2 from 172.17.156.72, 14 ms
Reply to request 2 from 172.17.156.78, 14 ms
Reply to request 2 from 172.17.156.98, 14 ms
Reply to request 2 from 172.17.156.71, 14 ms
Reply to request 2 from 172.17.156.68, 14 ms
Reply to request 2 from 172.17.156.81, 14 ms
Reply to request 2 from 172.17.156.93, 14 ms
Reply to request 2 from 172.17.156.76, 14 ms
Reply to request 2 from 172.17.156.77, 14 ms
Reply to request 2 from 172.17.156.88, 14 ms
Reply to request 2 from 172.17.156.86, 14 ms
Reply to request 2 from 172.17.156.65, 14 ms
Reply to request 2 from 172.17.156.70, 14 ms
Reply to request 2 from 172.17.156.73, 14 ms
Reply to request 2 from 172.17.156.74, 14 ms
Reply to request 3 from 172.17.156.72, 14 ms
Reply to request 3 from 172.17.156.71, 14 ms
Reply to request 3 from 172.17.156.78, 14 ms
Reply to request 3 from 172.17.156.98, 14 ms
Reply to request 3 from 172.17.156.81, 14 ms
Reply to request 3 from 172.17.156.93, 14 ms
Reply to request 3 from 172.17.156.76, 14 ms
Reply to request 3 from 172.17.156.86, 14 ms
Reply to request 3 from 172.17.156.77, 14 ms
Reply to request 3 from 172.17.156.88, 14 ms
Reply to request 3 from 172.17.156.68, 14 ms
Reply to request 3 from 172.17.156.65, 14 ms
Reply to request 3 from 172.17.156.74, 14 ms
Reply to request 3 from 172.17.156.73, 14 ms
Reply to request 3 from 172.17.156.70, 14 ms
Reply to request 4 from 172.17.156.74, 4 ms
Reply to request 4 from 172.17.156.76, 14 ms
Reply to request 4 from 172.17.156.77, 7 ms
Reply to request 4 from 172.17.156.93, 4 ms
Reply to request 4 from 172.17.156.81, 4 ms
Reply to request 4 from 172.17.156.98, 4 ms
Reply to request 4 from 172.17.156.71, 4 ms
Reply to request 4 from 172.17.156.78, 4 ms
Reply to request 4 from 172.17.156.86, 4 ms
Reply to request 4 from 172.17.156.88, 4 ms
Reply to request 4 from 172.17.156.68, 4 ms
Reply to request 4 from 172.17.156.65, 4 ms
Reply to request 4 from 172.17.156.70, 4 ms
Reply to request 4 from 172.17.156.73, 4 ms
Reply to request 4 from 172.17.156.72, 4 ms

MYPLSW05#ping 172.17.156.127
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.17.156.127, timeout is 2 seconds:

Reply to request 0 from 172.17.156.65, 7 ms
Reply to request 0 from 172.17.156.81, 7 ms
Reply to request 0 from 172.17.156.73, 7 ms
Reply to request 0 from 172.17.156.70, 7 ms
Reply to request 0 from 172.17.156.74, 7 ms
Reply to request 0 from 172.17.156.78, 7 ms
Reply to request 0 from 172.17.156.72, 7 ms
Reply to request 0 from 172.17.156.86, 7 ms
Reply to request 0 from 172.17.156.76, 7 ms
Reply to request 0 from 172.17.156.71, 7 ms
Reply to request 0 from 172.17.156.98, 7 ms
Reply to request 0 from 172.17.156.93, 7 ms
Reply to request 0 from 172.17.156.88, 7 ms
Reply to request 0 from 172.17.156.77, 7 ms
Reply to request 0 from 172.17.156.68, 7 ms
Reply to request 1 from 172.17.156.72, 3 ms
Reply to request 1 from 172.17.156.93, 10 ms
Reply to request 1 from 172.17.156.86, 7 ms
Reply to request 1 from 172.17.156.98, 3 ms
Reply to request 1 from 172.17.156.76, 3 ms
Reply to request 1 from 172.17.156.71, 3 ms
Reply to request 1 from 172.17.156.78, 3 ms
Reply to request 1 from 172.17.156.81, 3 ms
Reply to request 1 from 172.17.156.88, 3 ms
Reply to request 1 from 172.17.156.68, 3 ms
Reply to request 1 from 172.17.156.77, 3 ms
Reply to request 1 from 172.17.156.65, 3 ms
Reply to request 1 from 172.17.156.74, 3 ms
Reply to request 1 from 172.17.156.70, 3 ms
Reply to request 1 from 172.17.156.73, 3 ms
Reply to request 2 from 172.17.156.70, 3 ms
Reply to request 2 from 172.17.156.93, 7 ms
Reply to request 2 from 172.17.156.98, 7 ms
Reply to request 2 from 172.17.156.71, 7 ms
Reply to request 2 from 172.17.156.78, 3 ms
Reply to request 2 from 172.17.156.86, 3 ms
Reply to request 2 from 172.17.156.76, 3 ms
Reply to request 2 from 172.17.156.81, 3 ms
Reply to request 2 from 172.17.156.68, 3 ms
Reply to request 2 from 172.17.156.77, 3 ms
Reply to request 2 from 172.17.156.88, 3 ms
Reply to request 2 from 172.17.156.65, 3 ms
Reply to request 2 from 172.17.156.72, 3 ms
Reply to request 2 from 172.17.156.74, 3 ms
Reply to request 2 from 172.17.156.73, 3 ms
Reply to request 3 from 172.17.156.70, 1 ms
Reply to request 3 from 172.17.156.71, 25 ms
Reply to request 3 from 172.17.156.93, 4 ms
Reply to request 3 from 172.17.156.88, 4 ms
Reply to request 3 from 172.17.156.81, 4 ms
Reply to request 3 from 172.17.156.78, 4 ms
Reply to request 3 from 172.17.156.76, 4 ms
Reply to request 3 from 172.17.156.98, 4 ms
Reply to request 3 from 172.17.156.77, 4 ms
Reply to request 3 from 172.17.156.86, 4 ms
Reply to request 3 from 172.17.156.68, 4 ms
Reply to request 3 from 172.17.156.65, 4 ms
Reply to request 3 from 172.17.156.72, 4 ms
Reply to request 3 from 172.17.156.73, 4 ms
Reply to request 3 from 172.17.156.74, 4 ms
Reply to request 4 from 172.17.156.72, 3 ms
Reply to request 4 from 172.17.156.93, 7 ms
Reply to request 4 from 172.17.156.76, 7 ms
Reply to request 4 from 172.17.156.81, 7 ms
Reply to request 4 from 172.17.156.71, 3 ms
Reply to request 4 from 172.17.156.78, 3 ms
Reply to request 4 from 172.17.156.98, 3 ms
Reply to request 4 from 172.17.156.77, 3 ms
Reply to request 4 from 172.17.156.88, 3 ms
Reply to request 4 from 172.17.156.86, 3 ms
Reply to request 4 from 172.17.156.68, 3 ms
Reply to request 4 from 172.17.156.65, 3 ms
Reply to request 4 from 172.17.156.73, 3 ms
Reply to request 4 from 172.17.156.70, 3 ms
Reply to request 4 from 172.17.156.74, 3 ms

Always i get result pinging my network address and broadcast address. :)

[Jaderson Pessoa]

If this switch does forward a ping to a remote network subnet address, then the question becomes what will the remote router do? Does the remote router have the behavior of treating the network address as a broadcast? Would it would take a ping request from a remote source to the local subnet address and forward it to the local subnet? And part of that consideration would be on the remote router whether ip directed-broadcast is enabled or not.

R: This you explain to us.. In this case it wont work. Just if this request is locally.

[roesch4alc]

Indeed, an interesting result. Are this 4 devices: 

172.17.157.176
172.17.157.4
172.17.157.171
172.17.157.195

that replied to your echo request all of the same type? Are these labelprinters accidentally? I see something similiar in my environment. All devices are zebra printers in my case, answering my ping to the subnet address.

Thanks

[Richard Burts]

This question has gone in an interesting direction. The original question was about a ping to the subnet address sourced from a device in a remote subnet. Without knowing anything about the platforms involved, I based my original response on the currently accepted interpretation of the subnet address which leads to my suggestion that there would be no response. But as the discussion has progressed it is clear that we are dealing with some devices whose IP stack does not share that interpretation of the subnet address. There are many different implementations of the code for the IP stack, some more modern and treating the subnet address in one way, and some implementations that still use the older interpretation of the subnet address as a broadcast address for the subnet. So one of the lessons here is that when we are discussing behaviors in our networks, that we need to be aware that some devices may have behaviors that are different from what we expect.

In recognition of that I would change my earlier explanation of the behavior at the point that the ping request reaches the router where the subnet is locally connected. And I would explain that router behavior as follows:

- the router receives the ping request from the remote source and determines how to handle it as follows

** will the ping be treated in the modern way where the subnet address is just an address (is there any entry in the arp table for this address) and if there are arp responses then the ping will be forwarded and responses may be generated.

** will the ping be treated as a possible broadcast address? In which case the router should evaluate whether directed broadcast is enabled or not. If directed broadcast is enabled then the ping request would be forwarded as a local broadcast and responses may be generated. If directed broadcast is not enabled then the ping should not be forwarded.

HTH

Rick

[roesch4alc]

Actually, the question was quite global to get an answer for the behaviour when pinging a subnet address. I just explained that I tested it from a remote network, because I had no other device in the desintation network itself.

I´´ve never heard about the implementation of TCP/IP, that a stack is treating the subnet as broadcast address. In which TCP/IP Version / RFC was it like that? In which year was it implemented like this? Where to find documents about it? I mean how could it be compatible, when they´rem not talking the same language?

What would you expect what happens on an ASA with pretty current software installed, when pinging the subnet address where this ASA itself is the default gateway?

For these subnet addresses, there is no ARP entry. Please keep in mind, only certain devices, are replying to this.... In this case only Zebra Printers.

Thanks for all your efforts.

[Richard Burts]

This discussion has gone in a very interesting (and unexpected) direction. You asked a question that you intended to be broadly based about behavior when pinging the subnet address (but in reality based on behaviors in your network that seem not to be compliant with RFC based behavior). I offered an explanation based on RFC compliant implementation. @Jaderson Pessoa offered discussion of devices whose behavior (at least on locally connected subnets) seems not to be compliant with RFC. You have added discussion about some printers in your network whose behavior seems not to be compliant with RFCs. 

You ask for references to RFCs discussing use of the network address as a broadcast address. I do not believe that there are any RFCs that discuss this. It was a behavior observed in the early evolution of TCP/IP networking (and apparently still present in the TCP/IP stack of some devices in current networks). I believe that one important take away of this discussion is that while we can have discussions of what is the expected behavior in networks based on best practices (of the RFCs), that when we look at behaviors in our operating networks we should be aware of the very real possibility some of our network devices may not adhere to the RFC based behaviors. 

HTH

Rick

[Jaderson Pessoa]

This were request trough the CORE switch, pinging to network and brocast locally. If this task is locally will work without problem, but if you do it trough different network wont work. :)

[Richard Burts]

@Jaderson Pessoa Thank you for the additional information. Thank you for confirming that the switch with this behavior is a Cisco 9300. I am a bit surprised that a Cisco switch like the 9300 would have this behavior. But your evidence is pretty clear that it does. I find it sort of interesting that it works to ping the subnet address on locally connected subnets but does not work on remote subnets (which is the behavior that I expected).

HTH

Rick

[Jaderson Pessoa]

@Richard Burts  Thank you bro, I really apreciate your explations, i just  wanted to add this bit of information about network and broadcast address behavior under locally. 

Thank you :)