Hello,

On Wed, May 17, 2017 at 10:11:26AM -0700, Brian Kantor wrote: [..]

would seem to be the case. Perhaps someone in the path between us and Germany inserted a protocol 4 block, or perhaps the German router crashed and lost its routing tables.

No reply from Germany yet either.

well, I've read it, but I was not able to send an adaequate answer:

we learn the ipip routes at db0fhn. I checked that I could ping a host via that ipip tunnel. I also testet that host from a subnet behind db0fhn. And I tested to ping db0fhn.ampr.org from the internet; success. You said you cannot see inbound traffic from db0fhn. Well, in the first case (ipip mesh to another 44'er host) goes "direct", thus not via ucsd.edu. What kind of traffic do you expect? The rest of 44/8 that is not ipip and not direct-bgp? Actually, db0fhn routes non-advertised 44-ipip-routes (and non-44-hamnet-networks) to the internet (because non-ipip and non-hamnet is either direct-bgp or not-in-use). Perhaps, Jann has changed the 44/8 route; we need to wait for his answer.

vy 73, - Thomas dl9sau

Thomas, thank you for your reply. So outbound non-44 destinations from 44.130.0.0/16 are routed out onto the internet at db0fhn instead of being sent to amprgw? But the return path has to go through amprgw. This is non-symmetric routing and I wasn't expecting it. (It's not a problem.)

I have noted in the past that the link was often busy, and I expected it would be busy in both directions. If it's not used for outbound from 44.130.0.0/16, that would explain what I'm seeing for that gateway.

I was worried that something had gone wrong somewhere because the overall inbound encap traffic dropped by 90% or more suddenly at 19:00-19:15 on Tuesday. Whatever happened did so quickly. I thought it was the db0fhn gateway that malfunctioned but I could be wrong. I'll have to look elsewhere.

You can see this sudden drop in the graph at 19:00 May 16 on https://gw.ampr.org/router/encapinpkt.svg - Brian

On Wed, May 17, 2017 at 09:54:47PM +0200, Thomas Osterried wrote:

What kind of traffic do you expect? The rest of 44/8 that is not ipip and not direct-bgp? Actually, db0fhn routes non-advertised 44-ipip-routes (and non-44-hamnet-networks) to the internet (because non-ipip and non-hamnet is either direct-bgp or not-in-use). Perhaps, Jann has changed the 44/8 route; we need to wait for his answer.

vy 73,

• Thomas dl9sau

As a byproduct of the way that I'm routing the traffic for 44.0.0.1 (a special case) it won't work without a DNS entry. Maybe I can find a way around that, but it's not straightforward. No, I don't think DNS entries should be a requirement for intra-mesh communication.

It would be nice if everyone did register on the DNS, though. :-) - Brian

On Wed, May 17, 2017 at 11:46:00PM +0200, Jann Traschewski wrote:

Since you implemented some interesting services, I just set a manual route until Marius will change the ampr-ripd (maybe the upcoming weekend). I successfully tested access to gw.ampr.org from the HAMNET, however it would be nice if that would even work from hosts without valid DNS entries or do you think DNS entries should be a requirement even within the IPIP mesh?

Maybe some botnet blacklisted 44.0.0.0/8?

On 18.05.2017 01:46, Brian Kantor wrote:

(Please trim inclusions from previous messages) _______________________________________________ Well, turns out the German gateway is ok, but that leaves the question of what happened to the incoming encap traffic unanswered. I'd very much like to know what caused the sharp decline in inbound encap packets between 19:00 and 19:15 UTC on Tuesday 05-16. What went offline?

https://gw.ampr.org/router/encapinbytes.svg

• Brian

---

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

Interesting. I've not analyzed the crud to that level of detail as there is simply too much of it for manual inspection and I haven't written any automation to do it.

However, the accepted/rejected ratio didn't change much around that moment, so I don't think we're suddenly exempt from inbound crud. There's no sudden large change in the graph.

It's interesting that you're not seeing as much as usual, but I think that amprgw is. - Brian

On Thu, May 18, 2017 at 09:17:58AM +0300, Marius Petrescu wrote:

To be more specific:

Most of the bogus traffic I had on the gw interface where stray fragments of TCP connections and UDP packets to random ports, alien DNS requests and bogus ICMP replies from hosts as if there where some requests originating on my ampr subnet (unused addresses) to external hosts.

At this moment, all I see are ICMP ping messages from some Argentinian and Chinese IPs and some ssh and port 19 (chargen) attempts to the gateway IP, no stray traffic.

I'm currently blocking nearly 1000 high-volume inbound hosts (those that sent amprgw more than 10,000 packets a minute at the times of sampling), which may account for some of the change of traffic you're seeing get through the router.

None of the gateways are on that block list, so that doesn't account for the drop in inbound encap traffic.

I'm usually seeing around 20 million packets a minute (about 25 MB/s) at the inbound interface. Your 10-15 packets a minute is an awfully small amount to leak through. I must be doing a good job of filtering. - Brian

On Thu, May 18, 2017 at 09:46:55AM +0300, Marius Petrescu wrote:

The volume did not change (some 10-15 packets per minute), just the type.

I suspected at some point that there is a network using 44 addresses internally, had some leaks on them and that the garbage (DNS replies, ICM rejects, IP fragments and such stuff) were the replies from hosts on the internet receiving that traffic and sending replies back via the ampr-gw.

These are gone at the moment.