I have had this in place for ages, hopefully blocking egress of local
networks outside the nat. It appears to work...
iptables -t mangle -I POSTROUTING -d
192.168.0.0/16,172.16.0.0/12,10.0.0.0/8 -o ge00 -j DROP
but what I'd wanted was to actually send a reason for it, but putting
the reason in
Hi Toke,
On Jun 16, 2013, at 22:55 , Toke Høiland-Jørgensen t...@toke.dk wrote:
Sebastian Moeller moell...@gmx.de writes:
As far as I can tell at least VDSL typically means VDSL2 and that
probably means PTM instead of ATM. In essence this means you do not
have to deal with ATMs 48 payload
Hi Dave, hi Toke,
On Jun 16, 2013, at 22:57 , Dave Taht dave.t...@gmail.com wrote:
On Sun, Jun 16, 2013 at 1:55 PM, Toke Høiland-Jørgensen t...@toke.dk wrote:
Sebastian Moeller moell...@gmx.de writes:
As far as I can tell at least VDSL typically means VDSL2 and that
probably means PTM
Rich Brown richb.hano...@gmail.com writes:
Yes, s\200\200/s\ eliminates that message. It'd good to get rid of the
warning about TCP+UDP as well.
Well, to get rid of the other one you just need to add a line to the
rule block which has option name 'domain'. The line to add is option
proto 'tcp
Sebastian Moeller moell...@gmx.de writes:
Honestly, I think the best thing to do is not so much assume ATM or
lack of ATM, but simply measure it :)
Right, doing the ping test with payload sizes from 16 to 113 packets
gives me an almost completely flat ping time distribution ranging from
20.3
Hi Toke,
On Jun 17, 2013, at 11:44 , Toke Høiland-Jørgensen t...@toke.dk wrote:
Sebastian Moeller moell...@gmx.de writes:
Honestly, I think the best thing to do is not so much assume ATM or
lack of ATM, but simply measure it :)
Right, doing the ping test with payload sizes from 16 to 113
Sebastian Moeller moell...@gmx.de writes:
I fully believe you that it is flat (graph did not make it into my
inbox…)
Heh. May have forgotten to attach it... Should be there now...
So that looks like PTM. Good! But beware the expected step size
depends on your down and uplink speeds, at VDSL
OH, thank you!
One of the things that irked me on my htb+netem delay/loss setup was
that the need to also feed arp and ND through it resulted in major
startup transients that wouldn't exist in the real world.
So now I understand how to feed those protocols through a separate
unshaped htb queue.
