Jamal Hadi Salim writes:
> On 2019-01-05 12:03 a.m., Cong Wang wrote:
>> (Cc'ing Jamal)
>>
>> On Fri, Jan 4, 2019 at 10:11 AM Bartek Kois wrote:
>>>
>>> Basically my current scenario looks like this:
>>> - router with eth0 as WAN and eth1 as LAN with 10-20 vlans,
>>> - around 1000-2000 ip addres
On 2019-01-15 1:19 p.m., Cong Wang wrote:
I never say it is broken. I am saying you only fix vlan case by
introducing "vlanid XXX" and leave IPv4 option cases unfixed.
Let me see if we can get clarity.
IP options or TCP options typically work. You teach u32 what
to use to compute the next h
On Tue, Jan 15, 2019 at 7:09 AM Jamal Hadi Salim wrote:
>
> On 2019-01-13 1:22 p.m., Cong Wang wrote:
> > On Sat, Jan 12, 2019 at 4:12 AM Jamal Hadi Salim wrote:
> >>
> >> It will be a new feature in the sense the user will have to specify
> >> something like (adding "mark" for clarify):
> >>
> >
On 2019-01-14 3:12 a.m., Simon Horman wrote:
On Sat, Jan 12, 2019 at 07:12:34AM -0500, Jamal Hadi Salim wrote:
On 2019-01-10 8:45 a.m., Simon Horman wrote:
On Sun, Jan 06, 2019 at 09:44:30AM -0500, Jamal Hadi Salim wrote:
As opposed to what used to work before which would
have matched at
On 2019-01-13 1:22 p.m., Cong Wang wrote:
On Sat, Jan 12, 2019 at 4:12 AM Jamal Hadi Salim wrote:
It will be a new feature in the sense the user will have to specify
something like (adding "mark" for clarify):
tc filter add protocol 802.1q .. u32 \
match u32 0 0 \
mark 15 \
vlanid 1234
a
On Sat, Jan 12, 2019 at 07:12:34AM -0500, Jamal Hadi Salim wrote:
> On 2019-01-10 8:45 a.m., Simon Horman wrote:
> > On Sun, Jan 06, 2019 at 09:44:30AM -0500, Jamal Hadi Salim wrote:
>
> > > You can use flower instead of basic but such one offs basic would
> > > be more effective.
> > > Bartek, if
On Sat, Jan 12, 2019 at 4:12 AM Jamal Hadi Salim wrote:
>
> It will be a new feature in the sense the user will have to specify
> something like (adding "mark" for clarify):
>
> tc filter add protocol 802.1q .. u32 \
> match u32 0 0 \
> mark 15 \
> vlanid 1234
> action vlan pop reclassify
Th
On 2019-01-10 8:45 a.m., Simon Horman wrote:
On Sun, Jan 06, 2019 at 09:44:30AM -0500, Jamal Hadi Salim wrote:
You can use flower instead of basic but such one offs basic would
be more effective.
Bartek, if you say you have 20 vlans: worst case scenario
here is you are going to do 20 lookups (
On Sun, Jan 06, 2019 at 09:44:30AM -0500, Jamal Hadi Salim wrote:
> On 2019-01-05 12:03 a.m., Cong Wang wrote:
> > (Cc'ing Jamal)
> >
> > On Fri, Jan 4, 2019 at 10:11 AM Bartek Kois wrote:
> > >
> > > Basically my current scenario looks like this:
> > > - router with eth0 as WAN and eth1 as LAN
On 2019-01-05 12:03 a.m., Cong Wang wrote:
(Cc'ing Jamal)
On Fri, Jan 4, 2019 at 10:11 AM Bartek Kois wrote:
Basically my current scenario looks like this:
- router with eth0 as WAN and eth1 as LAN with 10-20 vlans,
- around 1000-2000 ip addresses in differnets subnets behind router (on
the L
(Cc'ing Jamal)
On Fri, Jan 4, 2019 at 10:11 AM Bartek Kois wrote:
>
> Basically my current scenario looks like this:
> - router with eth0 as WAN and eth1 as LAN with 10-20 vlans,
> - around 1000-2000 ip addresses in differnets subnets behind router (on
> the LAN side),
> - QoS made with tc + ifb
Hi
W dniu 03.01.2019 o 21:44, Cong Wang pisze:
On Thu, Jan 3, 2019 at 7:25 AM Bartek Kois wrote:
Hi
1. What exactly caused this change in the kernel?
I don't follow VLAN changes, I guess it must be some change which
inserts the VLAN tag before this ->ndo_start_xmit().
2. I don`t understan
Hi
Is this equally fast as hashing tables?
Best regards
Bartek Kois
W dniu 03.01.2019 o 22:49, Anton Danilov pisze:
Hi.
There is the workaround - classify the packets with iptables+ipset -
it's enough fast and more friendly.
On Fri, 4 Jan 2019 at 00:21, Bartek Kois wrote:
Hi
1. What exactly
Hi.
There is the workaround - classify the packets with iptables+ipset -
it's enough fast and more friendly.
On Fri, 4 Jan 2019 at 00:21, Bartek Kois wrote:
>
> Hi
> 1. What exactly caused this change in the kernel?
> 2. I don`t understand why adding VLAN tag, which is just 4 additional
> bytes
On Thu, Jan 3, 2019 at 7:25 AM Bartek Kois wrote:
>
> Hi
> 1. What exactly caused this change in the kernel?
I don't follow VLAN changes, I guess it must be some change which
inserts the VLAN tag before this ->ndo_start_xmit().
> 2. I don`t understand why adding VLAN tag, which is just 4 addi
Hi
1. What exactly caused this change in the kernel?
2. I don`t understand why adding VLAN tag, which is just 4 additional
bytes to the passing packet make it impossible to classify.
3. This whole thing makes the QoS under Linux routers hard to configure
in scenarios with more than one VLAN whi
On Tue, Jan 1, 2019 at 11:46 AM Bartek Kois wrote:
>
> Hi
> Yes it did work since I remember (like around 2.4.x) and it changed
> since I moved from Debian 8 to 9. I would appreciate fixing that in the
> future beacuse it is essential for queueing traffic on the routers, but
> the question is why
Hi
Yes it did work since I remember (like around 2.4.x) and it changed
since I moved from Debian 8 to 9. I would appreciate fixing that in the
future beacuse it is essential for queueing traffic on the routers, but
the question is why these filters don`t work in that case:
tc filter add d
On Mon, Dec 31, 2018 at 10:13 AM Bartek Kois wrote:
>
> Hi,
> I tested 4.20 and the problem remains (it is not possible to classify
> tagged packets if the root filter is on physical interface).
Hmm, I guess it is because the offset used by u32 filter is no
longer accurate when vlan tag is insert
Witam
Working setup (driver e1000e):
# ethtool -k eth1 | grep vlan
rx-vlan-offload: on
tx-vlan-offload: on
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
Broken setup (driver e1000e):
On Sat, 29 Dec 2018 13:52:23 +0100, Bartek Kois wrote:
> Hi,
> I`ve got problem while queuing with HFSC vlan tagged packets after
> migrating my tc scripts from Debian 8.2 (3.16.0-4-amd64) to Debian 9.5
> (4.9.0-6-amd64). tc filters added to eth1 do not classify correctly src
> and dst ip addres
Hi,
I tested 4.20 and the problem remains (it is not possible to classify
tagged packets if the root filter is on physical interface).
Best regards
Bartek Kois
W dniu 30.12.2018 o 22:14, Bartek Kois pisze:
Hi
I haven`t tested any newer kernels cause I thought that something
related to packet
Hi
I haven`t tested any newer kernels cause I thought that something
related to packet classification has been changed permanently and I have
to figure out what. Which one should I test?
Best regards
Bartek Kois
W dniu 30.12.2018 o 19:53, Cong Wang pisze:
Hello,
On Sat, Dec 29, 2018 at 11:5
Hello,
On Sat, Dec 29, 2018 at 11:54 AM Bartek Kois wrote:
>
>
> Hi,
> I`ve got problem while queuing with HFSC vlan tagged packets after
> migrating my tc scripts from Debian 8.2 (3.16.0-4-amd64) to Debian 9.5
> (4.9.0-6-amd64). tc filters added to eth1 do not classify correctly src
> and dst ip
Hi,
I`ve got problem while queuing with HFSC vlan tagged packets after
migrating my tc scripts from Debian 8.2 (3.16.0-4-amd64) to Debian 9.5
(4.9.0-6-amd64). tc filters added to eth1 do not classify correctly src
and dst ip addresses anymore if they are encapsulated with vlan tag
which wasn
25 matches
Mail list logo
