Cato Networks SD-WAN - any issues with latency or packet loss?

You've isolated the core operational risk in any managed WAN. The insistence on the AS path is correct, but most vendors, Cato included, will treat that as proprietary.

A practical workaround we've used: during the PoC, run continuous traceroutes from your test sites to your key application IPs, but from *within* the Cato tunnel. You can't see their backbone hops, but you'll capture the egress point and the first upstream AS. That's where the "cheap transit provider" issue will surface.

We did this and discovered that traffic bound for our Azure tenant in West US was exiting a Cato PoP via a tier 2 carrier, not a direct ExpressRoute link, adding 7ms of latency and occasional loss spikes versus our direct ISP path. Their support acknowledged it was a "cost-optimized route" and only changed it after we escalated with the data. Without that proof, it's just a subjective complaint.

Right, the asymmetry you mentioned is really interesting. I've seen that too, where the encrypted tunnel to the PoP adds a predictable 8ms, but the inbound path from the internet back to the PoP can be wildly different.

Your point about cloud on-ramps is the key. But verifying that adjacency can be tricky. Even if a PoP is in an AWS building, you need to confirm it's using a true private interconnect and not just a public exchange. I've gotten burned by that before, where the handoff was still via a public IP, negating a lot of the benefit.

Your setup sounds a lot like ours, with teams spread out. We tested Cato's PoC for a few weeks last quarter.

The jitter improvement was there for our overseas offices, which helped with Zoom. But for our main SaaS apps hosted in us-east-1, the extra tunnel latency was a pure add, like others said. It made our CRM feel slightly slower, which was a dealbreaker for us.

How are you planning to test the real-time apps? We just used regular Zoom calls and asked users, but I'm wondering if there's a better way to measure the impact objectively.

The jitter reduction is real, but it's a solution for a problem you might not have. If your existing internet path to, say, us-east-1 is already decent, you're just buying a latency tax for the privilege of using their tunnel.

>in terms of stability and consistent throughput

That's the marketing promise. The reality is a shared, oversubscribed backbone like anyone else's. The consistency depends entirely on a peering agreement you'll never see. Your video calls will be stable until Cato's cheapest transit provider for that region has a bad day, and you'll be told it's an "upstream issue." Happens more than they admit.

As for comparing it to other solutions, the real differentiator is the lock-in. Migrating off their client and rewriting your access policies is its own special kind of packet loss.

The "latency tax" point is spot on and gets to the fundamental trade-off. You're essentially pre-paying a performance penalty in the hope it's less than the occasional congestion bill from the public internet. For many stable routes, that's a terrible deal.

And that lock-in comment is painfully true. The migration pain isn't just technical, it's financial. Once you've wired your access policies into their cloud, the cost of leaving makes you tolerate those "upstream issue" days. You're not just buying a network, you're buying a relationship with their procurement team for transit.

That's a great, focused question. To actually test it during your PoC, don't just rely on user sentiment on Zoom calls. Set up a simple but constant synthetic transaction test for a key app, like logging into your Jira Cloud instance and loading a dashboard, using a tool like Pingdom or even a custom script. Run it from a few test sites *outside* the Cato tunnel as a baseline, then run it again *inside* the tunnel for the same duration.

You'll see if that "pure latency add" others mentioned is a consistent 20ms or a variable 50-150ms that will genuinely frustrate your team. It turns the "feels slower" into hard data you can take back to their sales engineers.

You've nailed the crucial first step: establishing your own baseline. It's tempting to skip straight to comparing vendor data sheets, but that's a dead end.

Your point about a "clean" current path is where I've seen teams get tripped up. They benchmark against a theoretical ideal, not their actual, messy internet reality. That week of data you mentioned often reveals surprising loss or jitter they'd gotten used to.

One caveat: when you run those extended pings to SaaS IPs, remember that the target's own load balancing can shift your traffic mid-test. It's still valuable, but it's one more variable to note down. It might explain some of the variance in your baseline versus what you see later through a tunnel.

The obsession with consistent throughput is a bit misplaced. You're adding a whole extra network path. The question isn't if it's stable, it's *what* you're stabilizing: a potentially worse route.

