On Wed, Sep 14, 2005 at 01:26:12PM -0400, Brandon Mercer wrote:
> 
> What I was figuring is that I need to shape the "general" bandwidth on
> the interface, i.e. give the VPN say 512Kb/512Kb and if that isn't in
> use let it be used by the other services that will be connecting to that
> interface.  Then within the VPN I need to allow 72Kb per phone, but give
> that bandwidth back up when it's not in use.  And I have to prioritize
> packets... so probably use hfsc.

  what comes to mind intially, is to take the real outgoing external
  iface, and setup queues on that such that there is one queue who will
  be used for outgoing esp, and then a queue used for outgoing everything-else.

  create children of the everything-else queue for your cleartext traffic
  as needed (eg, if you wanted simple basic ACK prio, make two of them under
  the everything-else queue)

  queue all outbound esp on the external iface equally.

  then setup altq on enc0 for the "queue in the VPN" stuff, with an 
  altq bandwidth equal to the same size you set up for the esp-only queue
  on the external iface.

  for all the queues on enc0, set those up as you want for the VPN queueing
  and just run from there.

  i'm thinking that traffic will come in, be queued out enc0 per the 
  'altq on enc0' into esp.  that stream of esp is already "interiorly" 
  queued as it goes out the external iface, and then as encapsulated esp, 
  has to obey the rules of the "vpn only" queue on the external.

  then, of course, make sure you don't prioritize traffic on the external
  such that the cleartext stuff ends up beating out the VPN-only traffic
  and mooting the queueing you did on enc0, relative to the big picture.

  if that's consistent with how altq/pf works wrt to the enc0 and actual
  interfaces, it would seem to be just a matter of imagining up how to 
  divvy the queues.

  jared

- 

[ openbsd 3.7 GENERIC ( sep 1 ) // i386 ]

Reply via email to