Project

General

Profile

Actions

Bug #3030

closed

When using LAGG+VLAN+ALTQ, the shaper wizard does not fill in the interface bandwidth

Added by Jim Pingle over 8 years ago. Updated about 8 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Traffic Shaper (ALTQ)
Target version:
Start date:
06/07/2013
Due date:
% Done:

100%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.1
Affected Architecture:

Description

If you are using LAGG+VLAN interfaces (e.g. lagg0_vlan10) in the shaper wizard, the wizard does not fill in the bandwidth for the interface when creating the queues. This leads to an invalid ruleset because the value entered for the WAN bandwidth will always be higher than the other interface, since they don't have any bandwidth defined.

The bandwidth for an interface is normally reported by the OS in ifconfig, for example:

bce0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
[...]
media: Ethernet autoselect (100baseTX <full-duplex>)

But that doesn't seem to work on lagg:

lagg0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
[...]
media: Ethernet autoselect

It does normally work on VLAN interfaces, such as:

fxp0_vlan10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
[...]
media: Ethernet autoselect (100baseTX <full-duplex>)

But because the lagg interface is the parent of the VLANs, it doesn't show the bandwidth there either:

lagg0_vlan10: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
[...]
media: Ethernet autoselect

The shaper wizard would either have to assume some other value as a default, or account for lagg and track down the link speed of the parent interface(s).

Actions #1

Updated by Renato Botelho over 8 years ago

It's fine to leave bandwidth blank, altq fills it using the interface bandwidth. On my tests I could reproduce the issue when I changed lagg protocol and lagg interface loses all capabilities and after that vlan reports 0 as bandwidth.

It's a issue on FreeBSD, I sent a PR [1] with a patch that can fix it. I can commit it to pfsense-tools after someone review and bless this change.

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=179733

Actions #2

Updated by Ermal Luçi over 8 years ago

Seems correct as a patch as long as you do not get LORs.

I though this was handled in the ioctl patch code already but the fix seems ok.

Actions #3

Updated by Renato Botelho over 8 years ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

Applied in changeset pfsense-tools:commit:0416a5113ab777964567fc30b78647b6167f8b75.

Actions #4

Updated by Chris Buechler about 8 years ago

  • Status changed from Feedback to Resolved
Actions

Also available in: Atom PDF