<div dir="ltr">Hi Sebastian, <div>I should have made this more clear please see below topology with added comments. the customers connecting to the linux router can be in range from 100 to 2000, so shaping on the switch is not really a option. I am right now testing on a i3 machine, but for actual live testing am planning to test with i7 or a xeon.</div><div><br></div><div><span class="im" style="font-size:12.8px">                  Cache-Server [ connected to internet gateway , traffic can be sent to it via wccp or policy based routing ]<br>                           |<br></span><span style="font-size:12.8px">  internet---->internet Gateway —> L2 switch [ MEN network on fiber ]   --> LInux router with cake[ includes a pppoe server which authenticates with radius ] - - [ pppoe connection over a fiber men network ]  --> customer [ customers can be 100 to 2000 ]</span><br></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">basically the customer will create a broadband connection on his pc to connect.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">. > @Allan, what is the link technology you use?</span><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">fiber 1g/10g/last hop cat5e</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">></span><span style="font-size:12.8px"> </span><span style="font-size:12.8px">As I just wrote, can’t we completely avoid the IMQ/IFB here and use dual egress shaping instead (once on the pppoe device and once on the interface connected to the switch, which effectively should shape both directions)?</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">i may be wrong here, but i think jonathan is advising the use of IMQ/IFB to provide two different shaping scenarios on egress itself. not ingress. as i need cache traffic to have higher bandwidth on the egress towards customer but non- cache traffic [ pure internet ] to remain within the bandwidth limits purchased by the customer.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 28, 2016 at 5:39 PM, moeller0 <span dir="ltr"><<a href="mailto:moeller0@gmx.de" target="_blank">moeller0@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Jonathan,<br>
<span class=""><br>
> On Mar 28, 2016, at 12:31 , Jonathan Morton <<a href="mailto:chromatix99@gmail.com">chromatix99@gmail.com</a>> wrote:<br>
><br>
><br>
>> On 27 Mar, 2016, at 11:20, moeller0 <<a href="mailto:moeller0@gmx.de">moeller0@gmx.de</a>> wrote:<br>
>><br>
>> it might be more future-proof to just use IFBs from the get-go<br>
><br>
> For this particular use-case, it seems to be more complicated to use IFB than IMQ, largely because there is no iptables rule to divert packets through an IFB device, and unlike iptables, the CBQ filter mechanism doesn’t directly support negative matches of any kind.<br>
<br>
</span>        As I just wrote, can’t we completely avoid the IMQ/IFB here and use dual egress shaping instead (once on the pppoe device and once on the interface connected to the switch, which effectively should shape both directions)?<br>
<span class=""><br>
><br>
> However, I think this would work - though it’s completely untested:<br>
><br>
> ip link set ifb0 up<br>
><br>
> tc qdisc replace dev ppp0 root handle 1: cake pppoe-vcmux bandwidth $FULL_RATE triple-isolate<br>
<br>
</span>        I wonder how you came up with pppoe-vcmux, I have not seen any information about the link technology in Allan’s post. As far as I know a number of (mislead) ISPs use PPPoE even on fiber links. @Allan, what is the link technology you use?<br>
<span class=""><br>
><br>
> tc qdisc replace dev imq0 root handle 2: cake raw bandwidth $NONCACHE_RATE flows<br>
<br>
</span>        I believe this might work as egress on the interface facing the L2-switch…<br>
<span class=""><br>
><br>
> tc filter replace dev ppp0 protocol ip prio 1 handle 11 u32 match ip src $CACHE_IP/32<br>
><br>
> tc filter replace dev ppp0 protocol ip prio 2 handle 12 u32 action mirred egress redirect dev ifb0<br>
><br>
> The logic of the above is that a positive match is made on the cache traffic, but no action is taken.  This terminates filter processing for that traffic.  The remaining traffic is redirected unconditionally to the IFB device by the second filter rule.<br>
><br>
> One thing I’m not entirely certain of is whether traffic that has been through an IFB device is then requeued in the normal way on the original device.<br>
<br>
</span>        It should, but only on egress…<br>
<span class=""><br>
<br>
> I’d appreciate feedback on whether this system does in fact work.<br>
><br>
>> I would respectfully recommend to avoid the symbolic overhead parameters<br>
><br>
> Even if I change their underlying behaviour in the future, it’ll be in a way that retains backwards compatibility with all the examples I’ve given for the current scheme.  I mostly wanted to raise awareness that the overhead compensation system exists for use on encapsulated links.<br>
<br>
</span>        All fair points!<br>
<br>
><br>
> - Jonathan Morton<br>
><br>
<br>
<br>
Best Regards<br>
        Sebastian</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Thanx and regd's.<br><br>Allan.<br><br></div></div>
</div>