--nextPart2460443.PiCAeWLt4t
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
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=20
packet has to go through userland (i.e. userland PPPoE). During this detou=
r=20
the packet loses the ALTQ mbuf_tag and thus can no longer be stuck into the=
=20
right queue. That is why there is ALTQ support on tun(4) eventhough it=20
doesn't make that much sense to introduce "unnatural" queueing in the pseud=
o=20
interface. For vlan(4) there is no such problem (VLANs are handled in the=
=20
kernel all the way) so it's easy to stick the ALTQ tags on the packet and=20
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? ]
=2D-=20
/"\ Best regards, | mlaier@freebsd.org
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News
--nextPart2460443.PiCAeWLt4t
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)
iD8DBQBDcPJ7XyyEoT62BG0RAi1GAJ9aJ9EPEA9c/7xy48qC9zcp/JRQoACeJhMP
2bPguV7gqyhXE95EWNLwp3w=
=PCrd
-----END PGP SIGNATURE-----
--nextPart2460443.PiCAeWLt4t--