About Us

Field notes from real network and security engineering.
Multi-vendor. Bilingual. Written by a working practice — not a content farm.

• 8+ years
• 6 vendor stacks
• EN + ES bilingual

↑ live shell — try help, whois, ping packetloss.tech, or cat readme

What we actually work on

A multi-vendor stack, from network to ops. Each layer is something we deploy, monitor, and maintain — not just a logo we recognize.

1. 01
   network & wireless

   Routing, switching, wireless that holds up.

   • Cisco IOS — DMVPN, EIGRP
   • Ruckus ZoneDirector → vSZ migrations
   • UniFi SMB designs + ICX switching
   • Cisco C9800M HA + multi-AP roaming

   • Cisco IOS
   • Ruckus
   • UniFi
2. 02
   network security

   Firewalls, VPN, identity-aware filtering.

   • FortiGate IKEv2 + IPsec site-to-site
   • SSL VPN deprecation path (FortiOS 7.4+) + SAML to Entra
   • Cisco FTD/FMC, ASA → FTD conversions
   • Umbrella DNS-layer filtering + tunnel debugging

   • FortiGate
   • Cisco FTD/FMC + Umbrella
3. 03
   identity & MDM

   Conditional Access + endpoint, unified.

   • Conditional Access design + LAPS
   • Intune compliance + hybrid identity
   • Domain → Entra migrations (USMT + KFM)
   • Mosyle for Apple — DEP + Entra-aware SSO

   • Entra ID + Intune
   • Mosyle
4. 04
   cloud networking

   Hybrid connectivity that feels like one network.

   • IKEv2 to AWS Site-to-Site + Azure VPN Gateway
   • Transit Gateway + hub-and-spoke designs
   • VPC/VNet peering + route propagation
   • Day-two: SG vs NSG vs firewall rules

   • AWS
   • Azure
   • Google Cloud
5. 05
   monitoring

   Pages on incidents, not noise.

   • Zabbix templates for FortiGate, Cisco, Linux
   • Grafana on InfluxDB or Prometheus
   • ntfy + email alerting
   • Capacity-planning queries that answer the question

   • Zabbix
   • Grafana
6. 06
   ops & AI

   AI as tooling, not autopilot.

   • Incident summarization from raw syslog
   • Change-plan drafts before MOPs
   • Runbook generation + post drafting
   • Operator-in-the-loop always

   • Claude
   • Gemini

How we work

A few principles that show up in every post and every engagement.

• →
  Vendor-neutral by default. If your current stack is the right tool for the problem, we keep it. If it isn't, we say so. No upsells, no platform allegiance, no marketing translations of vendor brochures.
• →
  Specific versions or it didn't happen. "FortiOS 7.6.3" not "recent versions." A command that worked on FortiOS 7.4.4 build 2662 doesn't necessarily work on 7.4.7 build 2860 — that nuance gets called out.
• →
  Rollback plan written down before anything ships. If a change can't be reverted, it isn't a change — it's a one-way door.
• →
  Failure modes published. Engineers Google error messages. The troubleshooting section of a tutorial generates more traffic than the tutorial itself for a reason. The failure modes get written down explicitly.
• →
  AI as tooling, not autopilot. Claude and Gemini are integrated into operational workflows where they earn their place — summarization, drafting, documentation. Operator-in-the-loop always.

Why this site exists

Most network engineering content online sits in one of two buckets — vendor documentation written for legal coverage, and tutorial-farm posts written by someone who has never opened the device. The middle ground (an active practice writing about real production deployments, with version numbers, with the gotcha you only learn at 2 AM) is rarer than it should be.

The other gap: bilingual coverage. There are 500M+ Spanish speakers and almost no dedicated enterprise IT content in Spanish that isn't a Microsoft Learn translation. The Spanish posts here are written natively in neutral pan-LATAM Spanish — same expertise, no machine-translated awkwardness.