Need quick help with networking question

[Ken Roach]

Thanks for the clarifications.

Allen-Bradley tries to keep you from entering invalid network configurations. The BOOTP/DHCP tool, and RSLinx Classic, will not let you enter an IP Address and Default Gateway that are on different subnets.

If you just clicked through quickly and didn't see an error message that warned you about such a conflict, then the controller *should* still be at the original settings.

The good news is that generation of controller has a USB port through which you can browse with RSLinx Classic and change the IP address, subnet mask, and default gateway.

[TonysControls]

Originally Posted by Ken Roach

Thanks for the clarifications.

Allen-Bradley tries to keep you from entering invalid network configurations. The BOOTP/DHCP tool, and RSLinx Classic, will not let you enter an IP Address and Default Gateway that are on different subnets.

If you just clicked through quickly and didn't see an error message that warned you about such a conflict, then the controller *should* still be at the original settings.

The good news is that generation of controller has a USB port through which you can browse with RSLinx Classic and change the IP address, subnet mask, and default gateway.

Ok so I was able to get into the PLC via USB and I can see its IP

it is 10.10.40.60 and the default gateway is 10.10.40.1 and the Subnet Mask is 255.255.255.0

I still can't ping the PLC for some reason?

[drbitboy]

Originally Posted by TonysControls

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).

[Ken Moore]

Did you change the IP of the laptop to match then new subnet?

[kalabdel]

Originally Posted by drbitboy

Yes, that makes sense.

The PC's TCP/IP configuration...................

Nice work.


This guy has good tutorial on his channel.


Link1
Link2