MikroTik Got Faster—and the Branch Lost Server Access: The FastTrack Trap

The Internet Got Faster. The Business Operation Disappeared

Hello, colleagues. I am Maksim, a systems administrator. A branch enables FastTrack: router CPU usage falls and Internet access looks faster. Yet employees can no longer open an application hosted at headquarters. The tunnel is up and ping succeeds, while a TCP connection stalls. The administrator starts Torch—and the fault seems to disappear.

It is tempting to blame the VPN, MTU or ISP. First investigate another possibility: did the connection enter an accelerated path incompatible with processing it still needs? FastTrack does not know which business operation matters. It follows the eligibility decision encoded in the rules.

We will trace a connection from its first packet to established state, distinguish packet marks from connection marks, and build narrowly scoped eligibility. The kit contains inspection commands, disabled lab candidates, activation and restoration of the previous state. Success means the intended operation follows the intended path, not merely a lower CPU graph.

The scope is IPv4 software FastTrack on RouterOS 7.x; the pilot deliberately covers TCP only. Import dry-run syntax requires RouterOS 7.16+. Verify the installed version and hardware capabilities separately. This is a teaching scenario, not measurements from a real branch. No customer router is being changed, and the lab fragment is not presented as a complete production configuration.

Three Different Failures Called “FastTrack Is Broken”

Separate the symptoms before changing anything. Otherwise we risk fixing routing with queues or investigating encryption where it is not involved.

1. Wrong path selection. Ordinary processing directs traffic through another table while the accelerated flow uses main. Initial packets and later parts of the exchange can therefore face incompatible routing conditions.
2. Required processing is skipped. The connection depends on IPsec, particular queues, mangle or another facility bypassed by acceleration. Connectivity may remain while the required policy stops being enforced.
3. Misleading observation. An ordinary-rule counter does not describe the whole stream, an existing connection retains old state, or the observing tool changes FastTrack conditions. The investigation starts contradicting itself.

These are different mechanisms. NAT alone is not a reason for exclusion: FastTrack supports SNAT and DNAT. Additional requirements create the incompatibility. Our pilot deliberately excludes DNAT to keep published-service behavior outside the initial ordinary-client test.

The blunt solution is permanently disabling FastTrack. That may restore processing, but can increase router load and does not establish which connections are safe to accelerate. Temporary restriction can be a sensible recovery action; it should be followed by an eligibility analysis. Connection tracking documentation.

The Teaching Branch: Two Policies and One Ordinary Client

Consider a branch with two WANs and an existing wg-hq tunnel. Client 192.0.2.10 must reach headquarters through table to-hq. Client 192.0.2.11 is the narrowly scoped ordinary-main pilot using ether1. These are documentation addresses; the exercise must remain isolated from the public Internet.

The incident depends on a specific condition: the useful HQ route is in the custom table while main leads toward a WAN. Ordinary policy processing selects the correct route before acceleration. This is not advice to hide corporate routes from main; it is a topology that exposes the distinction. If main also has a suitable HQ route, the symptom changes, although compatibility still needs examination.

An excerpt from the already functioning lab:

# ILLUSTRATION ONLY: excerpts from an ALREADY WORKING LAB.
# Not an importable tunnel configuration. No keys or WAN provisioning here.
/routing table
add name=to-hq fib
/ip route
add dst-address=198.51.100.0/24 gateway=wg-hq routing-table=to-hq
/routing rule
add src-address=192.0.2.10/32 dst-address=198.51.100.0/24 action=lookup-only-in-table table=to-hq
# This routing rule does NOT set connection-mark.
# main has the lab's WAN default; the custom table has the HQ route.
# Established sessions must never become eligible for main-only FastTrack.

Routing-rule order, WireGuard allowed addresses, reverse routes, NAT and the original access policy must already be verified. This block does not create a VPN, grant access or provision ISPs. If the ordinary route fails before FastTrack is involved, acceleration is the wrong starting point. It cannot repair basic routing.

Level 1. Decide What You Are Allowing the Router to Skip

An ordinary routed packet traverses a sequence of processing stages. Connection state, marks, translation and routing are established at the appropriate points. FastTrack shortens that path for a selected connection. Some packets still use ordinary processing, so the slow path must remain correct, including the existing established-traffic acceptance for authorized flows.

