44net

44net@mailman.ampr.org

4 participants
3196 discussions

Re: [44net] RIP problems?
by Brian 06 Apr '19

06 Apr '19

Rob et al; This user is flagged RADIO only in his config and should not be a listed "gateway" at all: 44.118.1.1 2018-03-01 18:16:04 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1403> 44.118.1.2 2018-03-01 18:16:12 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1404> 44.118.1.3 2018-03-01 18:16:19 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1405> 44.130.104.1 2017-10-02 18:34:13 DG8NGN View If this is causing an issue, let me know and I'll send him a note asking him what he's looking to do and point him to a few things that may help him out. I know in Maine, they prefer to use M$ and software that's 100% GUI based. The problem however becomes that the sysop doesn't learn what they're doing because the GUI hides the technical information. -- I won't be like a Texas official and call Ocasio-Cortez a bimbo but she does think Roe vs Wade are two different ways to cross a river. ----- 73 de Brian N1URO IPv6 Certified n1uro-dawt-ampr-dawt-org uronode-dawt-n1uro-dawt-com

1 0

Re: [44net] RIP problems?
by Rob Janssen 06 Apr '19

06 Apr '19

Well, after a week of frantic searching how this problem came about, it has finally been pinpointed. It turned out to be an unfortunate consequence of someone setting up a bad gateway entry with the external IP within out 44.137.0.0/16 network, combined with strict firewalling that returns ICMP messages on bad traffic, a bug in the handling of those messages, and the way ampr-ripd handles the above type of gateways. Finally when Marius discovered that ICMP messages were going back to the gateway in his test setup, and when this happened amprgw abruptly ended the sequence of RIP packets, combined with the observation that putting delay between the packets actually made things worse, and removing of the bad gateway fixed it, finally lead to resolution of the problem. Now there are some bugs to fix, but also I looked in the gateway list and I found several more of those bad gateways! It looks like the gateway concept is difficult enough for people to understand as it originally was, and adding the possibility to have a gateway address inside net-44 really pushes complexity beyond what can be handled. And because it is (under strict conditions) allowed, the check in the gateway that simply rejects such entries has been removed. Look at what we have now: 44.2.11.1 2018-01-17 20:55:30 KK6NHN View <https://portal.ampr.org/gateways_list.php?a=view&id=1555> 44.2.11.2 2018-01-17 20:56:07 KK6NHN View <https://portal.ampr.org/gateways_list.php?a=view&id=1556> 44.24.172.41 2018-01-04 23:09:44 KG7PNQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1546> 44.24.241.98 2017-04-26 06:31:05 KD7LXL View <https://portal.ampr.org/gateways_list.php?a=view&id=1378> 44.94.17.129 2018-09-04 05:12:02 N0NCE View <https://portal.ampr.org/gateways_list.php?a=view&id=1695> 44.102.222.16 2019-03-24 22:27:29 W8HRV View <https://portal.ampr.org/gateways_list.php?a=view&id=1760> 44.118.1.1 2018-03-01 18:16:04 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1403> 44.118.1.2 2018-03-01 18:16:12 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1404> 44.118.1.3 2018-03-01 18:16:19 N1QX View <https://portal.ampr.org/gateways_list.php?a=view&id=1405> 44.130.104.1 2017-10-02 18:34:13 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1481> 44.130.104.2 2018-04-15 16:36:26 DL2QT View <https://portal.ampr.org/gateways_list.php?a=view&id=1613> 44.130.105.1 2017-10-02 18:35:03 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1482> 44.130.106.1 2017-10-02 18:35:32 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1483> 44.130.107.1 2017-10-02 18:35:55 DG8NGN View <https://portal.ampr.org/gateways_list.php?a=view&id=1484> 44.131.14.253 2017-05-06 07:29:35 M6XCV View <https://portal.ampr.org/gateways_list.php?a=view&id=1382> 44.136.150.2 2019-03-11 01:55:46 VK4AA View <https://portal.ampr.org/gateways_list.php?a=view&id=1386> 44.137.8.1 2018-10-01 09:41:51 PA0HWB View <https://portal.ampr.org/gateways_list.php?a=view&id=1707> 44.137.44.118 2018-01-14 23:25:39 PD2LED View <https://portal.ampr.org/gateways_list.php?a=view&id=1551> 44.137.48.78 2019-03-01 09:26:45 PE1OWG View <https://portal.ampr.org/gateways_list.php?a=view&id=1806> 44.144.46.240 2017-11-07 13:21:48 ON7AVC View <https://portal.ampr.org/gateways_list.php?a=view&id=1505> 44.151.38.60 2018-05-13 11:24:03 F4FLQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1631> 44.151.38.61 2018-05-13 11:25:42 F4FLQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1632> 44.151.38.62 2018-05-13 11:26:32 F4FLQ View <https://portal.ampr.org/gateways_list.php?a=view&id=1633> 44.159.112.16 2018-08-17 19:28:16 9V1AN View <https://portal.ampr.org/gateways_list.php?a=view&id=1683> Most of them have "no subnets" and I think they were only created by experimenting people who tried some options in the gateway and finally gave up for the day. Only these actually have subnets routed: 44.24.172.41 44.94.17.129 44.130.104.1 44.130.105.1 44.130.106.1 44.130.107.1 44.131.14.253 44.136.150.2 Several of those route a subnet that contains the actual gateway... often subnets so small that they cannot be BGP-routed on internet, so likely invalid as well. This whole thing causes quite some risk of malfunction, loops, etc. as was demonstrated this week. I propose that the existing gateways in the above list with no gateways (those not in the second list) to be removed, and the portal changed to again disallow the creation of new gateways within net-44. Then, the valid users should be encouraged to find a gateway IP outside of net-44 and this whole thing be phased out. Too much time has been wasted on debugging this problem already, and what advantage does it really bring? Rob

