Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 14 Nov 2004 17:53:08 +0100
From:      Max Laier <max@love2party.net>
To:        "Shane James" <shane@virtek.co.za>
Cc:        freebsd-pf@freebsd.org
Subject:   Re: FreeBSD ALTQ + PF Problem
Message-ID:  <200411141753.15325.max@love2party.net>
In-Reply-To: <008b01c4ca67$98851fc0$320a0a0a@uranus>
References:  <008b01c4ca67$98851fc0$320a0a0a@uranus>

next in thread | previous in thread | raw e-mail | index | archive | help
--nextPart8092381.HcTstlFhYk
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 14 November 2004 17:32, Shane James wrote:
> Sorry about that one, here is my current rule set.. it's small as I'm just
> trying to get it to work, for now. It seems the traffic is being assigned
> to the que, it's just not limiting it correctly
>
> Here's what it looks like after I do a 'pfctl -vvsq'
>
> queue  argon_u bandwidth 10Mb hfsc( realtime 64Kb upperlimit 64Kb )
>   [ pkts:          4  bytes:        676  dropped pkts:      0 bytes:     =
 0
> ] [ qlength:   0/ 50 ]
>
> queue  argon_d bandwidth 10Mb hfsc( realtime 64Kb upperlimit 64Kb )
>   [ pkts:          5  bytes:        613  dropped pkts:      0 bytes:     =
 0
> ] [ qlength:   0/ 50 ]
>

Again. This is *not* the complete output. Moreover, I find it hard to belie=
ve=20
that you can reliablely measure 64Kbit with only 600 bytes of traffic. Plea=
se=20
post the complete statistics after some time of really bursting the queues.=
=20
If you keep -vvsq running you will also see how much throughput really is=20
happening. Please include this as well.

Can you also specify how you measure how much bandwidth you really have?

>  Macros
> uplink_if=3D"sis0" # External Interface
> hosting_if=3D"rl0" # Internal Interface
> access_if=3D"rl1" # Access Network
>
> # Options: tune the behavior of pf, default values are given.
> set timeout { interval 10, frag 30 }
> set timeout { tcp.first 120, tcp.opening 30, tcp.established 86400 }
> set timeout { tcp.closing 900, tcp.finwait 45, tcp.closed 90 }
> set timeout { udp.first 60, udp.single 30, udp.multiple 60 }
> set timeout { icmp.first 20, icmp.error 10 }
> set timeout { other.first 60, other.single 30, other.multiple 60 }
> set timeout { adaptive.start 0, adaptive.end 0 }
> set limit { states 10000, frags 5000 }
> set loginterface none
> set optimization normal
> set block-policy drop
> set require-order yes
> #set fingerprints "/etc/pf.os"
>
> # Normalization
> scrub in all
>
> # ALTQ
> altq on $uplink_if bandwidth 10Mb hfsc queue { dflt_u, argon_u }
> queue argon_u hfsc(realtime 64Kb upperlimit 64Kb)
> queue dflt_u hfsc(default upperlimit 128Kb)
>
> altq on $hosting_if bandwidth 10Mb hfsc queue { dflt_d, argon_d }
> queue argon_d hfsc(realtime 64Kb upperlimit 64Kb)
> queue dflt_d hfsc(default upperlimit 128Kb)
>
> # argon.virtek.co.za
> pass out on $uplink_if from 196.23.168.137 to any keep state queue argon_u
> pass out on $hosting_if from any to 196.23.168.137 keep state queue argon=
_d
> block in on $uplink_if proto tcp from any to 196.23.168.137 port 22
>
> On Saturday 13 November 2004 21:58, Shane James wrote:
> > Hey guys,
> >
> > I'm having a problem with pf + altq on FreeBSD 5.2.1 (FreeBSD
> > uplink-rtr-jhb.virtek.co.za 5.2.1-RELEASE-p11 FreeBSD 5.2.1-RELEASE-p11
> > #1:
> > Sat Nov 13 15:59:38 SAST 2004
> > root@uplink-rtr-jhb.virtek.co.za:/usr/src/sys.altq/i386/compile/UPLINK
> > i386)
> >
> > The Traffic I assign to queue's does not get limited according to the
> > specific limit, it only get's limited by the global bandwidth limited
> > assign to the specific NIC.
> > e.g. I assign traffic to a queue(argon_d) which is limited to 128Kb...
> > but it performs at 256Kb which is what the NIC is set to. therefore not
> > being assigned to it's designated queue. is it at all possible that this
> > is a problem perhaps with my Network cards... if not... any suggestions?
> >
> > pf.conf
> >
> > altq on $uplink_if bandwidth 256Kb hfsc queue { dflt_u, argon_u }
> > queue argon_u hfsc(realtime 64Kb upperlimit 64Kb)
> > queue dflt_u hfsc(default upperlimit 128Kb)
> >
> > altq on $hosting_if bandwidth 256Kb hfsc queue { dflt_d, argon_d }
> > queue argon_d hfsc(realtime 64Kb upperlimit 64Kb)
> > queue dflt_d hfsc(default upperlimit 128Kb)
> >
> > #assign argon traffic
> > pass out on $uplink_if from 196.23.168.137 to any keep state queue
> > argon_u pass out on $hosting_if from any to 196.23.168.137 keep state
> > queue argon_d
>
> I assume that is not your *complete* ruleset?!? Can everybody please post
> complete rulesets when asking for help? It is okay to emphasize the parts
> that you think are important as it will help to understand the problem, b=
ut
> giving advice or debugging it impossible without the complete ruleset.
>
> Other than that, what does "$pfctl -vvsq" tell you? Does it show that
> traffic
> is being assigned to the small queue at all?

=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

--nextPart8092381.HcTstlFhYk
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (FreeBSD)

iD8DBQBBl417XyyEoT62BG0RAuyfAJ9kVVbeMR+WnPu90eonhk+jqzFRwgCfWoWo
gSSsQ0yC66KPmMbzb5C7J0g=
=GmFP
-----END PGP SIGNATURE-----

--nextPart8092381.HcTstlFhYk--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200411141753.15325.max>