MikroTik documents the accelerated path as main-table processing: route lookup happens before routing marks are applied. A connection dependent on another table must therefore not accidentally become eligible. This is the core of our incident, not a claim that every VPN is incompatible with every form of acceleration. Packet Flow.

Before enabling it, ask whether removing subsequent packets from ordinary processing preserves routing, access control, encryption and servicing. Answer for both directions. If correctness requires repeated mangle processing, “the first packet saw the rule” is insufficient.

Keep authorization separate from acceleration. New connections must first satisfy the existing security policy. This article does not add broad accept rules merely to bypass FastTrack; doing so could accidentally skip later security controls while appearing to fix performance.

A Connection Mark Is Not a Routing Mark

A common recipe is to add connection-mark=no-mark and declare the problem solved. It helps only within a known classification architecture. If PCC already labels connections, the condition can exclude those flows. But routing rules can select another table without setting a connection mark—as in our lab.

A routing mark concerns packet processing; a connection mark belongs to the connection entry. There is no independent collection of labels for every project. Assigning a new “do not accelerate” mark can overwrite the PCC value that selects the WAN. Do not add mark-connection to an existing design without analyzing all current values and their consumers.

Even routing-mark=main in filter is only a supplementary check on the current packet. A reply can naturally use main toward the connected branch network while the original direction depends on policy routing. Selecting the whole connection from that reply would leave an eligibility gap.

My practical conclusion is to first identify flows for which main is correct in both directions and no bypassed facility is required, then scope FastTrack to that class. The new documentation includes the mangle reference. That reference does not replace examining your routing rules, VRFs and queues.

Level 2. Capture State Before Changing It

Before moving rules, record the version, interfaces, tables, routing rules and every connection/routing-mark assignment. Inspect filter, NAT, queues and VRFs. Find every active fasttrack-connection action: fixing one rule is ineffective if another broad selector still catches excluded flows.

# RouterOS 7.x: read-only. Redact exports before sharing.
/system resource print
/system package print
/interface print detail
/ip settings print
/routing table print detail
/routing rule print detail
/ip route print detail
/ip firewall filter print detail
/ip firewall filter print stats
/ip firewall mangle print detail
/ip firewall mangle print stats
/ip firewall nat print detail
/ip firewall connection tracking print
/queue simple print detail
/queue tree print detail
/ip vrf print detail
# Inspect IPsec/Hotspot/L3HW separately if configured; do not export secrets.
# On a large router narrow route/rule output before collection.

These commands inspect state, but their output can disclose internal addressing and topology. Store it in an approved private location. Narrow queries on a large router rather than generating uncontrolled dumps, and never publish secret-bearing exports. A binary backup, text export and tested recovery access serve different purposes; export alone is not a complete recovery image.

Locate the existing ordinary established-traffic accept after acceleration and the policy authorizing new connections. We are reducing acceleration scope, not installing a new firewall over an unknown one. If an excluded flow then encounters an ACL restriction, investigate that separately instead of adding accept-all.

Compare counter changes around one known client operation without unnecessarily resetting shared counters. A screenshot of aggregate throughput cannot establish the path of a particular TCP flow. Next we identify that flow’s original five-tuple and follow its state.

The First Packet Took the Correct Route. What About the Next?

In the teaching sequence, .10 contacts the HQ HTTP probe. The first packet follows the routing rule through wg-hq. During the exchange, the connection becomes established and reaches a broad FastTrack action. Accelerated packets subsequently face main-table routing, which does not implement the required HQ policy. This is a possible sequence for our topology; prove a real incident from observations rather than the feature’s name.

Choose a harmless client read operation. Test TCP establishment separately from application response: an open port is not a completed operation. The lab can use an existing simple HTTP service that creates no business documents and changes no data. A ping generated by the router uses local-out rather than the forwarded client path. Even client ICMP does not validate TCP FastTrack eligibility: the mechanism described here accelerates TCP/UDP.

# Windows client inside the isolated lab. Not a production 1C write test.
# 198.51.100.10:8000 is a preconfigured harmless HQ HTTP test service.
Test-NetConnection -ComputerName 198.51.100.10 -Port 8000
curl.exe --http1.1 --local-port 45000 --connect-timeout 5 --max-time 15 -H "Connection: close" http://198.51.100.10:8000/
# Re-test in a NEW process with a NEW source port after closing the prior flow.
curl.exe --http1.1 --local-port 45001 --connect-timeout 5 --max-time 15 -H "Connection: close" http://198.51.100.10:8000/
# Ordinary main-table pilot: run from 192.0.2.11 against a preconfigured LAB WAN service.
# curl.exe --http1.1 --local-port 45002 --connect-timeout 5 --max-time 15 -H "Connection: close" http://203.0.113.80:8000/

