44net

44net@mailman.ampr.org

3194 discussions

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> Can you ping .254? .255 should go direct and .254 should be > encapsulated to the same machine. No > Do you have an address I can test to? I have been doing a few tests > and it would appear that there are some issues here. 44.137.0.1 should be fine, and 44.137.41.97 as well > Previously I was able to access services that were public the same as > an external host, but now many of those are not working. As an example > 44.137.0.1 works fine from an external IP address, but not a > 44.131.14/24 one. I have found at least 1 host responding to my > encapsulated packets with ICMP Administratively Denied, which makes me > suspect that the problem is actually my anycast setup with my source > address not matching the gateway address. It is. Now I see what is wrong, the firewall log is full of: Apr 6 19:47:01 Packet REJECT: IN=eth0 OUT= SRC=45.63.97.98 DST=213.222.29.194 LEN=104 TOS=0x00 PREC=0x00 TTL=52 ID=19182 DF PROTO=4 That source address apparently belongs to you but it is not the tunnel endpoint. We reject all protocol 4 traffic from hosts not in the RIP broadcast for tunnels. Rob

1 0

Re: [44net] Gatway up
by Rob Janssen 06 Apr '17

06 Apr '17

> We do this for a large percentage of our customers without issue. We route public subnets to customer specific firewalls which then translate those addresses to internal hosts: You are doing NAT. I know this is customary in commercial internet practice but in HAMNET/AMPRnet we don't like NAT. (too much time is wasted by debugging the issues caused by inserting NAT into networks that also have direct routing) Rob

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 06 Apr '17

06 Apr '17

> Now another question about directly connected 44net addresses - is there > a way for them to reach tunneled addresses? I would prefer to have my > services accessible from all 44net addresses when I start offering > something serious later this year. ATM, it appears my /24 would be > unreachable from these addresses, because even if there is a host route > to an endpoint, the 44net address is not exposed to directly connected > endpoints (they see the public IP of my router). And those direct > connected addresses not running tunnels wouldn't reach me for obvious > reasons. When you get BGP routing on internet for a certain subnet, you should install and register an IPIP tunnel gateway for the same subnet as well. Until now this required a public (outside net 44) IP address on the gateway system, but with the mod discussed in this thread you may be able to put the tunnel endpoint inside your BGP routed subnet. Of course it will take some time for all people to pickup the necessary software and configuration changes for this to actually work. So you will still be reachable for only part of the users for some time. Rob

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 05 Apr '17

05 Apr '17

> Now, ampr-ripd does identify this host as directly connected, which > appears to be the expected behaviour with the new version. All well and > good from the Pi, but there is one significant implication - the source > IP is no longer my 44 net IP, but it's the public IP of my router, and > the internal IP is the 10.x IP of the Pi (my regular IP range. I think > that's where things are breaking. Ah yes, it would be better when ampr-ripd added a "src" option with the IP of the tunnel interface to the /32 routes it adds to the table... Rob

2 1

Re: [44net] Gatway up
by Rob Janssen 05 Apr '17

05 Apr '17

> Good morning all, > I seem to have my gatway up (44.131.192.128) > It responds to some of the ampr ping tools in the service list but not others. Could I ask a few of you to ping it and see if you can see it. It works! Note it is a bit controversial to use the first (and last) address of your subnet. You may run into problems sometime. You have a /29 so you should use 6 addresses. Also, please register DNS names for your addresses. Rob

3 2

Returning an assignment
by James Sharp 05 Apr '17

05 Apr '17

I have a small subnet I was assigned by the Florida administration. I have since moved to Nevada. Should I return the assigned block and get a new one from the Nevada coordinator, just to keep things square and straight?

2 1

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Brian Kantor 05 Apr '17

05 Apr '17

Mike, the problem is that the n8lrf gateway has an address on the subnet instead of a commercial IP address and is therefore not reachable. - Brian On Wed, Apr 05, 2017 at 07:43:15AM -0400, Michael Wolthuis wrote: > Rob, > I have managed that subnet since early 90's. What is your concern? You are welcome to be assigned ips on it in Kent County. I have several other subnets for our HamWan project and even an IPv6 assignment from ARIN. > > How can I help meet your goals? > > Feel free to call me at 616-422-5412 or on the 145.27 Lowell repeater > > Mike > KB8ZGL > > Sent from my iPhone > > > On Apr 5, 2017, at 6:13 AM, Brian Kantor <Brian(a)UCSD.Edu> wrote: > > > > I think it's a mistake. It's confusing. The gateway belongs to > > n8lrf(a)comcast.net but the subnet belongs to kb8zgl(a)kb8zgl.net. > > I'm guessing that n8lrf entered a gateway hostname that belongs to the > > ampr side of the gateway rather than the commercial IP. > > - Brian > > > >> On Wed, Apr 05, 2017 at 11:53:40AM +0200, Rob Janssen wrote: > >> But there also is a network 44.102.128.0/24 and it does not work. Is that one okay or is > >> it another config mistake? I suppose so, as its gateway 44.102.128.1 is routed to amprgw. > >> > >> I'm afraid we need better directions and/or safeguards in the portal. > >> > >> Rob > >> _________________________________________ > >> 44Net mailing list > >> 44Net(a)hamradio.ucsd.edu > >> http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 05 Apr '17

05 Apr '17

I have installed the 1.16 on our gateway (without the safeguard for now) and it appears to be doing its thing. I can ping hosts on those test networks. But there also is a network 44.102.128.0/24 and it does not work. Is that one okay or is it another config mistake? I suppose so, as its gateway 44.102.128.1 is routed to amprgw. I'm afraid we need better directions and/or safeguards in the portal. Rob

2 1

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 04 Apr '17

04 Apr '17

> Wouldn't you achieve the same result by adding that network's IP/subnet > to the -a list? Yes, but then I would have to know the offender's IP beforehand :-) However, it would be possible to just delete the route in the -x script that we already have. I think ampr-ripd will not detect that and the route will not be added every 5 minutes, right? Rob

2 1

Re: [44net] New ampr-ripd 1.16 and amprd 1.5 released
by Rob Janssen 04 Apr '17

04 Apr '17

> If the daemon encounters a 44 gateway in the RIP data, it creates a host > route to that specific host via the default gateway of the system. I was thinking about one specific issue: when we run this code on our gateway, which is BGP-routed for our 44.137.0.0/16 network and is on the IPIP network as well and runs ampr-ripd, and some portal user who does not understand the system well, they could add a gateway with an endpoint address inside the 44.137.0.0/16 network and we would add a circular route for that address to our table. Of course users should not do that. But they have done so, in the past. Maybe we would need an option to specify a (list of) subnet(s) where this new mode of operation would not be performed. Then a gateway can set that to the BGP routed network(s) it serves. (similar to the -a option) Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net