PM866 in RNRP monitor through NE870
Hello,
I have test environment with AS/CS/DC server NE870 and PM866 controller. NE870 splitting client/server network from control network. I managed to configure NE870 so I am able to to ping controller from the server, I am able to connect controller in the OPC server and even load application and go online.
For some reason, I am not able to see the controller in RNRP network status tool on the server. Is this normal behaviour or am I missing something here?
AS/CS/DC
IP:172.16.4.11 /22
GW:172.16.4.141
NE870
IP:172.16.4.141 /22, 172.16.80.141 /22
Routes:
C>* 127.0.0.0/8 is directly connected, lo
C>* 172.16.4.0/22 is directly connected, vlan101
C>* 172.16.80.0/22 is directly connected, vlan210
C>* 172.17.4.0/22 is directly connected, vlan102
C>* 172.17.80.0/22 is directly connected, vlan211
C>* 192.168.8.0/24 is directly connected, vlan1
PM866
IP:172.16.80.154 /22
Thank you
Ondrej
Answers
Try probing the controller (and NE870) with the RNRP Utility.
Use the "Get settings" and "Get network map" commands and post the results here.
Not likely, but possible scenario:
a) a bad RNRP Base Address or other explicit parameters set in controller is hindering RNRP from starting.
b) controller has NE870 set as default gateway (and know how to respond on ping & accept download)
To use implicit adressing mode in controller, only fill in IP address and mask on Eth1 and Eth2, leave all other fields at default (except for Eth2 Enable which must be true)
So, please find screenshots with config below and also enclosed NE870 configuration (.cfg file from download center, just added some FW rules). I did everything you suggested, but I can still see only the server in RNRP monitor. I tried to delete default GW, but I lost connection to controller immediately, so I put it back.
One more thing I forgot to mention, AS/CS/DC server is a VM running in VMware Workstation Player on my laptop, using Bridged connection directly to the physical network. Could maybe this cause the problem?
Any additional suggestions will be much appreciated. Thank you
RNRP

IGMP

IP Forwarding

Controller

Eth1

Eth2

And yes, I am running the VM on an ABB laptop with McAfee, but I am not able to turn it off. Need to check with our IT.

tcpdump vlan101

tcpdump vlan210

-> The virtual machine "reach out".
However, the NE870's own multicasts must also reach the virtual machine on the inside of VMware Workstation.
That traffic is subject to be blocked by a firewall running in the laptop.
The ABB MCE McAfee firewall can be temporarily disabled, at least on my laptop.

Followup on this topic. We are currently trying to implement the solution on site. Layout has changed a bit. I will try my best to describe the issues we are having. I will start with the first one and if we manage to solve it I will post next issue.
We have 2 redundant NE870 FW/routers. They have only 3 ports connected:
Port 1/1 - Connection to primary client server network (VLAN 101 - IP: 172.16.4.141/22 and 172.16.4.142/22)
Port 1/2 - Connection to secondary client server network (VLAN 102 - IP: 172.17.4.141/22 and 172.17.4.142/22)
Port 1/3 - Configured as trunk for VLANs: 210,211,1610,1620,1710,1720
More information in attached pictures.
The issue is, that in RNRP one NE870 has on the trunk interface (Port 1/3) only primary paths up and other NE870 has only secondary paths up. However, if we disconnect cable from port 1/3 on either NE870, on the other NE870 both paths are UP.
I turned off FW packet filtering for the testing.
If you need any additional info please let me know.








Does ping from NE870 work?
ROUTER101:/#> show iface
Press Ctrl-C or Q(uit) to quit viewer, Space for next page, <CR> for next line.
Interface Name Oper Address/Length MTU MAC/PtP Address
---------------- ---- ------------------ ----- ---------------------------
lo UP 127.0.0.1/8 16436 N/A
vlan1 UP DISABLED 1500 00:00:23:1f:6c:64
vlan1011 UP 172.16.4.101/22 1500 00:00:23:1f:6c:62
vlan1012 UP 172.17.4.101/22 1500 00:00:23:1f:6c:63
vlan2201 UP 172.16.80.101/22 1500 00:00:23:1f:6c:68
vlan2202 UP 172.17.80.101/22 1500 00:00:23:1f:6c:6c
vlan2211 UP 172.16.84.101/22 1500 00:00:23:1f:6c:67
vlan2212 UP 172.17.84.101/22 1500 00:00:23:1f:6c:6b
vlan2221 UP 172.16.88.101/22 1500 00:00:23:1f:6c:66
vlan2222 UP 172.17.88.101/22 1500 00:00:23:1f:6c:6a
vlan2231 UP 172.16.92.101/22 1500 00:00:23:1f:6c:65
vlan2232 UP 172.17.92.101/22 1500 00:00:23:1f:6c:69
------------------------------------------------------------------------------
ROUTER101:/#> ping iface vlan2201 172.16.80.102
Press Ctrl-C to abort PING 172.16.80.102 (172.16.80.102): 56 data bytes
64 bytes from 172.16.80.102: seq=0 ttl=64 time=4.197 ms
64 bytes from 172.16.80.102: seq=1 ttl=64 time=0.241 ms
64 bytes from 172.16.80.102: seq=2 ttl=64 time=0.221 ms
^C
--- 172.16.80.102 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.221/1.553/4.197 ms
We can finally see PM866 in the RNRP. Multicasts could not get through customer's infrastructure, so we bypassed it and it works now. We just get "No data from node" message on some nodes as you can see on the picture. Any ideas what can cause that? It is not the same on all nodes. From AS there is only PM866 with no data from node message, but on other nodes there are also interfaces from secondary NE870.
Add new comment