I had same problem...make sure the tunnel to UCSD has the correct endpoint that should fix it.

I also created a address list with 44.0.0.1 and 44.0.0.2 in it and used that as the source instead of 44.0.0.1 in the firewall filter as Ruben suggests.

Leon

On 6/6/2017 8:17 AM, Ruben ON3RVH wrote:

Jacek,

Check your routing table. There probably is a route to 44.0.0.1 & 44.0.0.2 in your routing table pointing towards IPIP interfaces. Delete those routes and interfaces and insert 44.0.0.1 & 44.0.0.2 in the filters for RIP with action reject or ignore. That should fix everything and your RIP table will be populated again after 5 min orso and you should be golden.

If you need the exact commands for the RIP filters, let me know and I'll forward them once I get home tonight.

Ruben - ON3RVH

...

On 6 Jun 2017, at 14:08, Jacek Grzona sp2gch@gmail.com wrote:

Hello. Is there any probel for a few days with yo2loj script? For a few days I receive such a return in the logs of the mikrotik "Jun / 06/2017 13:21:00 script, error AMPR: To few RIP entries available" Regards SP2GCH

No właśnie zastanawiam się czy nie został zmieniony adres IP tunel UCSD?

SP2GCH

2017-06-06 14:36 GMT+02:00 lleachii--- via 44Net 44net@hamradio.ucsd.edu:

Can someone explain exactly how the 44.0.0.2/32 route is causing an issue on the tiks?

Because that route could have been removed Monday anyway, as it would no longer be needed if the migration was completed.

Did all services and routing move to New_AMPRGW yesterday?

73,

• Lynwood

KB3VWG

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

Ruben,

I'm trying to understand how tunneling works on various OSes. Many thanks.

OK, this issue could only be solved at migration. Similar to the Cisco, your devices use multiple tunnels; apparently linked to the subnets routed to them. I understand standard RIPv2 considers where the announcement was received to be it's ENCAP Gateway. This needs to be placed in the Wiki too. *This an anomaly due to the workaround on Mikrotik.*

- Lynwood KB3VWG

If it gets in the RIP table, the tik script will autoadd an IPIP tunnel for it towards the new gateway (and 44.0.0.1 to the old gw) This renders all future RIP broadcasts from 44.0.0.2 & 44.0.0.1 non functional.

Lynwood--if you are using a mikrotik device, then the solution is to use Marius' solution of scripts that work 100%

leon wa4zlw

On 6/7/2017 8:43 AM, lleachii--- via 44Net wrote:

Ruben,

Can you provide sample command(s) to setup a tunnel to a subnet on AMPRNet?

Do you have to include routing table, "zones," etc?

• Lynwood

KB3VWG

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

--- This email has been checked for viruses by AVG. http://www.avg.com

Leon,

Thanks, I am trying to borrow a Mikrotik from a friend to understand the subnet-linked-to-tunnel thing more clearly.

I do indeed want to review Marius' scripts; but I wanted to do some research myself - prior.

Just as our good friend suggested, I don't want to run a script I don't yet understand.

73,

- Lynwood KB3VWG

Lynwood--if you are using a mikrotik device, then the solution is to use Marius' solution of scripts that work 100%

Lynwood,

The philosophy about that script is quite simple:

First, there is an isolated interface (usually called uscd-gw and the isolated virtual space is called VRF in mikrotik language) which has the gateway ip with netmask /8 (very important) which will receive RIP and is the base IPIP tunnel to 169.228.34.84. This VRF has a route tag, i use 44rip for it, and will place all received RIP routes in the 44rip routing table (this has no effect on the actual routing).

The script parses these dynamic RIP routes and does 4 things:

- creates an IPIP interface for each gateway, one endpoint being the local IP, the other being public gateway address of the mesh tunnel. Interfaces are called ampr-<gateway_ip> (except for 44.0.0.1 which gets dropped by a RIP filter - we already have that tunnel from the beginning).

- creates a static route via the systems default gateway if the endpoint is in the 44net space, thus serves a BGP routed subnet.

- creates a static route in the main routing table for the serviced subnet via the proper IPIP tunnel

- adds the interface to a interface list so that can be used for firewalling purposes (not very important, but useful)

Of course, it checks if gateways and subnets get added or get deleted, and adds/removes the appropriate entries for them.

Additional to this, the user has to ensure the following: - provide a 88.0.0.0/8 route for 44net addresses which do not fit any tunnel (BGP announced without tunnel interfacing). This could be either via the ucsd-gw tunnel, or via the default ISP gateway with NAT . - If one needs access from the internet, incoming connections via ucsd-gw need to get a connection mark and the replies a routing mark, so they can be routed back to the ucsd-gw tunnel. For this, for this routing mark, a default route has to be set up via 169.228.34.84.

I hope this helps to understand the inner working of the Tick script.

Marius, YO2LOJ

On 07.06.2017 18:17, Ruben ON3RVH wrote:

Very good policy Lynwood!

Part of my config:

/ip route add distance=1 dst-address=44.0.0.0/8 gateway=ucsd-gw pref-src=44.144.48.1 routing-mark=44rip add distance=2 gateway=194.50.91.30 pref-src=194.50.91.2 add comment="Added on 2017/06/06 17:30:14" distance=50 dst-address=44.2.2.0/24 gateway=ampr-216.218.207.198 pref-src=44.144.48.1 add comment="Added on 2017/06/06 17:30:14" distance=50 dst-address=44.2.7.0/30 gateway=ampr-73.185.12.233 pref-src=44.144.48.1 ....

