Thus far, we have only had forwarded bytes metrics.
Notably, forwarded bytes does not include bytes that were sent by the router
itself, e.g. by the webserver or rsync server running on the machine.
fixes https://github.com/rtr7/router7/issues/71
It is generally not a good idea to have multiple IP addresses on the same
interface unless managing their relative priorities via metrics etc.
During an outage, I noticed that with multiple IP addresses,
Linux was using the old obsolete one to send out packets,
which does not work with the ISP.
With this change,
we still hold on to IP addresses for as long as possible,
but no longer.
fixes issue #57
The nftables package started honoring the rule position (insert vs. append), and
it turns out our goldens have been wrong all along. Now the configured order
matches the golden order.
To set up a tunnel, create a /perm/wireguard.json as illustrated in
netconfig_test.go, and don’t forget to adjust your /perm/interfaces.json with
the address configuration for the WireGuard tunnel.
Note that static routes cannot currently be configured, so the usefulness is
limited. If you have a use-case you’d like to see covered, please explain it in
https://github.com/rtr7/router7/issues/14
We didn’t have a need to clamp the TCP Maximum Segment Size (MSS) up until now,
because fiber7 uses an MTU of 1500.
Because Path MTU discovery is often broken on the internet, it’s best practice
to limit the Maximum Segment Size (MSS) of each TCP connection, achieving the
same effect (but only for TCP connections).
This change is beneficial when running router7 behind a non-ethernet uplink,
such as a Fritz!Box cable modem.
This has no adverse effect on fiber7: after clamping, the MSS is still 1440, as
without clamping.
This makes them complete more quickly (because they are run in parallel) and
invalidates only the cache for the integration test I’m working on, not for all
of them.
