Tun and ALTQ

Max Laier max at love2party.net
Tue Nov 8 10:46:29 PST 2005


On Tuesday 08 November 2005 18:15, Brian Fundakowski Feldman wrote:
> On Tue, Nov 08, 2005 at 02:39:02PM +0100, Marko Cuk wrote:
> > It seems that it work. Thanks.
> >
> > Damn, for vlan's ( 802.1Q)  you should specify "em", for "tun", vice
> > versa... what a mess, hehe.
>
> No prob; I don't see why using the em(4) backing the tun(4) wouldn't
> work for ALTQ _IF_ you actually tagged the (PPPoE?) traffic on em(4).
> I think that might be really hard, though, so for ALTQ you should
> probably just specify the "logical" interface that you intend to
> limit (that would be the IP tun(4) rather than the PPPoE em(4)).

The problem with tun(4) in contrast to vlan(4) is that in some cases the 
packet has to go through userland (i.e. userland PPPoE).  During this detour 
the packet loses the ALTQ mbuf_tag and thus can no longer be stuck into the 
right queue.  That is why there is ALTQ support on tun(4) eventhough it 
doesn't make that much sense to introduce "unnatural" queueing in the pseudo 
interface.  For vlan(4) there is no such problem (VLANs are handled in the 
kernel all the way) so it's easy to stick the ALTQ tags on the packet and 
queue on the hardware interface underneath.

> Do you have suggestion on what would be good text to go into pf.conf(5)
> so that this particular case is documented?

[-> doc@, maybe somebody is interested/creative? ]

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20051108/888ac199/attachment.bin


More information about the freebsd-stable mailing list