Deployment Scenarios

Standard Inline Deployment

LibreQoS is placed inline at the edge of your network, usually between the network’s border router (NAT, firewall) and the core distribution router / switch.

NAT/CG-NAT

If you use NAT/CG-NAT, please place LibreQoS inline prior to where NAT is applied, as LibreQoS needs to shape pre-NAT addresses (100.64.0.0/12) not public post-NAT IPs.

MPLS/VPLS

LibreQoS can parse MPLS traffic, however the traffic must follow the standard pattern:

(mpls tags)(optional vlan tags)(ip header)

If you use MPLS with a different tag pattern, you would ideally want to terminate MPLS traffic at the core distribution router / switch, before it reaches LibreQoS.

Dynamic Routing: Bypass path

Primary path (low cost) through the server running LibreQoS
Backup path (high cost) bypassing the server running LibreQoS.

        flowchart LR
    A[Edge Router] -->|OSPF/BGP preferred path| B[LibreQoS inline path]
    B --> C[Core Router/Switch]
    A -->|Higher-cost backup path| C

Interpretation:

In normal operation, routing prefers the low-cost inline path through LibreQoS.
If the inline path fails, routing converges to the higher-cost bypass path.
After recovery, routing preference returns traffic to the inline path.

Option 1: Using Dynamic Routing (Strongly Recommended)

We recommend using dynamic routing protocols such as OSPF to create a high cost and low cost path between the edge router and core distribution router/switch. The low cost path should pass “through” the LibreQoS shaper bridge interfaces to allow LibreQoS to observe and shape traffic. For example, a low cost OSPF path may be set to a value of 1. The high-cost (backup) link would completely bypass LibreQoS, being set to a higher cost (perhaps 100 for OSPF) to ensure that traffic only takes that path when the LibreQoS shaper bridge is not operational.

Testbed Deployment (Optional)

When you are first testing out LibreQoS, you can deploy a small-scale testbed to see it in action on a test network.