44net

44net@mailman.ampr.org

3196 discussions

Re: [44net] AMPRNet Interoperability with BGP
by Steve L 19 Jun '15

19 Jun '15

I am in the same boat as Bob. Home connection with limited inbound speed. So the DNS filtering is nice. It also lets my wireless LAN end users easily decide if they want inbound internet connectivity or not (when that portion of the portal gets done) without having to get a hold of me to set a firewall rule for them. I also like the idea of other VPN technologies being an option. One being stateful for those in uncool firewall situations . Sometime back I though maybe one day there would be multiple regional portals (connected with BGP and all running the open portal code/web interface) where end gateways could connect using a couple different vpn technologies. I understand the problem at hand with the fragmentation between the BGP vs IPIP segments. Or I think I do, from my end I know hamwan is BGP connected and have problems reaching it: I use the AMPR RIPv2 daemon 1.11by Marius, YO2LOJ And it appears if the 44 address you are trying to reach isn't in the RIP list, like hamwan is, it defaults to route it to UCSD. That doesn't work for me, as you will see below. But when I override that, and tell it to go out eth0 like all non 44net traffic it then works. Or is there something special I can do in my configs to fix this? root@44.92.21.1:~# ip route show table 44 | grep 44.24 44.24.0.0/20 via 66.114.139.158 dev tunl0 proto 44 onlink window 840 44.24.10.0/24 via 192.231.186.20 dev tunl0 proto 44 onlink window 840 44.24.192.0/24 via 38.104.126.22 dev tunl0 proto 44 onlink window 840 44.24.194.0/24 via 216.161.250.189 dev tunl0 proto 44 onlink window 840 44.24.196.0/24 via 24.113.42.14 dev tunl0 proto 44 onlink window 840 root@44.92.21.35:~# ping hamwan.org PING hamwan.org (44.24.241.98) 56(84) bytes of data. >From ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu (137.110.222.1) icmp_seq=2 Time to live exceeded >From ebu-3b-720-vl441-cse-sysnet-gw-222-1.ucsd.edu (137.110.222.1) icmp_seq=3 Time to live exceeded ^C --- hamwan.org ping statistics --- 6 packets transmitted, 0 received, +2 errors, 100% packet loss, time 5002ms root@44.92.21.35:~# ping hambook.de.ampr.org PING hambook.de.ampr.org (44.225.56.138) 56(84) bytes of data. 64 bytes from hambook.db0sda.as64634.de.ampr.org (44.225.56.138): icmp_req=1 ttl=55 time=189 ms 64 bytes from hambook.db0sda.as64634.de.ampr.org (44.225.56.138): icmp_req=2 ttl=55 time=175 ms ^C --- hambook.de.ampr.org ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 999ms rtt min/avg/max/mdev = 175.383/182.595/189.808/7.225 ms ---- Quote ---- I appreciate especially the filtering out of 44 addresses who are not in the dns by ucsd. I hate to loose that when it goes to another ISP. I remember well the days when that extra garbage was not filtered out and I will hate it when that is lost. My gateway is presently just at a home connection with a static ip. I object when that stuff is moved and no filtering will be in place whatsoever. With other words: UCSD is working fine. So why is it that those BGP subnets have no mandatory IPIP entries in the list also? They don't have to route back over IPIP, only need to receive IPIP. Easy solution, nothing drastic, KISS, and done in no time.. Bob VE3TOK

10 18

(no subject)
by Steve L 19 Jun '15

19 Jun '15

That occurred to me after I sent my last message. Part of my startup script included this default route: ip rule add to 44.0.0.0/8 table 44 priority 44 So I commented that out, and then could reach hamwan.org, but wasn't able to reach hambook.de.ampr.org and other hosts. I also upgraded to ampr-ripd 1.13 If someone can reach both from their IPIP gateway I'd be most grateful if you'd share your startup script with me. Here is my script: http://www.qsl.net/kb9mwr/wapr/tcpip/startampr ---- Quote ---- NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T WORK AND IS POINTLESS. Marius, YO2LOJ

4 10

Re; (no subject)
by Steve L 18 Jun '15

18 Jun '15

Managed to fix this on my own. Had to add a masquerad rule When I removed: ip route add default dev tunl0 via 169.228.66.251 onlink table 44 I had to add this to allow eth1 (my wireless LAN) to get anywhere: iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Thanks again ---------- Forwarded message ---------- From: Steve L <kb9mwr(a)gmail.com> Date: Thu, Jun 18, 2015 at 7:36 PM Subject: Re; (no subject) To: "44net(a)hamradio.ucsd.edu" <44net(a)hamradio.ucsd.edu> Marius, I was to hasty in saying removing this line fixed everything. I forgot to test from a remote host on my wireless LAN, I got a message from one of my LAN users that this broke things. Although I am at a loss as to why. It broke all remote connectivity. Works from the gateway itself, but all remote traceroutes stop when they reach my gateway, Steve ---- Quote ---- The issue in your setup is 'ip route add default dev tunl0 via 169.228.66.251 onlink table 44' which should go away if ypu want to reach BGP announced networks. Marius