/interface ipip add allow-fast-path=no disabled=yes !keepalive local-address=194.50.91.2 name=OLD_UCS_GW remote-address=169.228.66.251 add comment="Added on 2017/06/06 17:30:14" !keepalive local-address=194.50.91.2 name=ampr-216.218.207.198 remote-address=216.218.207.198 add comment="Added on 2017/06/06 17:30:14" !keepalive local-address=194.50.91.2 name=ampr-73.185.12.233 remote-address=73.185.12.233

--

That's about it for the IPIP tunnel and route towards it. There is also a dynamic route for those subnets, but those get advertised by RIP as you well know. But I omitted that part of the config as the script will go through all RIP routes and create a tunnel for each RIP route and a static route towards that IPIP tunnel.

73,

Ruben - ON3RVH

-----Original Message----- From: 44Net [mailto:44net-bounces+on3rvh=on3rvh.be@hamradio.ucsd.edu] On Behalf Of lleachii--- via 44Net Sent: woensdag 7 juni 2017 16:06 To: 44net@hamradio.ucsd.edu Cc: lleachii@aol.com Subject: Re: [44net] Mikrotik

Leon,

Thanks, I am trying to borrow a Mikrotik from a friend to understand the subnet-linked-to-tunnel thing more clearly.

I do indeed want to review Marius' scripts; but I wanted to do some research myself - prior.

Just as our good friend suggested, I don't want to run a script I don't yet understand.

73,

• Lynwood

KB3VWG

...

Lynwood--if you are using a mikrotik device, then the solution is to use Marius' solution of scripts that work 100%

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net

Marius,

Thanks my friend, I highly value your dedication to the AMPRNet. I will take time to review the Tik, Cisco, etc. scripts.

I want to understand how the OP's nodes work for them, their OSes, Kernel module(s), RIP44 system/user applications, etc.

73,

- Lynwood KB3VWG

The philosophy about that script is quite simple

Tom,

So you're good to go?

If so, take a look at the Startampr Wiki, and perhaps the Starting a Gateway on Linux Wiki, lets clean those pages up a little bit, etc.

73,

- Lynwood KB3VWG

I didn't remove the 44.0.0.2/32 route until this morning - sorry, had other things on my mind. But it shouldn't have caused any difficulties while it was there.

All services and routing have been moved to the new amprgw on 169.228.34.84. - Brian

On Tue, Jun 06, 2017 at 08:36:04AM -0400, lleachii--- via 44Net wrote:

Can someone explain exactly how the 44.0.0.2/32 route is causing an issue on the tiks?

Because that route could have been removed Monday anyway, as it would no longer be needed if the migration was completed.

Did all services and routing move to New_AMPRGW yesterday? 73,

• Lynwood

KB3VWG

It is simple. When the move started, I published a workaround for using both gateways by creating an additional gw interface and apply some connection/packet marks on it, so that outgoing 44 to internet traffic would go via tunnel.

Now this new route appeared and created a tunnel with the same endpoint parameters which took precedence over the old one, being newer. So incoming traffic via the old gateway never got its connection/packet marks and responses never got out via tunnel (old or new, it doesn't matter).

Can someone explain exactly how the 44.0.0.2/32 route is causing an issue on the tiks?

Because that route could have been removed Monday anyway, as it would no longer be needed if the migration was completed.

Did all services and routing move to New_AMPRGW yesterday?

73,

• Lynwood

KB3VWG

Well, I'm wondering if the UCSD tunnel IP address was changed?

SP2GCH

2017-06-06 14:41 GMT+02:00 Jacek Grzona sp2gch@gmail.com:

44.0.0.1 & 44.0.0.2 I do not have in the routing table. If I get an error in the script right away in the routing table I am reducing the IP list. If it is possible then please be very careful about the filters. I have the following entries in the Routing-> prefix lists tab: "Chain ampr, prefix 44.0.0.1, prefix length 32 discard Chain ampr, prefix 44.0.0.0/8, prefix length 8-32 accept Chain ampr, prefix 0.0.0.0/0, prefix length 0-32 discard "

SP2GCH

2017-06-06 14:17 GMT+02:00 Ruben ON3RVH on3rvh@on3rvh.be:

...

Jacek,

Check your routing table. There probably is a route to 44.0.0.1 & 44.0.0.2 in your routing table pointing towards IPIP interfaces. Delete those routes and interfaces and insert 44.0.0.1 & 44.0.0.2 in the filters for RIP with action reject or ignore. That should fix everything and your RIP table will be populated again after 5 min orso and you should be golden.

If you need the exact commands for the RIP filters, let me know and I'll forward them once I get home tonight.

Ruben - ON3RVH

...

On 6 Jun 2017, at 14:08, Jacek Grzona sp2gch@gmail.com wrote:

Hello. Is there any probel for a few days with yo2loj script? For a few days I receive such a return in the logs of the mikrotik "Jun / 06/2017 13:21:00 script, error AMPR: To few RIP entries

available"

...

Regards SP2GCH

It works! is beautifully. Thank you for the new UCSD IP address.

SP2GCH

2017-06-06 15:24 GMT+02:00 Brian Kantor Brian@ucsd.edu:

Yes it has. It is now 169.228.34.84. I've talked of little else for the past few weeks. - Brian

On Tue, Jun 06, 2017 at 02:43:47PM +0200, Jacek Grzona wrote:

...

Well, I'm wondering if the UCSD tunnel IP address was changed? SP2GCH

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net