> Belows IP's belong to SR3BBS gateway
> which _IS OFF LINE_ for a long time!
Then why is it in the table?
Maybe it should again be considered to add a mandatory field to a
gateway registration with a net-44 IP that should be pingable via the tunnel
(e.g. the IP of the gateway itself) and run some very infrequent ping
to that address from a monitoring system that is also on the tunnel network
(not amprgw as some people apparently choose not to tunnel to that system).
When e.g. one ping per hour is made and nothing is heard for 7 days or even more,
the gateway can be marked down and removed from the encap.txt and RIP broadcast.
The operator can then re-enable it via the portal.
Rob
Hi everybody,
Just to clarify the issues related to "strange routes" appearing during
the use of the rip daemons.
Together with Jann, DG8NGN, we devised a solution for interoperating BGP
announced 44 subnets with the current full mesh tunnel system.
Initially I implemented the system for testing and proof of concept in
the Mikrotik script v.3.0, and later in the ampr-ripd starting with
version 1.16 and amprd version 1.5.
Current versions are 1.16.3 for ampr-ripd (bug fixes and small
enhancements) and 1.6 (bug fixes), please use these.
Now to the idea behind it...
Directly BGP announced gateways need to be reached, well, directly, as
any other gateway.
If we have a default route by which we could reach the BGP announced
hosts (via your public IP, please don't use default routes via amprgw!),
on installing a subnet route via the RIP daemon, e.g. 44.130.121.0/24
(it is a working test host) then the endpint 44.130.121.2 will also be
routed via the tunnel, creating a loop, which is of course wrong.
So ampr-ripd will detect your default gateway on the system, and set
host routes for those direct gateways via the default gateway, if the
RIP announced gateway has a 44 address.
The detection of the default gateway is done by getting the route to
8.8.8.8 from your kernel tables.
So you will end up with 2 routes for that entry, like:
44.130.121.0/24 via 44.130.121.2 dev tunl0 proto 44 onlink
44.130.121.2 via 192.168.1.1 dev eth0 proto 44 onlink.
In this case, traffic for those subnets (in this case to
44.130.121.0/24) will be encapsulated and sent directly to 44.130.121.2,
which is reachable via internet.
It is expected that your system will nat those destinations to your
public IP (which probably happens).
If the detection of your default gateway is not correct, there is a
parameter '-g' by which you can set your gateway IP by hand.
Your internal addresses are not published, nor are the known to the
gateway. It is a local lookup performed by the daemons.
At the moment there are 4 functional gateways using this setup:
44.130.121.2, 44.130.122.2, 44.130.124.2 (as test systems) and
44.131.14.255 as a live setup.
Reachable tests hosts are: 44.130.121.3, 44.130.121.130, 44.130.122.3,
44.130.122.130, 44.130.124.3, 44.130.124.130, and of course the end points.
(44.130.121.2 runs amprd, 44.130.122.2 runs ampr-ripd and 44.130.124.2
runs the Mikrotik script).
I hope this clarifies some of the questions that may arise.
Have fun with the hobby,
Marius, YO2LOJ
amprgw has recently logged several discarded packets like the following:
Apr 24 18:44:03 <local0.info> amprgw ipipd[1518]: IBCAST: len 149, os 208.110.114.235, od 169.228.66.251, is 44.135.193.18, id 255.255.255.255, ttl 64, proto 17
encapped packets aren't supposed to send to the broadcast address (255.255.255.255).
Apr 24 18:44:05 <local0.info> amprgw ipipd[1518]: ISRC0: len 122, os 77.138.34.39, od 169.228.66.251, is 0.0.0.0, id 255.255.255.255, ttl 64, proto 17
encapped packets aren't supposed to come from address 0.0.0.0 and
encapped packets aren't supposed to send to the broadcast address (255.255.255.255).
Apr 24 18:44:06 <local0.info> amprgw ipipd[1518]: TIMXCEED: len 52, os 85.234.252.133, od 169.228.66.251, is 44.165.53.254, id 224.0.0.9, ttl 1, proto 17
Looks like a routing loop on RIP packets.
Ah well, variety is the spice of life...
- Brian
> Yes, it was intentionally dropped by the daemons. If it will be
> reachable, I will update the code accordingly.
I see it in the code now, just a couple of lines that can be deleted around line 1346:
/* drop 44.0.0.1 */
if (rip->address == inet_addr("44.0.0.1"))
{
#ifdef HAVE_DEBUG
if (debug && verbose) fprintf(stderr, " - rejected\n");
#endif
return;
}
A temporary workaround until everyone has again updated ampr-ripd could be to
announce 44.0.0.0/30 instead of 44.0.0.1/32 in the RIP sender.
Rob
> ampr-ripd does not set a route for 44.0.0.1, because that IP is not
> reachable via the tunnel, only via the internet.
Ah, it is treated as a special case?
Brian has been working on that problem and now this route is announced again.
(it had been deleted from the RIP broadcast before)
I think it is added in the RIP sender, maybe it would be better to just register
a portal entry so it is in encap.txt as well.
Rob
What you logged there are probably DHCP packets and private use of RIP, not the AMPR-RIP.
Well, I do see a lot of those things here either...
Recently I again worked on the filters and found e.g.:
- router-sourced traffic with inner source address equal to the external IP (bad source address selection)
- router sending some of the traffic outside of the tunnel (net-44 to net-44 traffic unencapsulated)
the funny thing is that e.g. when pinging them it returns via the tunnel but when doing BGP the
SYN ACKs from port 179 come outside the tunnel. when the sender had proper source address filtering
at their ISP I would not see those packets at all.
- of course still a lot of traffic with inner source address in RFC1918 range
The first two above are blamed on "MikroTik VRF". I never use it, I always use a manual implementation
using multiple routing tables, ip routing rules and maybe some mangle rules just as I am used to do
on bare Linux, and I don't have those problems.
Another group swears by VRF and they always have issues.
As I believe MikroTik VRF is just an an automatic configuration of the mentioned features and
it apparently does not work completely OK (and may need some help e.g. some extra mangle rule).
I tried to get information on what really happens when you define a VRF, but I was unable to
get answers.
Rob
> Yes, there was an off-by-one error in the count of entries in
> the last packet. This error was not present when we were sending
> in gateway major order, but was there in packet-major-order which
> change I made early today. It has been corrected. Please check
> the next RIP update and see if that fixes things.
Ok, now I get the correct RIP packet :-)
But the entry still does not appear in the route table... :-(
IP Address: 44.2.2.0, Metric: 1
Address Family: IP (2)
Route Tag: 4
IP Address: 44.2.2.0 (44.2.2.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 24.52.189.1 (24.52.189.1)
Metric: 1
IP Address: 44.0.0.1, Metric: 1
Address Family: IP (2)
Route Tag: 4
IP Address: 44.0.0.1 (44.0.0.1)
Netmask: 255.255.255.255 (255.255.255.255)
Next Hop: 169.228.66.251 (169.228.66.251)
Metric: 1
44.0.0.0/8 via 213.222.29.193 dev eth0 src 44.137.0.1
44.2.2.0/24 via 24.52.189.1 dev tunl0 proto ampr-ripd metric 4 onlink
So now I can continue local debugging to see what is going wrong...
It fails both on the gateway (running latest ampr-ripd) and the Raspberry Pi
(running earlier version).
It does not appear in /var/lib/ampr-ripd/encap.txt either.
Never assume there is only one bug...
Rob
> Yes, that's very much a mystery, because my tcpdump shows the route
> being sent right after the one for 44.2.2.0/24.
> [...]
> AFI IPv4, 44.2.2.0/24, tag 0x0004, metric: 1, next-hop: 24.52.189.1
> AFI IPv4, 44.0.0.1/32, tag 0x0004, metric: 1, next-hop: 169.228.66.251
Could there be some length or count field that is off by one?
I am tracing with wireshark (tshark). But ampr-ripd does not pick it up either.
Rob
> Because of concern that the rip sender might be sending
> the pseudo-RIP packets to gateways faster than they can
> receive them, I have changed the sending order.
> ...
> This has the effect of inserting a few milliseconds delay
> between consecutive packets being sent to any one gateway,
> which should give the receiving process more time to handle
> the transmission.
My main concern was not the receiving process, but the routers
in front of the gateway system that (in my case) appeared to
drop the tail end of the transmission, probably because of
rate limiting or a queue overflow.
Now, I get the 26 packets in about 150ms, which should solve
that problem for anything but the slowest connections. Thanks!
Unfortunately there is still no 44.0.0.1 route. I did a trace
and confirm that the last packet received has the lowest addresses,
but it ends with:
IP Address: 44.2.7.0, Metric: 1
Address Family: IP (2)
Route Tag: 4
IP Address: 44.2.7.0 (44.2.7.0)
Netmask: 255.255.255.252 (255.255.255.252)
Next Hop: 73.185.12.233 (73.185.12.233)
Metric: 1
IP Address: 44.2.2.0, Metric: 1
Address Family: IP (2)
Route Tag: 4
IP Address: 44.2.2.0 (44.2.2.0)
Netmask: 255.255.255.0 (255.255.255.0)
Next Hop: 24.52.189.1 (24.52.189.1)
Metric: 1
Still some mystery somewhere :-)
Rob
Because of concern that the rip sender might be sending
the pseudo-RIP packets to gateways faster than they can
receive them, I have changed the sending order.
There are currently 26 packets per gateway per transmission.
Instead of sending all packets to a gateway, then sending
them to the next gateway, and so on, now each packet is
sent to each individual gateway before the next packet is
generated and sent.
This has the effect of inserting a few milliseconds delay
between consecutive packets being sent to any one gateway,
which should give the receiving process more time to handle
the transmission.
The same total data is sent, so nobody should miss out on
any routes.
Thanks to Rob, PE1CHL for suggesting this technique.
- Brian