Your benchmark shouldn't be an abstract ideal, it should be your current, messy reality. Run a week of extended pings and iperf tests to your Jira and Zoom IPs from your key sites *right now*. Map the loss and jitter. That's your baseline. Then run the same tests through their tunnel during a PoC.

If your baseline is already decent, you're just adding their "latency tax" and hoping their backbone's bad days are fewer than the internet's. That's the gamble.

Your focus on real-time application performance is exactly where the evaluation needs to start. Several points made here about the "latency tax" are valid, but the impact is highly asymmetric based on your team's geography.

If your users are concentrated in regions with good direct internet paths to your SaaS providers, the tunnel overhead is indeed a pure penalty. However, if you have significant teams in locations with historically poor or congested last-mile connectivity, Cato's jitter reduction can transform video call quality. The trade-off is that you're averaging performance, potentially degrading your best-connected users to improve your worst-connected ones.

For a concrete test during your PoC, don't just measure latency to the Cato PoP. You must measure the full path to the actual application endpoints, like Zoom's media servers or the specific AWS region hosting Linear. I've seen scenarios where the Cato egress point was further from the target cloud region than the user's own ISP's egress, adding 20+ ms. That's the data you need.

Yes, the geographic asymmetry is huge. I've seen exactly that in APAC, where a team in Singapore got a worse route to our Tokyo SaaS instance through Cato's backbone than their own ISP provided. That egress point distance is the silent killer.

You're right about needing the full path test. I'd add that you should schedule that test for the same time of day your teams actually work. The peering and backbone load can be completely different at 3pm local versus 3am.

That last point about geography is huge. We rolled out Cato last year for a team split between Europe and North America, and our experience was similar but reversed. Our UK users saw a slight penalty to AWS, but our folks in less-connected areas of Eastern Europe got a much more stable Zoom experience. The trade-off is real.

>in terms of stability and consistent throughput
For us, it's been stable, but as others hinted, it's the consistency of their specific path. You're not getting the "best" path from your ISP, you're getting Cato's path, which is optimized for their network, not necessarily the shortest hop to your Jira instance. If you have a clean, low-latency route already, you might just be paying that tax for no gain.

Definitely run your own PoC tests with synthetic monitoring to key app IPs. We used a simple script and it showed exactly what to expect: a predictable latency add for some sites, and a big jitter improvement for others. The data made the decision clear for our specific pain points.

You're right about the financial lock-in being a separate kind of pain. It's one thing to be technically stuck, but it's another to see the exit costs balloon because every policy and team workflow is tied into their system.

That "relationship with their procurement team" rings so true. It shifts all your future leverage to them once you're fully deployed. Did you find any good ways to structure the PoC to test the ease of policy migration later, or is that something you can't really know until you're already leaving?

Exactly, the on-ramp technical definition is everything. That 3-5ms penalty for a public exchange peer is optimistic if your destination SaaS is experiencing its own regional congestion at that moment. The private interconnect path can hold steady while the public path degrades.

You can't just ask for the BGP AS path. You have to request and validate the *service level* for the interconnect in the contract. A "Direct Connect" could be on a shared 10G port with other tenants, which introduces a different contention variable than a dedicated one.

We've had to specify the exact cloud provider region and service (like us-east-1 S3) in our agreement to get that clarity.

Agreed on using synthetic tests. That's the only way to get real numbers.

Don't just use Pingdom's default nodes, though. They're often in major cloud regions. Spin up your own lightweight test containers in the specific AWS or Azure regions your apps actually use. You'll get a more accurate picture of the tunnel's overhead to your exact destinations.

Also, correlate those test timestamps with Cato's own monitoring graphs if you can during the PoC. Sometimes the variance isn't their tunnel, it's your own local ISP. You need to know which is which.

That's a smart point about the test containers, it gets you real data from the exact place you care about.

But how do you "correlate" your test timestamps with their graphs? Do you need to ask for a specific log file from their support during the PoC, or is there a dashboard you can see live? I'm picturing trying to match up a spreadsheet and it sounds messy.