ALTQ + vlan

[Radosław Kujawa]

Hello list,
I am trying to configure ALTQ on a server, where multipie vlan(4)'s are
used. However, it looks like ALTQ and vlan are incompatible.

For example, let's assume that bge1 is the interface, where vlans are
configured:

# ifconfig bge1
bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
enabled=0
address: 00:11:85:c5:cb:41
media: Ethernet autoselect (1000baseT full-duplex)
status: active
# ifconfig vlan0
vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
enabled=0
vlan: 1 parent: bge1
address: 00:11:85:c5:cb:41
inet 10.4.0.1 netmask 0xffffff00 broadcast 10.4.0.255
inet alias 10.10.10.3 netmask 0xffffff00 broadcast 10.10.10.255

Unfortunately, it does not matter what kind of ATLQ classes and filters
are set up, every packet will always go to the default class. I have
following rules for bge1:

interface bge1 bandwidth 100M cbq
class cbq bge1 root_class NULL priority 0 pbandwidth 100
class cbq bge1 net_class root_class exactbandwidth 756000
filter bge1 net_class 0 0 0 0 0
class cbq bge1 lan_class root_class pbandwidth 95 default
filter bge1 lan_class 10.4.0.0 netmask 16 0 192.168.0.0 netmask 16
0 0

altqstat clearly shows that even packets for 192.168.0.0 network are
going into net_class.
Of course, at first I tried using vlan0 instead of bge1 - it does not
make any difference.

I did some experiments - after disabling vlans everything worked as
expected. I suspect that ATLQ'ing traffic takes place before
deencapsulation of 802.1q... Is this a known problem? Should I gather
more data and fill PR?

Greetings
Radoslaw Kujawa


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Radosław Kujawa
Hello list,
I am trying to configure ALTQ on a server, where multipie vlan(4)'s are
used. However, it looks like ALTQ and vlan are incompatible.
For example, let's assume that bge1 is the interface, where vlans are
# ifconfig bge1
bge1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
enabled=0
address: 00:11:85:c5:cb:41
media: Ethernet autoselect (1000baseT full-duplex)
status: active
# ifconfig vlan0
vlan0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
enabled=0
vlan: 1 parent: bge1
address: 00:11:85:c5:cb:41
inet 10.4.0.1 netmask 0xffffff00 broadcast 10.4.0.255
inet alias 10.10.10.3 netmask 0xffffff00 broadcast 10.10.10.255
Unfortunately, it does not matter what kind of ATLQ classes and filters
are set up, every packet will always go to the default class. I have
interface bge1 bandwidth 100M cbq
class cbq bge1 root_class NULL priority 0 pbandwidth 100
class cbq bge1 net_class root_class exactbandwidth 756000
filter bge1 net_class 0 0 0 0 0
class cbq bge1 lan_class root_class pbandwidth 95 default
filter bge1 lan_class 10.4.0.0 netmask 16 0 192.168.0.0 netmask 16
0 0
altqstat clearly shows that even packets for 192.168.0.0 network are
going into net_class.
Of course, at first I tried using vlan0 instead of bge1 - it does not
make any difference.
I did some experiments - after disabling vlans everything worked as
expected. I suspect that ATLQ'ing traffic takes place before
deencapsulation of 802.1q... Is this a known problem? Should I gather
more data and fill PR?

No, I think it's the expected behavior. The classifier will operate when
packets go out of the IP stack, so you have to use the vlan interfaces and
not bge1 in the config file.

[Radosław Kujawa]

Post by Manuel Bouyer

Post by Radosław Kujawa
Of course, at first I tried using vlan0 instead of bge1 - it does not
make any difference.

(...)
No, I think it's the expected behavior. The classifier will operate when
packets go out of the IP stack, so you have to use the vlan interfaces and
not bge1 in the config file.

Well, that was the first thing I tried, and I even stated that in my
mail, maybe not clearly enough :). Funny thing is, that in my case there
is no difference between using real interface (bge) and vlan interface.
Packets always go into default class...

Thanks
Radoslaw Kujawa

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Radosław Kujawa
Well, that was the first thing I tried, and I even stated that in my
mail, maybe not clearly enough :). Funny thing is, that in my case there
is no difference between using real interface (bge) and vlan interface.
Packets always go into default class...

Hum, it seems to work fine for me, but I do use conditionners for input
traffic here, I have no queuing policy on output.

[Radosław Kujawa]

Hi.

Post by Manuel Bouyer
Hum, it seems to work fine for me, but I do use conditionners for input
traffic here, I have no queuing policy on output.

Well, queueing works only for output traffic, right? So I have no other
choice.

What version of NetBSD do you use? I'll do some additional tests and
properly document the results, but first I'd like to know that I use
something that is known to work. Maybe I am missing something obvious.

I can always connect some layer-3 switch before this NetBSD box, and
configure routing between vlans there - that would be some kind of
workaround... But it would be really awesome if I could do all this
stuff (vlans, routing, QoS, monitoring) on one NetBSD box. Right now I
am only missing QoS on vlan*.

Radek


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Radosław Kujawa
Hi.

Post by Manuel Bouyer
Hum, it seems to work fine for me, but I do use conditionners for input
traffic here, I have no queuing policy on output.

Well, queueing works only for output traffic, right? So I have no other
choice.

It depends on what you want to do. In my case it's just to
limit the traffic, so a conditionner on input works.

Post by Radosław Kujawa
What version of NetBSD do you use? I'll do some additional tests and
properly document the results, but first I'd like to know that I use
something that is known to work. Maybe I am missing something obvious.

It's on NetBSD 4.0_RC1