4 4

Re: [44net] RIP problems?
by Rob Janssen 06 Apr '19

06 Apr '19

> Until a decision is made about what to do long term here, maybe the AMPR > Portal web interface can change this name from "gateway" to "public > Internet IP (gateway)". I think that would help some people avoid this > issue. Either that, and/or a descriptive text above the form that explains what a gateway is, why you want to have it (and why not), and where to read more about it. There are those "hover" type help texts but I am afraid it is not enough. I think several "gateways" now listed (with no subnets) are the result of people wanting to register/publish their system information in a way that is more like what HamnetDB does. It should be clearer that creating a gateway here actually sets up routes and when done incorrectly can mess things up pretty badly. The announced subnets list has similar risks. For a while it was limited to subnets registered by the person logged in, there were people wanting to route subnets for others (probably to forward them internally) and this check was removed, and now people who do not completely understand what is going on are randomly announcing other people's subnets without anyone knowing. Perhaps best would be when all gateway setup had to be validated by someone with more experience (a coordinator, an old hat in AMPRnet, etc) before it becomes finalized, similar to the subnet allocation. Rob

1 0

Re: [44net] RIP problems?
by Rob Janssen 02 Apr '19

02 Apr '19

Talked to network people at the ISP, they indicate that they have changed something w.r.t. the routing via Eurorings. It should be researched and hopefully fixed. In the meantime I am thinking about relaying the RIP packets from my own colo host to our gateway as an extra safeguard against things like this. I see that ampr-ripd has options -E and -F that should relay the raw packets to a specified address, good. That should work. But I don't think it is possible to make ampr-ripd receive and act upon those relayed packets, isn't it? Should I NAT them at the receiving system so they again have 224.0.0.9 as destination? Has anyone tried such a setup and does it work without nasty issues? (normally all RIP packets will be received twice in this case) Rob

2 1

Fwd: mailman.ampr.org mailing list memberships reminder
by William Lewis 02 Apr '19

02 Apr '19

