6 Jun
2017
6 Jun
'17
8:07 a.m.
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
6 Jun
6 Jun
8:17 a.m.
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(a)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
>
8:24 a.m.
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(a)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
>>
8:36 a.m.
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
8:43 a.m.
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(a)hamradio.ucsd.edu>du>:
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
8:43 a.m.
Lynwood,
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. From
my firewall logs where I accept and log RIP, it shows the packets from the gateways but no
RIP broadcasts untill I remove those tunnels and routes
Ruben - ON3RVH
On 6 Jun 2017, at 14:36, lleachii--- via 44Net
<44net(a)hamradio.ucsd.edu> 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
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
7 Jun
7 Jun
7:14 a.m.
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.
8:43 a.m.
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
8:46 a.m.
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
---
This email has been checked for viruses by AVG.
http://www.avg.com
9:13 a.m.
Indeed, marius's script works like a charm
http://www.yo2loj.ro/hamprojects/ampr-gw-README.txt
&
http://www.yo2loj.ro/hamprojects/ampr-gw-3.1.rsc
73,
Ruben - ON3RVH
-----Original Message-----
From: 44Net [mailto:44net-bounces+on3rvh=on3rvh.be@hamradio.ucsd.edu] On Behalf Of Leon
Zetekoff
Sent: woensdag 7 juni 2017 14:46
To: 44net(a)hamradio.ucsd.edu
Subject: Re: [44net] Mikrotik
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
---
This email has been checked for viruses by AVG.
http://www.avg.com
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
10:05 a.m.
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%
11:17 a.m.
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(a)hamradio.ucsd.edu
Cc: lleachii(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
12:42 p.m.
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(a)hamradio.ucsd.edu
Cc: lleachii(a)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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
1:36 p.m.
Small correction.
The route is 44.0.0.0/8, not 88...
On 07.06.2017 19:42, Marius Petrescu wrote:
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 .
7:32 p.m.
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
8 Jun
8 Jun
4:32 a.m.
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
9:54 a.m.
Yes. I will work with you to update the pages...
--tom
Tom Cardinal/N2XU/MSgt USAF (Ret)/BSCS/CASP, Security+ ce
On 6/8/2017 03:32, lleachii--- via 44Net wrote:
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
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
6 Jun
6 Jun
9:21 a.m.
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
9:25 a.m.
Well, that would be fine, because I have this IP address in UCSD
169.228.66.251
SP2GCH
2017-06-06 15:21 GMT+02:00 Brian Kantor <Brian(a)ucsd.edu>du>:
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
_________________________________________
44Net mailing list
44Net(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
9:50 a.m.
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
8:41 a.m.
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(a)on3rvh.be>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(a)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
> >
8:43 a.m.
Well, I'm wondering if the UCSD tunnel IP address was changed?
SP2GCH
2017-06-06 14:41 GMT+02:00 Jacek Grzona <sp2gch(a)gmail.com>om>:
> 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(a)on3rvh.be>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(a)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
>> >
9:28 a.m.
It works! is beautifully. Thank you for the new UCSD IP address.
SP2GCH
2017-06-06 15:24 GMT+02:00 Brian Kantor <Brian(a)ucsd.edu>du>:
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net
2535
days inactive
2537
days old
24 comments
8 participants
participants (8)
-
Brian Kantor -
Jacek Grzona -
Leon Zetekoff -
lleachii＠aol.com -
Marius Petrescu -
marius＠yo2loj.ro
-
Ruben ON3RVH -
Tom Cardinal