44net

44net@mailman.ampr.org

3179 discussions

Re: [44net] Portal doesn't allow IPIP anycast via 44net

by kb9mwr＠gmail.com

Alright how many people are still running some sort of NOS on DOS? Time to move forward folks and use the excellent routing capabilities of Linux. Every time I look at the encap.txt and see stuff like: route addprivate 44.129/16 encap 118.22.1.194 I ask myself why do we still export is this way. I say export it as: ip route add 44.129.0.0/16 via 118.22.1.194 dev tunl0 onlink And let those who still need it the old way learn the pain of conversion. Give them a reason to upgrade/ move forward. </Off my soap box> ---- Quote--- Bart, Don brought up some good points. In addition: - non Linux-kernel routers (e.g. JNOS and TNOS) would not be able to route to you as they would need to be reprogrammed and recompiled (FYI, JNOS and TNOS is the most commonly used AMPR Network OS)

11 years, 2 months

NANOG 61 June 2-4

by Bryan Fields

https://www.nanog.org/meetings/nanog61/home I'll be here, and Tim Osbourn W7RSZ as well. Is there anyone else going? I'd enjoy having a dinner or lunch breakout to meet with some of the AMPRnet users at NANOG. Post if you're going and we'll arrange something if we have some interest. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

11 years, 2 months

Re: [44net] Portal doesn't allow IPIP anycast via 44net

by Bryan Fields

On 4/11/14, 11:37 AM, lleachii(a)aol.com wrote: > It's much easier, and doesn't require a total reconfiguration of AMPR to > simply have Bart run a 44GW speaking rip 44 using his Public IP address as > the GWip - be advised that he is required to do so under the Terms of > Service: That's a heck of a jump in logic. I see nothing in there requiring anyone to run rip44d. All it means is you need have the ability of supplying connectivity to other hams in your area out of your subnet. I'm doing this via GRE and VPN dialers. I have little interest in connecting to the rest of AMPRnet hosts who are not rotatable in the global table. My interest is supplying access over RF using the AMPR space and setting up routed redundant multi-megabit links. What AMPRnet has running now is akin to the GRX network IMO. It's private with one interconnection to the internet. 73's -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

11 years, 2 months

Re: [44net] AMPRNet BGP vs non-BGP routing

by Bryan Fields

On 4/11/14, 11:32 AM, Bart Kus wrote: > It allows our microwave network to remain connected to the rest of > AMPRnet as long as we have at least 1 ISP that isn't dead. The > microwave network peers with the Internet at 2 different points at > present, but more points will come in the future. It's a robustness > improvement in the face of partial failures, like in a natural disaster > when an ISP's fiber gets torn or their building collapses. So this is a hack to correct for the hack of AMPRnet IPIP tunnels. Argh, it makes my head hurt. If AMPRnet was treated like any other network on the internet, this problem would go away. At worst anyone not redundantly connected to the global internet would lose connectivity if their small gateway went down. -- Bryan Fields 727-409-1194 - Voice 727-214-2508 - Fax http://bryanfields.net

11 years, 2 months