Does anyone else find it useless to have a password reminder email sent out every month where you're told your password is [****] ? -------- Forwarded Message -------- Subject: mailman.ampr.org mailing list memberships reminder Date: Mon, 01 Apr 2019 05:00:19 -0700 From: mailman-owner(a)mailman.ampr.org To: wlewis(a)acscalifornia.org This is a reminder, sent out once a month, about your mailman.ampr.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. <SNIP> List Password // URL ---- -------- 44net(a)mailman.ampr.org ****

6 7

RIP problems?
by Rob Janssen 02 Apr '19

02 Apr '19

Since yesterday, or maybe earlier, we do not receive the full RIP table anymore and our route table for IPIP routes has almost emptied. A trace of UDP port 520 shows only 2 RIP packets per cycle. Has something changed? Or does this have to be some rate-limiting on the path to here? Rob

5 7

Re: [44net] RIP problems?
by Rob Janssen 02 Apr '19

02 Apr '19

I did further debugging... It is indeed our 213.222.29.194 gateway that has the issue, it misses most of the routes at least since yesterday (I notice because I have some mail in the queue routed over IPIP that has stalled since yesterday). But I do have another independently hosted IPIP host in the Netherlands that receives all the normal routes. It is at IP 89.18.172.156 and is located in another datacenter. So likely it is a routing issue on the internet... Rob

1 0

Linux Gateway Question.
by KJ7DMC 31 Mar '19

31 Mar '19

Hello, I'm setting up a gateway on a linux server, I have added NAT and firewall rules to send protocol 4 over to my server at 10.0.2.1. Here's some output from tcpdump. Does this look right to you? Under it I have the output from ampr-ripd, showing nothing coming in. 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 102 15:41:24.153222 IP (tos 0x50, ttl 242, id 15047, offset 0, flags [none], proto IPIP (4), length 174) ip72-192-148-49.sd.sd.cox.net > 10.0.2.1: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 154) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 126 15:41:35.790028 IP (tos 0x50, ttl 232, id 5104, offset 0, flags [none], proto IPIP (4), length 166) dhcp-91-241-24-251.zc.net.pl > 10.0.2.1: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 146) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 118 15:41:40.735505 IP (tos 0x50, ttl 233, id 5482, offset 0, flags [none], proto IPIP (4), length 150) 89-67-160-225.dynamic.chello.pl > 10.0.2.1: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 130) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 102 15:42:24.169078 IP (tos 0x50, ttl 242, id 15303, offset 0, flags [none], proto IPIP (4), length 174) ip72-192-148-49.sd.sd.cox.net > 10.0.2.1: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 154) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 126 15:42:35.827618 IP (tos 0x50, ttl 232, id 5105, offset 0, flags [none], proto IPIP (4), length 166) dhcp-91-241-24-251.zc.net.pl > 10.0.2.1: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 146) 0.0.0.0.5678 > 255.255.255.255.5678: UDP, length 118 root@rigel:~/ampr-ripd-2.4# ./ampr-ripd -d -i tunl0 Using gateway 10.0.0.1 for direct 44net endpoints via interface enp2s0. Waiting for RIPv2 broadcasts... Any help would be greatly appreciated. Thanks and 73, -Nate, KJ7DMC

2 1

Brian Kantor could you contact me off-list please
by Ruben ON3RVH 29 Mar '19

29 Mar '19

Hi Brian, I am trying to reach you off-list but the message keeps bouncing at your bkantor.net o365 mailbox due to security settings. I have a question about re-routing my BGP subnet. Would it be possible to contact me off-list please? Thanks! 73, Ruben - ON3RVH

3 11

Vultr & vyos bgp setup
by brian＠binded.net 24 Mar '19

24 Mar '19

Hello All! I just got my /24 setup over at vultr. Im trying to follow a generic VYOS guide to setup bgp. Im getting some errors when trying to setup the bgp network command. Im used to working with cisco stuff, never really configured anything else. Has anyone used VYOS for bgp? Or is there another router OS thats better to use. 73, Brian

7 8

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net