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

Comments (0) New comment

ondrej.petras Rank: 694

Asked 2 years ago

Answer this question Follow

Answers

Should work.

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)

Comments (0) New comment

Stefan Stromqvist AKS expert

Rank: 1

Answered 2 years ago

Hi Stefan,

Thank you for your reply. Please see screenshots with additional information below.

Thank you
Ondrej

Comments (1) New comment

ondrej.petras Rank: 694

Answered 2 years ago

Hello Stefan,

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

Comments (1) New comment

ondrej.petras Rank: 694

Answered 2 years ago

NE870-config-FWrules.txt

IGMP on VLANs is disabled. I tried to connect with putty and running tcpdump and there seems to be some communication running, but I am not able to tell if that's how it should behave, could you clarify, please?
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

Comments (0) New comment

ondrej.petras Rank: 694

Answered 2 years ago

The capture from vlan101 of the NE870 display healthy (periodic, every 1 second) multicasts from 172.16.4.11.
-> 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.

Comments (0) New comment

Stefan Stromqvist AKS expert

Rank: 1

Answered 2 years ago

I cannot turn it off as it requires password, but you are right, just checked a log and it is blocking UDP communication on port 2423. So I guess that's it. I will try to solve it with IT and I will let you know how it went. Anyway, thank you very much for your support. Cheers

Comments (0) New comment

ondrej.petras Rank: 694

Answered 2 years ago

Hi Stefan,

So I requested temp password for my McAfee and turned the FW off once I got it. Everything works now. Let me thank you one more time for your support.

Comments (1) New comment

ondrej.petras Rank: 694

Answered 2 years ago

Hello Stefan,

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.

Comments (3) New comment

by Stefan Stromqvist AKS expert

Rank: 1 on 2/10/2020 8:15:56 AM | Like (0) | Report

1) You are running old firmware. Download and upgrade to NEOS v4.24.1 from ABB Library.

2) VLAN separation is OK to use to reduce the number of physical networks, but never use the same Ethernet interface for both primary and secondary paths.

3) If you must trunc the traffic, please assign two separate trunc ports
a) one for primary paths (VLAN1610, VLAN1620 and VLAN210) and
b) another for secondary paths (VLAN1710, VLAN1720 and VLAN211)

The truncing reduces separation. A multicast storm on VLAN1610 may cause trouble for the other VLANs on the same Ethernet port. If possible, do not trunc traffic (but I can see the use of it, e.g. if these areas are remotely located and you have few fibers going there). In any case, you should have two fibers so that primary and secondary paths are kept separated (the main idea of RNRP - keep things separated to increase robustness).

Remember: the Network Status Tool report "reachability", not a network map with ports.

The third column (Dist/Ra/Rn) tells you how the "row" is reached. As you can see, all remote areas are at distance 1 (one jump over the NE870) and reported with 141 as the primary router (142 will only be taken in effect if 141 go down). So the yellow marked rows (with Primary path is missing) are seen with the view of node 141 alone. The first yellow row says "I (Area 1 node 12) cannot reach the primary path of Area 2 node 142 via my preferred router, Area 1 node 141".

Please change to use at least four interfaces of the NE870, two for the own area (Area 1) and another two for the other areas (Areas 2, 5 and 20).

Make sure IGMP is turned off on all these VLANs.

There is a presentation error in the RNRP Network Status tool which will be corrected in a future release. Try pinging the down interface, if ping works it is likely that you are affected by the presentation error. An even better tool is tracert (Traceroute).

I have two routers to subnet 80 (Area 20), 101 and 102. This is how trace route to the secondary router's secondary interface looks like in traceroute (substitute 101/102 with 141 and 142 in your case)

C:\> tracert 172.16.80.102

Tracing route to 172.16.80.102 over a maximum of 30 hops

1 <1 ms <1 ms <1 ms 172.16.4.101
2 6 ms <1 ms <1 ms 172.16.80.102

Trace complete.

