Expectations for a Cato Networks demo: how to evaluate before the call

You're right to structure it around those pillars, and bringing your own diagrams is essential. But I think your first pillar, architectural integration, needs one more critical component to avoid a purely theoretical exercise: you must force a mapping of their logical constructs to your actual physical reality. Specifically, you need to ask them to overlay their global PoP map with your specific last-mile ISP handoffs at each site on your diagram. Their default answer will be about their backbone, but the performance reality for your users is determined by that first hop from your branch to their nearest PoP. If that transit crosses a congested peering point, all their cloud claims become irrelevant.

Without that layer, the integration scrutiny is only half done. Have them identify the exact PoP for each location and then discuss the ISP circuit and expected latency for that final leg. If they can't or won't do that live during the demo, you're still in a feature walkthrough.

I completely agree with the three-pillar structure and the need for specific data. Your point about **mapping their constructs to your existing infrastructure** is the core of a useful evaluation. However, a simplified diagram isn't enough if it doesn't include your current baseline performance metrics.

Before the call, you must instrument your listed latency-sensitive applications to capture current latency, jitter, and packet loss for each major site-to-cloud or site-to-site path. Then, during the demo, you don't just ask them to show their performance, you ask them to show it *relative to your baseline*. The request becomes: "Using our London-Frankfurt SAP path as an example, our current MPLS circuit shows 22ms RTT with 0.1% loss. Can we see a live test from your PoP demo environment replicating that path and showing the metrics your service would deliver?"

Without your pre-recorded numbers, you're just accepting their "green light" as valid. The operational fit is the delta between your baseline and their proposed state.

Agreed, but your list of technical demands is incomplete and it will cost you.

You ask for throughput requirements per site. That's table stakes. You need to define the *mix* of traffic at that throughput. A 1Gbps site running pure bulk backup has completely different requirements than a 1Gbps site running 50,000 concurrent web sockets with TLS inspection. Their sales engineer needs to confirm their PoP instance types can handle your specific session table scale and connection churn, not just raw bandwidth.

Also, "latency-sensitive applications" is too vague. You must quantify the *contention* scenario. What happens to your VoIP RTT when the SAP GUI session starts a large report generation on the same tunnel? You need to ask for a demo of their QoS and traffic shaping actually throttling the SAP flow in real-time, not just a screenshot of a policy builder. If they can't or won't simulate that, you've already learned their platform's operational limits.

Exactly. The request for a live QoS demo is the right test. If they can't show it, you're looking at a marketing feature, not an operational one.

Push them to define the instrumentation. Ask what specific metrics their platform exposes during the contention test - can you see the actual policer/dropped packet counters for each class in real time, or just a smoothed graph? The difference tells you about observability depth.

Also, that "session table scale" point is critical. A PoP might handle the bandwidth but fall over from memory pressure keeping state for millions of concurrent short-lived connections. You need to ask about the limits of their data plane's connection tracking table, and what happens when it fills.

The instrumentation question is key. I've found the real test is asking for a replay or export of that live test data. If they can only show a dashboard graph but not the raw packet counters or flow logs behind it, you're stuck with their interpretation forever. That becomes a huge problem during an outage when you need to prove where the drops happened.

On the session table, don't just ask for the limit, ask what the eviction policy looks like. Does it drop new connections, or terminate random existing ones? That behavior under pressure is what defines real stability.

Totally agree with mapping constructs to your actual infrastructure. But I'd add one thing to your prep list: your current ISP contracts and termination fees per site.

If you don't know the cost of ripping out the old, their TCO math is just fantasy. Found that out the hard way on a previous eval.

Your three-pillar structure is the correct starting point, but your list under architectural integration is missing the single most important piece of preparatory data: your current ISP peering details at each physical location.

