Re: Node 7490 not connecting to reflectors

k9dc
 

As John suggested, run the 'troubleshoot-irlp’ command. All tests must pass. The ip address of 7490 has changed to 72.132.11.23, but there is no port forwarding in place for that address. It is very important that the inbound path and the outbound path ALWAYS cross the same gateways on the way in or out. Multiple internet connections will screw with that and very likely break things.

I just checked the server log and found the IP address for 7490 has been changing between 72.132.16.199 and 47.156.178.150, probably as many as 100 times per day for at least the last year. This creates considerable load on the servers to keep up with these changes. Your node also is not working when the IP is so wildly unstable.

Please turn 7490 off until you can stabilize your routing. You will most likely have to turn one of your gateways off permanently, or add static routes to your configuration so IRLP always takes the same path out. Two or more active gateways almost never work.

Here are the changes from just yesterday. This (or worse) has been happening at least since the first of this year

Nov 05 01:23:13 nsupdate stn7490 47.156.178.150 VALID
Nov 05 01:33:30 nsupdate stn7490 72.132.16.199 VALID
Nov 05 02:50:57 nsupdate stn7490 47.156.178.150 VALID
Nov 05 03:26:38 nsupdate stn7490 72.132.16.199 VALID
Nov 05 05:02:47 nsupdate stn7490 47.156.178.150 VALID
Nov 05 06:10:56 nsupdate stn7490 47.156.178.150 SAMEIP
Nov 05 06:47:05 nsupdate stn7490 72.132.16.199 VALID
Nov 05 07:18:02 nsupdate stn7490 47.156.178.150 VALID
Nov 05 07:52:26 nsupdate stn7490 72.132.16.199 VALID
Nov 05 08:22:09 nsupdate stn7490 72.132.16.199 SAMEIP
Nov 05 09:10:22 nsupdate stn7490 72.132.16.199 SAMEIP
Nov 05 09:22:19 nsupdate stn7490 47.156.178.150 VALID
Nov 05 09:58:36 nsupdate stn7490 72.132.16.199 VALID
Nov 05 10:34:54 nsupdate stn7490 72.132.16.199 SAMEIP
Nov 05 10:55:38 nsupdate stn7490 47.156.178.150 VALID
Nov 05 11:10:05 nsupdate stn7490 72.132.16.199 VALID
Nov 05 12:04:39 nsupdate stn7490 47.156.178.150 VALID
Nov 05 13:43:52 nsupdate stn7490 72.132.16.199 VALID
Nov 05 14:21:43 nsupdate stn7490 72.132.16.199 SAMEIP
Nov 05 14:57:00 nsupdate stn7490 47.156.178.150 VALID
Nov 05 16:43:30 nsupdate stn7490 72.132.16.199 VALID
Nov 05 16:50:59 nsupdate stn7490 47.156.178.150 VALID
Nov 05 17:06:17 nsupdate stn7490 72.132.16.199 VALID
Nov 05 17:50:55 nsupdate stn7490 47.156.178.150 VALID
Nov 05 19:14:29 nsupdate stn7490 47.156.178.150 SAMEIP
Nov 05 19:59:14 nsupdate stn7490 72.132.16.199 VALID
Nov 05 20:19:56 nsupdate stn7490 47.156.178.150 VALID
Nov 05 20:50:05 nsupdate stn7490 72.132.16.199 VALID
Nov 05 21:11:18 nsupdate stn7490 47.156.178.150 VALID
Nov 05 21:55:37 nsupdate stn7490 72.132.16.199 VALID
Nov 05 22:16:40 nsupdate stn7490 47.156.178.150 VALID
Nov 05 22:38:05 nsupdate stn7490 72.132.16.199 VALID
Nov 05 22:52:28 nsupdate stn7490 47.156.178.150 VALID
Nov 05 23:06:37 nsupdate stn7490 72.132.16.199 VALID
Nov 05 23:21:49 nsupdate stn7490 47.156.178.150 VALID
Nov 05 23:56:15 nsupdate stn7490 72.132.16.199 VALID

On Nov 6, 2019, at 01:01, ai6bx <ai6bx@...> wrote:

On Tue, Nov 5, 2019 at 04:23 AM, k9dc wrote:
Dave,
Thank you for your thoughtful feedback. 7490 is not operating with a VPN so 47.156.178.150 is the appropriate public IP. My other node number 7482 is working through the AMPR VPN IP at his time.

Yes, I do have a router between my Internet connection and the node, a configuration that has been in place for the better part of three years. I have a Netgear router for my home internet with an ARDEN gateway node carrying signal to my repeater site. The Netgear has a DMZ set for the IP of the AREDN gateway and the AREDN node has all the appropriate port forwards built into it to direct two way traffic to the repeater site supporting the IRLP/Echolink node, DMR repeater, remote control for other repeaters, Winlink server, mapping services, and a few other pieces. I think I may know what is happening as I have watched and seen the IRLP come and go today. I note that another AREDN gateway has been opened up on the network with near equal link quality as the path I am using to my QTH. the TCP port forwards are following the path back to my QTH and I suspect the UDP ports going back to the Internet may be taking the alternate path as it is presenting as the most efficient path for exit traffic. Does this make sense as the possible culprit? I think it does as the telnet irlp.net 10000 yields IP 72.132.11.23 which is the alternate gateway path I referenced. It may be time to make some hard code changes in my OLSR tables in the AREDN node to force the return path or get the second gateway shut down.

Thoughts?

Keith

Join IRLP@irlp.groups.io to automatically receive all group messages.