Record original source address/port, destination address/port, protocol, time and result. Then inspect the matching entry:

# READ ONLY: pick a known client and its actual fresh TCP tuple.
/ip firewall connection print detail where protocol=tcp and src-address~"^192[.]0[.]2[.]10:"
# Example ONLY: port 45000 is deliberately bound by the client below.
/ip firewall connection print detail where protocol=tcp and src-address="192.0.2.10:45000" and dst-address="198.51.100.10:8000"
/ip firewall filter print stats where action=fasttrack-connection
/ip firewall mangle print stats
# Check original/reply addresses, connection-mark and F / fasttrack fields.
# When exposed by the build: orig-fasttrack-bytes / repl-fasttrack-bytes.
# No remove [find], no global connection-table flush.

Compare original and reply directions, the connection mark, FastTrack indication and available accelerated-packet counters. A small request may finish too quickly or transfer too little data; lack of visible counter growth alone does not prove exclusion. A positive acceleration test needs a controlled sufficient exchange, not a production stress test.

Do not flush the entire connection table. That interrupts unrelated sessions, alters NAT state and destroys evidence. A fresh source port and new client session test the new policy with much less impact.

Why Torch Can Appear to Repair the Branch

For the documented software path, MikroTik lists absence of running Torch/sniffer among FastTrack conditions. This creates an observer effect: starting the tool changes processing and can hide the original fault. It does not establish that an ISP problem disappeared. Packet Flow requirements.

Start with table inspection, narrow connection queries and ordinary counters. If a capture is necessary, explicitly record its activation as a changed experimental condition. Compare a fresh client session after stopping it. Where possible, observe at endpoints or through an approved external mirror/TAP without changing router processing.

This is not a promise that every tool disables every form of acceleration on every ASIC. Hardware paths need their own validation. However, “everything works while Torch is running, therefore FastTrack is unrelated” is already invalid reasoning for the software design described here.

Three comparisons are more useful than one capture: the original policy without observing tools; an approved control policy with a fresh flow; and the original or corrected policy after observation stops. Record which conditions changed in each case. That turns an apparently mysterious self-healing network into an experiment somebody else can review.

Level 3. Explicit Eligibility Instead of Accumulating Exceptions

Start with a narrow positive class: one verified ordinary client, .11; established TCP; main; no connection mark; and bridge-lan↔ether1. That class must require no policy routing, IPsec, VRF, Hotspot or incompatible queue treatment. Corporate destinations and policy client .10 are also listed as exclusions.

Check both directions. Outbound traffic needs an eligible local source and a nonexcluded destination. Replies need a nonexcluded source and an eligible local destination. This avoids a source-only exclusion that the reply direction could bypass when selecting the connection.

connection-mark=no-mark and routing-mark=main remain supplementary restrictions. They do not replace the semantic contract of AF-FT-ELIGIBLE. Do not later add a host requiring its own queue, VRF or routing rule without reclassification. The policy owner must maintain that contract as the network changes.

The pilot sets hw-offload=no so software behavior is not mixed with hardware FastTrack. This candidate property does not automatically disable every other L3 offload mechanism. On hardware-routing devices, first establish that the test traffic really traverses the intended software path.

Excluding DNAT is a pilot boundary, not a claim that FastTrack lacks translation support. UDP and related flows are not added automatically either. Introduce separately verified classes rather than broadening one rule to encompass everything.

Stage Disabled Candidates While Preserving the ACL

Warning: a firewall or routing error can disconnect the branch and management access. Restricting broad FastTrack can also increase CPU load. Use an approved window, appropriate exports/backups, independent access and a defined restoration plan. This publication provides a lab example; it makes no changes to a live router.

The kit checks identity AF-FASTTRACK-LAB and one exact LAB-OLD-FASTTRACK anchor. This prevents accidental import; it does not certify the configuration as safe. Select the initially enabled anchor beforehand in the lab. The script neither creates it nor chooses the first FastTrack rule it finds.

