NE870 and IP Forwarding
Hello:
Was hoping someone could help our customer with a issue where a ENG. Station cannot access any Controllers Through a NE870 on a 2nd Control network Area (21). Please see attach drawing. We have confirmed that CS25 can reach the route through the NE870 to Area 21 (172.16.84.x). There are 4 Connect Servers (Red.) 1 Pair on Area 20 and 1 pair on Area 21. We have purposely Turned off all IP Forwarding at the Connect Servers except CS25 so it can Route The ENG Station to either Area. Route Print from ENG Station Confirms it is Hitting CS25 and can see all Controllers on Area 20 but will not get passed through to Area 21 Via NE870. It also cannot Ping the NE870. However CS25 can Ping NE870 and access any Controller on the Other Area 21. We have Enabled Global Routing on Both NE870 Routers and Both Have Firewall Turned off. Vlans are setup and Working. RNRP see's as everything up with no Errors except of Course the ENG Station RNRP shows NO Data for the NE870 since it cannot get its Diagnostic Data through CS25. Please see Attached Drawing and Route Print. If we enable IP Forwarding on the Area 21 Side then yes it will take this Route to Area 20 and 21 Via RNRP IP Forwarding but we want it to use CS25 IP Forwarding. any Help would be appreciated. Route Print attached shows to get to IP 172.16.84.x (Area 21) it must get there via 172.16.4.44 (CS25) this is correct but cannot get to the NE870 from there.
Thanks
Was hoping someone could help our customer with a issue where a ENG. Station cannot access any Controllers Through a NE870 on a 2nd Control network Area (21). Please see attach drawing. We have confirmed that CS25 can reach the route through the NE870 to Area 21 (172.16.84.x). There are 4 Connect Servers (Red.) 1 Pair on Area 20 and 1 pair on Area 21. We have purposely Turned off all IP Forwarding at the Connect Servers except CS25 so it can Route The ENG Station to either Area. Route Print from ENG Station Confirms it is Hitting CS25 and can see all Controllers on Area 20 but will not get passed through to Area 21 Via NE870. It also cannot Ping the NE870. However CS25 can Ping NE870 and access any Controller on the Other Area 21. We have Enabled Global Routing on Both NE870 Routers and Both Have Firewall Turned off. Vlans are setup and Working. RNRP see's as everything up with no Errors except of Course the ENG Station RNRP shows NO Data for the NE870 since it cannot get its Diagnostic Data through CS25. Please see Attached Drawing and Route Print. If we enable IP Forwarding on the Area 21 Side then yes it will take this Route to Area 20 and 21 Via RNRP IP Forwarding but we want it to use CS25 IP Forwarding. any Help would be appreciated. Route Print attached shows to get to IP 172.16.84.x (Area 21) it must get there via 172.16.4.44 (CS25) this is correct but cannot get to the NE870 from there.
Thanks
Asked 1 month ago
Answers
0
How does the routing table of the controller on area 21 look like?
It must use the NE870 and CS25 as routers to reach area 1.
For this to take place,the RNRP Max No Of Hops setting must be set to two or greater (default is 3) and Max No Of Remote Areas be set to two or greater (default is 4).
You can query for "RNRP's view" in any node by using RNRP Fault Tracer's option 3 - Get network map from one node. Of course, the interrogator and the subject must be within reach of each other, e.g. CS25 should be able to query the controller on area 21.
If there has been or still are other areas in use, the Max No Of Remote Areas parameter may block the controller from "learning a new". Make sure this has not taken place. In some cases you must restart RNRP. This can easily be done by downloading a parameter change of any of the RNRP parameters, e.g. Max No Of Remote Areas.
From the Network Configuration Manual, 3BSE034463-610
Somewhere deep down, I wonder what happened when you turned off the IP Forwarding of the connectivity servers for area 21... the first rule of RNRP is to prefer least number of hops. Going via area 20 adds distance and is not favored if there is a shorter path. Not all permutations of configuring network has been tested. I put my hopes into that restarting RNRP in the controller will resolve this, if it should be the core issue.
It must use the NE870 and CS25 as routers to reach area 1.
For this to take place,the RNRP Max No Of Hops setting must be set to two or greater (default is 3) and Max No Of Remote Areas be set to two or greater (default is 4).
You can query for "RNRP's view" in any node by using RNRP Fault Tracer's option 3 - Get network map from one node. Of course, the interrogator and the subject must be within reach of each other, e.g. CS25 should be able to query the controller on area 21.
If there has been or still are other areas in use, the Max No Of Remote Areas parameter may block the controller from "learning a new". Make sure this has not taken place. In some cases you must restart RNRP. This can easily be done by downloading a parameter change of any of the RNRP parameters, e.g. Max No Of Remote Areas.
From the Network Configuration Manual, 3BSE034463-610
Somewhere deep down, I wonder what happened when you turned off the IP Forwarding of the connectivity servers for area 21... the first rule of RNRP is to prefer least number of hops. Going via area 20 adds distance and is not favored if there is a shorter path. Not all permutations of configuring network has been tested. I put my hopes into that restarting RNRP in the controller will resolve this, if it should be the core issue.
0
Hi Stefan:
I attached a new Pic from when we did the Route Check last week. It looks Normal . 147 is the NE870 Router.
Thanks
Miro
![]()
I attached a new Pic from when we did the Route Check last week. It looks Normal . 147 is the NE870 Router.
Thanks
Miro
Answered 1 month ago
0
0
(I am working with Miro on this issue below are collections from site.)
First, we acknowledge the likely need for firmware upgrade.
We ping from 172.16.4.1 to 182.16.84.181 in this test. In theory it should have two hops.
ABB NEOS v4.20.0-r0 vendor/abb/4.20.0-r0 -- Aug 23 14:19 CEST 2017 Type: 'help' for help with commands, 'exit' to logout or leave a context. AutomationNetworkEquipmentX:/#> show ifaces Press Ctrl-C or Q(uit) to quit viewer, Space for next page, <CR> for next line.
Here is the tcpdump on the 172.16.84.0/22 side of the router. We find the request and reply pass through this interface. 
Next is the tcpdump on the 172.16.80.0/22 side of the router. We find the request passed through but the reply did not.
Base on the two commands above the ICMP request goes through both interfaces but the reply only comes back through the 84 interface. The reply cannot get out of the router.
Next we examine the ARP table and find it does not resolve 172.16.4.1 on row 3. Upon receiving a TCP message (during the ICMP request) the router should learn and keep the source MAC from the header. Host 172.16.4.1 should show the same MAC as our connectivity server [(172.16.80.25) at 00:0c:29:d0:86:b1] since it acts as the router.
This raises a few questions:
1. Firmware release 4.24.1 mentions a fix for stale ARP caches. This may be our problem?
2. If we had IPForwarding enable on a pair of connectivity servers, do they issue Gratuitous ARP messages when the routing server goes down and all the RNRP instances on the network rewrite routing tables? Our SV6.1 RNRP is version 5.17.
First, we acknowledge the likely need for firmware upgrade.
We ping from 172.16.4.1 to 182.16.84.181 in this test. In theory it should have two hops.
ABB NEOS v4.20.0-r0 vendor/abb/4.20.0-r0 -- Aug 23 14:19 CEST 2017 Type: 'help' for help with commands, 'exit' to logout or leave a context. AutomationNetworkEquipmentX:/#> show ifaces Press Ctrl-C or Q(uit) to quit viewer, Space for next page, <CR> for next line.
Here is the tcpdump on the 172.16.84.0/22 side of the router. We find the request and reply pass through this interface. Next is the tcpdump on the 172.16.80.0/22 side of the router. We find the request passed through but the reply did not.
Base on the two commands above the ICMP request goes through both interfaces but the reply only comes back through the 84 interface. The reply cannot get out of the router.
Next we examine the ARP table and find it does not resolve 172.16.4.1 on row 3. Upon receiving a TCP message (during the ICMP request) the router should learn and keep the source MAC from the header. Host 172.16.4.1 should show the same MAC as our connectivity server [(172.16.80.25) at 00:0c:29:d0:86:b1] since it acts as the router.
This raises a few questions:
1. Firmware release 4.24.1 mentions a fix for stale ARP caches. This may be our problem?
2. If we had IPForwarding enable on a pair of connectivity servers, do they issue Gratuitous ARP messages when the routing server goes down and all the RNRP instances on the network rewrite routing tables? Our SV6.1 RNRP is version 5.17.
Answered 1 month ago
Add new comment