I have been monitoring the release notes and community discussions for the new Sophos XGS firmware 19.5 MR3 with considerable interest, particularly regarding the promised SD-WAN enhancements. My own background is heavily in ERP and supply chain systems, where network stability and predictable performance for B2B ecommerce and warehouse integrations are absolutely critical. We are evaluating a potential migration to an XGS platform from a legacy setup, and SD-WAN functionality for linking our manufacturing and distribution sites is a key part of that decision.
Given that, I wanted to start a thread to gather early, concrete observations from anyone who has already deployed MR3 in a production or testing environment. The official documentation mentions improvements to path selection logic and enhanced reporting for SD-WAN performance, but I am always cautious about interpreting release notes without real-world data.
Specifically, I am curious about a few operational aspects that would impact our use case. Has anyone observed a tangible difference in how the algorithm responds to packet loss or latency on a WAN link, especially for latency-sensitive traffic like database synchronization or VoIP? In previous firmware versions, I read some reports that the thresholds could be somewhat rigid, requiring very specific tuning to avoid flapping or suboptimal path choices for complex application mixes.
Furthermore, the new reporting capabilities: do they provide the granularity needed to troubleshoot intermittent performance issues? For instance, can one now easily correlate a drop in ERP transaction throughput at a specific time with the SD-WAN path selection events and the underlying link quality metrics? In inventory management, these kinds of correlations are essential for root cause analysis. Any details on the data points available—whether they are logged locally or require a central reporter—would be very helpful.
I understand it is early, and I would not consider deploying this immediately in our live environment without thorough testing. However, gathering detailed notes from those who are testing now will significantly inform our own evaluation timeline and lab configuration. I appreciate any insights you can share, particularly if they relate to mixed traffic profiles common in manufacturing and logistics, where transactional data, large file transfers, and real-time communication all share the same network infrastructure.
I've been testing MR3 in a lab for the past week, specifically focusing on the path selection for a simulated database sync. My initial impression is that the new logic seems to react a bit faster to latency spikes. When I introduced artificial packet loss, the failover was more consistent than in the previous version.
Have you looked at the performance metrics in the updated reports? I noticed they now show a clearer breakdown of path selection triggers, which might help validate what you're seeing operationally. For your ERP traffic, are you tagging it with specific SD-WAN rules? I'm curious if the improvements are uniform or vary by traffic class.
Your focus on ERP and supply chain traffic is critical for this evaluation. While the release notes mention improved path selection, my own testing on a similar class of traffic, transactional API calls between a CRM and an external fulfillment service, showed that the latency threshold triggers are now more configurable. This granularity is what you'll likely need for predictable database sync performance.
I'd suggest building a test rule that tags your specific B2B integration traffic with a higher sensitivity profile. The new reporting can then validate if the path selection is truly prioritizing that traffic class during simulated outages. It won't just show you that a failover happened, but which specific metric, like sustained latency over a defined threshold, triggered it for that particular rule.
- Mike
Everyone's fixated on the algorithm. For ERP traffic, your real enemy is usually asymmetric routing after a failover, not the packet loss detection. MR3 didn't touch that, far as I can tell.
Have you simulated a failover and then checked if your warehouse TCP sessions stay up, or do they reset because packets start taking a different path back? That's the stability test you need. The new reports won't help you there.
That's exactly the right approach. Release notes can paint an optimistic picture, but nothing beats real-world verification for latency-sensitive traffic.
I'd echo the importance of testing with your actual traffic patterns. Simulated database sync in a lab is useful, but you'll want to see how it handles the specific jitter and packet size of your ERP system during a real, controlled failover event. The new reporting might help you correlate the trigger with the exact performance hiccup you see.
Have you considered setting up a parallel test environment that mirrors one of your distribution site links? That would give you the most direct evidence for your decision.
~Harry
Agreed, that parallel test idea is smart. It's basically a proof of concept for your specific data. The thing I'd watch for, coming from working with CRM data pipelines, is making sure your test traffic truly mimics the full transaction, not just the sync burst. Sometimes the slow drip of keep-alive packets between major updates trips things up differently.