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
> My understanding is that it's working correctly, because the icmp reply
> is sent back to 2.238.198.249 inside the tunnel and towards the
> amprnet router (169.228.66.251).
> Unfortunately there's something wrong in the middle because no packets
> are actually reaching 2.238.198.249
It must be something in your 2.238.198.249 system or the path to it, because
I can ping 44.134.160.1 without problem from other internet hosts.
Rob
I don't remember seeing PHPIPAM mentioned here before. (And I searched...)
https://phpipam.net/
Perhaps it would be useful - if not for the overall process for local
or regional LANS.
73
Bill, WA7NWP