Ergo: the ping to the secondary router's "other side" is travelling via the primary router.

There is another quirk you need to know if you are using 6.1; when pinging a secondary network interface, the secondary router is used.

C:\> tracert 172.17.80.101

Tracing route to 172.17.80.101 over a maximum of 30 hops

1 2 ms <1 ms <1 ms 172.17.4.102
2 3 ms <1 ms <1 ms 172.17.80.101

Notice the difference in choice of router!

Please feed back your comments after updating to the recent firmware and assigning separate interfaces for primary and secondary network.

by ondrej.petras Rank: 694 on 2/10/2020 9:13:01 AM | Like (0) | Report

Hi Stefan,

Thank you for your answer. I will update to newest firmware tomorrow when I'm at work.

In regards of using 1 trunk interface for 6 VLANs. This is because NE870 has only 3 ports that are 1Gb. The rest is only 100 Mb and customer insists, they want to use 1Gb ports only. That is because behind the NE870s is customer's infrastructure (passive optical network with ONTs, OLT, and splitters) and according to customer, their device will not communicate on 100Mb network.
Their infrastructure is another topic for later. This is a datacenter and it has been a nightmare so far.

by Stefan Stromqvist AKS expert

Rank: 1 on 2/10/2020 11:33:21 AM | Like (0) | Report

I ***strongly*** advise against running Primary and Secondary paths over same Ethernet Interface or media.

A better choice would to put the NE870s ”on the other side”, still between your four areas, but with no trunking or sharing of Ethernet interfaces.

Besides the above, please upgrade and use the tracert tool to try to reach the ports reported ”down”. Return with the results.

Add new comment

ondrej.petras Rank: 694

Answered 1 year ago

As for now, I cannot change port assignments. I am not present at site and it will have to be discussed with customer first. But anyway, I updated firmware to 4.24.1 and here is what you asked for. I can already see from tracert, that primary VLANs (210, 1610, 1710) are accessed through first NE870 and secondary VLANs (211, 1620, 1720) through second NE870. I suspect, that the issue it is because of customer's infrastructure behind the NE870. Whenever we are trying to reach secondary VLAN interface on first NE870, it goes through second NE870 and cannot reach it through customer's infrastructure. And vice versa for primary VLAN interfaces on second NE870. Am I right? I have attached topology drawing for you to have better understanding how it is connected. For now, I would take under consideration only area 20 (VLANs 210, 211).

Comments (1) New comment

ondrej.petras Rank: 694

Answered 1 year ago

Hi, routing info below:

Comments (0) New comment

ondrej.petras Rank: 694

Answered 1 year ago

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

Comments (4) New comment

by ondrej.petras Rank: 694 on 2/13/2020 5:16:41 AM | Like (0) | Report

Hi Stefan,

We managed to find out the cause for UP/DOWN issue in RNRP. There is a problem on customer's infrastructure. Anyway, for now it is connected only through one NE870. It is UP/UP now. There are 2 PM866 connected to control network. They are in master/slave mode. I can ping it from servers on both primary and secondary network (172.16.80.151/172.17.80.151). I can also ping the slave PM866 (172.16.82.151/172.17.82.151), but only directly from NE870 (I was told that it is normal behavior and it can be pinged only from control network). Failover from one PM866 to another works ok.

Issue is, I cannot see it in the RNRP network status tool. I started this topic with the same issue when I was testing connection here in the office, and it was caused by McAfee on my laptop. Now the issue is on customer's site. Any tips how to troubleshoot? NE870 and PM866 are once again connected through customer's infrastructure and I guess it is the problem, but any tips would be appreciated. Thank you

by Stefan Stromqvist AKS expert

Rank: 1 on 2/13/2020 6:08:35 AM | Like (0) | Report

"I cannot see it" = the Backup CPU?

This is expected, the backup CPU does not run RNRP, hence it will not be listed by any RNRP tool, nor be pingable from outside the L2 network it is connected to.