# LAB ONLY. Requires an existing, reviewed firewall and working routes/tunnel.
# Creates DISABLED TCP FastTrack candidates; does not add any accept rule.
# Re-running refuses collisions. Not an atomic transaction: inspect partial results.
{
 :if ([/system identity get name] != "AF-FASTTRACK-LAB") do={ :error "LAB identity required; adapt only after review" }
 :foreach iface in={"bridge-lan";"ether1"} do={
  :if ([:len [/interface find where name=$iface]] != 1) do={ :error ("Missing interface: " . $iface) }
 }
 :local old [/ip firewall filter find where comment="LAB-OLD-FASTTRACK"]
 :if ([:len $old] != 1) do={ :error "One exact old-rule anchor required" }
 :if ([/ip firewall filter get $old action] != "fasttrack-connection") do={ :error "Wrong old action" }
 :if ([/ip firewall filter get $old chain] != "forward") do={ :error "Wrong old chain" }
 :if ([/ip firewall filter get $old disabled]) do={ :error "Expected original rule enabled" }
 :if ([:len [/ip firewall filter find where action=fasttrack-connection and disabled=no]] != 1) do={ :error "Review other enabled filter FastTrack selectors" }
 :if ([:len [/ip firewall mangle find where action=fasttrack-connection and disabled=no]] != 0) do={ :error "Review enabled mangle FastTrack selectors" }
 :if ([:len [/ip firewall filter find where comment~"^AF-FT-PILOT-"]] != 0) do={ :error "Pilot rules already exist" }
 :if ([:len [/ip firewall address-list find where list="AF-FT-ELIGIBLE"]] != 0) do={ :error "Eligible list collision" }
 :if ([:len [/ip firewall address-list find where list="AF-FT-SLOW"]] != 0) do={ :error "Slow list collision" }
 /ip firewall address-list add list=AF-FT-ELIGIBLE address=192.0.2.11 comment="AF-FT-PILOT-HOST"
 /ip firewall address-list add list=AF-FT-SLOW address=198.51.100.0/24 comment="AF-FT-PILOT-HQ"
 /ip firewall address-list add list=AF-FT-SLOW address=192.0.2.10 comment="AF-FT-PILOT-POLICY-HOST"
 /ip firewall filter add chain=forward action=fasttrack-connection protocol=tcp connection-state=established connection-mark=no-mark routing-mark=main in-interface=bridge-lan out-interface=ether1 src-address-list=AF-FT-ELIGIBLE dst-address-list=!AF-FT-SLOW connection-nat-state=!dstnat ipsec-policy=out,none hw-offload=no disabled=yes place-before=$old comment="AF-FT-PILOT-OUT"
 /ip firewall filter add chain=forward action=fasttrack-connection protocol=tcp connection-state=established connection-mark=no-mark routing-mark=main in-interface=ether1 out-interface=bridge-lan src-address-list=!AF-FT-SLOW dst-address-list=AF-FT-ELIGIBLE connection-nat-state=!dstnat ipsec-policy=in,none hw-offload=no disabled=yes place-before=$old comment="AF-FT-PILOT-IN"
 :put "Staged DISABLED rules. Check placement and existing slow-path accepts/drops. Old rule still active."
}

Candidates are disabled and placed before the reviewed anchor. Their address lists must not already exist. Conflicts cause a stop. RouterOS scripts are not atomic transactions: an error after some operations can leave partial state. Inspect it instead of blindly repeating the import.

The script adds no accept rule. Existing firewall policy continues to decide whether a connection is authorized. If a design requires every established packet to traverse later security checks, acceleration there is not valid merely because these candidates are narrow.

Production adaptation is a separate review of real interfaces, host classification, all selectors and ACL order. Renaming a production router to pass the identity check is not that review.

Dry-Run, Safe Mode and the Limits of Recovery Safeguards

RouterOS 7.16 introduced verbose import dry-run checking. It helps find syntax errors, but does not simulate packet delivery or validate the topology. A successful check cannot replace a working lab with the relevant conditions reproduced. Scripting/import reference.

# RouterOS 7.16+ import syntax check, AFTER reviewing the file.
# Run on the disposable lab router, not via a production routing experiment.
/import file-name=02-stage-lab.rsc verbose=yes dry-run
# Dry-run is NOT proof of routing, firewall semantics or runtime prerequisites.
# Enter Safe Mode with Ctrl+X / F4 and confirm <SAFE>; keep changes small.
# Then, in the approved LAB only:
# /import file-name=02-stage-lab.rsc
# Inspect disabled candidates and rule order before activation.

