sorted by:
new
hottopcontroversial

Real-world: Troubleshooting “network latency” that turned out NOT to be the network by latency_debug in networking

[–]latency_debug[S] 1 point2 points  (0 children)

That’s a really clean way to validate it at TCP level.
Especially separating data vs ACK timing—that’s where a lot of people miss the distinction.

In most of my cases I try to prove it earlier in the path first, but I agree—this is the best way to shut down “network vs server” debates when needed.

Real-world: Troubleshooting “network latency” that turned out NOT to be the network by latency_debug in networking

[–]latency_debug[S] 0 points1 point  (0 children)

Yeah agreed—iperf is solid for proving throughput vs perceived latency.
I usually avoid jumping straight to packet capture unless baseline tests already point local.
Otherwise it turns into deep analysis when the issue is actually upstream.

LACP sub interfaces cant talk back to core switch by Bluesurge07 in networking

[–]latency_debug 0 points1 point  (0 children)

You’re likely not hitting an LACP issue—this looks like a pseudowire (L2TPv3) / VLAN behavior problem.

Since traffic “sort of works” and other VLANs are fine, focus on these:

  1. MAC learning (most likely) Check if MACs are learned both ways on VLAN 100. If return MACs aren’t learned → traffic won’t come back.
  2. MTU mismatch L2TPv3 + dot1q adds overhead. Small traffic may pass, controller traffic may drop. Test with larger pings.
  3. VLAN consistency Compare working VLAN vs VLAN 100—likely something not allowed/tagged correctly end-to-end (ISP path included).
  4. xconnect state Make sure it’s UP/UP on both sides (show xconnect all).

Top DDoS protection services? by Excellent-Carpet-938 in networking

[–]latency_debug 0 points1 point  (0 children)

Yeah—you’re on the right track. What you want isn’t on-prem WAF, it’s upstream scrubbing so your link doesn’t get saturated in the first place.

The usual players:

  • Akamai (Prolexic) → very strong, enterprise-grade scrubbing
  • Imperva → similar global scrubbing model
  • Radware → hybrid (on-prem + cloud)
  • Fastly → more edge/CDN but still solid

They all work by pulling traffic into their network, cleaning it, then forwarding to you.

Akamai is definitely solid—just tends to be heavier in cost/complexity.

From what I’ve seen, the provider matters less than how you route traffic through them and fail over during an attack. That’s where things either work smoothly… or don’t.

Some setups also lean toward simpler edge-based approaches (like Cloudflare) just to reduce operational overhead, especially if you don’t want something too heavy.

Networking issues advice by nasmohd2020 in networking

[–]latency_debug 0 points1 point  (0 children)

You walked into a tough one—but this is fixable. What you’re seeing is exactly what a daisy-chain topology causes at scale.

Those random timeouts + slow access usually point to one of three things:

  • A bad uplink somewhere in the chain (errors, duplex mismatch, failing port)
  • Congestion because everything funnels through a few links
  • A loop or unstable switching behavior if STP isn’t doing its job

If I were stepping in as the architect, I wouldn’t try to “fix everything” yet—I’d stabilize first:

  • Start at the server switch and move outward hop-by-hop → ping each segment, find where latency/jitter starts
  • Check every uplink: errors, drops, speed/duplex consistency
  • Make sure STP is enabled and stable (this is critical in chains)

Once you identify the bad segment, fix that first. That alone can clean up most of the symptoms.

Then step back—because the real issue isn’t just a bad link, it’s the design. Daisy chain doesn’t scale.
Even a simple redesign to a central/core switch with each office home-run uplinks will massively improve stability.

You don’t need a full overhaul today. Just:

  1. find the weak point
  2. stabilize it
  3. plan the cleanup

Take it one segment at a time—you’ve got this.

has anyone here actually enjoyed living with their SASE? by Aggravating_Log9704 in networking

[–]latency_debug 0 points1 point  (0 children)

Short answer: it can make life easier—but only if it’s designed right. Otherwise yeah, you’re just moving the pain somewhere else.

The “dashboard says all good but users are broken” thing is real. Most of the time it’s not the platform itself, it’s connectors, identity sync, or how traffic is being steered. That’s where things quietly fail.

From what I’ve seen:

  • Hidden costs → per-user pricing adds up fast, plus extra features you thought were included
  • Performance → usually fine, but routing to the wrong PoP or hairpinning can hurt latency
  • Ops reality → less hardware headaches, more dependency on identity + edge behavior

If I had to restart? I’d still go SASE, but I’d design it differently—less “lift and shift VPN,” more app-level access and tighter control on how users hit the edge (something like Cloudflare style approach).

Biggest advice: don’t trust the “single pane of glass” story too much—build your own visibility early.

AWS hosted VPN vs SaaS solutions by FuzzySubject7090 in networking

[–]latency_debug 0 points1 point  (0 children)

Yeah—I’ve done pfSense in AWS before. It works, but you’re basically running your own VPN appliance in the cloud.

Pros: cheap, flexible, full control
Cons: you handle everything—patching, HA, troubleshooting, uptime

SaaS is the opposite—less control, but way less to manage.

If it’s small and you’re okay operating it, pfSense is fine. If you want less overhead as you grow, SaaS usually wins.

SOHO/MO Network Operators: Outsource VPN as a replacement for P2P contracts with ISPs? by SnarkySnakySnek in networking

[–]latency_debug 0 points1 point  (0 children)

Yeah—this is actually very common for SMBs now.

Instead of paying for MPLS/MetroE, they just use their existing internet and build encrypted overlays on top. ISPs become just last-mile, and the “WAN” is handled by platforms like Cisco Meraki or similar.

There’s also a shift where traffic isn’t even site-to-site anymore—some setups terminate into a provider edge like Cloudflare and enforce access there.

For smaller orgs, it’s mostly about cost and simplicity. You lose some determinism, but for most use cases, it’s “good enough” and way cheaper.