Hi, thanks for your answers that confirm my assumptions. I tried in the last days and yes the ifb doesn't have any netfilter hook :( . I want to try the ipset ematch action that tc should have but when i try to do this command: tc filter add dev ethlan basic match 'ipset(voip src)' Unknown ematch "ipset" Illegal "ematch" Anyone using it succesfully ? Thanks Marco On Thu, 25 Sep 2014 20:32:26 +0100 Andrew Beverley <andy@xxxxxxxxxxx> wrote: > On Thu, 2014-09-25 at 18:44 +0200, GGounot wrote: > > Le 25/09/2014 12:19, marco@xxxxxxxxxx a écrit : > > > Hi to all, > > > i read some stuff about ingress filtering with ifb module. > > > > > > According to someone it is impossible but for someone not. > > > > > > possible: > > > https://wiki.archlinux.org/index.php/Advanced_traffic_control > > > > > > no possible: > > > http://www.mail-archive.com/lartc@xxxxxxxxxxxxxxx/msg15545.html > > > http://www.spinics.net/lists/netfilter/msg53729.html > > > http://www.spinics.net/lists/lartc/msg22358.html > > > > > > It is possible to use connection mark (ctmark) or packet mark > > > (nfmark) with the tc filter on ifb or the only possibility is > > > with the patch provided by these links ? > > > https://aur.archlinux.org/packages/act_connmark/ > > > https://aur.archlinux.org/packages/iproute2-connmark/ > > > > > > or im missing something ? > > > > > > Thanks > > > -- > > > 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 > > > > > > > Hi Marco. > > > > Ingress shaping is possible : > > > > #!/bin/bash > > ## Paths and definitions > > tc=/sbin/tc > > EHT=eth0 # Change for your device! > > IFB=ifb0 # Use a unique ifb per rate limiter! > > modprobe ifb > > modprobe act_mirred > > # Clear old queuing disciplines (qdisc) on the interfaces > > $tc qdisc del dev $EHT root 2>/dev/null > > $tc qdisc del dev $EHT ingress 2>/dev/null > > $tc qdisc del dev $IFB root 2>/dev/null > > $tc qdisc del dev $IFB ingress 2>/dev/null > > # Create ingress on external interface > > $tc qdisc add dev $EHT handle ffff: ingress > > ifconfig $IFB up # if the interace is not up bad things happen > > # Forward all ingress traffic to the IFB device > > $tc filter add dev $EHT parent ffff: protocol all u32 match u32 0 0 > > action mirred egress redirect dev $IFB > > # (Example !) Create an EGRESS filter on the IFB device > > $tc qdisc add dev $IFB root handle 1: htb default 0 > > $tc class add dev $ETH parent 1:0 classid 1:1 htb rate 1000kbps > > ceil 1000kbps prio 0 > > $tc class add dev $ETH parent 1:1 classid 1:300 htb rate 300kbps > > ceil 300kbps prio 0 > > $tc qdisc add dev $ETH parent 1:300 handle 300: sfq perturb 10 > > $tc filter add dev $ETH parent 1:0 prio 0 protocol ip handle 300 fw > > flowid 1:300 > > > > iptables -t mangle -I FORWARD -i eth0 -j MARK --set-mark 300 > > > > (not tested) > > Again, not tested, but I don't think that will work. The marks get > added after the traffic has been through the IFB device. > > I'm a long time out of the loop on this, but IIRC, you can ineed do > ingress shaping using the IFB device, but you won't have the full > range of netfilter functionality such as packet marking. The IFB > device sits before the entire netfilter stack. > > You can't attach an IFB device any later in the traffic flow, but you > could look at IMQ, which allow you to hook into other areas. It's not > part of the vanilla kernel though. > > Andy > > > -- > 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 >
Attachment:
signature.asc
Description: PGP signature