Enter CLI Safe Mode with Ctrl+X/F4 and confirm the session state. It can restore configuration changes after an abnormal management disconnect, but is not instantaneous, cannot undo already lost client operations, and has bounded history. Keep changes small and retain independent management access. Configuration Management.

Before activation, recheck disabled candidates, an unambiguous anchor, its originally enabled state, other broad FastTrack rules, and the ordinary established path and required ACLs. Read current ordering instead of relying on previously displayed row numbers.

The addresses and roles are illustrative. Perfectly valid syntax does not turn 192.0.2.11 into a safe client in your organization. This is where the example’s general method ends and responsibility for a particular network begins.

Level 4. Change Selection for New Flows and Check Existing Ones

During the lab window, disable the exact old selector and enable the two reviewed candidates. This changes acceleration eligibility, not routes or access rights. The script rechecks anchor count, action and expected enabled state.

# LAB ONLY, approved test window and independent management path.
# Changing FastTrack policy does not reclassify already accelerated connections.
{
 :if ([/system identity get name] != "AF-FASTTRACK-LAB") do={ :error "LAB identity required" }
 :local old [/ip firewall filter find where comment="LAB-OLD-FASTTRACK"]
 :local outbound [/ip firewall filter find where comment="AF-FT-PILOT-OUT"]
 :local inbound [/ip firewall filter find where comment="AF-FT-PILOT-IN"]
 :if (([:len $old] != 1) || ([:len $outbound] != 1) || ([:len $inbound] != 1)) do={ :error "Exact anchors required" }
 :foreach r in={$old;$outbound;$inbound} do={
  :if ([/ip firewall filter get $r action] != "fasttrack-connection") do={ :error "Rule action changed" }
  :if ([/ip firewall filter get $r chain] != "forward") do={ :error "Rule chain changed" }
 }
 :if ([/ip firewall filter get $old disabled]) do={ :error "Original enabled-state changed; stop and inspect" }
 :if ([:len [/ip firewall filter find where action=fasttrack-connection and disabled=no]] != 1) do={ :error "Unexpected active filter selector" }
 :if ([:len [/ip firewall mangle find where action=fasttrack-connection and disabled=no]] != 0) do={ :error "Unexpected active mangle selector" }
 :if ((![/ip firewall filter get $outbound disabled]) || (![/ip firewall filter get $inbound disabled])) do={ :error "Candidates must still be disabled" }
 /ip firewall filter disable $old
 /ip firewall filter enable $outbound
 /ip firewall filter enable $inbound
 :put "Only the two reviewed candidates enabled. Start FRESH test connections. Check for other broad FastTrack rules."
}

An already selected FastTrack connection need not be immediately recreated by editing filter rules. The documented state follows the connection lifetime. Close the approved test-client session and start a fresh one, confirming a new tuple. An application’s old keepalive connection is not a test of the new selector.

Deleting a configuration rule does not undo NAT state or resurrect an old TCP exchange. Agree which test connections may close and which live sessions must remain untouched. Global connection-table flushing and router reboot are not part of this method.

The comparison needs two positive cases: the policy client gets its HQ response without acceleration, while the ordinary pilot uses main with verified FastTrack. Add a negative case: a forbidden new connection remains forbidden. Testing only Internet access can miss another change in security or corporate reachability. Check after observing tools stop, and preserve both the configuration and flow-state conditions so the result can be reproduced.

IPsec, Queues and Hardware Acceleration Are Different Mechanisms

A VPN’s presence does not identify the cause by itself. Policy-based IPsec requires its policy processing; a flow that depends on it must not bypass it. With a routed tunnel such as WireGuard, distinguish inner traffic, outer UDP transport and routing-table choice. Excluding only the tunnel interface may not describe all those directions.

Queue behavior depends on the facility. Accelerated traffic bypasses Simple Queues and queue trees parented to global; that does not mean every interface queue disappears. Evaluate required mangle classification as well. A low queue counter can reflect bypass rather than absence of traffic.

Bridge hardware offload, software FastTrack and L3 hardware offload are distinct. An H flag in one display does not explain the entire packet journey. Supported ASICs have their own processing rules, table restrictions, capacity and CPU interactions. Current L3 Hardware Offloading guide.

