As you can see from the graph https://gw.ampr.org/router/encapinpkt.svg,
there was a precipitous decline in inbound encap traffic about 19:00
UTC on May 16th. I've been wondering what happened to all that traffic.
Well, it turns out that the amount of traffic coming in before that cutoff
was anomalously high. There was a host called chocolate-nebula.mit.edu
(18.96.0.110) which was sending over 95% of the inbound traffic to amprgw,
and had been for several days, before the graph started. I jumped to
the conclusion that that amount of traffic was normal, when in fact it
was not.
So what has really happened was that inbound traffic has returned to
normal after 16 May at 19:10.
chocolate-nebula.mit.edu is registered on the portal as
amprnet-gateway1.amolbhave.com, the gateway for subnet 44.44.7.224/28,
belonging to KC1EDX. I don't yet know why it was sending all that
traffic, nor why it suddenly stopped.
So most of the mystery is solved. Maybe KC1EDX will pop up here and
explain what was going on.
- Brian
Hey,
I'm wondering of anyone has successfully got a gateway running in Amazon's EC2 service? I was thinking of using a raspberry pi with a tinc VPN to the EC2 instance to tie into my RF connection regardless of my IP address. I hit a wall when it came to getting ampr-ripd running. If anyone has such a configuration working I would love to pick your brain about your setup.
Regards,
Mark Scrano K2EXE
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
> Guys, I think I may be missing something here. I've seen a couple
> references to RIP being required. I didn't see that mentioned in any of
> the on-line docs. Perhaps I've missed it, and if so, I apologize. I'll go
> look at the Wiki to see if it is there.
> Is this required or optional?
It is optional, but I think it will be very unpractical or even impossible to
get the IPIP tunneling working on your SRX.
Note that it is NOT sufficient to setup a single IPIP tunnel to the amprgw
and route all net-44 traffic over that. You need to setup a tunnel to each
of the (about 430) gateway systems and route the defined subnets (about 615)
over those tunnels. And the IP addresses of some of the endpoints are changing
all the time because users are on a dynamic internet IP.
To keep that config uptodate in your router, you either need to do AMPR-RIP,
or you need to setup elaborate scripting to reconfigure the router whenever
required. (regularly downloading the encap.txt file and generating config for it)
In practice, you need a Linux box to do the routing, or a MikroTik router that
has scripting powerful enough to do the above on its own.
With your SRX you will need a separate machine that does the updating.
Rob
I got curious about what all the inbound traffic we're
experiencing (and mostly rejecting) was all about. Here's
a very elementary breakdown of a one minute sample of
what I saw on the inbound Ethernet:
22434704 packets read from savefile
344 non-IP packets discarded
proto 1 (ICMP) count 87478
proto 2 count 14
proto 4 (IPIP) count 26162
proto 6 (TCP) count 20467723
proto 17 (UDP) count 1829610
proto 41 count 330
proto 47 (GRE) count 23041
proto 103 count 2
I'll do some additional analysis when I have time.
- Brian
> 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.
I think that is not a legitimate use but an attack group that spoofs sender
addresses when sending their attacks and they use net-44 addresses as well.
To have that go down, more ISPs should implement BCP38 (source address filtering).
Unfortunately, there is little incentive for ISPs to do that, because it benefits
only others and not themselves.
Rob
> it is strange that my one camera consume half of the bandwith of all the 44 net bandwith
Oh but that is only the traffic from tunneled hosts talking to the internet via amprgw!
We output about twice that amount (700kB/s) continuoously on our gateway for only network 44.137.0.0/16.
And that is after the Brandmeister hosts have been disconnected for internet addresses due to the DDoS.
Before that, it was several MB/s, up to about 8 MB/s last february.
Rob
> Perhaps it's time to revisit UDPIP. Does Linux support the use
> of UDP port 94 for encapsulation?
It appears it has been introduced in kernel 3.18 which is quite recent and
will mean there are some issues for many users.
(requirement to install a backported kernel and "ip" program that supports
the newly introduced "ip fou" subcommand.
It is not supported on the systems we are currently running.
(Debian Wheezy and Jessie)
It also is not supported on MikroTik routers.
Rob
May someone explain to me how the "Firewall: inbound raw vs outbound encapsulated traffic" show that the encap data is bigger then the raw input ? may i misunderstand something ?
> Perhaps someone in the path between
> us and Germany inserted a protocol 4 block
That is what I suggest... it is up for us, and we can reach you, so it
is probably not a problem in either Germany nor inside your network.
Try a traceroute to a few gateways with zero traffic to find if there is
a common path or provider.
Rob
