Wow, Thanks. Just checked that IFB is a successor to IMQ, which I couldn't find any documentation about from the internet. I think I will scrap all my current inbound shaping policy and migrate them to IFB. Horace Ng ----- Original Message ----- From: "Phil Daws" <uxbod@xxxxxxxxxxxx> To: lartc@xxxxxxxxxxxxxxx Sent: Wednesday, August 21, 2013 4:55:49 AM Subject: Re: TC on Ingress/Egress ----- Original Message ----- From: "Phil Daws" <uxbod@xxxxxxxxxxxx> To: lartc@xxxxxxxxxxxxxxx Sent: Tuesday, 13 August, 2013 10:16:55 PM Subject: TC on Ingress/Egress Hello, am trying to learn about TC and getting a little confused on its implementation for Ingress traffic. I have read that its possible to use IFB and iptables to classify the traffic by redirecting all inbound to the IFB interface. Can HSFC then be used within the IFB interface ? Sorry if these questions do not make sense; as I said am trying to learn :) Thank you. -- After some reading, and searching, it seems that one can use the following to redirect all ingress traffic to an IFB interface: tc qdisc add dev eth0 handle ffff: ingress tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0 then apply rules as you would on the egress side. That seems really cool but are there any disadvantages ? If I created a HSFC class with an id of 1:10 could I then do something like: -A ACCESS -d 192.168.1.10 -m multiport -m state --state NEW -m tcp -p tcp --dports 80,443 -j CLASSIFY --set-class 1:10 but once it hits the classify queue will it be automatically accepted ? am thinking why shape traffic that is going to be dropped anyway. 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 -- 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
