Queues and multiple interfaces



  • I have a traffic shaping dilemma. We currently have a Soekris net-5501-70 setup with the following attributes :

    WAN vr0 1.5Mb T1 (routed /30 net)
    LAN  vr1 100Mb Ethernet (Natted /24 RFC1918 net)
    Bridge ath0 (wifi bridged to LAN)
    OPT1 vr2 100Mb Ethernet (routed /28 net)

    OPT2 vr3 6Mb/768k DSL

    All traffic from the LAN interface is natted to the WAN, and all traffic from the OPT1 interface is routed to the WAN. A load balancing rule diverts HTTP traffic on the LAN to OPT2 (DSL).

    Traffic shaping was setup using the wizard for LAN/WAN, this works great for our private LAN network. For those using the OPT1 (further labeled as "pub") network with public IP addresses, there is no traffic shaping. Due to an issue with pfSense, we can not use multiple SIP phones on the private network (see NAT Limitations http://www.pfsense.org/index.php?option=com_content&task=view&id=40&Itemid=43). Due to this limitation, we are using SIP phones on the OPT1 network.

    My first inclination was to setup additional queues for the OPT1 (pub) network, and this is where I ran into the first barrier. There appears to be a bug in the code that generates the queues that results in several errors, here's the first one :

    There were error(s) loading the rules: /tmp/rules.debug:28: queue qpubRoot has no parent

    This is apparently caused by the lack of an "altq" command being created for the vr2 interface. Here is the original generated code from /tmp/rules.debug :

    altq on vr0 hfsc bandwidth 1450Kb queue { qwanRoot }
    altq on vr1 hfsc bandwidth 1450Kb queue { qlanRoot }

    queue qwanRoot bandwidth 1450Kb priority 0 hfsc { qwandef, qwanacks, qVOIPUp, qP2PUp, qOthersUpH, qOthersUpL }
    queue qlanRoot bandwidth 1450Kb priority 0 hfsc { qlandef, qlanacks, qVOIPDown, qP2PDown, qOthersDownH, qOthersDownL }
    queue qpubRoot bandwidth 1450Kb priority 0 hfsc { qpubdef, qpubacks, qVOIPpubDown }

    queue qwandef bandwidth 1% priority 1 qlimit 500 hfsc (  default realtime 1% )
    queue qlandef bandwidth 1% priority 1 qlimit 500 hfsc (  default realtime 1% )
    queue qpubdef bandwidth 1% priority 1 hfsc (  default realtime 1% )

    queue qwanacks bandwidth 25% priority 7 hfsc (  realtime 10% )
    queue qlanacks bandwidth 25% priority 7 hfsc (  realtime 10% )
    queue qpubacks bandwidth 25% priority 7 hfsc (  realtime 10% )

    queue qVOIPUp bandwidth 25% priority 7 hfsc (  realtime 512Kb )
    queue qVOIPDown bandwidth 25% priority 7 hfsc (  realtime 512Kb )
    queue qVOIPpubDown bandwidth 25% priority 7 hfsc (  realtime 512Kb )

    queue qP2PUp bandwidth 1% priority 1 qlimit 500 hfsc (  red ecn upperlimit 384Kb realtime 1Kb )
    queue qP2PDown bandwidth 1% priority 1 qlimit 500 hfsc (  red ecn upperlimit 384Kb realtime 1Kb )
    queue qOthersUpH bandwidth 25% priority 4 hfsc (  red ecn realtime 1Kb )
    queue qOthersDownH bandwidth 25% priority 4 hfsc (  red ecn realtime 1Kb )
    queue qOthersUpL bandwidth 1% priority 2 qlimit 500 hfsc (  red ecn realtime 1Kb )
    queue qOthersDownL bandwidth 1% priority 2 qlimit 500 hfsc (  red ecn realtime 1Kb )

    If I add the following line :

    altq on vr2 hfsc bandwidth 1450Kb queue { qpubRoot }

    I can load the queues with :

    pfctl -f /tmp/rules.debug

    I suspect there are other issues, as qpubdef should have "qlimit 500" like qlandef and qwandef. Can someone confirm this is indeed a bug, so that I may file a report if one does not exist already? All I saw in the bug database were issues relating to .08x versions of pfSense.

    With the queues and rules being loaded, I do see traffic properly handled by the corresponding queues. Unfortunately I fear that traffic will not be properly shaped during peak usage because the LAN and OPT1 Root queues each have the same bandwidth available as the WAN. In other words, the aggregate bandwidth configured for these two internal interfaces (LAN and OPT1) exceeds the T1 (WAN) by a factor of two. This theoretically means that traffic shaping will fail when the T1 is saturated, as it often is.

    That said, what is the proper way to divide the available WAN bandwidth between the two internal interfaces, without restricting either interface to half the max available bandwidth?

    Chris


Log in to reply