Our pilot deliberately avoids global hardware toggles and universal throughput claims. If traffic remains in an ASIC outside the software path under investigation, it is a different experiment. Establish the model, installed version and actual path before choosing a verification method.

Acceptance Matrix: Verify Exclusion and Preserved Acceleration

Verification does not end at “it opens now.” For every probe, preserve client, server, source port, time, active policy, observing-tool state, connection state and application result. Before/after tests must share the relevant conditions.

A negative test does not require scanning the whole network or introducing risk. Use an approved forbidden destination in the isolated lab. Verify management access separately; a successful browser request does not prove continued administrative access.

Also check ordinary handling for an eligible FastTrack flow. Some packets still take that path by design, so the existing firewall must handle them correctly. Compare deltas and the specific connection entry rather than requiring one rule counter to equal total traffic volume.

Route changes and WAN failures interact with existing state and NAT. Preserving sessions during failover is a separate problem; this selector change does not promise to solve it. Our acceptance test needs a fresh authorized flow on a known working path. After a successful pilot, expand eligibility one reviewed class at a time rather than replacing .11 with the entire LAN.

Restoration and the Boundary of Validation

Distinguish two rollback goals. Restoring the original configuration also restores the broad FastTrack rule that may have caused the fault. Recovering the business operation may instead require leaving acceleration restricted while capacity is addressed separately. These are not the same action.

# LAB ONLY. Restores the documented original ENABLED state of the old anchor.
# This can reproduce the original fault. Incident recovery may instead keep FT off.
# Does not remove lists, purge connections, alter routes, NAT or security accepts.
{
 :if ([/system identity get name] != "AF-FASTTRACK-LAB") do={ :error "LAB identity required" }
 :local old [/ip firewall filter find where comment="LAB-OLD-FASTTRACK"]
 :local outbound [/ip firewall filter find where comment="AF-FT-PILOT-OUT"]
 :local inbound [/ip firewall filter find where comment="AF-FT-PILOT-IN"]
 :if (([:len $old] != 1) || ([:len $outbound] != 1) || ([:len $inbound] != 1)) do={ :error "Exact anchors required" }
 :foreach r in={$old;$outbound;$inbound} do={
  :if ([/ip firewall filter get $r action] != "fasttrack-connection") do={ :error "Rule action changed" }
  :if ([/ip firewall filter get $r chain] != "forward") do={ :error "Rule chain changed" }
 }
 /ip firewall filter disable $outbound
 /ip firewall filter disable $inbound
 /ip firewall filter enable $old
 :put "Previous LAB FastTrack enabled-state restored. Verify fresh connections; old flow state was not undone."
}

The script assumes the lab’s documented original state: the exact old anchor was enabled. It does not remove lists or flush connections; flow state does not rewind with configuration. Verify fresh flows and management access afterward. In production, record exact anchors, original values and restoration criteria before any change.

Download inspection commands, lab candidates, activation, rollback, RU/EN guides and the acceptance matrix.

Commands were checked against MikroTik documentation; no RouterOS/CHR instance ran for this publication. The files did not undergo an actual RouterOS dry-run and are not claimed device-tested configurations. Local checks cover article generation, code integrity, kit structure and the eligibility model, not firewall emulation.

The old help.mikrotik.com site is marked frozen. Key behavior was cross-checked against accessible sections of the new manual.mikrotik.com; this is not a compatibility matrix for every model and release. No throughput percentages or customer-branch test results were invented.

Acceleration Must Preserve the Network’s Meaning

We moved from “FastTrack broke the branch” to a specific chain: the required table, connection-selection timing, ordinary and accelerated paths, both directions and observation conditions. That removes much of the guesswork between VPNs, ISPs and randomly disabling features.

The key point is simple: FastTrack grants permission to skip processing. Grant it only to connections that genuinely do not need that processing. No mark does not prove absence of policy, a connected tunnel does not establish application routing, and Torch can change the experiment itself.

Thank you for reading. Start with one flow, one pilot client and a reproducible result. Preserved security and a correct business operation matter more than a pleasing CPU graph. Then measure the acceleration that remains useful.

• How do you maintain FastTrack eligibility after adding queues, routing rules or another ISP?
• Have you seen a fault disappear while Torch or a capture ran, and how did you separate observation from processing changes?
• Which tests establish that ordinary main traffic remains accelerated after policy-dependent flows are excluded?