1 0

Re; (no subject)
by Steve L 18 Jun '15

18 Jun '15

Marius, I was to hasty in saying removing this line fixed everything. I forgot to test from a remote host on my wireless LAN, I got a message from one of my LAN users that this broke things. Although I am at a loss as to why. It broke all remote connectivity. Works from the gateway itself, but all remote traceroutes stop when they reach my gateway, Steve ---- Quote ---- The issue in your setup is 'ip route add default dev tunl0 via 169.228.66.251 onlink table 44' which should go away if ypu want to reach BGP announced networks. Marius

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Rob Janssen 18 Jun '15

18 Jun '15

> Subject: > Re: [44net] AMPRNet Interoperability with BGP > From: > "Cory (NQ1E)" <cory(a)nq1e.hm> > Date: > 06/17/2015 11:02 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Wed, Jun 17, 2015 at 1:17 PM, Marius Petrescu<marius(a)yo2loj.ro> wrote: > >> > >> >NO GATEWAY SHOULD EVER HAVE A DEFAULT 44/8 ROUTE TO UCSD BECAUSE IT DOESN'T >> >WORK AND IS POINTLESS. >> > > Whoa... no need to yell:) Indeed... I was never talking about a 44/8 route, it is a 0.0.0.0/0 route. > > I'm finally taking a look at the wiki doc he referred to: > http://wiki.ampr.org/index.php/Ubuntu_Linux_Gateway_Example > > It does mention creating a new routing table with the default route (0/0, > not 44/8) pointed at the UCSD gateway. This makes sense as you may want to > generate packets with a 44 source and a non-44 destination on the > internet. The gateway will forward those correctly. That is why it is there! it is required for IPIP gateways on a source address filtered connection. > it would also do it > for non-tunneled 44 nets if we didn't have the upstream routing issue at > UCSD that started this thread. > > The problem seems to be with the traffic that gets flagged to use the > alternate routing table: > > ## Configure Policy Based routing > # Packets to 44/8 network use routing table 44 > ip rule add to 44.0.0.0/8 table 44 priority 44 > > # Packets from our 44 subnet use table 44 (put your AMPRNet Subnet here) > ip rule add from 44.128.10.0/24 table 44 priority 45 > > The second ip rule makes sense to me. You want all packets sourced from > your 44 net to use the alternate routing table so they can egress through > UCSD and keep their source IP without NAT. However, the first ip rule (all > packets with 44 destinations) seems unneeded and troublesome. Packets that > aren't sourced from your own 44 net, but happen to have a 44 destinations > shouldn't be forced to use your tunnel. The reason that it is there: when you make an outgoing connect from a socket that is not bound to a specific address, the kernel will decide on the local address based on the route. When you do nothing, traffic to 44.0.0.0/8 will be routed to your normal default route to your ISP, and the source address will be your public IP. The traffic will be routed "outside" via UCSD or a BGP-announcing gateway. Of course you want to make such connections via a tunnel, so there is the first rule that will match the 44.0.0.0/8 destinations, select table 44, and find the tunnel routes there. Then, your 44.x.x.x source address will be selected. Rob

2 1

Re: [44net] portal purge
by clark edwards 18 Jun '15

18 Jun '15

Kml £ On Jun 18, 2015 1:25 PM, Brian Kantor <Brian(a)ucsd.edu> wrote: (Please trim inclusions from previous messages) _______________________________________________ On Thu, Jun 18, 2015 at 10:14:00AM -0700, Tom Hayward wrote: > Which ICANN requirement is this? I'm only familiar with WDRP, which is > a requirement for registrars to maintain ICANN accreditation. I don't > think AMPR is a registrar or ICANN accredited, so I must be totally > out of context. ARIN requires that I verify my contact info once a year; they say it's a requirement placed on them by ICANN. > Also, how do I connect to the AMPR WHOIS server to read this information? The whois server is under development and not yet deployed. I'm not up on the progress of that project. The intent was to have it run on the portal, where the registration database is operated so that it can have access to the necessary data. - Brian _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] (no subject)
by Steve L 17 Jun '15

17 Jun '15

