I still can't ping the PLC for some reason?
Yes, that makes sense.
The
PC's TCP/IP configuration tells the
PC that the
PC is on subnet
10.10.41.0/255.255.255.0, so when it tries to ping the target
PLC at
10.10.40.60, the the
PC's IP driver does a bitwise and of the
PC's subnet netmask (
255.255.255.0) and the
target of the ping (
10.10.40.60) and gets a subnet result of
10.10.40.0. When it compares that
target PLC's subnet result (
10.10.40.0) with the
PC's own subnet (
10.10.41.0), it sees they are different, and that difference means that the
PC and the
PLC are on logically* different subnets.
Sidebar
That is the key question in understanding IP packet routing: is this packet's target subnet the same as my local (Ethernet) LAN? That question
always has a binary result:
- yes it is, and so the packet can be delivered directly to the target via the target's Ethernet interface on my local subnet.
- no it is not, and so the packet must be sent to the gateway, to which gateway the responsibility for delivering the packet is passed, via the local subnet i.e. Ethernet.
Since they are on different
IP subnets*, the only way for IP traffic to go from the
PC's subnet to the
PLC's subnet is through a gateway.
Gateways manage IP traffic between different subnets.
So if you were sniffing the packets, you would see the PC sending a packet with a destination IP of
10.10.40.60 to the
PC's gateway at
10.10.41.1**. The gateway receives the Ethernet packet from the Ethernet** port that it uses to communicate with the
10.10.41.0, and sees that the packet is destined for a subnet other than
10.10.41.0. The gateway does not know of any subnet that contains
10.10.40.60, so it kicks the can down the road by routing that packet the next gateway's Ethernet down the line, in the hope that that next gateway either knows of the target subnet or has a connection to another gateway (and it's turtles all the way down until TTL hits 0
). However, that is a vain hope because a subnet containing
10.10.40.60 does not exist, and I am guessing your PING command eventually results in several "No route to host" errors.
If you have gotten this far, you may understand what I was trying to do by suggesting that you change the PC's subnet mask to 255.255.254.0:
- The bitwise AND of
- subnet mask 255.255.254.0,
- with the PC's IP address of 10.10.41.xxx
- results in a subnet of 10.10.40.0/255.255.254.0
- Which is the same subnet as the bitwise AND of
- subnet mask 255.255.254.0
- with the target PLC's IP address of 10.10.40.60
- So now the PC will think it is on the same subnet as the PLC, and will attempt to communicate with the PLC via the local Ethernet LAN.
However, if you did get this far, then you will also know why this may not work: the
PLC still has an IP of
10.10.40.60 and netmask of 255.255.255.0 and so the
PLC will think it is on subnet
10.10.40.0/255.255.255.0, and when it tries to reply to a packet from the
PC at
10.10.41.xxx, it will think the packet came from a different subnet, and try to send that packet via a phantom gateway at
10.10.40.1,
which does not exist.
* N.B. It does not matter that the
PC and
PLC are on the same Ethernet LAN i.e. Ethernet broadcast domain; they are configured to be on different
IP subnets.
** actually it would be sent to the Ethernet MAC address of the gateway, because ultimately the PC can only send Ethernet packets, and it can sent those Ethernet packets only to other hosts on the same Ethernet LAN (broadcast domain).