by ondrej.petras Rank: 694 on 2/13/2020 7:06:45 AM | Like (0) | Report

No, I cannot see any PM866. There are just servers, NE870 with all configured interfaces, but no PM866.

by Stefan Stromqvist AKS expert

Rank: 1 on 2/13/2020 7:11:06 AM | Like (0) | Report

Please insert what the traditional RNRP Monitor list (as ASCII letters)

Please use RNRP Diagnostic Tool and select "3 - Get network map from one node" and query:
a) the NE870
b) the controller you can ping, but do not see

Add new comment

Stefan Stromqvist AKS expert

Rank: 1

Answered 1 year ago

Hi,

172.16.80.141 is NE870 interface facing control network
172.16.80.151 is PM866 I cannot see in RNRP but can ping.

Comments (2) New comment

by Stefan Stromqvist AKS expert

Rank: 1 on 2/13/2020 11:04:49 PM | Like (0) | Report

Is IGMP restricted on area 20?

Try listening for the controller RNRP multicast beacons from the NE870 router's CLI:

#> show iface
(find the VLAN where the controller is connected, I believe I recall 210)

#> tcpdump iface vlan210 expr "udp port 2423"

You should see 1 telegram / second from each node. If not, investigate if the switches in that network pass multicast - they must. Verify IGMP is DISABLED:

by Stefan Stromqvist AKS expert

Rank: 1 on 2/13/2020 11:06:25 PM | Like (0) | Report

ROUTER101:/#> tcpdump vlan2201 expr "udp port 2423"
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vlan2201, link-type EN10MB (Ethernet), capture size 68 bytes
08:06:24.501791 IP 172.16.80.156.63997 > 239.239.239.80.2423: UDP, length: 76
08:06:24.517066 IP 172.16.80.102.56966 > 239.239.239.80.2423: UDP, length: 278
08:06:24.517127 IP 172.16.80.102.56966 > 239.239.239.80.2423: UDP, length: 278
08:06:24.520431 IP 172.16.80.102.56966 > 239.239.239.80.2423: UDP, length: 79
08:06:24.520483 IP 172.16.80.102.56966 > 239.239.239.80.2423: UDP, length: 79
08:06:24.636435 IP 172.16.80.157.58033 > 239.239.239.80.2423: UDP, length: 76
08:06:24.663269 IP 172.16.80.101.51051 > 239.239.239.80.2423: UDP, length: 278
08:06:24.663349 IP 172.16.80.101.51051 > 239.239.239.80.2423: UDP, length: 278
08:06:24.666224 IP 172.16.80.101.51051 > 239.239.239.80.2423: UDP, length: 80
08:06:24.666307 IP 172.16.80.101.51051 > 239.239.239.80.2423: UDP, length: 80
08:06:24.673724 IP 172.16.80.101.51051 > 239.239.239.80.2423: UDP, length: 75
08:06:24.673807 IP 172.16.80.101.51051 > 239.239.239.80.2423: UDP, length: 75
08:06:24.732805 IP 172.16.80.152.1026 > 239.239.239.80.2423: UDP, length: 76
08:06:24.759850 IP 172.16.80.155.57268 > 239.239.239.80.2423: UDP, length: 76
08:06:24.999496 IP 172.16.80.153.1026 > 239.239.239.80.2423: UDP, length: 76
08:06:25.034703 IP 172.16.80.102.56966 > 239.239.239.80.2423: UDP, length: 76
^C
16 packets captured
16 packets received by filter
0 packets dropped by kernel

Add new comment

ondrej.petras Rank: 694

Answered 1 year ago

It seems ok:

Comments (2) New comment

ondrej.petras Rank: 694

Answered 1 year ago

Hi Stefan,

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.

Comments (4) New comment

ondrej.petras Rank: 694

Answered 1 year ago

Question details

PM866 in RNRP monitor through NE870

Answers

Other questions needing answers

Related topics

AKS experts