SD-WAN design and deployment, firewall and edge security, switching and routing architecture, load balancing, site-to-site VPN. Topology diagrams you can read, runbooks you can follow, failover that actually fails over when the primary link drops.
Networking is where "it works most of the time" is the enemy. Our designs prioritize predictability over cleverness: segment properly, document religiously, test failover quarterly, replace equipment before it dies in a thunderstorm.
Multi-site SD-WAN with dual-carrier failover, application-aware routing, and QoS tuned per site. Design starts with your traffic profile and bandwidth per site, not vendor datasheet promises.
Next-gen firewall deployment, rule base design and quarterly review, IDS/IPS tuning, SSL inspection where appropriate. Rules written as code where supported, so changes are tracked and reversible.
LAN design with proper segmentation: VLANs per role, inter-VLAN routing policies, STP tuning that prevents loops instead of hoping for the best. Documented IP schema so the next person can read it.
L4/L7 load balancer deployment with health checks that actually detect application failure (not just port-up). CDN integration for static assets. Session persistence configured for stateful apps that need it.
IPsec site-to-site tunnels for interconnect, WireGuard where latency matters, zero-trust remote access replacing legacy VPN. Modern remote access without the "all or nothing" posture of yesterday's VPN.
SD-WAN overlay, perimeter security, traffic distribution. Not sold as separate line items by separate teams. One architecture, one documentation set, one on-call rotation when something flaps at 3am.
SD-WAN replaces fragile MPLS as default, but we deploy MPLS or dedicated circuits where latency or compliance requires. Application-aware routing, QoS tuned to your traffic profile, and dual-carrier last-mile so a single provider outage does not take down a site.
Platforms we deployRules written as code where the vendor supports it, so changes are tracked, reviewed, and reversible. Quarterly rule-base audit removes orphaned ACLs that accumulate over time. IDS/IPS tuned to your traffic (not vendor defaults) and SSL inspection scoped to what the policy actually requires.
Platforms we deployLoad balancer health checks that detect application failure, not just port-up. Session persistence configured correctly for stateful apps. CDN at the edge for static assets. Zero-trust remote access (Cloudflare Access, Tailscale) replacing legacy all-or-nothing VPN wherever the posture allows.
Platforms we deployMost networking engagements end with a diagram you cannot read, a config nobody has, and a vendor contact who left the firm. Here is how we work differently.
Every deployment ships with a current, versioned topology diagram, VLAN plan, IP schema, and change log. Not Visio screenshots from six months ago, not whiteboard photos. Readable artifacts that match the running config.
When the config drifts from the diagram, we update the diagram, not the other way around.
Dual-carrier SD-WAN failover, HA firewall pairs, redundant uplinks: all of them are only real if they have been tested within the last 90 days. We schedule and run quarterly failover tests with scripted procedures and documented outcomes.
The first time you discover failover is broken should not be during a real outage.
We are not a Fortinet reseller, not a Cisco Partner tier, not a Palo Alto NextWave. No commission shapes what we recommend. If your existing Meraki stack is fine, we leave it alone and operate it. If pfSense fits better than $40k of commercial firewalls, we say so.
The recommendation is driven by your constraints and your team's skills, not our quarterly channel targets.
For most Canadian multi-site deployments, yes, by a wide margin. SD-WAN over two commodity internet links (fibre + cable, or fibre + LTE) typically runs 40-70% below equivalent MPLS pricing with better burst bandwidth. The gap closes if your sites genuinely need carrier-managed QoS for real-time workloads at low latency.
Where MPLS still wins: locations where carriers have monopoly pricing on internet circuits, latency-sensitive workloads with strict jitter budgets, or regulatory requirements that specifically demand private circuits. We assess per site rather than applying one model to everything.
Change windows depend on scope: routine access requests (new SaaS, new user group) get processed weekly in a batched change window with documented justification. Policy-level changes go through a design review before any config touches production.
Separately, we run a quarterly rule-base audit: unused rules get flagged for removal, shadowed rules get consolidated, overly permissive rules get tightened. The rule base shrinks over time with proper hygiene, not grows forever.
Autonomous failover first. Dual-carrier SD-WAN flips to the secondary link within 1-3 seconds depending on vendor. HA firewall pair fails over sub-second. If the architecture is designed properly, nothing wakes anyone up for a single-link failure.
If something does need human attention, the on-call engineer gets paged within 2 minutes of the primary alert, acknowledges within 15 minutes, and the designated incident contact at your organization is notified within 30 minutes with status and ETA. Post-incident report lands within 48 hours.
Separation of layers. Overlay (SD-WAN) is picked for fit per deployment, but the underlying principles (dual-carrier, QoS buckets, routing policy) are vendor-neutral. If we had to migrate off Fortinet to Palo Alto, the architecture translates cleanly because the design is not Fortinet-specific.
Configurations are stored as code in your git repo where the vendor supports it (Fortinet via FortiManager APIs, Palo Alto via Panorama, Cisco via NSO/Ansible). Even non-code configs get exported, versioned, and reviewed quarterly. The config is yours, not held in our tenancy.
Yes, and yes, you probably should start caring. Canadian ISPs are increasingly deploying IPv6 by default, cloud providers charge extra for IPv4, and modern mobile networks (Rogers, Bell, Telus) are IPv6-first with 4-to-6 translation.
Our default new designs are dual-stack IPv4+IPv6 where equipment supports it. For existing IPv4-only networks, we scope IPv6 enablement as a project: typically a few weeks of design + rollout for a mid-sized multi-site org, run alongside existing IPv4 with no cut-over risk.
In most cases, yes, incrementally. Zero-trust remote access (Cloudflare Access, Tailscale, Twingate) is strictly better than legacy VPN for the common case: granular per-app access, device posture checks, no "trusted network" fiction, and users do not have to connect to anything.
We typically run the two side by side during migration: zero-trust for new apps and new users, legacy VPN for the small set of workloads that genuinely require it (noisy UDP protocols, legacy admin tools). Over 6-12 months the legacy VPN footprint shrinks to zero.