Marius, Thanks for the explanation, it helped clear up quite a few things I wasn't clear on. And yes after I removed the line: ip route add default dev tunl0 via 169.228.66.251 onlink table 44 I can reach hamwan.org. hambook.de.ampr.org and am able to accept connections from general internet IP's. So this was the secret for me. Thanks Steve

1 0

Re: [44net] (no subject)
by Steve L 17 Jun '15

17 Jun '15

Yes root@ampr-gw:~# ip route show table 44 | grep 44.224 44.224.0.0/15 via 141.75.245.225 dev tunl0 proto 44 onlink window 840

1 0

Re: [44net] AMPRNet Interoperability with BGP
by Rob Janssen 17 Jun '15

17 Jun '15

> Subject: > Re: [44net] AMPRNet Interoperability with BGP > From: > Brian Kantor <Brian(a)UCSD.Edu> > Date: > 06/17/2015 08:01 AM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > On Tue, Jun 16, 2015 at 10:47:31PM -0700, Tom Hayward wrote: >> >Good question! No, a change to the portal around the same time >> >prohibits adding 44.xx.xx.xx addresses as gateways. I believe there >> >was some noise on this list about it at the time. > That change was made because > 1) it was reported that 44.x gateway addresses didn't work > 2) it was reported that 44.x gateway addresses caused problems > 3) people were entering 44.x gateway addresses for their IPIP tunnels > instead of the proper commercial IP address of the endpoint. The reason (1 and 2) is that for a typical system that has both a public IP and an AMPRnet IP and is to function on the IPIP mesh, you need policy routing when you want the AMPRnet IP to be reachable from public IP addresses on internet. Normal internet traffic is to go out using the public IP, possibly using NAT, and AMPRnet traffic is to go out via the IPIP tunnels. When such a system is on a source-address filtered internet connection, the default route for outgoing AMPRnet traffic (to 0.0.0.0/0) is to go via an IPIP tunnel to another mesh system that has unfiltered internet access. Typically the system at UCSD. It is preferred that the varying gateway systems are configured only via RIP (usually in a separate route table), and that it is not required to make specific policy routing configuration for gateways. So the policy routing is static for 44.0.0.0/8. This conflicts with the 44.x gateway addresses, because the traffic got incorrectly routed by the routing policy (which is used both for the actual traffic and the encapsulated packets). When people see a way around that (I don't completely oversee if Jann's suggestion will achieve that), it would be no problem when tunnel endpoints exist within 44.x. Please see the example configuration for Linux systems in the wiki and suggest a way how that could be made working without manual "ip rule" entries dedicated to specific gateways. Or else, those "ip rule" entries maybe could be managed by ampr-ripd, that would be fine as well. Aside from that, of course it should still be validated that tunnel endpoints are not within the subnet being tunneled (3). That is simply an error condition. There were some networks that were claimed to be reachable via a tunnel at their first address (Sweden, for example) and there were some entries with tunnel endpoint == tunneled address. The portal should refuse that so that applicants are made aware of their error before such entries are broadcast via RIP and result in encapsulation loops. Rob

4 3

AMPRNet Interoperability with BGP
by Tim Osburn 16 Jun '15

16 Jun '15

So to solve the issue of Existing AMPRnet tunnel users not being able to reach BGP announced 44-net IP Space I've drawing the below drawing that shows how this can be done without having Brian Kantor ask UCSD to make any network/routing changes. This only requires at least 1 (or more) ISP (or companies running BGP) willing to setup a BGP over GRE tunnel to Brian's server to make this work. There are currently two ISP I know of willing to do this if Brian is willing to do this on the AMPRnet Server shown in the drawing. This only requires setting up BGP with a route-map for changing the next hop IP's and running GRE tunnels on his server. The bonus is he can set this up with multiple ISP so that there is redundancy. Since the ISP is only sending BGP routes of the 44 IP Space of size /16-/24, this will not consume very much routing table space on his box (currently 53 prefixes). I also have to imagine the bandwidth going over this GRE tunnels not going to be a huge amount. So to summarize how this work. AMPRnet tunnel users can send traffic to a BGP announced 44 ip space which would travel over their IPIP tunnels (perhaps a low pref 44.0.0.0/8 route to UCSD in rip? or inject the BGP routes into RIP) back to UCSD and then over the GRE tunnel to a ISP and then ride the internet to get to that BGP announced block. Return traffic would just follow the existing internet routing table and come back via the UCSD network. AMPRNet Interoperability with BGP Drawing: https://www.osburn.com/amprnet-150614-1.0.0-bgptunnels.jpg Tim Osburn www.osburn.com W7RSZ

12 26

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net