Jack Bates wrote:
Can you spot what I'm doing wrong? or suggest how to debug this? Can I
provide any more details that would help?
There are lots of things to consider around the shaping and nature of
the link, but I'm AFK for a while, so just to get something working
here's a paste of an old test that seems to still work.
It would be horrible in practice, but the filtering does (seem to) get
traffic to the right places. The main things different from you are
flowids to keep tc happy, explicitly only redirecting ip so as not to
shape arp, and putting prio on egress as you need something there to be
able to add the filter.
Again - just an example, not for real use as it is - the htb doesn't
even share/do prio etc.
set -x
modprobe ifb &>/dev/null
tc qdisc del dev ifb0 root &>/dev/null
tc qdisc add dev ifb0 root handle 1: htb
tc class add dev ifb0 parent 1: classid 1:1 htb rate 100kbit ceil 100kbit
tc class add dev ifb0 parent 1: classid 1:2 htb rate 100kbit ceil 100kbit
tc filter add dev ifb0 protocol ip prio 1 parent 1: u32 match ip src
192.168.0.3/32 classid 1:1
tc filter add dev ifb0 protocol ip prio 2 parent 1: u32 match ip dst
192.168.0.3/32 classid 1:2
ip li set up ifb0
tc qdisc del dev eth0 root
tc qdisc add dev eth0 root handle 1: prio
tc filter add dev eth0 parent 1: protocol ip prio 1 u32 \
match u32 0 0 flowid 1:1 \
action mirred egress redirect dev ifb0
tc qdisc del dev eth0 ingress &>/dev/null
tc qdisc add dev eth0 ingress
tc filter add dev eth0 parent ffff: protocol ip prio 1 u32 \
match u32 0 0 flowid 1:1 \
action mirred egress redirect dev ifb0
--
To unsubscribe from this list: send the line "unsubscribe lartc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