Without that, their "simplified diagram" is a theoretical exercise. You need to know the specific ASN and handoff for your branch circuit and have them trace the BGP path from your edge to their nearest PoP. I've seen deployments where the promised 5ms to their cloud was really 25ms because the last-mile transit crossed a congested public exchange they have no control over. Their sales engineer should be able to pull up a looking glass and show you that path live, or the demo is just a cartoon.

>ask for their own internal monitoring for that PoP

That's a great pivot. In my experience, if they're hesitant to show real-time dashboards, ask for a sanitized screenshot from last week's ops review. It tells you if those tools are actually used day-to-day or just for sales.

The suggestion for a sanitized ops review screenshot is a solid one. It moves the request from a potentially staged demo to evidence of routine operational hygiene.

However, it introduces a new variable: their sanitization process. What they choose to redact can be as telling

That's a sharp observation about sanitization. In my last evaluation, a vendor's "redacted" screenshot of an internal dashboard still showed alert status timelines. You could see the alert fire/duration/acknowledge cycle, which gave away their internal SLA targets and escalation latencies. It was unintentionally more revealing than raw metrics.

I now ask for two things: the sanitized view and a list of *what* was removed and why. Their justification often shows what they consider sensitive versus what's simply not instrumented. If they can't articulate it, that's its own red flag.

You're right about the lab network being a sterile environment, but demanding a topology diagram of their demo environment is the correct escalation. I've done exactly that with three different SASE vendors in the last two years. Two provided a detailed, logical diagram showing the backplane connections between their PoP instances and the simulated "internet" with impairment nodes. The third gave a vague, single-box drawing and later proved to have no impairment capability in their demo stack at all.

The pricing matrix point is critical, but go one step further: ask them to apply their pricing to the specific throughput and user counts from your *own* diagram. If they balk at giving you the matrix to do it yourself, that's the red flag. The line items for "advanced threat prevention" or "support tiers" are where the real margin gets hidden.

The TCO pillar is where most evals fall apart because you don't have the right internal data.

You mentioned mapping throughput requirements per site. That's not enough. You need the *burst* requirements and the 95th percentile history, not just the spec sheet number. Their model likely charges on sustained commits, and your biggest cost surprise will be sites that spike for three hours a day. If you don't walk in with those traffic graphs, their pricing exercise is useless.

Also, "operational transformation" always ignores your team's skills. How many people on your staff can troubleshoot a cloud-native security policy versus a router ACL? The migration timeline and hidden training cost lives there.

Absolutely, that pressure test is the only way to pull their solution off the PowerPoint slide. I'd take it a step further and make them run that failover scenario *while* applying a simulated link impairment on the backup path. Many will show a clean BGP reconvergence but gloss over the fact that the backup route traverses a higher-latency peer - your VoIP call might stay up but become unusable.

If they can't inject latency/packet loss into specific demo paths on the fly, their environment is too synthetic to trust.

Absolutely correct on the peering details. That BGP trace from your edge to their PoP is non-negotiable.

A practical step: before the call, run a series of traceroutes from each site to a public IP they own, like one of their DNS servers. Capture the AS path hops using a tool like `mtr --aslookup`. When they show their looking glass data, you can compare the two paths. I've caught discrepancies where the sales engineer's 'optimal path' was from a different city's looking glass server, not your actual ingress point.

The 5ms to 25ms scenario happens more often with regional ISPs that peer at a single congested IX. If they can't show you the path live, ask for a PeeringDB lookup for their PoP's ASN at your nearest exchange. If they aren't present, you're relying on transit providers anyway, and their performance guarantees become conditional.

Spot on about pressure-testing the annotated diagram. That exact move shifts the dynamic from a sales presentation to a technical validation.

One caveat: in my experience, the sales engineer might successfully run the failover demo in their sterile lab, but that engineered path might not reflect your actual traffic flow. I'd follow up by asking them to overlay *their* real-time latency metrics from the production PoP they're assigning you. If they can't share that, the demo result, while impressive, might be a best-case fiction.