Traffic shaper not seeing WAN interface

[lobotiger]

I installed the latest 2.1 RC (with IPv6 support following url from ipv6 how-to) and I noticed that when I went into the traffic shaper section that my WAN interface is not listed.

When going through the wizard, only my LAN interface shows up as an option to select for WAN #1.

This has been happening ever since I started playing around with 2.1 RC with dates from July 10 onwards.

LoboTiger

P.S. If this is not related to 2.1 RC I apologize.

[phil.davis]

I checked on a July 15 system, and it is showing me LAN, WAN and OPT1. So its not generally broken.
What hardware do you have?
What might be special about your WAN?

[xbipin]

shows all interfaces for me on the 16th July snap

[zenny]

All interfaces are available with 15th July snapshot.

[lobotiger]

The current setup I'm playing with is a spare netbook with a usb ethernet adapter acting as the WAN interface.

The funny thing is last week I installed a fresh image from July 10 and I even managed to get traffic shaping all setup as I expected.  Then when I went to remove the traffic shaping the WAN interface option disappears from the selections.  Doing a fresh re-install seems to bring things back but if I repeat the steps above it disappears again.  Everything else however appears to be working fine.  I could understand the WAN interface disappearing but then shouldn't it impact my connectivity to the internet?

???

LoboTiger

[rcfa]

Just looked at my web interface: not a single interface shows up. Or must I set up something before the interfaces are listed there?
I have the very latest July 18th, late night build…

...not only that, I can't run any of the wizards, because they won't see even one LAN and one WAN interface.

Setup: LAN, WAN for IPv4, a DMZ: these are the three physical interfaces, then a tunnelbroker interface as WAN link for IPv6 traffic, and an IPSec tunnel through which the actual internet traffic is routed, i.e. the WAN interface provides internet for NAT-ed traffic from/to the DMZ, and for the ESP traffic to a remote VPN unit, which provides the route to the public net.

Maybe slightly non-standard, but certainly not so esoteric that the software shouldn't see the WAN and LAN interfaces, right?

[rcfa]

Did anyone figure out why some of us have this issue, and some don't?
Below how this looks on my web interface: no NIC showing :(


[razzfazz]

I seem to remember that not all NIC drivers actually support ALTQ; could that be the issue?

[rcfa]

@razzfazz:

I seem to remember that not all NIC drivers actually support ALTQ; could that be the issue?

Could be a possibility, but it's not like my unit has exotic NICs: these are regular intel chips, em0 through em5 interfaces, bonded together to failover LAGG0 through LAGG2

Or won't limiting work in that case?

[razzfazz]

From the altq man page on FreeBSD 9.1:

SUPPORTED DEVICES
     The driver modifications described in altq(9) are required to use a cer-
     tain network card with ALTQ.  They have been applied to the following
     hardware drivers: ae(4), age(4), alc(4), ale(4), an(4), ath(4), aue(4),
     axe(4), bce(4), bfe(4), bge(4), cas(4), cxgbe(4), dc(4), de(4), ed(4),
     em(4), ep(4), epair(4), et(4), fxp(4), gem(4), hme(4), igb(4), ipw(4),
     iwi(4), ixgbe(4), jme(4), le(4), msk(4), mxge(4), my(4), nfe(4), nge(4),
     npe(4), nve(4), qlxgb(4), ral(4), re(4), rl(4), rum(4), sf(4), sge(4),
     sis(4), sk(4), ste(4), stge(4), ti(4), txp(4), udav(4), ural(4), vge(4),
     vr(4), vte(4), wi(4), and xl(4).

     The ndis(4) framework also has support for ALTQ and thus all encapsulated
     drivers.

     The tun(4) and ng_iface(4) pseudo drivers also do support ALTQ.

That list does not include LAGG devices. However, having said that, the list also doesn't include VLAN devices, and I know that these do in fact work with ALTQ on pfSense, so there may be local changes to enable either or both.

[razzfazz]

Actually, it looks like this is a known issue for LAGG interfaces:

http://redmine.pfsense.org/issues/1630

[rcfa]

@razzfazz:

Actually, it looks like this is a known issue for LAGG interfaces:

http://redmine.pfsense.org/issues/1630

Indeed, removing the lagg and assigning the em0 to WAN, and the interface shows up.. Bummer that the two can't work together.

Wonder what was meant by the "bandaid using piples" in the redmine comments.

Anyway, failover isn't that important. Unless a hardware interface fries while I'm not here and I just tell someone to move the ethernet plug one slot over to fix things, I can handle the minor reconfiguration myself if something goes south with em0 and I need to use em1 for WAN.

[jimp]

If the NIC doesn't show up there, the driver doesn't support traffic shaping via ALTQ.

The "bandaid" via pipes means to use Limiters rather than ALTQ.

You can make limiter pairs (one upload, one download) and then make child limiter/queues to do priorities. In that way, you can effectively have shaping on any NIC regardless of its ALTQ support.

[jimp]

@rcfa:

@razzfazz:

Actually, it looks like this is a known issue for LAGG interfaces:

http://redmine.pfsense.org/issues/1630

Indeed, removing the lagg and assigning the em0 to WAN, and the interface shows up.. Bummer that the two can't work together.

It's funny though: lagg does not support ALTQ, but we have patches to make VLANs support ATLQ. Make your switch tag the traffic on the LAGG and then use a tagged VLAN interface, and you can get ALTQ again.

e.g. LAGG on the switch set to both ports with a native VLAN of 10, change that to trunk/802.1q tag of 10 on the switch, and then add a VLAN on the LAGG on pfSense, so you'd assign laggX_vlan10 rather than laggX as the interface.