Joined: 11 Apr 2005
|Posted: Sat Apr 19, 2014 3:34 pm Post subject: tc and tcpdump issues with brctl
|I have a router with 2 wired NICs. Both are bridged with a VPN:
br0 XXXXXXX no eth0
When i do traffic shaping on eth0, it seems to affect eth1. I do that to limit bandwidth on eth0, this works; but i also feel like bandwidth is limited on eth1; what is absolutely certain is that, on eth1, i do a perpetual ping test (to an other machine on this side) and when I start TC, and use fully eth0 (to saturate the traffic), latency hugely increases on eth1. Over 3 y, the latency on eth1 is betwwen 0.5 ans 3ms. When i do tc and use traffic, latency grows up to 80ms. In the LAN !!! Why ?
ext=eth0 # Change for your device!
ext_ingress=ifb0 # Use a unique ifb per rate limiter!
# Set these as per your provider's settings, at 90% to start with
ext_up=200kbps # Max theoretical: for this example, up is 1024kbit
ext_down=200kbps # Max theoretical: for this example, down is 8192kbit
q=1514 # HTB Quantum = 1500bytes IP + 14 bytes ethernet.
# Higher bandwidths may require a higher htb quantum. MEASURE.
# Some ADSL devices might require a stab setting.
quantum=300 # fq_codel quantum 300 gives a boost to interactive flows
# At higher bandwidths (50Mbit+) don't bother
sysctl -w net.ipv4.tcp_ecn=1
ethtool -K $ext tso off gso off gro off # Also turn of gro on ALL interfaces
# e.g ethtool -K eth1 gro off if you have eth1
# some devices you may need to run these
# commands independently
$tc qdisc del dev $ext root
$tc qdisc del dev $ext ingress
$tc qdisc del dev $ext_ingress root
$tc qdisc del dev $ext_ingress ingress
$tc qdisc add dev $ext handle ffff: ingress
ifconfig $ext_ingress up # if the interace is not up bad things happen
$tc filter add dev $ext parent ffff: protocol all u32 match u32 0 0 action mirred egress redirect dev $ext_ingress
$tc qdisc add dev $ext_ingress root handle 1: htb default 11
$tc class add dev $ext_ingress parent 1: classid 1:1 htb rate $ext_down
$tc class add dev $ext_ingress parent 1:1 classid 1:11 htb rate $ext_down prio 0 quantum $q
$tc qdisc add dev $ext_ingress parent 1:11 fq_codel quantum $quantum ecn
$tc qdisc add dev $ext root handle 1: htb default 11
$tc class add dev $ext parent 1: classid 1:1 htb rate $ext_up
$tc class add dev $ext parent 1:1 classid 1:11 htb rate $ext_up prio 0 quantum $q
$tc qdisc add dev $ext parent 1:11 fq_codel quantum $quantum ecn
eth1 is wired to a hub, with other machines. I have checked the MAC seen by other hosts, and link local IPv6 pings ... I am 100% certain that it's eth1 on the hub.
When I do tcpdump on eth1, i don't see the traffic generated by other machines on the hub; but I see it on eth0
Seeing it on eth0 makes sens, because of the bridge; but why the hell can't I see it on eth1 ?
Iptables & ebtables may be involved ... eventually. Even if, at the moment, i don't see which rules would affect this. Iptables show very few rules, and no reject or drop. Ebtables does have a few drop, but all ebtables rules (accept or drop) all only concern tap0, not eth*.
DEMAINE Benoît-Pierre (aka DoubleHP ) http://www.demaine.info/
>o_/ Coin coin coin \_o<
to contact me (MSN,ICQ, JABBER, Skype ... ) http://benoit.demaine.info/contact.png