Re: [44net] AMPRNet BGP vs non-BGP routing (was: Portal doesn't allow IPIP anycast via 44net)

by Brian Kantor

As far as I know, because of routing restrictions on the amprgw network connectivity, hosts on BGP-announced subnets of 44/8 will be unable to communicate with hosts on tunnel-routed subnets of 44/8 unless the BGP-announced subnet also runs a listed tunnel router gateway with a non-44/8 gateway address. This is because the building-level router one hop upstream from amprgw has a fixed route directing all 44/8 traffic to amprgw. This building-level router does not speak BGP and so cannot learn about BGP-announced subnets of 44/8. This is a historical artifact; it predates the availability of BGP-announced 44/8 subnets by many years. We hope to change this topology in the future to connectivity with the border router that DOES speak BGP, but indications are that that change will not be able to be done soon. In the meantime, gateway tunnel routers with a non-44 gateway address (that's all of them, except HamWan's proposed gateway) are the workaround to this restriction. I'm sorry for this difficulty but it's what we're stuck with for now. - Brian

11 years, 2 months

Portal doesn't allow IPIP anycast via 44net

by Bart Kus

Hi, In trying to migrate HamWAN to IPIP anycast as discussed in a previous thread. I have run across a problem at the very last step. The relevant screenshot is at http://imgur.com/X2BfziT . Cannot attach the PNG due to message size restrictions. Basically, when I try to change the Gateway IP for our 44.24.240.0/20 subnet to be 44.24.221.1, I get the error message "Invalid gateway IP address". I'm sure this was intentionally coded at some point, but I believe this to be a design error. Here's why: 1) 44.24.221.1 is outside the associated prefix list for this gateway (44.24.240.0/20 only). 2) 44.24.221.0/24 will not be configured to have an IPIP gateway as it is being announced directly on the Internet. Given those two conditions, anyone with traffic for 44.24.240.0/20 can send it via Internet or IPIP to 44.24.221.1. When sending to 44.24.221.1 (outer IPIP header dst-addr), there should be no conflicting route and the default route should be taken, resulting in proper packet delivery to HamWAN. Can someone add this gateway manually and then fix the portal interface problem? Our tunnels are re-configured into the new desired state and awaiting packets. :) We are presently in AMPR tunnel downtime mode until that gateway is set + propagated. Thanks! --Bart

11 years, 2 months

Can't communicate with 44.0.0.1 from 44-space?

by Bart Kus

Hi, I have a couple traces to share: [eo@Seattle-ER1] > /tool traceroute address=44.0.0.1 src-address=209.189.196.68 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 209.189.196.65 0% 10 1.9ms 0.8 0.4 1.9 0.5 2 209.189.202.195 0% 10 0.7ms 73.1 0.4 261 108.6 3 206.81.80.99 0% 10 0.7ms 5.1 0.5 10.7 3.9 4 69.28.171.145 0% 10 28ms 26.6 20 38.1 5.2 5 69.28.171.210 0% 10 22.8ms 21.4 18.6 31.9 3.9 6 198.32.176.33 0% 10 21.6ms 19.5 19.1 21.6 0.7 7 137.164.47.19 0% 10 21.4ms 24.1 21.4 29 2 8 137.164.46.67 0% 10 25.1ms 25.1 23.6 27.1 0.9 9 137.164.46.244 0% 10 34.7ms 33.5 32.4 35.6 1.2 10 137.164.47.15 0% 10 39.4ms 39.7 39.3 41.5 0.6 11 137.164.23.54 0% 10 39.7ms 40.2 39.5 43.2 1 12 132.239.254.163 0% 10 40.5ms 41.5 39.7 49.1 2.7 13 132.239.255.131 0% 10 39.6ms 40.2 39.6 43.1 1 14 44.0.0.1 10% 10 39.7ms 39.9 39.6 40.5 0.3 [eo@Seattle-ER1] > /tool traceroute address=44.0.0.1 src-address=44.24.242.22 # ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV STATUS 1 209.189.196.65 0% 5 0.7ms 1.3 0.5 2.5 0.7 2 209.189.201.195 0% 5 3.5ms 1.5 0.5 3.5 1.2 3 206.81.80.99 0% 4 0.4ms 4.1 0.4 8.1 3.5 4 69.28.171.145 0% 4 25.7ms 24.7 19.6 29.6 3.6 5 69.28.171.210 0% 4 34.7ms 25.3 21.5 34.7 5.5 6 198.32.176.33 0% 4 19.5ms 20.4 19.3 23.2 1.6 7 137.164.47.19 0% 4 23.7ms 23.6 21.9 25.4 1.3 8 137.164.46.1 0% 4 24.4ms 26.3 24.4 27.5 1.2 9 137.164.46.248 0% 4 36.1ms 33.8 32.1 36.1 1.5 10 137.164.47.111 0% 4 42.9ms 40.3 39.1 42.9 1.6 11 137.164.23.54 0% 4 41.2ms 45.8 39.8 61.6 9.1 12 100% 4 timeout 13 100% 4 timeout 14 100% 4 timeout 15 100% 4 timeout 16 100% 4 timeout They'll look like crap without monospace font, and I don't wanna use HTML cuz the content of my message will be torn out of the email and replaced with a web link. So, adjust your fonts + screen size accordingly to properly view the traces. The only difference between them is the source address. Both addresses are bound to that router. That router holds IPIP tunnels to every ENCAP.txt network. Since 44.0.0.1 is not one of these networks, there is no tunnel that covers that IP, so the packets go over the regular internet. We BGP announce 44.24.242.22, so the trace from that IP should succeed in theory. Can someone explain what's breaking here and how to fix it? Thanks, --Bart

11 years, 2 months

Linux Gateway Tutorial

by Neil Johnson

I'm trying to decide how to write a "How To" guide for setting up a Linux Gateway for the Wiki. I'm planning on basing it on the excellent guide found here (with Credit): http://marc.storck.lu/blog/2013/08/howto-setup-an-amprnet-gateway-on-linux/ But I'm wondering what level of Linux Administration and IP Networking Expertise I should assume. If I assume zero, it's going to be a looong guide, probably too long. Below is a link to the diagram I was planning to base the guide off of. AMPRNet Gateway Diagram - https://docs.google.com/drawings/d/1xAcMbROBpbuRFY0tVf1VdBrAP0ZQwTsE6Eqokn2… Comments welcome. Thanks -Neil

11 years, 2 months

Wiki Updates

by Neil Johnson

All, I finished by volunteer stint at a youth robotics competition, so I have been poking around the Wiki making some changes. Mainly I have been adding some small pieces of content to eliminate the Wiki links that go to empty pages, but I have also rearranged some of the content on the main page. If you run across any issues, please let me know. I hope that is okay with everyone. -Neil -- Neil Johnson, N0SFH http://erudicon.com

11 years, 2 months

Pi bug for ipencap?

by Brian Rogers

Greetings; I've noticed recently after doing a package update on the iproute packages I can no longer configure my tunnel interface tunl0. Mainly I'm trying to reset the ttl to 64 for traceroute to properly work. Everything I've searched comes up empty. Here's what I see: root@gw:/usr/local/bin# iptunnel show tunl0: ip/ip remote any local any ttl inherit nopmtudisc root@gw:/usr/local/bin# ifconfig tunl0 tunl0 Link encap:IPIP Tunnel HWaddr inet addr:44.88.0.1 Mask:255.255.255.255 UP RUNNING NOARP MULTICAST MTU:0 Metric:1 ttl is stuck on inherit and MTU autoconfigs to 0. This I know is set by nopmtudisc however if I try to adjust things: root@gw:/usr/local/bin# ip tunnel change tunl0 ttl 64 ttl != 0 and noptmudisc are incompatible root@gw:/usr/local/bin# ip tunnel change pmtudisc mode ipip add tunnel tunl0 failed: No such file or directory Why would it try to ADD? the command is CHANGE. Has anyone else suffered this before and if so what was the fix? Thanks in advance. -- 73 de Brian Rogers - N1URO email: <n1uro(a)n1uro.ampr.org> Web: http://www.n1uro.net/ Ampr1: http://n1uro.ampr.org/ Ampr2: http://nos.n1uro.ampr.org Linux Amateur Radio Services axMail-Fax & URONode AmprNet coordinator for: Connecticut, Delaware, Maine, Maryland, Massachusetts, New Hampshire, Pennsylvania, Rhode Island, and Vermont.

11 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net