On Mon, October 25, 2004 12:50 pm, Henning Brauer said:
> * Tony Sarendal <[EMAIL PROTECTED]> [2004-10-25 16:48]:
>> Is there a way to assign wich queues stateful traffic
>> will use in both directions ?
>
> yes, you can have queues with the same names on multiple interfaces.
>
> i. e. you create the queue "customer1" on both your external (dc0) and
> "his" interface (vlan1). outbond will go to the one on dc0, inbound to
> the one on vlan1.
A better topic would be perhaps "upstream bandwidth
distribution...downstream"
All, the PF FAQ states several fundementals about queuing:
1) "queuing is only useful for packets in the outbound direction"
..then later:
2) "Note that queue designation can happen on an interface other than the
one defined in the altq on directive:
[...example rule set..]
Queueing is enabled on fxp0 but the designation takes place on dc0. If
packets matching the pass rule exit from interface fxp0, they will be
queued in the ftp queue. This type of queueing can be very useful on
routers."
-----
I think a lot of confusion on this topic of multiple interfaaces
originates from three problems:
*) The FAQ/documentation doesn't discuss how stateful rules effect
behavior of queue assigment of returing traffic.
*) The FAQ/documentation doesn't really clarify how matching traffic
inbound on one interface (of which the destination traffic matched will
travel outbound on an inteface on which queuing is enabled) and applying
it to the "outbound" queue of the designated interface (point #2 above)
differs in behavior from simply matching traffic "outbound" on said
queuing-enabled interface.
*) The documentation is a bit ambiguous in the use of terminology such as
"direction", "inbound", "outbound", "upstream", "downstream", "ingress",
"egress", etc.,
....this is especially important with regards to the naming conventions on
queues and also when the behavior of an example rulset is described.
Back to the multiple interface issue:
Let's looks at an example like a Frame Relay network might....say that
your objective is an SLA for your customers worded as so:
"Customer 1 has a 300Kbps bi-directional CIR. Customer 2 has a 500Kbps
bi-directional CIR. Both may borrow from the total available."
*) 1 or 2 physical interface, 3 logical, whatever.
*) The upstream "external" interface is broadband/narrowband delivered via
Fast Ethernet (xl0)
*) For the sake of sanity, the narrowband connectivity is
synchronous/symetric
*) Customer handoff is 100mbs Ethernet (vlan10,vlan20), switch trunked
*) The OpenBSD router is a "perimeter router" with a "pass all" style
ruleset (with scrubbing and RFC1918 bogon filters, etc.)
In this case, you can use a generic template to enforce "upstream" or
"outbound" queues on xl0.
altq on xl0 cbq queue { std-up cust1-up cust2-up }
queue std-up cbq(default ecn)
queue cust1-up bandwidth 10Mb cbq(ecn)
queue cust2-up bandwidth 10Mb cbq(ecn)
pass out on xl0 from $vlan10_subnet to any keep state queue cust1-up
pass out on xl0 from $vlan20_subnet to any keep state queue cust1-up
# these filters will match customer FTP uploads and HTTP GETs from
cuomster-hosted web servers, etc.
# this rule is redundant because the traffic would be forwarded anyway, it
exists simply to match traffic into a queue and create a state table entry
while we're at it.
...
But then let's say you want to invert those rules.
**NOTE**, if customer1 and customer2 were visibile via the same interface,
then you could easily create a queue on that shared customer-facing
interface with a "bandwidth" statement that matches the max hypothetical
"downstream" speed of the broadband connection. Then divy it up using
sub-queues and borrow statements.
...but what if Customer 1 and Customer 2 are on seperate interfaces?
1) You could create non-stateful matching rules as "pass in on $ext_if"
2) You could create non-stateful matching rules as "pass out on $cust1
...", "pass out on $cust2...",
But the question remains: Into what queue? What type of queue would be
used to desginate a policy for "downstream traffic flows" that are
traveling "inbound" via an "upstream" interface, processed by the router,
and forwarded "outbound" via two "downstream" interfaces, ***while SHARING
the available "downstream" bandwidth available via the "inbound
interface"***
It's as if there needs to almost be a seperate type of queue not affilated
with an Interface, i.e., the "ingress/egress" queue for matching traffic
switched from interface-to-interface.
We keep saying, "you can't queue inbound", which makese sense.
But you need a technique for queuing a "shared ingress"
~BAS
>
> --
> http://2suck.net/hhwl.html - http://www.bsws.de/
> Unix is very simple, but it takes a genius to understand the simplicity.
> (Dennis Ritchie)
>
>
--
l8r* --
~ Brian A. Seklecki
"From back in the heady days when 'Help Desk' meant nothing, 'Disk Quota'
meant everything, and lives could be bought and sold for a couple of pages
of laser printout...and frequently were."
