> On 31 Mar, 2016, at 14:49, Allan Pinto wrote:
>
> im not sure if we can route it to ifb this way,( maybe only works with tc
> redirection?) as i feel that i have just set up a routing loop.
Both IFB and IMQ use the original routing information to direct the packet to
the original device aft
>I gave this a shot, it doesn't route the packets back trhough the
>underlying interface...
>perhaps policy routing?
tried it with policy routing too, packets get dropped when i point them to
the ifb interfaces fast/slow. tried both dummy and ifb.
ip route add $custip dev fast table 10
ip route a
I gave this a shot, it doesn't route the packets back trhough the
underlying interface...
perhaps policy routing?
TC=/home/d/git/tc-adv/tc/tc
IFACE=eno1
F=2601:640:4103:56c0:2ab4:103a:39c5:a43a
S=2601:640:4103:56c0:120d:7fff:0:647
ip link add $IFACE name fast type dummy # maybe ifb?
ip link add
An overall ISP in tc need exposed by this discussion is some means of
mapping multiple ipv4 and ipv6 addresses and netmasks into something
that will return a (key,value) pair. This would work something like
ipset does, although what you would return is not "present or not" but
present and a value
Jonathan Morton writes:
> But maybe u32, in the hashing configuration, scales better.
I did a similar setup for a small ISP quite some time ago that used HTB
as the classful qdisc and a hashing u32 filter to divide traffic. This
was pre-FQ-CoDel, so it used SFQ on the leaves, but there's no reas
> On 29 Mar, 2016, at 00:01, Stephen Hemminger
> wrote:
>
> IMQ was abandoned by original author because there was no way to make it
> reliable and SMP safe.
That’s a shame, because for this use-case, it’s a heck of a lot easier to get
it doing the right thing - simply because iptables is th
On Mon, 28 Mar 2016 22:20:58 +0300
Jonathan Morton wrote:
> Did you try the IMQ alternative? I don’t see any reason why it shouldn’t
> work, as long as you can build a kernel with IMQ support.
IMQ was abandoned by original author because there was no way to make it
reliable and SMP safe.
> On 28 Mar, 2016, at 15:25, Allan Pinto wrote:
>
> 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
getting a illegal filter id for these two commands,
>tc filter replace dev ppp0 protocol ip prio 1 handle 11 u32 match ip src
$CACHE_IP/32
> tc filter replace dev ppp0 protocol ip prio 2 handle 12 u32 action mirred
egress redirect dev ifb0
will check further and reply.
On Mon, Mar 28, 2016 at 6:
Hi Allen,
> On Mar 28, 2016, at 14:25 , Allan Pinto wrote:
>
> Hi Sebastian,
> 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.
Hi Sebastian,
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 plan
Hi Jonathan,
> On Mar 28, 2016, at 12:31 , Jonathan Morton wrote:
>
>
>> On 27 Mar, 2016, at 11:20, moeller0 wrote:
>>
>> it might be more future-proof to just use IFBs from the get-go
>
> For this particular use-case, it seems to be more complicated to use IFB than
> IMQ, largely because t
Hi Allan,
> On Mar 27, 2016, at 07:31 , Allan Pinto wrote:
>
> > Is the cache inside or outside the point where the router is fitted
> outside..
>
> Cache-Server
>|
> internet Gateway —> L2 switch --> LInux router with cake - - [ pppoe
> connection ] --> customer
Looking a
>tc qdisc replace dev imq0 root handle 2: cake raw bandwidth $NONCACHE_RATE
flows
here imq0 should be replaced by ifb0 right?.
i will be testing this tonight and reply with results.
On Mon, Mar 28, 2016 at 4:01 PM, Jonathan Morton
wrote:
>
> > On 27 Mar, 2016, at 11:20, moeller0 wrote:
> >
> >
> On 27 Mar, 2016, at 11:20, moeller0 wrote:
>
> it might be more future-proof to just use IFBs from the get-go
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 ipta
Hi Jonathan,
Thank you for the response I will check this and get back.
Wishing you all a happy Easter.
-Original Message-
From: "Jonathan Morton"
Sent: 27-03-2016 13:12
To: "Allan Pinto"
Cc: "cake@lists.bufferbloat.net"
Subject: Re: [Cake] cake sepa
Hi Allan,
> On Mar 27, 2016, at 09:35 , Jonathan Morton wrote:
>
>
>> On 27 Mar, 2016, at 08:31, Allan Pinto wrote:
>>
>> Cache-Server
>> |
>> internet Gateway ---> L2 switch --> LInux router with cake - - [ pppoe
>> connection ] --> customer
>
> Aha - that is a different topology
> On 27 Mar, 2016, at 10:35, Jonathan Morton wrote:
>
> iptables -t mangle -A PREROUTING -o ppp0 -s $CACHE_IP -j IMQ —todev 0
Correction:
iptables -t mangle -A PREROUTING -o ppp0 ! -s $CACHE_IP -j IMQ --todev 0
- Jonathan Morton
___
Cake mailing l
> On 27 Mar, 2016, at 08:31, Allan Pinto wrote:
>
> Cache-Server
>|
> internet Gateway ---> L2 switch --> LInux router with cake - - [ pppoe
> connection ] --> customer
Aha - that is a different topology than we usually assume. So the egress side
of the port is the right one to co
> Is the cache inside or outside the point where the router is fitted
outside..
Cache-Server
|
internet Gateway ---> L2 switch --> LInux router with cake - - [ pppoe
connection ] --> customer
>Also, the command shown will apply a limit to *egress* traffic on the
given port. If you n
> On 26 Mar, 2016, at 17:14, Allan Pinto wrote:
>
> I'm experimenting in replacing a mikrotik router with plain linux. by
> following the instructions on the cake page, i have setup the following line
> in the /etc/ppp/ip-ip script so that the user will be limited to bandwidth
> using cake.
>
Hi ,
I'm experimenting in replacing a mikrotik router with plain linux. by
following the instructions on the cake page, i have setup the following
line in the /etc/ppp/ip-ip script so that the user will be limited to
bandwidth using cake.
/usr/sbin/tc qdisc add dev $pppdev root cake bandwidth ${B
22 matches
Mail list logo
