Re: Controls Engineer (Automation, so not IT) 2 Di...

Hendrix-BWDG · ‎09-14-2022

I am a controls engineer using VMWare to run VM's that hold several legacy versions of Rockwell Software RSLogix and Studio 5000 software for PLC programming. This means that my work requires me to connect to PLC's and other devices over Ethernet connections often, with many unique situations to be found.

In order to use Rockwell's proprietary OPC communications tool, RSLinx, in the VM, the common knowledge of my company is to use a Bridged connection directly to our main physical Ethernet adapter on the Host. It allows us to find devices on a given network more easily and create links for constant communications as needed. NAT does work for external connections, but it confuses RSLinx when run from the VM, which defeats the point of using the VM for all of the legacy programs. In the past (and quite ideally), our customers have given me 2 IP's for my Host and my VM on the same network with a 255.255.255.0 subnet mask. My problem comes with a unique customer situation that leaves me stumped:

My customer has given me two IP addresses (subnet masks in parentheses) that they have spare on their wider controls network:

Host: 10.136.4.65 (255.255.0.0)

VM: 10.136.7.65 (255.255.0.0)

These two work great to access devices on both the 10.136.4.xxx and 10.136.7.xxx network given the proper subnet. My problems come in where there are some devices to which I would like to connect for reference purposes that are on the 10.136.4.xxx network, but they were set up with a 255.255.255.0 subnet mask. I can ping them and see them in RSLinx on my host (obviously, being on the same network regardless of subnet mask), but I cannot do so on my VM. I cannot change their subnet mask settings as I am a contractor, so here is my main question:

In this situation, is there an alternate way to preserve the functionality that a Bridged connection affords me when using RSLinx while also allowing me to connect strictly to the 10.136.4.xxx network alone?

I will ask Rockwell's knowledgebase as well, but I have started here first as it is possibly the simpler answer.

Go easy on me; my networking skills are probably much more rudimentary than what IT power users have.

CarltonR · ‎09-14-2022

Indeed, a head scratcher . . . if I get it right, this is what your setup is (clearly a representation and missing much of the interconnecting infrastructure):

and that . . .

- the 10.136.4.xxx Device/s and the Host can communicate
- the 10.136.7.xxx Device/s and the VM can communicate
- but not between IP subnet ranges

One possibility, would be to ask your customer to issue you with a third IP in the 10.136.4.xxx range and then add another Bridged Virtual Network and present it to the VM.

Note: for the second VMware Bridged network, configure the VM to use the most appropriate subnet mask, 255.255.0.0, 255.255.255.0 or whatever. depending on the scope.

Another, possibility would be to leave your setup as is, and ask your customer to setup a network router route between the two, but I've no idea of your network topology, and as you said, as a contractor . . .

View solution in original post

Hendrix-BWDG · ‎09-14-2022

Thanks for responding!

Yes, what you have looks right. The customer's network is large enough that they mask only the first 2 octets generally, meaning that anything on the 10.136.xxx.xxx network should communicate unless the masks are set up differently in the device's settings, like in my problematic case.

Your answer will work for sure. I have not gotten clearance for another IP on the 10.136.4.xxx subnet as of yet, so I was hoping there was some slicker way to pull it off until I do.

If I don't have any other answers once I get the 2nd IP in the 10.136.4.xxx subnet, I'll mark this as the correct answer for the post.

Thanks, @CarltonR !

Hendrix-BWDG · ‎09-15-2022

I got the 3rd IP, 2nd on the 10.136.4.xxx subnet. It seems like that's just the route that needs to be taken. RSLinx requires a direct connection, so this is the quickest solution. I may still ask on the Rockwell end; if they have something revolutionary, I will post a reply here.

Thanks!

Technogeezer · ‎09-15-2022

Actually IMO they need to fix their broken network. It makes no sense to have some devices with 10.136.4.x IP addresses on a 10.136.0.0/16 (255.255.0.0) subnet and others with a 10.136.4 IP on a 10.136.4.0/24 (255.255.255.0) subnet and expect everything to work correctly. Not without a lot of static routing or entries in the router.

- Paul (Technogeezer)
Editor of the Unofficial Fusion Companion Guides

Controls Engineer (Automation, so not IT) 2 Different Network IP's over Bridged Connection