44net

44net@mailman.ampr.org

3170 discussions

How to modify the mikrotik scripts to work in current "dual gateway" setup

by Marius Petrescu

Hi guys, I tried to set up my router so match the current situation, so here are the steps to get it working: 1. add a filter to Routing->prefix lists to drop 44.128.0.0/16, prefix length 16-32, similar to the one for 44.0.0.1 (IMPORTANT - the dynamic created ampr-169.228.34.84 would interfere with our tunnel base interface , having the same IP endpoint and taking precedence over it being newer) For the RIP protocol, you should now have drops on 44.0.0.1 pref len 32, 44.128.0.0 pref. len 16-32 and your local subnets (if any are there), accept the rest. 2. Change your endpoint in the current ucsd-gw interface from 169.228.66.251 to 169.228.34.84 3. Delete the interface ampr-169.228.34.84 in Interfaces 4. Delete the now invalid route to 44.128.0.0 in IP->Routes Wait a while for the first RIP update. Mesh access should work fully now and you should see RIP updates in Routing->RIP->Routes If you need access from internet to your 44net hosts, these are the additional steps: 3. Add a new IPIP interface, lets say 'ucsd-gw-old' with endpoint 169.228.66.251 (like the old one) 4. Add an unused 44 local ip other than your gateway IP witm mask /32 to the 'ucsd-gw-old' interface in IP->Addresses 5. Add similar connection marks as the ones for ucsd-gw for uscd-gw-old under IP->filter->mangle 6. Check your firewall filters to allow incoming connections from ucsd-gw-old like tho ones from ucsd-gw (input and forward) These latter changes will be removed after full switch to the new gateway. Marius, YO2LOJ

7 years, 7 months

Good News! and some changes coming

by Brian Kantor

Good News! Our friends in the CAIDA research group at UCSD have come up with a new machine for amprgw, quite a bit newer than the existing one, and with faster CPU, more cores, and more memory. It also has RAIDed disk and dual power supplies, although unlike the current amprgw, it won't be on a UPS. (There isn't a UPS in the new building where the new machine is located. Luckily our power is pretty reliable; besides buying utility power, UCSD also generates its own from solar and natural gas sources. And we don't have lightning storms very often here in the almost-desert.) There will be some minor differences between the machines, of course, although small enough that I hope to move all the services over from the old machine to the new one over the next several weeks. The primary difference is that the gateway will have a NEW ADDRESS and a slighly DIFFERENT NAME. Instead of being known as 'AMPRGW.SYSNET.UCSD.EDU' as the current one on address 169.228.66.251 is known, the new machine will be 'AMPRGW.UCSD.EDU' (no 'sysnet' in the name), and will be on address 169.228.34.84. You should probably adjust your firewalls soon, letting both machines in for a while, as they will both be operating at the same time as services are moved from old to new. Do not move your tunnel endpoints to the new machine quite yet; that won't work until the routing software is installed and reconfigured for the new address. I'll let you know what it's ready for that. - Brian

7 years, 7 months

documentation of gateway move

by Michael Fox - N6MEF

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

7 years, 7 months

Re: [44net] Good News! and some changes coming

by Rob Janssen

> 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

7 years, 7 months

Re: [44net] documentation of gateway move

by Michael Fox

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

7 years, 7 months

Re: [44net] Good News! and some changes coming

by Rob Janssen

> 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

7 years, 7 months

Re: [44net] Good News! and some changes coming

by Rob Janssen

> 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

7 years, 7 months

Re: [44net] ampr-ripd 2.0 released Marius Petrescu marius at yo2loj.ro

by Rob Janssen

> - 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

7 years, 7 months

Re: [44net] Good News! and some changes coming

by Rob Janssen

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

7 years, 7 months

Warning - Bad Startampr/Linux Scripts on Internet

by lleachii＠aol.com

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

7 years, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net