44net

44net@mailman.ampr.org

3198 discussions

documentation of gateway move
by Michael Fox - N6MEF 27 May '17

27 May '17

I can find where the new amprgw info is documented. Shouldn't the old/new hostname, external IP address and cut-over date appear prominently somewhere? Michael N6MEF

3 4

Re: [44net] Good News! and some changes coming
by Rob Janssen 27 May '17

27 May '17

> Yes, it's on the same box, but because the two boxes are on physically > different networks, I can configure them both to be 44.0.0.1 without > conflict. One of them won't get any packets except those originating > on its own physical network, but they won't conflict. That's what I've > done; when the 44/8 route next hop is moved from old amprgw to new amprgw, > which machine serves 44.0.0.1 to the outside will automatically change. I think when you announce 44.0.0.1 with the new gw address on the gateways list (encap, RIP) and keep the 44.0.0.0/8 BGP pointed to the old box, users with a tunnel will connect to the new box and those connecting from internet will get the old box, without any conflict or need to re-route things inside the campus network. That makes it possible to test tunnels two-way. But it is not that important, it will probably work right away and obvious mistakes will be found and fixed within one or some days, which is good enough. I have been doing quite some rebuilding lately, short downtimes sometimes are unavoidable when working within hobby constraints. Rob

1 0

Re: [44net] documentation of gateway move
by Michael Fox 27 May '17

27 May '17

Yes, thanks.M Sent from my Verizon, Samsung Galaxy smartphone -------- Original message --------From: Brian Kantor <Brian(a)UCSD.Edu> Date: 5/26/17 18:31 (GMT-08:00) To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] documentation of gateway move (Please trim inclusions from previous messages) _______________________________________________ I assume you meant "can't". Updates to the wiki are in progress. I think there ought to be an 'amprgw' page on the wiki, but there isn't one yet. I'll try to get to writing one soon. - Brian old address: 169.228.66.251 old hostname: amprgw.sysnet.ucsd.edu New address: 169.228.34.84 New hostname: AMPRGW.UCSD.EDU Cutover date: TBD On Fri, May 26, 2017 at 06:20:34PM -0700, Michael Fox - N6MEF wrote: > I can find where the new amprgw info is documented. > Shouldn't the old/new hostname, external IP address and cut-over date appear > prominently somewhere? > Michael > N6MEF _________________________________________ 44Net mailing list 44Net(a)hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

1 0

Re: [44net] Good News! and some changes coming
by Rob Janssen 27 May '17

27 May '17

> I've already tested the 44.0.0.1 address using loopback and it > works ok, and I've tested inbound using 44.128.0.1, and it > works ok too. I think things will be ok. > I don't like to bother the campus networking people more than I have to. Ah, I thought that 44.0.0.1 was running on the same machine as amprgw and would be moved as well... so that ciould be done before. Apparently it is a different box. Rob

2 1

Re: [44net] Good News! and some changes coming
by Rob Janssen 27 May '17

27 May '17

> Don't most hosts and routers ignore ICMP Redirects > out of security concerns these days? Certainly for such external addresses. Locally on the LAN it usually works. (e.g. when you have two routers and one sends redirects to the address of the other, both in the local subnet) Rob

1 0

Re: [44net] ampr-ripd 2.0 released Marius Petrescu marius at yo2loj.ro
by Rob Janssen 26 May '17

26 May '17

> - brought back option -r, to allow using multicast sockets by default > and raw sockets as a backup for systems with multicast issues. This will > hopefully sort out the firewall filtering inability on previous releases > since 1.13. I had to put back the -r option that I had cleaned up from my start script as it still does not work with the multicast socked on Debian Linux with kernel 3.16. I remember it failed after some kernel update and it apparenty is still broken. However, I do not mind using the -r option, only want to remind people that they may need to put it back. Rob

4 22

Re: [44net] Good News! and some changes coming
by Rob Janssen 26 May '17

26 May '17

We do not send outgoing traffic via amprgw so no change is necessary, but I updated the address on our info page (that says "use our address instead of 169.228.66.251 as your default gw"). It would probably be a good idea to change the route for 44.0.0.1 before the incoming routes are switched over, so it can be tested from the inside. Rob

2 1

Warning - Bad Startampr/Linux Scripts on Internet
by lleachii＠aol.com 26 May '17

26 May '17

All, It's my understanding that there are multiple copies of the original Startampr script on the Internet. What I have not noticed until alerted by two operators that attempted to implement those copies in their devices, are the following: - Scripts NOT distributed from my site at http://44.60.44.10 ON AMPRNET include the misuse of the -a argument to run the RIP44 daemon(s). - The syntax used on the Internet scripts ('use -a argument to remove your allocation from the table' by a. specifying WAN IP IN rip44d; vs b. specifying 44 allocation CIDR IP as in ampr-ripd, are reversed. - This appears to be a documentation bug made by a copier who used my original scripts (made for rip44d) and converted them to work for ampr-ripd. - if you use my scripts placing lookups for your local 44 LAN in the main table, this issue wouldn't affect you 73, -Lynwood KB3VWG

1 1

Re: [44net] ampr-ripd 2.0 released Marius Petrescu marius at yo2loj.ro
by Rob Janssen 26 May '17

26 May '17

> >/Everyone is free to use the -g option if needed /> Yes, but is eth0.2 a valid entry? The parameter of -g is an IP address. It it not the IP address of an interface but of the gateway to the internet. So specifying an interface like eth0.2 does not make sense. You could use something like this: .... -g `ip route list | grep '^default' | sed -e 's/.*via //' -e 's/ .*//'` Rob

2 1

Re: [44net] non-operational gateways
by Rob Janssen 26 May '17

26 May '17

> Thinking about this, I recall that I run an IPv6 tunnel with Hurricane > Electric in the same manner. They require that I allow ICMP - Echo > Request to the border. The tunnel doesn't come online at their end, > until they receive an Echo Reply from the IP I specified (either > statically or with DDNS). > Just a rule used by one ISP. I think it is not required to allow pings to the outside address, and it may be difficult for some people to fulfill that requirement (as it may be part of the setup of their ISP router to disallow these). Instead, I would like to see that pings to at least one of the gatewayed addresses are allowed (a net-44 address inside one of the subnet(s) routed to that gateway). This is also much more indicative of a functioning gateway. In the IPv6 tunnel example that would mean allowing ping to one IPv6 address. Of course our problem is that we never asked the gateway operators for the address of their gateway on net-44. So that would have to be added in the form, the database and the encap file (or some other file). Rob

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net