Forem: FirstPassLab

Cisco ASA vs FTD in 2026: NAT, VPNs, Policy Workflows, and Which to Learn First

FirstPassLab — Wed, 08 Apr 2026 16:54:26 +0000

If you work on Cisco firewalls in 2026, you usually inherit both worlds at once: legacy or brownfield ASA deployments, and newer FMC-managed FTD estates that add IPS, application visibility, and centralized policy.

That creates a very practical engineering question: what actually changes when you move from ASA CLI muscle memory to FTD workflows, and which platform should you learn first if you need to operate both?

This breakdown focuses on the parts that matter in real environments and labs: deployment modes, NAT behavior, failover, VPN workflows, policy construction, and the operational mistakes that waste the most time.

Quick takeaways

Start with ASA fundamentals. NAT, ACL logic, VPN behavior, and failover concepts transfer directly.
Spend more operating time on FTD/FMC. That is where Cisco’s newer policy and inspection workflows live.
The biggest FTD mistake is procedural, not conceptual: forgetting to deploy from FMC.
Mixed environments are normal. Knowing how ASA troubleshooting maps to FTD is often more valuable than treating them as separate products.

The v6.1 Blueprint Reality

Let's start with what Cisco actually tells us. The CCIE Security v6.1 exam topics list both platforms explicitly:

Section 2.0 — Perimeter Security and Intrusion Prevention (22%) covers ASA and FTD deployment, NAT, VPN, and high availability
Section 3.0 — Secure Connectivity and Segmentation (19%) includes site-to-site and remote access VPN on both platforms
Section 5.0 — Advanced Threat Protection and Content Security (12%) is heavily FTD/FMC territory

That's roughly 53% of the lab where ASA and/or FTD knowledge is directly tested. But here's what the blueprint doesn't tell you: the balance between them has shifted dramatically from v6.0.

The Shift Toward FTD

In v6.0, ASA carried roughly equal weight to FTD. In v6.1, candidates consistently report that FTD tasks outnumber ASA tasks by approximately 2:1. FMC-managed FTD is the primary firewall platform in most lab scenarios.

This doesn't mean ASA is irrelevant — far from it. But it means your study time allocation should reflect reality:

Platform	Recommended Study Time	Why
FTD (FMC-managed)	55-60% of firewall study time	Primary platform in v6.1 lab
ASA	30-35% of firewall study time	Still tested, especially VPN and failover
FTD (FDM-managed)	5-10% of firewall study time	Appears in limited scenarios

ASA: What You Need to Know Cold

ASA isn't going away from the exam. Cisco knows that thousands of production networks still run ASA, and the platform tests fundamental security concepts that every expert should understand.

Deployment Modes

You'll encounter ASA in two modes on the lab:

Routed Mode — the default and most common:

ciscoasa(config)# firewall transparent
ciscoasa(config)# no firewall transparent
ciscoasa(config)# show firewall
Firewall mode: Router

Transparent Mode — Layer 2 firewall, appears as a bump in the wire:

ciscoasa(config)# firewall transparent
ciscoasa(config)# show firewall
Firewall mode: Transparent

In transparent mode, you lose the routing capabilities but gain the ability to insert the ASA inline without readdressing. The lab loves testing whether you know when to use each mode and the behavioral differences.

Key transparent mode gotcha that catches candidates: you need a management IP on a BVI, and ARP inspection is enabled by default:

ciscoasa(config)# interface BVI 1
ciscoasa(config-if)# ip address 10.1.1.1 255.255.255.0
ciscoasa(config-if)# no shutdown

NAT on ASA: The Foundation

ASA NAT is where your fundamentals get tested hard. The exam expects you to configure NAT without hesitation — and to troubleshoot when it breaks.

Twice NAT (Manual NAT) — full control, processed in order:

! Static NAT for a web server
ciscoasa(config)# object network WEB-SERVER-REAL
ciscoasa(config-network-object)# host 10.1.1.100

ciscoasa(config)# object network WEB-SERVER-MAPPED
ciscoasa(config-network-object)# host 203.0.113.100

ciscoasa(config)# nat (inside,outside) source static WEB-SERVER-REAL WEB-SERVER-MAPPED

Auto NAT (Object NAT) — simpler, defined inside the object:

ciscoasa(config)# object network INSIDE-SUBNET
ciscoasa(config-network-object)# subnet 10.1.1.0 255.255.255.0
ciscoasa(config-network-object)# nat (inside,outside) dynamic interface

The critical distinction: Twice NAT is processed before Auto NAT (within each section — before/after auto). If your NAT isn't working, check the processing order first:

Twice NAT (Section 1) — manual, before auto
Auto NAT — ordered by prefix length (most specific first)
Twice NAT (Section 3) — manual, after auto

ciscoasa# show nat
Manual NAT Policies (Section 1)
1 (inside) to (outside) source static WEB-SERVER-REAL WEB-SERVER-MAPPED
    translate_hits = 1523, untranslate_hits = 892

Auto NAT Policies (Section 2)
1 (inside) to (outside) source dynamic INSIDE-SUBNET interface
    translate_hits = 45210, untranslate_hits = 0

ASA Failover

ASA Active/Standby failover is a guaranteed lab topic. The configuration is straightforward but the troubleshooting can be tricky:

! Primary ASA
ciscoasa(config)# failover
ciscoasa(config)# failover lan unit primary
ciscoasa(config)# failover lan interface FAILOVER GigabitEthernet0/3
ciscoasa(config)# failover polltime unit 1 holdtime 5
ciscoasa(config)# failover key cisco123
ciscoasa(config)# failover link STATE GigabitEthernet0/4
ciscoasa(config)# failover interface ip FAILOVER 10.0.0.1 255.255.255.252 standby 10.0.0.2
ciscoasa(config)# failover interface ip STATE 10.0.0.5 255.255.255.252 standby 10.0.0.6

! Secondary ASA
ciscoasa(config)# failover
ciscoasa(config)# failover lan unit secondary
ciscoasa(config)# failover lan interface FAILOVER GigabitEthernet0/3
ciscoasa(config)# failover key cisco123
ciscoasa(config)# failover link STATE GigabitEthernet0/4
ciscoasa(config)# failover interface ip FAILOVER 10.0.0.1 255.255.255.252 standby 10.0.0.2
ciscoasa(config)# failover interface ip STATE 10.0.0.5 255.255.255.252 standby 10.0.0.6

The number one failover debugging command:

ciscoasa# show failover state
               State          Last Failure Reason
This host  -   Primary
               Active         None
Other host -   Secondary
               Standby Ready  None

If you see "Standby Cold" or "Failed," check the failover link first — 90% of the time it's a Layer 1/2 issue on the failover interface.

FTD: The New Reality

FTD (Firepower Threat Defense) is Cisco's converged NGFW platform. It combines the ASA firewall engine with Snort IPS, URL filtering, malware detection, and AMP into a single image. For the CCIE Security lab, you'll primarily manage FTD through FMC (Firepower Management Center).

FMC vs FDM: Know the Difference

FMC (Firepower Management Center) — centralized management for multiple FTD devices. This is what the lab uses 90% of the time.

FDM (Firepower Device Manager) — on-box management for standalone FTD. Limited features, simpler GUI.

The lab expects FMC proficiency. You need to navigate it fast — because FMC's GUI has latency, and every click costs you time.

FTD Deployment Modes

FTD supports the same two fundamental modes, but the terminology and configuration differ:

Routed Mode — default, most common in the lab:

FTD acts as a Layer 3 hop
Full routing capabilities (OSPF, BGP, EIGRP, static)
NAT and PAT processing

Transparent Mode — Layer 2 inline:

Configured during initial setup or via FMC
Bridge groups replace traditional interfaces
Same BVI concept as ASA but configured through FMC GUI

Inline Set — unique to FTD, not available on ASA:

FTD sits inline between two interfaces
Traffic passes through without FTD being a routed hop
Primarily for IPS/IDS inspection without network topology changes
The lab sometimes tests this for specific IPS scenarios

NAT on FTD: The FMC Way

Here's where candidates get burned. FTD NAT is conceptually identical to ASA NAT — same Twice NAT vs Auto NAT logic — but it's configured through FMC's GUI, and the terminology is slightly different.

Auto NAT in FMC:

Devices → NAT → select the FTD device
Add Rule → Auto NAT Rule
Select the network object and define the translation

Manual NAT (Twice NAT) in FMC:

Devices → NAT → select the FTD device
Add Rule → Manual NAT Rule
Define source original, source translated, destination original, destination translated

The processing order is identical to ASA:

Manual NAT (Section 1)
Auto NAT (Section 2)
Manual NAT (Section 3 — after auto)

Critical FMC workflow you must internalize: After configuring NAT (or any policy), you must deploy to the FTD device. Forgetting to click Deploy is the #1 time-waster I've seen candidates report.

FTD Access Control Policies

This is the core of FTD management and where the NGFW capabilities shine:

Access Control Policy (ACP) — the main traffic policy:

Ordered rules evaluated top-down
Each rule can specify: zones, networks, ports, applications, URLs, users
Actions: Allow, Trust, Block, Monitor, Interactive Block

Prefilter Policy — evaluated BEFORE the ACP:

Uses traditional 5-tuple matching (like ASA ACLs)
Much faster because it bypasses Snort inspection
Use for trusted traffic that doesn't need deep inspection

Lab tip: Use Prefilter rules for high-volume trusted traffic (like management traffic or backup streams). This reduces Snort load and can prevent performance issues during the lab that cause timeout failures on verification.

FTD VPN Configuration

VPN on FTD through FMC is one of the most time-consuming lab tasks because of the multi-step GUI workflow:

Site-to-Site VPN:

Devices → VPN → Site to Site → Add VPN
Define topology (Point to Point or Hub and Spoke)
Configure IKE settings (IKEv1 or IKEv2)
Configure IPsec proposals
Define protected networks
Deploy

Remote Access VPN (RAVPN):

Devices → VPN → Remote Access → Add
Select authentication method (AAA, certificates, both)
Configure connection profiles
Define group policies
Configure address pools
Deploy

The deploy step after each change is what kills your time. Batch your VPN changes — configure everything, verify in the GUI, then deploy once.

Head-to-Head: ASA vs FTD for Key Lab Tasks

Task	ASA	FTD (via FMC)	Time Impact
Basic NAT	CLI, fast	GUI, slower	ASA wins by 5-10 min
Site-to-Site VPN	CLI, well-documented	GUI, multi-step wizard	ASA wins by 10-15 min
IPS/IDS	Limited (legacy)	Full Snort integration	FTD only
URL Filtering	Not available	Built-in category-based	FTD only
Malware/AMP	Not available	Built-in	FTD only
Failover/HA	CLI, straightforward	GUI + deploy cycle	ASA wins by 5 min
Troubleshooting	Rich CLI (`show`, `debug`, `capture`)	CLI available but limited compared to ASA + FMC events	ASA wins
Application Visibility	Not available	Full app detection	FTD only

The pattern is clear: ASA is faster to configure, FTD is more capable. The lab tests both — ASA for speed and fundamentals, FTD for advanced NGFW features.

The Study Order That Works

Based on the v6.1 blueprint weight and platform dependencies, here's the order I recommend:

Phase 1: ASA Fundamentals (Weeks 1-3)

Start with ASA even though FTD carries more lab weight. Why? Because FTD's firewall engine IS the ASA engine. Understanding ASA NAT, ACLs, and VPN from the CLI gives you the conceptual foundation that makes FMC configuration intuitive instead of magical.

Week 1: Deployment modes, interfaces, security levels, basic ACLs
Week 2: NAT (Auto NAT, Twice NAT, NAT order of operations, identity NAT)
Week 3: Failover (Active/Standby, Active/Active), VPN (site-to-site IKEv1/v2)

Phase 2: FTD/FMC Core (Weeks 4-7)

Now transition to FTD. Your ASA knowledge translates directly.

Week 4: FMC navigation, device registration, platform settings, interface configuration
Week 5: Access Control Policies, Prefilter policies, Security Intelligence
Week 6: NAT on FTD (map your ASA NAT knowledge to the FMC GUI), FTD HA
Week 7: VPN on FTD (site-to-site, RAVPN), certificate management

Phase 3: Advanced FTD Features (Weeks 8-10)

The NGFW capabilities that only exist on FTD:

Week 8: Snort IPS policies, custom rules, variable sets
Week 9: Malware/AMP policies, file policies, URL filtering
Week 10: FTD integration with ISE (pxGrid), identity-based access control — our CCIE Security v6.1 ISE lab prep guide covers the ISE side in detail

Phase 4: Speed Labs (Weeks 11-12)

Timed practice combining both platforms:

Configure ASA failover pair + FTD/FMC pair in the same topology
Build VPN between ASA and FTD (interoperability scenario)
Troubleshoot broken configs on both platforms under time pressure
Practice the FMC deploy workflow until it's muscle memory

The FMC Speed Problem (and How to Beat It)

Every candidate complains about FMC being slow. The GUI has inherent latency — page loads, deploy cycles, and the occasional "please wait" spinner that eats 30 seconds of your life.

Here's how to minimize the damage:

1. Pre-Build Your Object Library

Before touching any policies, create all your network objects, port objects, and interface groups first. When you start building ACPs and NAT rules, you'll select from existing objects instead of creating them inline (which triggers additional page loads).

2. Batch Your Deploys

Never deploy after a single change. Configure all related changes (NAT + ACP + VPN for a given requirement), verify in the GUI, then deploy once. Each deploy cycle takes 30-90 seconds depending on the change scope.

3. Use the FMC CLI When Possible

FMC has a diagnostic CLI. For troubleshooting, SSH into the FTD device and use:

> system support diagnostic-cli
ciscoasa# show nat
ciscoasa# show xlate
ciscoasa# show conn
ciscoasa# show access-list

Yes, that's the ASA CLI running underneath FTD. Your ASA troubleshooting skills transfer directly.

4. Know Your Keyboard Shortcuts

FMC doesn't have many, but the browser does:

Ctrl+F to search within long policy lists
Tab to move between fields quickly
Enter to submit dialogs instead of clicking Save

These seem trivial. They save 10-15 minutes over an 8-hour lab.

Common Pitfalls on Exam Day

Pitfall 1: Forgetting to Deploy

I cannot stress this enough. You configure a perfect NAT rule in FMC, move to the next task, and wonder why traffic isn't flowing. The rule exists in FMC's pending changes — it's not on the FTD device yet. Deploy after every logical block of changes.

Pitfall 2: NAT Order Confusion

You built the same NAT logic on ASA and FTD, but one works and the other doesn't. Check the rule ordering. FMC's NAT rule table doesn't always display in processing order by default — make sure you're looking at the actual Section 1/2/3 placement.

Pitfall 3: Security Zone Mismatch

FTD uses Security Zones instead of ASA's security levels. A common error: you create an ACP rule allowing traffic from "inside-zone" to "outside-zone," but the FTD interfaces aren't assigned to those zones. Always verify zone assignments under Devices → Device Management → Interfaces.

Pitfall 4: IKEv1 vs IKEv2 Platform Defaults

ASA defaults to IKEv1 for site-to-site VPN. FTD defaults to IKEv2. If you're building a VPN between them and don't explicitly match versions, the tunnel won't come up — and the error messages won't clearly tell you why.

Pitfall 5: ASA Syslog vs FTD Events

When troubleshooting ASA, you rely on syslogs (show logging). On FTD, you use FMC's Analysis → Connection Events. Different tools, same troubleshooting logic — but knowing which tool to reach for on each platform saves critical minutes.

Resource Stack for ASA vs FTD Prep

Here's what actually works, based on candidate feedback:

Resource	Best For	Notes
Cisco CCIE Security Official Cert Guide	ASA fundamentals, exam topic mapping	Solid foundation, but light on FTD/FMC
INE CCIE Security v6.1	FTD/FMC lab walkthroughs	Best video content for FMC workflows (see our INE vs CBT Nuggets comparison)
Cisco dCloud	Free lab environments	ASA and FTD labs available, registration required
Orhan Ergun's Security material	Blueprint-aligned study plans	Good structure, complements hands-on practice
Cisco FTD Configuration Guide (official docs)	FMC step-by-step procedures	Keep this bookmarked — it's your exam-day reference mental model

The Bottom Line

For CCIE Security v6.1:

Learn ASA first — it's the conceptual foundation and the faster platform for basic tasks
Spend more time on FTD — it carries more weight in the v6.1 lab
Master the FMC workflow — deploy cycles, object management, and ACP construction
Practice interop scenarios — ASA-to-FTD VPN tunnels, mixed environments
Build speed on FMC — pre-built objects, batched deploys, diagnostic CLI

The candidates who struggle aren't the ones who don't know the technology. They're the ones who can't execute fast enough in FMC. Time management on FTD tasks is the single biggest differentiator between passing and failing. If you're mapping out your full Security track timeline, see our CCNP to CCIE Security realistic study plan.

Frequently Asked Questions

Should I learn ASA or FTD first for CCIE Security v6.1?

Start with ASA. FTD's firewall engine is built on ASA, so understanding ASA NAT, ACLs, and VPN from the CLI gives you the conceptual foundation that makes FMC configuration intuitive. Then shift 55-60% of your firewall study time to FTD.

How much of the CCIE Security v6.1 lab is FTD vs ASA?

Candidates consistently report FTD tasks outnumber ASA tasks by approximately 2:1 in v6.1. About 53% of the total lab directly tests ASA and/or FTD knowledge, with FMC-managed FTD as the primary firewall platform.

What is the biggest time waster in the CCIE Security lab?

Forgetting to deploy changes in FMC. Every configuration change in FMC sits in pending state until you explicitly deploy it to the FTD device. Batch your changes and deploy after each logical block to save time.

Can I use CLI on FTD during the CCIE Security lab?

Yes. FTD has a diagnostic CLI accessible via SSH that runs the ASA engine underneath. Commands like show nat, show xlate, and show conn work directly, so your ASA troubleshooting skills transfer to FTD.

How long should I study for the CCIE Security v6.1 firewall sections?

Plan for 12 weeks focused on firewalls: 3 weeks on ASA fundamentals, 4 weeks on FTD/FMC core, 3 weeks on advanced FTD features like Snort IPS and ISE integration, then 2 weeks of timed speed labs combining both platforms.

AI disclosure: This article was adapted with AI assistance from the original FirstPassLab post, then reviewed and prepared for Dev.to publication.

NAC Is Moving Into the Fabric: What Nile’s Segment-of-1 Means for Campus Security

FirstPassLab — Tue, 07 Apr 2026 22:55:45 +0000

NAC Is Moving Into the Fabric: What Nile’s Segment-of-1 Means for Campus Security

Most campus access control stacks still look like this: a NAC appliance cluster, RADIUS plumbing, VLAN sprawl, ACL overlays, and a long tail of exceptions for IoT devices that do not behave like laptops.

Nile’s latest platform update is interesting because it challenges that whole model. Instead of treating NAC as a separate control plane bolted onto the network, it pushes identity, access control, and microsegmentation directly into the fabric.

If you design or operate enterprise networks, the useful question is not “should I buy this vendor tomorrow?” It is this: is campus NAC starting to move from appliance-centric to fabric-native?

What Nile actually changed

Nile added three things that matter to engineers:

Native NAC inside the fabric instead of a separate appliance stack
Segment-of-1 microsegmentation, where each endpoint becomes its own security boundary
More cloud-delivered services around branch and campus operations

That first point is the real shift. Traditional campus NAC usually means dedicated infrastructure, certificate handling, RADIUS tuning, policy troubleshooting, and a lot of operational drag. Nile is trying to collapse that into the access fabric itself.

Why this is technically important

Fabric-native NAC still has to solve the same old problems. It just solves them in a different place.

According to the underlying product details, the policy layer is built around:

Active Directory integration for identity and group context
RADIUS certificate authentication for managed corporate devices
802.1X and captive portal flows for wired and guest-style access
Device fingerprinting for IoT gear that cannot run normal supplicants

That means the core engineering concepts do not go away. You still need to understand 802.1X, RADIUS attributes, certificate chains, identity mapping, and policy enforcement. What changes is who operates the infrastructure and how much of the stack becomes opaque.

Segment-of-1 vs traditional campus segmentation

The most interesting part of the announcement is not NAC. It is the segmentation model.

With a classic campus design, segmentation often starts with VLAN boundaries and then gets refined with ACLs or policy overlays. That works, but it is operationally noisy and usually leaves too much lateral movement inside each segment.

Nile’s “Segment-of-1” model pushes the opposite idea: deny by default, then allow only explicit policy for each endpoint.

Approach	Granularity	Lateral movement risk	Operational model
VLAN-based segmentation	Groups of endpoints	High	VLAN and ACL administration
Identity group segmentation	Per user or device group	Moderate	Policy-driven but still grouped
Segment-of-1	Individual endpoint	Lowest	Per-device policy in the fabric

In practical terms, that means a compromised camera, scanner, badge reader, or kiosk should not be able to discover or talk to peer devices unless policy explicitly permits it.

That is a pretty meaningful change for campus security teams who have spent years trying to retrofit zero trust principles onto VLAN-era access designs.

Where this is stronger than a traditional NAC deployment

A fabric-native model can be genuinely better in a few areas:

Less infrastructure to run. No separate NAC appliance lifecycle, fewer moving parts, less cluster care-and-feeding.
Better blast-radius control. Per-device isolation is a stronger default than broad VLAN trust zones.
Cleaner handling for IoT-heavy environments. Device fingerprinting plus identity policy is often more realistic than trying to force full supplicant behavior onto every endpoint.
A simpler operations story for distributed campus environments.

For teams buried in DHCP dependencies, RADIUS troubleshooting, and access policy sprawl, that is a compelling operational pitch.

Where the model is weaker

This is not a free win.

The tradeoff is that you may lose some of the integration depth that made traditional NAC platforms valuable in the first place. If your environment depends on posture assessment, deep ecosystem integrations, or very custom onboarding flows, a fabric-native model may not be a drop-in replacement.

Here is the real comparison engineers should make:

Capability	Traditional NAC platform	Fabric-native NAC model
Deployment	Separate appliances or VMs	Embedded in the access fabric
Authentication methods	Mature and broad	Usually focused on core access flows
Segmentation	Often layered on VLANs and policy overlays	Identity-based, fabric-enforced
Ecosystem integrations	Usually deeper	Often narrower
Operational overhead	Higher	Lower
Platform transparency	Higher for engineers who own it	Lower, more vendor-managed

So the decision is not “old bad, new good.” It is more like integration depth vs operational simplicity.

What network engineers should evaluate now

Even if you never deploy Nile, this announcement is still useful because it shows where the market is heading.

If I were evaluating this model, I would look at five things first:

How much operational cost is your current NAC stack creating?

Count the nodes, policy objects, cert dependencies, and exception workflows.
How much of your current segmentation still depends on coarse VLAN trust?

If the answer is “most of it,” per-endpoint policy is worth serious attention.
How much of your estate is unmanaged IoT?

This is where fabric-native identity and fingerprinting can have outsized value.
What advanced NAC features do you actually use today?

A lot of teams run complex platforms but consume only a small slice of the feature set.
Are your engineers strong on the underlying protocols?

That matters more, not less, in a vendor-managed world.

The bigger takeaway

The big signal here is not one vendor feature release. It is the architecture trend.

Campus security is slowly moving away from “connect first, secure later” and toward identity-first, deny-by-default, fabric-enforced access. If that trend continues, the valuable engineering skill set will be less about babysitting NAC appliances and more about understanding authentication, identity, segmentation, and policy intent at a deep level.

That is a healthy shift.

And honestly, it is overdue.

Canonical version: Nile NaaS Adds Native NAC and Microsegmentation: What It Means for Campus Network Engineers

AI disclosure: This article was adapted with AI assistance from an original FirstPassLab post for Dev.to. The canonical source, analysis direction, and technical framing come from the original article.

CML vs GNS3 vs INE: How Network Engineers Should Build Labs in 2026

FirstPassLab — Tue, 07 Apr 2026 18:16:44 +0000

If you're building network labs in 2026, the real question is not "which tool is best?" It's which tool matches the kind of lab work you actually need to do.

Some engineers want a legal, repeatable Cisco-heavy environment for deep protocol work. Some want guided labs they can launch in a minute. Others just want the cheapest path to testing routing, switching, VPN, and firewall ideas at home.

The three tools that come up most often are Cisco Modeling Labs (CML), INE's cloud labs, and GNS3. They overlap, but they are not interchangeable.

My short take:

CML is the best foundation for serious Cisco-centric lab work
INE is best when you want structured, ready-to-run scenarios
GNS3 is still excellent when budget and flexibility matter most

Quick Comparison

Feature	CML	INE	GNS3
Cost	~$200/year	~$20 to $50/month	Free
Official Cisco images	Yes, included	Yes, in provider labs	No
Local lab control	Yes	No, cloud only	Yes
Custom topologies	Excellent	Limited compared to local builds	Excellent
Modern Cisco platform support	Strong	Strong in prebuilt labs	Mixed, depends on images and host resources
Best for	Cisco-focused engineers, repeatable deep labs	Structured practice	Budget builds, mixed-vendor labs, experimentation

1. CML is the strongest base for Cisco-heavy labs

CML wins when you want a lab that feels like an engineering sandbox, not just a training portal.

The biggest advantage is simple: you get legitimate Cisco images out of the box. That removes the messiest part of home labbing, especially if you want to work with IOS-XE, IOS-XR, NX-OS, or ASAv without hunting around for images and licenses.

That matters a lot if your lab goals include:

routing protocol behavior
BGP policy testing
MPLS or segment routing experiments
EVPN and VXLAN topologies
firewall and services integration
repeatable topology snapshots

CML is also one of the few options that makes it realistic to build larger topologies and keep iterating on them. You can save a base design, clone it, break it on purpose, and rebuild quickly.

Why engineers like it

Legal Cisco image access
Good support for modern Cisco virtual platforms
API access for automation and repeatable topology deployment
Better fit for protocol deep dives than point-and-click training labs

Where it hurts

It wants real hardware, especially RAM
Apple Silicon support is still awkward because x86 emulation costs performance
It is a blank canvas, which is great for engineers but less friendly for beginners

Here's the kind of simple config loop CML is great for when you're testing and retesting behavior:

! R1
router ospf 1
 router-id 1.1.1.1
 network 10.0.12.0 0.0.0.255 area 0
 network 1.1.1.1 0.0.0.0 area 0
!
interface GigabitEthernet2
 ip address 10.0.12.1 255.255.255.0
 ip ospf network point-to-point
 no shutdown

! R2
router ospf 1
 router-id 2.2.2.2
 network 10.0.12.0 0.0.0.255 area 0
 network 2.2.2.2 0.0.0.0 area 0
!
interface GigabitEthernet2
 ip address 10.0.12.2 255.255.255.0
 ip ospf network point-to-point
 no shutdown

That looks trivial, but once you scale it into 12 to 20 nodes and start layering redistribution, overlays, services, and failure testing, the choice of platform starts to matter a lot.

2. INE is best when you want fast, structured reps

INE solves a different problem.

Its biggest strength is not topology freedom. It's friction reduction. If you want a lab launched for you, with a workbook or a guided task waiting, INE is much faster than building everything yourself.

That makes it useful when you want:

guided labs instead of blank topologies
repeatable drills with less setup overhead
cloud access from a lighter laptop
a structured path through topics

For a lot of engineers, that structure is worth paying for. It removes the "I spent 45 minutes wiring a lab and 20 minutes actually learning" problem.

Why engineers like it

Prebuilt scenarios
Fast start time
Good for focused drills and guided progression
No need to run a heavy local lab server

Where it hurts

Monthly cost adds up fast
Cloud dependency means no internet, no lab
You are working inside someone else's topology design most of the time
It is not the best place for open-ended architecture experiments

My practical read: INE is a great complement to a local lab, not always a replacement for one.

3. GNS3 is still the best zero-dollar power tool

GNS3 remains useful because it is flexible, familiar, and free.

If you are early in your journey, building mixed-vendor labs, or testing ideas that do not depend on bundled Cisco images, GNS3 still does a lot of work for the price of zero.

It is especially good for:

budget home labs
combining routers, Linux VMs, containers, and appliances
mixed-vendor experiments
learning how virtual network topologies actually fit together

Why engineers like it

Free and mature
Huge community footprint
Flexible enough for lots of weird lab ideas
Strong choice when your environment is not Cisco-only

Where it hurts

No official Cisco image bundle
Modern Cisco virtual platforms can be more painful to run well
Stability and performance depend more heavily on how you assemble the environment
Support is community-driven

GNS3 is still very good. It is just not the cleanest answer when your goal is repeatable Cisco production-style behavior with minimal licensing ambiguity.

What should you choose?

Here's the practical version.

Choose CML if:

you work primarily in Cisco environments
you want protocol and topology freedom
you care about legal image access
you want to automate lab deployment through an API
you plan to keep and evolve labs over time

Choose INE if:

you learn best from guided scenarios
you want to spend more time practicing and less time building
you do not want to maintain local lab infrastructure
you mainly need focused reps, not open-ended design work

Choose GNS3 if:

budget matters most
you want maximum flexibility
you are building mixed-vendor or hybrid labs
you are comfortable owning more of the setup and troubleshooting yourself

My recommendation

For most serious Cisco-focused engineers, the strongest setup is:

CML as the main lab platform
INE when you want guided drills
GNS3 when you need cheap flexibility or mixed-vendor experimentation

If you can only pick one, I would pick CML for deep Cisco lab work and GNS3 for budget-first lab work.

Cost reality

Platform	18-month cost	Notes
CML Personal	~$300	Cheapest legal Cisco-first path over time
INE	~$360 to $900	Depends on plan and duration
GNS3	$0	Software is free, hardware and images are the real variables

That cost discussion matters less if the platform saves you dozens of hours or helps you run more realistic labs. Cheap tools are not actually cheap if they slow down every session.

Practical setup advice

A few things matter more than the logo on the platform:

Use a dedicated lab box if you can. CPU and RAM solve more problems than brand debates.
Save base topologies. Rebuilding the same underlay every time is wasted energy.
Practice failure, not just configuration. Break adjacencies, corrupt policy, fail links, then recover.
Keep a known-good config library. Good labs come from fast iteration, not retyping from scratch.
Time your sessions. Even outside certification study, time pressure reveals weak spots in your workflow.

Bottom line

If you want the cleanest and most engineer-friendly Cisco lab platform in 2026, CML is the strongest default.

If you want fast guided reps, INE is excellent.

If you want the most flexible zero-cost lab tool, GNS3 still absolutely belongs in the conversation.

The right answer is less about hype and more about how you work: blank-canvas experimentation, guided repetition, or budget-first flexibility.

Disclosure: This Dev.to post was adapted with AI assistance from the original FirstPassLab article. The canonical version is published on firstpasslab.com.

22 Fortinet Patches, 2 Ivanti Auth Bypasses, 9 Intel UEFI Bugs — Your March 2026 Patching Cheat Sheet

FirstPassLab — Sat, 04 Apr 2026 16:56:43 +0000

Fortinet dropped 22 security patches on March 11, 2026, including a FortiOS authentication bypass (CVE-2026-22153) that lets unauthenticated attackers slip past LDAP-based VPN and FSSO policies. The same patch cycle addresses a heap buffer overflow (CVE-2025-25249) in FortiOS and FortiSwitchManager enabling remote code execution. Ivanti simultaneously patched a high-severity auth bypass in Endpoint Manager. If you manage FortiGate firewalls, Ivanti EPM, or Intel-based infrastructure, here's your prioritized action plan.

TL;DR: FortiOS 7.6.0–7.6.4 has an auth bypass that grants unauthorized network access without credentials. Patch to 7.6.5+ immediately if you use Agentless VPN or FSSO with LDAP.

The Fortinet Patch Dump: What Actually Matters

Fortinet released fixes for 22 security defects across its portfolio. Here's the breakdown of what you need to care about:

CVE	Product	CVSS	Impact	Exploited?
CVE-2026-22153	FortiOS 7.6.0–7.6.4	7.2	Auth bypass (LDAP/VPN/FSSO)	No
CVE-2025-25249	FortiOS, FortiSASE, FortiSwitchManager	7.4	RCE via heap overflow	No
CVE-2026-24018	FortiClientLinux	7.4	Local privesc to root	No
CVE-2026-30897	FortiOS API	5.9	Stack overflow / code exec	No
N/A	FortiWeb	High	Auth rate-limit bypass	No
N/A	FortiSwitchAXFixed	High	Unauthorized cmd exec	No

None are currently exploited in the wild. But Fortinet's track record says exploitation follows disclosure by days, not weeks. CVE-2026-24858 — a related FortiOS SSO auth bypass — was actively exploited in January 2026 with attackers creating rogue admin accounts before patches even shipped.

CVE-2026-22153: The Auth Bypass You Need to Fix Today

This is a CWE-288 authentication bypass in FortiOS that lets an unauthenticated attacker bypass LDAP authentication for Agentless VPN or FSSO policies. Successful exploitation grants unauthorized access to network resources without valid credentials.

The catch: it requires a specific LDAP server configuration. But Agentless VPN and FSSO are exactly the features that enterprise networks deploy at scale. If your FortiGate authenticates remote users or maps AD users to firewall policies via FSSO, you're in the blast radius.

Affected: FortiOS 7.6.0 through 7.6.4
Fix: Update to FortiOS 7.6.5+

CVE-2025-25249: Heap Overflow → Remote Code Execution

A heap-based buffer overflow (CWE-122) in the cw_acd daemon of FortiOS and FortiSwitchManager. Remote unauthenticated attackers can execute arbitrary code via crafted requests.

The version spread is brutal:

FortiOS 7.6.0–7.6.3
FortiOS 7.4.0–7.4.8
FortiOS 7.2.0–7.2.11
FortiOS 7.0.0–7.0.17
FortiOS 6.4.0–6.4.16
FortiSwitchManager 7.2.0–7.2.5
FortiSwitchManager 7.0.0–7.0.5

That covers essentially every FortiOS release train still in production.

Ivanti: Two More Auth Problems

Ivanti released patches in Endpoint Manager 2024 SU5:

CVE	CVSS	Impact
CVE-2026-1603	7.4	Auth bypass exposing credential data
CVE-2026-1602	5.3	SQL injection

CVE-2026-1603 is the bigger concern — an auth bypass that exposes credential data remotely. Given Ivanti's history (CVE-2025-22457 in Connect Secure was a zero-day RCE exploited before the patch), don't sit on this one.

Your Prioritized Patching Plan

Based on severity, exploitability, and typical network exposure:

Priority 1: FortiOS 7.6.x (CVE-2026-22153) — This Week

If you run Agentless VPN or FSSO with LDAP authentication, this is job #1.

# Check your current FortiOS version
get system status

# Verify LDAP server configuration
show user ldap

# Check if Agentless VPN or FSSO is configured
show user fsso
diagnose debug application fssod -1

Priority 2: FortiOS/FortiSwitchManager (CVE-2025-25249) — Within 2 Weeks

The heap overflow affects nearly all FortiOS versions. Attack complexity is high, but impact is full RCE. Schedule alongside your CVE-2026-22153 patching.

Priority 3: FortiClientLinux (CVE-2026-24018) — Next Maintenance Window

Local privesc to root via symlink following. If you deploy FortiClient on Linux endpoints, queue it up.

Priority 4: Ivanti EPM (CVE-2026-1603) — Within 2 Weeks

Update to EPM 2024 SU5. Auth bypass + credential exposure = potential cascade.

Priority 5: Intel UEFI Firmware — Next Quarterly Window

Intel published advisory INTEL-SA-01234 with nine UEFI vulnerabilities across 45+ processor models. Five rated high severity. Requires local access, so lower urgency — but UEFI compromises persist across OS reinstalls.

Why Does Fortinet Keep Having Auth Bypasses?

This is the pattern that should concern you: multiple authentication bypass vulnerabilities within Q1 2026 alone.

CVE-2026-24858 was actively exploited as a zero-day in January:

Attackers created unauthorized local admin accounts on FortiGate appliances
Downloaded full device configurations (including VPN credentials)
Modified firewall policies to enable persistent access

Now CVE-2026-22153 arrives — another auth bypass, same vulnerability class (CWE-288). This suggests a systemic issue in how FortiOS handles authentication flows.

If Fortinet is your primary perimeter defense:

Don't rely solely on FortiGate for auth — integrate with a dedicated IdP
Enforce MFA at every layer
Monitor for config changes via FortiAnalyzer or SIEM
Consider defense-in-depth beyond a single-vendor auth stack

Post-Patch: Check for Pre-Patch Exploitation

Even after patching, verify these weren't exploited before your update window:

For CVE-2026-22153 (LDAP bypass):

# Check for unexpected VPN sessions
diagnose vpn tunnel list
get vpn ssl monitor

# Review admin login history
diagnose sys admin list

# Check for unauthorized policy changes
execute log filter device 0
execute log filter category 1
execute log display

For CVE-2025-25249 (heap overflow):

# Monitor crashlog for cw_acd daemon
diagnose debug crashlog read

# Check for unexpected processes
fnsysctl ls -la /tmp/

For Ivanti EPM (CVE-2026-1603):

Review EPM audit logs for unusual auth events
Check for new/modified admin accounts
Monitor SQL query logs for injection patterns

The Bigger March 2026 Picture

This wasn't just Fortinet and Ivanti. March 2026 was one of the heaviest patch loads of the year:

Microsoft: 83 vulnerabilities including two publicly disclosed zero-days
Adobe: 80 vulnerabilities across eight products
SAP: Critical NetWeaver flaws
Siemens, Schneider, Moxa, Mitsubishi Electric: ICS/OT patches

If you haven't built an automated patch validation pipeline (test → staging → production), March 2026 is your wake-up call.

Originally published at FirstPassLab. More deep dives on network security engineering at firstpasslab.com.

Disclosure: This article was adapted from original research with AI assistance in editing and formatting.

SRv6 uSID Is Replacing MPLS at Scale — Here's How to Migrate with Working IOS XR Configs

FirstPassLab — Fri, 03 Apr 2026 22:56:35 +0000

If you work in service provider networking, the question is no longer whether your network will move from MPLS to SRv6 — it is when. By early 2026, over 85,000 Cisco routers are running SRv6 uSID in production across more than 60 operators worldwide. Swisscom, Rakuten Mobile, SoftBank, and Jio Platforms have either completed or are actively executing their SRv6 uSID migrations.

This is not a lab curiosity anymore. It is the dominant transport transformation in the SP space.

In this article, we'll break down what SRv6 uSID actually is, why it matters, how to configure it on Cisco IOS XR, and how to execute a lossless migration from legacy MPLS or SR-MPLS to SRv6 uSID F3216.

What Is SRv6 uSID and Why Should You Care?

SRv6 (Segment Routing over IPv6) encodes forwarding instructions directly into IPv6 addresses. Each Segment Identifier (SID) is a 128-bit IPv6 address, and a list of SIDs in the IPv6 Segment Routing Header (SRH) describes the packet's path through the network.

The problem with early SRv6 implementations was overhead. A full 128-bit SID per hop adds up fast — four waypoints meant 64 bytes of SRH, which created MTU headaches in real networks.

SRv6 micro-SIDs (uSIDs) solve this by compressing multiple segment instructions into a single 128-bit IPv6 address, called a uSID Carrier. The dominant production format is F3216:

32-bit uSID Block — identifies the SRv6 domain
16-bit uSID IDs — identifies specific nodes or functions

A single uSID carrier encodes up to 6 micro-SIDs, which means you can describe 18 source-routing waypoints in only 40 bytes of overhead. That is comparable to or better than an MPLS label stack for the same path complexity.

Pro Tip: When planning your SRv6 addressing scheme, choose your 32-bit uSID block prefix carefully. This prefix identifies your entire SRv6 domain, and changing it later requires touching every node. Treat it like your BGP AS number — pick it once, document it everywhere.

SR-MPLS vs. SRv6 uSID: Key Differences

Attribute	SR-MPLS	SRv6 uSID (F3216)
Encoding	MPLS label stack	IPv6 SRH with compressed uSIDs
Path description	Label per hop (4 bytes each)	Up to 6 waypoints per 16-byte carrier
Data plane	MPLS forwarding	Native IPv6 forwarding
Programmability	Limited to label operations	Full IPv6 extension header programmability
Network slicing	Complex, requires dedicated LSPs	Native support via FlexAlgo + uSID

The programmability advantage is significant. With SRv6, you can define custom behaviors (called SRv6 functions) at each segment endpoint — enabling service chaining, VPN overlay binding, and traffic engineering that would require multiple protocol interactions in MPLS.

Configuring SRv6 uSID on Cisco IOS XR

Let's walk through a complete SRv6 uSID deployment on a Cisco 8000 Series router running IOS XR.

Step 1: Define SRv6 Locators

The locator is the foundation of your SRv6 configuration. It defines the prefix that the router will use to generate its local SIDs:

segment-routing srv6
 encapsulation
  source-address fcbb:bb00:0001::1
 !
 locators
  locator myuSID
   micro-segment behavior unode psp-usd
   prefix fcbb:bb00:0001::/48
  !
 !
!

Key points:

The source-address is the IPv6 address used as the outer source in SRv6-encapsulated packets. It must be reachable in your IGP.
micro-segment behavior unode psp-usd enables the F3216 uSID format with Penultimate Segment Pop (PSP) and Ultimate Segment Decapsulation (USD) behaviors.
The /48 prefix defines the locator block. The first 32 bits (fcbb:bb00) are the uSID block, and bits 33-48 (0001) are this node's uSID ID.

Pro Tip: Always use psp-usd as your default uSID behavior. PSP removes the SRH at the penultimate hop, reducing processing overhead on the endpoint node. USD handles decapsulation cleanly when this node is the final destination.

Step 2: Integrate with IS-IS

IS-IS advertises SRv6 locator reachability across the network:

router isis CORE
 is-type level-2-only
 net 49.0001.0000.0000.0001.00
 address-family ipv6 unicast
  metric-style wide
  segment-routing srv6
   locator myuSID
  !
 !
 interface Loopback0
  address-family ipv6 unicast
  !
 !
 interface HundredGigE0/0/0/0
  point-to-point
  address-family ipv6 unicast
  !
 !
!

When applied, the router advertises its /48 locator prefix into IS-IS. Other routers install this as a route in their IPv6 RIB, enabling SRv6 forwarding.

Step 3: Enable BGP and EVPN Overlays

For L3VPN and EVPN services, bind the uSID locator to BGP:

router bgp 65001
 address-family vpnv4 unicast
 !
 address-family vpnv6 unicast
 !
 address-family l2vpn evpn
 !
 segment-routing srv6
  locator myuSID
 !
 neighbor 2001:db8::2
  remote-as 65001
  update-source Loopback0
  address-family vpnv4 unicast
  !
  address-family l2vpn evpn
  !
 !
!

evpn
 segment-routing srv6
  locator myuSID
 !
!

With this, BGP allocates SRv6 uSIDs for VPN prefixes and advertises them to PE peers. The receiving PE uses the uSID to forward encapsulated traffic directly over the IPv6 underlay — no LDP, no RSVP, no separate MPLS signaling stack.

Migration Strategy: Ship in the Night

The most critical question for any production network: how do we get from MPLS to SRv6 without dropping traffic?

Cisco's recommended approach is Ship in the Night — running both forwarding planes simultaneously during the transition.

State 1: Initial (Legacy MPLS or SR-MPLS)

Your network runs traditional MPLS with LDP/RSVP, or SR-MPLS with format1 SIDs. All services use MPLS transport. No SRv6 configuration exists.

State 2: In-Migration (Dual Mode)

You deploy SRv6 uSID locators alongside the existing MPLS configuration. Both forwarding planes coexist:

Existing MPLS/SR-MPLS control plane continues to signal labels and forward traffic
SRv6 uSID locators are advertised in IS-IS concurrently
BGP and EVPN are configured with uSID locators on all PE nodes
Traffic can flow over either transport depending on which SIDs the ingress PE selects

This is the critical phase. You must enable overlay F3216 locators under BGP and EVPN on all PE nodes before cutting over any services.

State 3: End State (SRv6 uSID Only)

Once all services are verified on SRv6 uSID transport, you remove legacy MPLS configuration.

Pro Tip: Use the delayed-delete command when removing format1 locators during cutover. This keeps old SIDs active in the forwarding table for a configurable period while F3216 SIDs take over. A 60-second delay is usually sufficient for BGP to reconverge.

Migration Caveats

Line card reloads may be required during hardware profile transitions on some platforms. Plan maintenance windows.
Cisco 8000 Series (K100, A100 ASICs) and 8700-MOD support dual-mode natively. Verify your hardware.
For mixed-vendor networks, check draft-ietf-spring-srv6-mpls-interworking for SRv6-MPLS gateway interworking standards.

Verification and Troubleshooting

Verify SRv6 Locator Status

RP/0/RP0/CPU0:PE1# show segment-routing srv6 locator

Name          Prefix                    Status
----          ------                    ------
myuSID        fcbb:bb00:0001::/48       Up

If status shows Down, check:

No prefix conflict with another locator on the same node
IS-IS is configured to advertise the locator
The platform supports the specified uSID behavior

Verify IS-IS SRv6 Advertisement

RP/0/RP0/CPU0:PE1# show isis segment-routing srv6 locators detail

IS-IS CORE Level-2 SRv6 Locators:

  Locator: myuSID
    Prefix: fcbb:bb00:0001::/48
    Topology: IPv6 Unicast
    Algorithm: 0
    Metric: 1
    Advertised: Yes

Verify BGP SRv6 SID Allocation

RP/0/RP0/CPU0:PE1# show bgp vpnv4 unicast vrf CUSTOMER-A 10.1.1.0/24

BGP routing table entry for 10.1.1.0/24, Route Distinguisher: 65001:100
  Local
    fcbb:bb00:0001:: (via SRv6 SID: fcbb:bb00:0001:e004::)
    Origin IGP, metric 0, localpref 100, valid, sourced, best
    SRv6 SID: fcbb:bb00:0001:e004::
      Function: End.DT4
      Locator: myuSID

The End.DT4 function indicates a decapsulation-and-lookup behavior for IPv4 VPN traffic — the SRv6 equivalent of a VPN label in MPLS.

Common Troubleshooting Scenarios

SRv6 locator is Up but BGP is not allocating SIDs:
Ensure segment-routing srv6 locator myuSID is configured under both router bgp and evpn.

Traffic is blackholing after enabling uSID locators:
Verify all transit routers have IS-IS SRv6 locator routes in their IPv6 RIB. A single router without the locator route will drop SRv6-encapsulated packets.

MTU issues after migration:
SRv6 encapsulation adds a minimum of 40 bytes (IPv6 outer header) plus SRH overhead. Core links need at least 9216-byte MTU.

Key Takeaways

SRv6 uSID is production-ready at scale. 85,000+ routers deployed globally across 60+ operators. This is not early-adopter tech.
F3216 solves the MTU problem. Six micro-SIDs per 128-bit carrier means SRv6 overhead is comparable to MPLS label stacks.
Ship in the Night enables lossless migration. Run both planes in parallel, validate per-service, cut over at your own pace.
Configuration is straightforward. Three building blocks — locators, IS-IS integration, and BGP/EVPN binding — cover the majority of deployments.
Open-source support is growing. FRRouting 10.5 now supports SRv6 uSID, extending this beyond Cisco-only shops to SONiC and other FRR-based platforms.

The MPLS-to-SRv6 migration is the defining infrastructure shift for service providers in 2026. Start with a lab, validate with Ship in the Night, and build operational confidence before touching production. The technology is ready — the question is whether you are.

Originally published at FirstPassLab. For more deep dives on networking protocols and infrastructure, visit firstpasslab.com.

AI Disclosure: This article was adapted and edited with AI assistance. All technical content is based on published vendor documentation, IETF standards, and real-world deployment data.

9 AppArmor Kernel Bugs Hidden Since 2017 — Root Escalation, Container Escape, and 12.6M Linux Systems Exposed

FirstPassLab — Fri, 03 Apr 2026 16:54:24 +0000

Nine critical vulnerabilities in Linux AppArmor — collectively dubbed CrackArmor by the Qualys Threat Research Unit — let any unprivileged local user escalate to root, escape container isolation, and crash entire systems via kernel panic. These flaws have existed in every kernel since v4.11 (April 2017). If you run infrastructure on Ubuntu, Debian, or SUSE — and if you use Kubernetes, your nodes almost certainly do — this is a patch-now situation.

Over 12.6 million enterprise Linux instances run with AppArmor enabled by default. Here's what broke, why it matters for your containers and infrastructure, and exactly how to check and fix it.

The Attack Surface: What CrackArmor Actually Does

CrackArmor exploits a confused deputy flaw in AppArmor's kernel implementation. AppArmor is the Mandatory Access Control (MAC) framework that confines processes under security profiles — it ships enabled by default on Ubuntu, Debian, and SUSE. The nine vulnerabilities let an attacker trick privileged processes into performing actions they shouldn't.

Here's the attack matrix:

Attack Vector	Mechanism	Impact
Profile manipulation	Write to `/sys/kernel/security/apparmor/.load`, `.replace`, `.remove`	Disable protections on any service
Privilege escalation	Leverage setuid binaries (sudo, postfix) to modify AppArmor profiles	Full root from unprivileged user
Container escape	Load crafted "userns" profile to bypass namespace restrictions	Break Kubernetes/container isolation
Denial of service	Trigger recursive stack exhaustion via deeply nested profiles	Kernel panic and reboot
KASLR bypass	Out-of-bounds read during profile parsing	Disclose kernel memory layout

The Qualys advisory puts it simply: "This is comparable to an intruder convincing a building manager with master keys to open restricted vaults that the intruder cannot enter alone." The attacker doesn't need special permissions — they manipulate the privileged machinery that already exists.

Why This Matters for Your Containers and Infrastructure

AppArmor isn't just an abstract kernel feature. It's the trust boundary for a massive amount of production infrastructure:

Kubernetes clusters. According to Kubernetes docs, AppArmor profiles are the recommended mechanism to "restrict a container's access to resources." CrackArmor breaks that restriction entirely. An attacker inside any container can escape to the host, then pivot to other containers — controllers, databases, monitoring.

Linux-based appliances. Many firewalls, SDN controllers, and network appliances ship Ubuntu or Debian under the hood with AppArmor enabled. A local exploit on any of these devices means full control.

NFV and edge deployments. Containerized network functions and edge computing nodes use AppArmor to isolate workloads. A container escape in these environments doesn't just compromise one function — it can expose the entire control plane.

CI/CD systems and jump boxes. If your build infrastructure or management stations run affected distros, an attacker with unprivileged access (stolen SSH creds, compromised service account) gets root.

Infrastructure Component	AppArmor Exposure	Risk Level
Kubernetes nodes (Ubuntu/Debian)	AppArmor profiles per pod	Critical — container escape
Linux-based firewalls/appliances	Often enabled by default	Critical — root = device control
NFV / edge platforms	Default MAC enforcement	High — lateral movement
CI/CD runners / jump boxes	Varies	High — pivot to production
Red Hat / CentOS / Fedora	SELinux (not AppArmor)	Not affected

How the Container Escape Works

This is the most dangerous chain for anyone running Kubernetes or Docker.

Ubuntu's user-namespace restrictions were specifically designed to prevent unprivileged users from creating fully-capable namespaces. CrackArmor bypasses this by loading a specially crafted "userns" profile for /usr/bin/time, enabling an attacker to create namespaces with full capabilities.

In a Kubernetes environment:

Attacker gains shell inside a container (compromised app, RCE in a dependency)
Exploits CrackArmor to escape to the host node
From the host, accesses all other containers on that node
Kubernetes AppArmor security boundary = nullified

The DoS path is equally nasty: deeply nested profiles trigger recursive removal routines that overflow the 16KB kernel stack, causing immediate kernel panic. An unexpected reboot of your K8s node is a production outage.

Am I Affected? Check in 10 Seconds

# Check if AppArmor is loaded
aa-status 2>/dev/null && echo "AppArmor ACTIVE - check kernel version" || echo "AppArmor not active"

# Check kernel version (v4.11+ is vulnerable if AppArmor is active)
uname -r

Run this across your infrastructure — not just servers. Check:

Kubernetes worker/control-plane nodes
CI/CD runners (GitHub Actions self-hosted, GitLab runners, Jenkins agents)
Docker hosts
Network appliances and firewalls on Linux
Jump boxes and bastion hosts

Affected: Any distro using AppArmor + kernel ≥ v4.11 without March 2026 patches

Distribution	Affected?	Patch Status
Ubuntu (all supported)	Yes — AppArmor default	`apt update && apt upgrade`
Debian (bookworm, trixie)	Yes — AppArmor default	`apt update && apt upgrade`
SUSE / openSUSE	Yes — AppArmor default	`zypper refresh && zypper update`
Red Hat / CentOS / Fedora	No — uses SELinux	Not affected
Alpine Linux	Varies	Check `aa-status`

Patch Now: Step-by-Step

Ubuntu / Debian

sudo apt update && sudo apt upgrade -y linux-image-$(uname -r)
sudo reboot

SUSE

sudo zypper refresh && sudo zypper update kernel-default
sudo reboot

Yes, reboots are required — this is a kernel-level fix.

Post-Patch: Audit Profile Integrity

# List all loaded profiles and enforcement mode
aa-status

# Check for unexpected profiles
ls /etc/apparmor.d/

# Verify no profiles were modified recently
find /etc/apparmor.d/ -mtime -7 -ls

Harden Kubernetes After Patching

# Ensure AppArmor annotations are enforced on pods
metadata:
  annotations:
    container.apparmor.security.beta.kubernetes.io/my-container: runtime/default

Configure admission controllers to reject pods without AppArmor profiles — a post-patch hardening step that prevents future profile manipulation.

CVE Status: Don't Wait for Numbers

As of mid-March 2026, no CVE identifiers have been assigned. The upstream kernel team typically assigns CVEs 1-2 weeks after fixes land in stable releases. Qualys has published the full technical advisory and proof-of-concept details.

Do not wait for CVE assignment to justify patching. The exploit details are public.

Context: How CrackArmor Compares

Vulnerability	Attack Vector	Impact	Key Difference
CrackArmor (AppArmor)	Local unprivileged	Root + container escape	Requires local access first
Fortinet FortiOS CVE-2025-24472	Remote unauth	Super-admin access	No local access needed
Ivanti Connect Secure CVE-2025-22467	Authenticated remote	Remote code execution	Needs valid credentials

CrackArmor requires local access — but in environments where attackers already have a foothold (compromised container, stolen SSH key, malicious insider), it turns limited access into total control.

Three Takeaways

Defense in depth isn't optional. AppArmor was one layer. When it failed, containers, namespaces, and privilege boundaries all failed together. Layer your controls independently — don't rely on a single MAC framework.
Know your attack surface. CrackArmor needs local access first. Your SSH hardening, network access controls, and authentication policies are the real first line. If an attacker can't get local access, CrackArmor is irrelevant.
Patch management is engineering, not ops. The ability to rapidly identify, test, and deploy kernel patches across heterogeneous infrastructure is a core engineering competency — not an afterthought.

Originally published at FirstPassLab. For more deep dives on network security, cloud architecture, and infrastructure engineering, visit firstpasslab.com.

🤖 AI Disclosure: This article was adapted from the original blog post with AI assistance. The technical content, vulnerability analysis, and remediation steps are based on primary sources including the Qualys CrackArmor advisory and vendor security bulletins.

386 Global Outages in One Week: What ThousandEyes Q1 2026 Data Reveals About Modern Network Fragility

FirstPassLab — Thu, 02 Apr 2026 22:53:25 +0000

Cisco ThousandEyes tracked between 199 and 386 global network outage events per week during Q1 2026, with a 62% spike during the last week of February. The defining outage pattern of 2026 isn't broken components — it's systems interacting in ways nobody designed for.

If your monitoring stops at your network boundary, you're blind to the failures that actually hit your users.

The Numbers: Q1 2026 Outage Data

ThousandEyes monitors ISPs, cloud service providers, conferencing services, and edge networks (DNS, CDN, SECaaS). Here's the week-by-week breakdown:

Week	Global Outages	WoW Change	U.S. Outages
Dec 29 – Jan 4	199	−14%	71
Jan 5 – Jan 11	255	+28%	135
Jan 12 – Jan 18	263	+3%	149
Jan 19 – Jan 25	236	−10%	148
Jan 26 – Feb 1	314	+33%	156
Feb 2 – Feb 8	264	−16%	157
Feb 9 – Feb 15	247	−6%	136
Feb 16 – Feb 22	239	−3%	114
Feb 23 – Mar 1	386	+62%	184
Mar 2 – Mar 8	304	−21%	124
Mar 9 – Mar 15	272	−11%	155
Mar 16 – Mar 22	277	+2%	144

The January 5–11 week saw U.S. outages surge 90% (71 → 135) as operations resumed after the holiday change-freeze period. Global outages increased 178% from November to December 2025, rising from 421 to 1,170 monthly incidents.

The Biggest Outages: Who Went Down and Why

The highest-profile incidents hit Tier 1 carriers, cloud platforms, and critical infrastructure:

Date	Provider	Duration	Regions	Root Cause Pattern
Jan 6	Charter/Spectrum	1h 43m	U.S. + 9 countries	Node migration across NYC, DC, Houston
Jan 17	TATA Communications	23m	14 countries	Cascading failures Singapore → U.S. → Japan
Jan 27	Cloudflare	2h 23m	U.S. + 4 countries	Chicago → Winnipeg → Aurora expansion
Jan 27	Lumen	1h 5m	U.S. + 13 countries	Oscillating DC → Detroit → LA → DC
Feb 10	Hurricane Electric	25m	U.S. + 12 countries	Dallas → Atlanta → Charlotte → NYC
Feb 17	Cogent	1h 20m	U.S. + 4 countries	Recurring Denver node failures
Feb 20	Cloudflare BYOIP	1h 40m	Global	Automated maintenance withdrew customer IP prefixes
Feb 26	GitHub	1h	U.S. + 6 countries	Washington D.C. centered
Mar 4	PCCW	48m	14 countries	Marseille → LA → Hong Kong cascade
Mar 6	ServiceNow	1h 3m	29 countries	Austin → Seattle → Chicago node migration
Mar 20	Arelion (Telia)	1h 38m	18+ countries	Ashburn → DC → Dallas → Newark expansion

The Cloudflare BYOIP incident (Feb 20) is the most instructive: a bug in an automated maintenance task caused Cloudflare to unintentionally withdraw customer IP address advertisements from the global routing table. No human made a mistake — the automation itself created the failure.

Cogent appeared twice (Feb 17 and Mar 12), both times centered on Denver — a pattern that multi-path SD-WAN failover is specifically designed to survive.

The Cost: $14K–$23.7K Per Minute

Enterprise downtime costs between $14,000 and $23,750 per minute depending on organization size (EMA, ITIC, BigPanda 2026). Over 90% of midsize and large companies report hourly costs exceeding $300K.

Industry	Avg. Hourly Cost	Key Risk Factor
Financial Services	$1M – $9.3M	Real-time transaction processing
Healthcare	$318K – $540K	Patient safety + HIPAA fines
Retail / E-commerce	$1M – $2M (peak)	Lost sales + customer churn
Manufacturing	$260K – $500K	Supply chain disruption
Automotive	$2.3M	Assembly line stoppages
Telecommunications	$660K+	Service credits + customer churn

Global 2000 companies collectively lose $400 billion annually from unplanned downtime.

Root Causes: It's the Network, and It's Us

Network and connectivity issues are the #1 cause of IT service outages (31%), per the Uptime Institute's 2024 Data Center Resiliency Survey. Within that:

Configuration/change management failures: 45% — BGP route policies, OSPF area design, SD-WAN overlay topology. Understand blast radius before executing changes.
Third-party provider failures: 39% — Cogent, Lumen, Charter all had repeated outages. Multi-homed BGP with RPKI validation is the engineering response.
Software/system failures: 36% — 64% of these stem from config/change issues. 44% of respondents say network changes cause outages "several times a year."

Human error contributes to 66–80% of all downtime. Of those, 85% stem from staff not following procedures (47%) or flawed processes (40%). Only 3% of organizations catch all mistakes before impact.

The New Pattern: Autonomous Agent Interaction Failures

This is the section that matters most for 2026 and beyond.

ThousandEyes identifies autonomous agents — auto-scalers, AIOps platforms, remediation bots, intent-based automation — as the single biggest emerging risk. The pattern is no longer "something broke" but "systems interacting in ways nobody anticipated."

Three 2025 incidents that define this pattern:

AWS DynamoDB (Oct 2025): Two independent DNS management components operated correctly within their own logic. A delayed component applied an older DNS plan at the precise moment a cleanup operation deleted the newer plan. Neither malfunctioned — their timing interaction created the failure.

Azure Front Door (Oct 2025): A control plane created faulty metadata. Automated detection correctly blocked it. The cleanup operation triggered a latent bug in a different component. Every system did its job. The interaction produced the outage.

Cloudflare Bot Management (Nov 2025): A configuration file exceeded a hard-coded limit. The generating system operated correctly. The proxy enforcing the limit also operated correctly. The output of one system exceeded the constraints of another.

The proliferation of agents creates three specific risks:

Cascading failures: Agents make decisions in milliseconds. When one agent reacts to another's output, mistakes propagate before humans detect degradation.
Optimization conflicts: A performance agent, a cost-reduction agent, and a reliability agent may work against each other simultaneously.
Intent uncertainty: When one agent changes a route, other agents must determine whether the change was intentional. Get that wrong and agents start undoing each other's work.

5-Layer Defense Strategy

Layer 1: End-to-End Observability Beyond Your Boundary

Traditional SNMP traps capture what happens inside your infrastructure. The Q1 data shows outages cascading across Tier 1 carriers (Arelion across 18 countries), cloud platforms (ServiceNow across 29 countries), and edge networks simultaneously. You need visibility into dependencies you don't own — ThousandEyes, Catchpoint, and Kentik provide Internet-wide path analysis.

Layer 2: Multi-Homed BGP with RPKI Validation

Cogent's recurring Denver outages demonstrate why single-carrier dependency is unacceptable. Implement BGP RPKI Route Origin Validation with at least two upstream providers. Configure BGP communities and local preference to steer traffic away from degraded paths automatically. IX peering adds a third failover path.

Layer 3: Automated Change Validation

45% of outages come from config/change failures. Every network change needs pre-deployment validation. Network digital twins (Batfish, ContainerLab) simulate route policy impact before production. Pair with Terraform IaC for auditable, reversible changes.

Layer 4: Agent Coordination as a Design Concern

If your network runs auto-scalers, AIOps remediation, and intent-based policies, define interaction boundaries. Establish rate limits on automated changes. Implement circuit breakers that halt cascading automation when change velocity exceeds thresholds. This is the evolution of network automation from scripting to architecture.

Layer 5: Redundancy Matched to Financial Exposure

90% of organizations require minimum 99.99% availability — only 52.6 minutes of annual downtime. At $14K/min for midsize businesses, that's $736K of maximum tolerable loss per year. Calculate your specific exposure: Annual Revenue ÷ Total Working Hours = Hourly Revenue at risk. That number justifies geographic distribution, SD-WAN multi-path failover, and dual-DC designs.

Action Items Right Now

Map your carrier dependencies — run traceroutes from multiple vantage points and identify single-carrier paths
Implement RPKI if you haven't — route origin validation prevents the BGP hijacks and leaks that contributed to several Q1 incidents
Audit your automation guardrails — do your auto-scalers and remediation bots have rate limits and circuit breakers?
Calculate your per-minute downtime cost — make the business case for observability investment concrete
Schedule a real failover test — untested failover is no failover

The Q1 2026 data proves that we're building more capable networks that are simultaneously more fragile. We spent 20 years building redundancy. Now we need coordination.

Originally published at FirstPassLab. For more deep dives on network engineering and infrastructure resilience, check out firstpasslab.com.

This article was adapted from original research with AI assistance. The data, sources, and technical analysis have been verified against the cited references.

Why Multi-AZ Failed: Lessons from the First Kinetic Attack on a Major Cloud Region

FirstPassLab — Thu, 02 Apr 2026 16:52:57 +0000

When Iranian drones struck AWS data centers in the UAE and Bahrain on March 1, 2026, they didn't just destroy server racks — they invalidated the multi-AZ assumptions that most cloud architectures are built on. AWS responded by waiving all March charges for ME-CENTRAL-1 and ME-SOUTH-1, an unprecedented move. Here's what engineers need to understand about what failed and how to design around it.

TL;DR: Multi-AZ is not a disaster recovery plan when the threat is geopolitical. Only tested, cross-region failover with active data replication protects against the physical destruction of an entire cloud region.

What Actually Happened

Shahed 136 drones struck two AWS data center facilities, causing structural damage, power grid disruption, and water damage from fire suppression systems. The AWS Service Health Dashboard confirmed:

ME-CENTRAL-1 (UAE): 2 of 3 AZs impaired (mec1-az2, mec1-az3)
ME-SOUTH-1 (Bahrain): 1 of 3 AZs lost power entirely (mes1-az2)
84+ services offline including EC2, S3, DynamoDB, Lambda, RDS, and the Management Console

Regional customers — Careem, Alaan, Tabby, and banking services — went down immediately (CNBC, 2026).

Impact Detail	ME-CENTRAL-1 (UAE)	ME-SOUTH-1 (Bahrain)
AZs Impaired	2 of 3	1 of 3
Services Affected	84+	60+
Power Status (Late March)	Partially restored	Still restoring mes1-az2
Customer Migration	Active to unaffected regions	Active to unaffected regions

The Billing Waiver Created a Second Problem

AWS waived all March usage charges — unprecedented. But the waiver also removed Cost and Usage Report (CUR) data from billing dashboards. As Cory Quinn pointed out, for most enterprises the CUR isn't just an invoice — it's the authoritative record of what infrastructure exists. Compliance teams, auditors, and FinOps teams all build on it.

AWS later clarified the data wasn't deleted, just filtered from standard reports. But the lesson is clear: your billing data is also your infrastructure inventory. If your DR playbook doesn't account for billing data availability during a region-wide failure, you have an audit gap.

Why Multi-AZ Didn't Protect Workloads

This is the critical engineering lesson. Multi-AZ distributes across physically separate data centers within a single region, but all AZs sit within the same metro area and share the same geopolitical threat envelope.

Three assumptions that broke:

1. Multi-AZ ≠ Multi-Region

AZs within ME-CENTRAL-1 are ~50-100 km apart. A coordinated strike targeting a metropolitan area reaches multiple AZs. Engineers running workloads across all three AZs still experienced degradation because the surviving AZ couldn't absorb full regional load.

2. Control Plane Failures Cascade

Even where data plane instances survived (mec1-az1), the control plane was disrupted. Customers couldn't launch new instances, modify security groups, or execute failover automation. If your DR runbook requires API calls to the impaired region's control plane, your failover is dead on arrival.

3. Shared Dependencies Are Invisible

Services running in healthy AZs had hidden dependencies on impaired zones — internal load balancers, DNS resolution, IAM authentication endpoints. These cross-AZ dependencies aren't documented in customer-facing architecture diagrams.

Architecture Pattern	Protects Against	Does NOT Protect Against
Multi-AZ (same region)	Single AZ failure, hardware failure	Regional disaster, military strike
Multi-Region (active-passive)	Full region outage	Data lag during failover, control plane dependency
Multi-Region (active-active)	All above + zero RPO failover	Complexity, cost, global routing challenges
Multi-Cloud	Single provider failure	Doubled operational complexity

A Practical Redesign Framework

Here's how to rethink your architecture:

Tier 1: Region Risk Assessment. Before deploying to any region, evaluate the sovereign risk profile. Map regions against active conflict zones, not just latency numbers. AWS operates in the UAE, Bahrain, and is investing $5.3B in Saudi Arabia. Each region has a different threat model.

Tier 2: Cross-Region Data Replication. Implement async or sync replication to a geographically and politically distant region. S3 Cross-Region Replication, DynamoDB Global Tables, Aurora Global Database. RPO under 1 minute requires active-active with Global Accelerator routing.

Tier 3: Tested Failover. "Untested failover is no failover." Schedule quarterly game days where you actually cut traffic from one region. Organizations that never tested ME-CENTRAL-1 failover discovered missing encryption keys, expired credentials, and incomplete replication during the crisis.

Tier 4: Decouple Data Residency from Compute. If regulations require data in a specific country, architect so compute/serving can operate from a different region while maintaining data locality compliance.

Industry Impact

This was the first confirmed kinetic attack destroying a major cloud provider's infrastructure. Israel reportedly struck a Tehran data center on March 11 (Jerusalem Post), confirming both sides view digital infrastructure as strategic targets.

Counterintuitively, Amazon's stock rallied ~3% — investors betting the incident accelerates cloud spending on resilience. Oracle's Middle East regions experienced zero incidents during the same period, validating the multi-cloud argument for critical workloads.

Compared to Previous Outages

Outage	Cause	Duration	Regions	Services Down
AWS us-east-1 (Dec 2021)	Scaling bug	~10 hours	1	20+
AWS ME-CENTRAL-1 (Mar 2026)	Drone strikes	Weeks	2	84+
Azure (Jan 2023)	WAN routing misconfig	~5 hours	Multiple	15+
Google Cloud (Apr 2023)	Paris region power failure	~12 hours	1	10+

Physical infrastructure cannot be rebooted. It must be rebuilt. Organizations with infrastructure defined in Terraform or Ansible redeployed in hours. Those relying on ClickOps are still migrating a month later.

Five Things to Do Right Now

Audit region dependencies: aws ec2 describe-instances --query 'Reservations[].Instances[].[InstanceId,Placement.AvailabilityZone]'
Verify cross-region replication — check actual RPO/RTO metrics, not just config
Schedule a real failover test within 30 days
Review your CUR data pipeline for gaps during crisis scenarios
Document a geopolitical risk matrix for every region where you run workloads

The cloud is not an abstraction. It's concrete, steel, and cooling systems sitting on land that exists inside a geopolitical reality. Engineers who build truly resilient multi-region architectures will define the next decade of enterprise cloud design.

Originally published at firstpasslab.com. More deep dives on cloud networking, infrastructure security, and network architecture at FirstPassLab.

AI Disclosure: This article was adapted from original research with AI assistance for editing and formatting. All technical claims are sourced and linked. The original article contains full source citations.

Stop Accepting BGP Routes on Trust Alone: Deploy RPKI ROV on IOS-XE and IOS XR Today

FirstPassLab — Wed, 01 Apr 2026 22:54:32 +0000

If you run BGP in production and you're not validating route origins with RPKI, you're accepting every prefix announcement on trust alone. That's the equivalent of letting anyone walk into your data center and plug into a switch because they said they work there.

BGP RPKI Route Origin Validation (ROV) is the mechanism that changes this. With 500K+ ROAs published globally, mature validator software, and RFC 9774 formally deprecating AS_SET, there's no technical barrier left. Here's how to deploy it on Cisco IOS-XE and IOS XR.

How RPKI ROV Actually Works

RPKI (Resource Public Key Infrastructure) cryptographically binds IP prefixes to the autonomous systems authorized to originate them. Three components make it work:

Route Origin Authorizations (ROAs) — Signed objects published by prefix holders in RPKI repositories. A ROA states: "AS 65001 is authorized to originate 192.0.2.0/24 with a maximum prefix length of /24."

RPKI Validators — Servers (Routinator, Fort, OctoRPKI) that download ROA data from the five RIR trust anchors, validate cryptographic signatures, and build a validated cache.

RPKI-to-Router Protocol (RTR) — RFC 8210 protocol that transports the validated cache to your BGP routers. Each prefix gets tagged:

Valid: Prefix and origin AS match a ROA
Invalid: A ROA exists but origin AS or prefix length doesn't match
NotFound: No ROA published for this prefix

⚠️ Critical distinction: NotFound ≠ Invalid. ~60% of the global table is still NotFound. Dropping those would black-hole most of the internet. The safe policy: drop Invalid, accept everything else, prefer Valid.

Connecting to RPKI Validators

IOS-XE Configuration

router bgp 65001
 bgp rpki server tcp 10.0.0.50 port 8282 refresh 300
 bgp rpki server tcp 10.0.0.51 port 8282 refresh 300

IOS XR Configuration

router bgp 65001
 rpki server 10.0.0.50
  transport tcp port 8282
  refresh-time 300
 !
 rpki server 10.0.0.51
  transport tcp port 8282
  refresh-time 300
 !

The refresh 300 sets a 300-second poll interval as a safety net. Incremental updates (Serial Notify) arrive between polls.

🔑 Always deploy at least two validators from different implementations (e.g., Routinator + Fort). If your only validator goes down and the RTR session expires, the router flushes its cache and silently disables ROV. You won't even know it happened.

Applying ROV Policy — Start Soft

Without a route-map acting on validation state, the router knows which routes are Invalid but does nothing about it. Here's where enforcement happens.

Phase 1: Tag and Deprioritize (Weeks 1-4)

route-map RPKI-POLICY permit 10
 match rpki invalid
 set community no-export additive
 set local-preference 50
!
route-map RPKI-POLICY permit 20
 match rpki valid
 set local-preference 200
!
route-map RPKI-POLICY permit 30
 match rpki not-found
 set local-preference 100
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map RPKI-POLICY in

This does three things:

Invalid routes → local-preference 50 + no-export community (least preferred, not propagated)
Valid routes → local-preference 200 (strongly preferred)
NotFound routes → local-preference 100 (functional, but not as trusted)

Why not hard-drop Invalid immediately? Some Invalid states come from stale or misconfigured ROAs by other operators. You need to observe before you enforce.

Phase 2: Hard Enforcement (After Monitoring)

route-map RPKI-POLICY deny 10
 match rpki invalid
!
route-map RPKI-POLICY permit 20
 match rpki valid
 set local-preference 200
!
route-map RPKI-POLICY permit 30
 match rpki not-found
 set local-preference 100

Now Invalid routes are silently dropped at the edge. Route hijacks don't propagate into your network.

Verification and Troubleshooting

Check Validator Connectivity

Router# show bgp rpki servers

BGP RPKI Server:
  Server Address: 10.0.0.50
  Server Port: 8282
  Server State: established
  Serial Number: 47
  Record Count: 482631

Key checks:

Server State must be established — if connecting or down, check reachability and validator health
Record Count should be 400K-500K+ — if 0, the validator isn't syncing

Check a Specific Prefix

Router# show bgp ipv4 unicast 1.0.0.0/24

BGP routing table entry for 1.0.0.0/24
  RPKI validation state: valid
  Origin AS: 13335
  ROA: 1.0.0.0/24, maxlen /24, origin-as 13335

Monitor Invalid Routes

Router# show bgp ipv4 unicast rpki invalid

This is your daily monitoring command during initial deployment. Cross-reference Invalid prefixes against the ROA database to separate genuine hijacks from ROA misconfigurations.

Common Issues

Problem	Cause	Fix
Validator session flapping	MTU issues on RTR path	Check path MTU; large cache responses trigger fragmentation
High record count but no Valid routes	Route-map not applied to neighbor	Verify `neighbor X route-map RPKI-POLICY in`
Prefix shows NotFound when you expect Valid	ROA not published or expired	Check ROA status in RPKI repositories directly
Validator shows 0 records	Not syncing with RIR trust anchors	Verify validator config syncs with all 5 RIRs

💡 Set up syslog/SNMP traps for RPKI session state changes. A validator failure should be a P1 alert, not something you discover during the next change window.

Beyond ROV: What's Coming

RPKI ROV validates the origin AS only. It can't detect route leaks where a legitimate AS improperly announces a prefix it received from a peer.

ASPA (Autonomous System Provider Authorization) is the emerging standard that encodes customer-provider AS relationships, enabling AS path validation. NIST is building test tools (the BRIO framework), and early adoption is expected in 2026-2027.

RFC 9774 deprecated AS_SET, which simplifies ROV — every route now has a single unambiguous origin AS. If you're still generating AS_SET in aggregate routes, update your aggregate-address configs now. Compliant peers will increasingly reject those routes.

Key Takeaways

RPKI ROV is production-ready — 500K+ ROAs, mature validators, no excuses
Start soft — tag Invalid with low local-pref for 2-4 weeks, then hard deny
Two validators minimum — single validator failure = silent ROV death
ROV is layer one — complement with ASPA and BGP session auth (TCP-AO) as they mature
Fix your aggregation — RFC 9774 killed AS_SET; update your configs
Alert on validator failures — treat RTR session drops as P1 incidents

BGP security is no longer optional for any network participating in the global routing system. RPKI ROV gives you a concrete, deployable mechanism to verify route origins today. Configure it, monitor it, enforce it.

Originally published at FirstPassLab. For more protocol deep dives and lab guides, visit firstpasslab.com.

AI Disclosure: This article was adapted with AI assistance. All technical content, configurations, and recommendations are based on documented Cisco IOS-XE/XR behavior, RFC specifications, and industry best practices. Human-reviewed for accuracy.

Ditch the vPC Peer-Link: EVPN ESI Multi-Homing on Nexus 9000 with NX-OS 10.6.x (Config + Verification)

FirstPassLab — Wed, 01 Apr 2026 16:56:45 +0000

If you've ever wished you could multi-home a server to more than two leaf switches in your VXLAN EVPN fabric — or eliminate the vPC peer-link entirely — EVPN ESI multi-homing on NX-OS 10.6.x is the answer. It replaces Cisco's proprietary vPC control plane with standards-based BGP EVPN Type-1 and Type-4 routes, enabling multi-vendor interoperability and scaling beyond the traditional two-node limit.

This article walks through the architecture, a production-grade NX-OS configuration, and every verification command you need to confirm it's working.

Why ESI Multi-Homing Matters

vPC has served data center engineers well for over a decade. You pair two Nexus leaf switches, configure a vPC domain, and dual-home your servers. It works — but with well-known limitations:

Two-node limit: vPC is strictly a two-switch technology. You cannot multi-home a server to three or four leaf switches.
Peer-link dependency: The vPC peer-link must carry orphan traffic and synchronize MAC/ARP tables, adding complexity and consuming bandwidth.
Proprietary control plane: vPC uses a Cisco-specific mechanism (CFS over peer-keepalive and peer-link), which breaks multi-vendor interoperability.

EVPN multi-homing with ESI solves all three by moving the multi-homing intelligence into the EVPN control plane itself. Instead of a proprietary peer-link protocol, the leaf switches use BGP EVPN Type-1 (Ethernet Auto-Discovery) and Type-4 (Ethernet Segment) routes to coordinate forwarding, elect a Designated Forwarder (DF), and ensure loop-free traffic delivery.

Note: ESI multi-homing and vPC can coexist in the same NX-OS 10.6.x fabric. You can migrate incrementally — keep vPC for existing server connections and deploy ESI for new racks.

Core Concepts

Before diving into configuration, understand four key mechanisms:

Ethernet Segment Identifier (ESI)

An ESI is a 10-byte identifier that uniquely represents a multi-homed link bundle (e.g., a LAG connecting a server to two or more leaf switches). Every leaf switch participating in the same Ethernet Segment advertises the same ESI value via BGP EVPN, which is how remote VTEPs learn that multiple paths exist.

NX-OS 10.6.x supports both manually configured ESI values and auto-derived ESI values based on LACP system parameters. The auto-LACP approach eliminates the need to manually coordinate ESI values across leaf pairs.

EVPN Route Types 1 and 4

Type-1 (Ethernet Auto-Discovery per ES): Advertised by each leaf in the Ethernet Segment. Remote VTEPs use these to build a list of all VTEPs behind a given ESI, enabling aliasing (load balancing) and fast convergence on link failure.
Type-4 (Ethernet Segment Route): Used for Designated Forwarder (DF) election. All leaves in the ES exchange Type-4 routes, and a deterministic algorithm selects which leaf forwards BUM traffic per VLAN.

Designated Forwarder Election

When a broadcast or multicast frame arrives at the fabric, only one leaf per Ethernet Segment should forward it to the locally connected host. The DF election process ensures exactly one forwarder per VLAN per ES. NX-OS 10.6.x supports preference-based DF election.

Split Horizon and Aliasing

Split horizon prevents BUM traffic received from an ES member from being forwarded back to the same ES.
Aliasing allows remote VTEPs to load-balance unicast traffic across all leaves in an ES, even if the MAC was only learned on one of them.

Configuration: ESI Multi-Homing on NX-OS 10.6.x

We assume the underlay (OSPF or eBGP), NVE interface, and BGP EVPN overlay are already in place.

Step 1: Enable EVPN ESI Multi-Homing

! Enable EVPN ESI multi-homing globally
nv overlay evpn
feature nv overlay
feature bgp
feature interface-vlan
feature vn-segment-vlan-based

evpn esi multihoming
  ethernet-segment 1
    identifier auto lacp
    designated-forwarder election type preference
      preference 32767
    route-target auto

! Associate the Ethernet Segment with a port-channel
interface port-channel10
  description ESI-to-Server-Rack1
  switchport
  switchport mode trunk
  switchport trunk allowed vlan 100,200
  ethernet-segment 1
  no shutdown

This tells NX-OS to automatically derive the ESI from the LACP system ID and port-channel key. The preference 32767 sets this leaf as the preferred DF. On the partner leaf, configure the same Ethernet Segment with a lower preference (e.g., preference 16384).

Step 2: VXLAN Fabric Integration

Map VLANs to VNIs and configure anycast gateways:

vlan 100
  vn-segment 10100
vlan 200
  vn-segment 10200

fabric forwarding anycast-gateway-mac 0001.0001.0001

interface Vlan100
  no shutdown
  vrf member TENANT-1
  ip address 10.100.0.1/24
  fabric forwarding mode anycast-gateway

interface Vlan200
  no shutdown
  vrf member TENANT-1
  ip address 10.200.0.1/24
  fabric forwarding mode anycast-gateway

interface nve1
  no shutdown
  host-reachability protocol bgp
  source-interface loopback1
  member vni 10100
    ingress-replication protocol bgp
  member vni 10200
    ingress-replication protocol bgp
  member vni 50001 associate-vrf

Step 3: BGP EVPN Overlay for ESI Routes

The BGP EVPN session to spine route reflectors carries Type-1 and Type-4 routes. Verify that extended communities are enabled:

router bgp 65001
  router-id 10.255.0.1
  neighbor 10.255.0.100
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community extended
      send-community both
  neighbor 10.255.0.101
    remote-as 65001
    update-source loopback0
    address-family l2vpn evpn
      send-community extended
      send-community both

evpn
  vni 10100 l2
    rd auto
    route-target import auto
    route-target export auto
  vni 10200 l2
    rd auto
    route-target import auto
    route-target export auto

Verification and Troubleshooting

Verify Ethernet Segment Status

Leaf-1# show evpn esi
ESI: 0000.0000.0001.0001.0001
  Status: Up
  Interface: port-channel10
  DF election: Preference
  DF preference: 32767
  DF status: DF (elected)
  Peers:
    10.255.0.2 (preference 16384) - Non-DF

Confirms Leaf-1 is elected as the Designated Forwarder. The partner leaf at 10.255.0.2 shows as Non-DF.

Verify BGP EVPN Type-1 and Type-4 Routes

Leaf-1# show bgp l2vpn evpn route-type 1
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.0.1:3
*>l[1]:[0000.0000.0001.0001.0001]:[0]/120
      10.255.0.1           100      0 i
*>i[1]:[0000.0000.0001.0001.0001]:[0]/120
      10.255.0.2           100      0 i

Leaf-1# show bgp l2vpn evpn route-type 4
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.0.1:3
*>l[4]:[0000.0000.0001.0001.0001]:[10.255.0.1]/184
      10.255.0.1           100      0 i
*>i[4]:[0000.0000.0001.0001.0001]:[10.255.0.2]/184
      10.255.0.2           100      0 i

Both local (*>l) and remote (*>i) Type-1 and Type-4 routes should appear with matching ESI values.

Verify Aliasing on Remote Leaves

Remote-Leaf# show l2route evpn mac all | include 10100
Topology ID  Mac Address    Prod  Next Hop(s)
10100        aabb.cc00.0100 BGP   10.255.0.1, 10.255.0.2

Two next-hop addresses confirms aliasing is working — unicast traffic gets load-balanced across both ESI member leaves.

Common Troubleshooting Scenarios

DF election not converging:

Check that both leaves have the same ESI configured (show evpn esi)
Verify Type-4 routes are being exchanged (show bgp l2vpn evpn route-type 4)
Confirm LACP is operational on both ends (show port-channel summary)

Duplicate BUM frames on the host:

DF election has failed and both leaves are forwarding BUM traffic
Verify designated-forwarder election type preference is configured consistently
Check for Type-4 route filtering on the spine route reflectors

MAC flapping on remote leaves:

Usually caused by an ESI mismatch — one leaf has the ESI configured while the other does not
Verify with show evpn esi on both leaves and ensure ESI values are identical

ESI vs. vPC: When to Use Each

Criteria	vPC	ESI Multi-Homing
Max leaf switches per group	2	2+ (standards allow more)
Control plane	Proprietary (CFS)	BGP EVPN (RFC 7432)
Multi-vendor support	No	Yes
Peer-link required	Yes	No
Maturity on NX-OS	10+ years	NX-OS 10.6.x (new)
Incremental migration	N/A	Can coexist with vPC

For greenfield deployments on NX-OS 10.6.x, ESI multi-homing is the forward-looking choice. For brownfield environments with existing vPC domains, the coexistence capability lets you adopt ESI at your own pace.

Key Takeaways

EVPN ESI multi-homing replaces the proprietary vPC peer-link with standards-based BGP EVPN Type-1 and Type-4 routes, enabling multi-vendor interop and scaling beyond two-node pairs.
NX-OS 10.6.x supports both auto-LACP ESI derivation and manual ESI, with preference-based DF election for deterministic forwarding.
Aliasing ensures remote VTEPs load-balance across all ESI member leaves.
Coexistence with vPC makes incremental migration practical.
Key verification commands: show evpn esi, show bgp l2vpn evpn route-type 1, and show l2route evpn mac all.

Originally published at firstpasslab.com.

This article was adapted from original content with AI assistance. The technical configurations and verification outputs are based on NX-OS 10.6.x documentation and lab testing.

Volt Typhoon Weaponized SOHO Routers at Scale — Here's Your Zero-Trust Playbook for the Remote Edge

FirstPassLab — Tue, 31 Mar 2026 22:54:04 +0000

The FCC just banned all new foreign-made consumer routers from US sale (effective March 23, 2026), but here's what most coverage misses: the ban doesn't fix the actual problem. Millions of unpatched SOHO routers already deployed in your remote workers' homes are the real attack surface — and three Chinese state-sponsored campaigns (Volt Typhoon, Flax Typhoon, Salt Typhoon) have been weaponizing them for years.

This post breaks down the technical reality behind the ban, why it might actually increase the US attack surface, and — most importantly — a concrete zero-trust playbook for removing the home router from your enterprise trust chain entirely.

What the FCC Actually Banned

The FCC's Public Safety Bureau issued DA 26-278 on March 20, 2026. The order adds every consumer-grade router manufactured outside the US to the FCC's Covered List. New models can't get the FCC ID required for legal sale.

Date	Action
March 23, 2026	FCC ceases all new equipment authorizations for covered foreign-made routers
September 2026	Retailers prohibited from importing new inventory of covered devices
March 2027	Maintenance Waiver expires — security patches from covered jurisdictions require federal audit

The ban does not affect: routers already purchased, previously authorized models, or enterprise/carrier-grade equipment.

Here's the supply chain math that matters: China and Taiwan manufacture 60–75% of all consumer routers globally. The US produces ~10%. Supply disruption isn't hypothetical — it's arithmetic.

The Typhoon Campaigns: How SOHO Routers Became Attack Infrastructure

The FCC explicitly cited three Chinese state-sponsored campaigns as justification. Each exploited SOHO routers differently:

Campaign	Technique	Enterprise Impact
Volt Typhoon	Hijacked end-of-life SOHO routers as proxy infrastructure; targeted power grids, water systems	VPN tunnels from compromised home routers provided direct pivot into enterprise networks
Flax Typhoon	Built Raptor Train botnet from compromised IoT/SOHO devices	Mass credential harvesting through residential IP addresses
Salt Typhoon	Embedded in telecom networks using compromised routers as persistent footholds	Long-term access to communications infrastructure; lateral movement across operator networks
CovertNetwork-1658	Password spraying via thousands of compromised SOHO routers	Evasive attack infrastructure rotating residential IPs to bypass detection

The CISA/NSA Joint Advisory documented that US-based processor architectures were involved in over 90% of the compromises. Vendors like Cisco, Juniper, Netgear, and Fortinet were all exploited. Geographic origin was secondary to the actual attack vector: unpatched firmware, default credentials, and exposed management interfaces.

The Paradox: This Ban Might Increase Your Attack Surface

Here's the part that should concern every security engineer. Analysis from the Internet Governance Project at Georgia Tech argues that banning the newest, most secure Wi-Fi 7/8 routers from dominant manufacturers forces consumers to either pay substantially more for US-made alternatives or — more likely — keep their older, more vulnerable devices longer.

Compare the security posture across router generations:

Feature	Modern Wi-Fi 7	Wi-Fi 6	Legacy Wi-Fi 5 and older
Encryption	WPA3 mandatory	WPA3 supported	WPA2 only (KRACK-vulnerable)
Firmware Updates	Active auto-updates	Active with manual check	End-of-life — no patches
Hardware Security	Secure Boot + TPM	Firmware signing	Minimal or none
Management Exposure	Cloud-managed, no open ports	Mixed	Often exposes UPnP, Telnet, HTTP admin

The enterprise takeaway: regardless of what the FCC does about new hardware, your security posture cannot depend on the home router. Treat every remote edge as hostile.

Zero-Trust Playbook: Remove the Home Router from Your Trust Chain

1. Deploy ISE Posture Assessment for All Remote Access

Evaluate the endpoint before granting network access — not the router. Configure posture policies that check OS patch level, endpoint protection status, disk encryption, and host-based firewall state.

# Authorization Policy (simplified)
Rule: Remote_VPN_Posture
  Condition: Network Device Group == VPNs AND Posture_Status == NonCompliant
  Result: Redirect to Client Provisioning Portal (ACL: POSTURE_REDIRECT)

Rule: Remote_VPN_Compliant
  Condition: Network Device Group == VPNs AND Posture_Status == Compliant
  Result: PermitAccess (dACL: FULL_ACCESS)

Posture decisions are binary: compliant or non-compliant. Non-compliant endpoints get remediation instructions, not network access. This removes the SOHO router from the trust equation entirely.

2. Migrate from Traditional VPN to ZTNA

Traditional site-to-site and remote-access VPN architectures implicitly trust the network path, including the home router. ZTNA flips the model: authenticate the user and device per-session, directly to the application, with no reliance on the underlying network.

Architecture	Trust Model	Home Router Dependency
Traditional RA-VPN	Trusts the tunnel endpoint (includes home network path)	High — router compromise can intercept or manipulate tunnel
Split-tunnel VPN	Trusts partial path; internet traffic exits locally	Medium — local traffic is fully exposed
ZTNA	Zero trust — per-session, per-app authentication	None — connection is user-to-app, router is irrelevant

3. Enforce SWG and DNS Security on Every Endpoint

Even with ZTNA, remote endpoints still generate DNS queries and web traffic that traverse the home router. Deploy a Secure Web Gateway and DNS-layer security (like Cisco Umbrella or Cloudflare Gateway) on every managed endpoint:

DNS queries route to secure resolvers regardless of DHCP-assigned DNS from the home router
Web traffic inspection occurs at the cloud proxy, not the SOHO device
Intelligent proxy decrypts and inspects suspicious HTTPS connections

4. Segment Remote Access with Micro-Zones

Don't grant flat network access to VPN users. Use Security Group Tags (SGTs) or dynamic ACLs to segment remote workers into micro-zones based on role, device posture, and application requirements. A compromised remote endpoint should never have Layer 3 reachability to your DC management plane.

5. Monitor for Residential IP Anomalies

The CovertNetwork-1658 campaign used thousands of compromised residential IPs for password spraying. Your SOC should:

Flag authentication attempts from residential ISP ranges that don't match known employee locations
Correlate VPN login geolocation with HR employee records
Alert on unexpected residential IP blocks, especially from broadband providers in regions where you have no employees

The March 2027 Firmware Cliff

The FCC's Maintenance Waiver expires in March 2027. After that date, security patches for foreign-made legacy devices originating from covered jurisdictions may require a secondary federal audit. Millions of currently-deployed routers could effectively become permanently unpatched.

For security teams, this creates a hard deadline:

Accelerate ZTNA migration — remove the home router from the trust chain before the firmware cliff hits
Deploy managed CPE — issue corporate-managed access points or routers to critical remote workers
Enforce endpoint-only security — ensure every security function (firewall, DNS, VPN, posture) runs on the managed endpoint, not the SOHO device

Supply Chain Reality Check

Vendor	Manufacturing Base	Ban Impact
TP-Link	China (Shenzhen)	Directly affected — no new consumer model authorizations
Netgear	Contract manufacturing in China, Vietnam	Affected unless production shifts
Linksys	China, Vietnam	Affected for China-manufactured models
Starlink	Texas, USA	Exempt — manufactured domestically
Juniper/HPE	Flextronics (China, Canada, Mexico)	Partially affected; pursuing Conditional Approval

As Greyhound Research chief analyst Sanchit Vir Gogia put it: "This is about control, not just compromise. Routers sit at the network edge, but functionally they are part of the control plane of the enterprise."

TL;DR

The FCC banned all new foreign-made consumer routers (March 23, 2026)
The Typhoon campaigns weaponized SOHO routers to infiltrate US critical infrastructure at scale
The ban might actually make things worse by slowing router upgrade cycles
Your fix isn't a different router — it's removing the router from your trust chain entirely
Deploy ISE posture + ZTNA + SWG + micro-segmentation + residential IP monitoring
March 2027 firmware cliff makes this urgent

Originally published on FirstPassLab. More deep dives on network security architecture at firstpasslab.com.

AI Disclosure: This article was adapted from original research with AI assistance for formatting and style optimization. All technical content, data points, and cited sources have been verified against their original publications.

Equinix's 280-DC AI Fabric Just Changed the DCI Game — Here's the Architecture Under the Hood

FirstPassLab — Tue, 31 Mar 2026 16:55:05 +0000

Equinix launched the Distributed AI Hub on March 11, 2026 — spanning 280 data centers across 77 markets. Powered by Fabric Intelligence, it automates connectivity, routing, and security policy enforcement for distributed AI workloads. For network engineers, this is the clearest signal yet that manual DCI provisioning is being replaced by intent-based orchestration.

Let's break down the architecture.

The Three-Component Stack

Component	Function	Network Impact
AI-Ready Backbone	High-bandwidth transport fabric	400 Gbps physical ports, 100 Gbps virtual connections
Fabric Intelligence	Software-defined orchestration	Real-time telemetry, automated routing, policy enforcement
AI Solutions Lab	Architecture validation across 20 locations	Pre-deployment testing for DCI and AI topologies

For engineers working with VXLAN EVPN multi-site DCI, this is a familiar pattern scaled to an unprecedented level. Equinix is abstracting the underlay complexity into a managed service — the engineering challenge shifts from building the fabric to integrating with it.

How Fabric Intelligence Changes DCI Operations

Fabric Intelligence is a software layer on top of Equinix Fabric with real-time awareness, AI-driven automation, and policy enforcement for next-gen AI workloads. Here's what it means in practical terms:

Real-time telemetry and observability. Live telemetry feeds across the entire Fabric mesh. For engineers accustomed to polling SNMP counters or scraping streaming telemetry from individual routers, this is centralized, cross-domain observability across dozens of metro areas — the kind of visibility that traditionally required building a custom network digital twin.

Automated routing and segmentation. Rather than manually configuring BGP peering sessions or adjusting ECMP weights, Fabric Intelligence dynamically adjusts routing based on workload requirements. This is intent-based networking applied to the interconnection layer — define performance and security requirements, the platform handles path selection.

Policy enforcement at scale. Palo Alto Networks Prisma AIRS is embedded directly in the Hub. Security policies enforced at the infrastructure layer from day one. No more bolt-on security where firewall rules lag behind connectivity changes.

According to Equinix CBO Jon Lin, Q4 2025 saw over 4,500 deals closed in a single quarter, with ~60% of the largest deals driven by AI workloads. That volume can't be served by manual provisioning.

The APAC Demand Problem

Asia-Pacific added 1,557 MW of new DC capacity in 2025, bringing the total to 13,763 MW — yet vacancy rates shrank from 12.4% to 10.9% (Cushman & Wakefield, H2 2025). Record construction couldn't keep pace with AI demand.

Metric	Value
Total APAC DC capacity (2025)	13,763 MW
New capacity added	1,557 MW
Vacancy rate	10.9% (down from 12.4%)
Development pipeline	19.37 GW
Bangkok forecast growth (2026-2030)	10.3x
Jakarta forecast growth (2026-2030)	4.4x

Investment highlights: CapitaLand committed US$874M (Singapore + Osaka), Nvidia-backed Reflection AI announced $6.7B in South Korea, AirTrunk secured Japan's largest-ever DC financing at $1.2B.

For network engineers, these emerging Southeast Asian markets mean greenfield DCI designs with less legacy — but less mature peering ecosystems and higher latency challenges.

Architecture Deep Dive: Three Planes

Transport Plane: 400G-Ready Backbone

400 Gbps physical ports with QSFP-DD and OSFP transceiver support, plus 100 Gbps Fabric virtual connections. This is the WAN/metro DCI equivalent of what NVIDIA Spectrum-X does within a single AI cluster.

Control Plane: Fabric Intelligence Orchestration

The orchestration layer integrates with AI workload schedulers and cloud providers. When a Kubernetes cluster in Tokyo needs training data staged in Singapore, Fabric Intelligence handles virtual connection provisioning, QoS attachment, and route optimization — tasks that would traditionally require configuring BGP communities, adjusting DSCP markings, and verifying end-to-end latency manually.

Security Plane: Prisma AIRS at the Edge

Prisma AIRS runs locally on Equinix Network Edge — AI-powered threat detection without backhauling to a centralized security stack. For distributed AI inference where microseconds matter, inline security at the interconnection point eliminates the hairpinning latency penalty.

Skills That Matter Now

Based on the technical requirements in the Equinix architecture and APAC buildout:

400G transport and optics — QSFP-DD, OSFP, ZR/ZR+, FEC options, fiber capacity planning. The market is moving toward 800G coherent for metro DCI.

EVPN-VXLAN multi-site DCI — Even though Equinix abstracts the underlay, enterprises connecting their own fabrics still need EVPN Type-5 routes, multi-site BGW peering, and VNI-to-VRF mappings.

AI traffic engineering — AI inference workloads are bursty and latency-sensitive, often requiring RoCEv2 semantics across DCI links. DSCP marking for AI traffic classes, ECN configuration, PFC tuning.

Multi-cloud overlay architecture — The Hub connects to AWS, Azure, GCP, and dozens of smaller clouds. Designing overlays that span Transit Gateway, Azure vWAN, and GCP NCC alongside Equinix Fabric.

Intent-based networking and automation — Fabric Intelligence is IBN for the DCI layer. Engineers who can write NETCONF/RESTCONF calls for Equinix Fabric or build Terraform modules for multi-cloud overlays will have a distinct advantage.

The Career Shift

Traditional DCI Role	Emerging Distributed AI Role
Manual cross-connect provisioning	API-driven fabric orchestration
Static BGP peering configuration	Intent-based routing automation
Bolt-on firewall insertion	Embedded security policy
Per-link capacity planning	AI workload-aware traffic engineering
Single-metro DCI design	Multi-region, multi-cloud overlay architecture

Continental AG deployed NVIDIA GPU clusters and IBM storage inside Equinix to support ADAS AI workloads — achieving 14x increase in AI experiments. The engineering work was designing the interconnection topology for distributed GPU clusters with consistent latency, not rack-and-stack.

The operating model is shifting from CLI-driven config to API-driven orchestration. The foundational protocols (EVPN, BGP, VXLAN, QoS) don't change — the interface does.

TL;DR

Equinix launched the largest AI-ready DCI fabric: 280 DCs, 77 markets, Fabric Intelligence orchestration
APAC DC vacancy is shrinking despite record construction — AI demand outpaces everything
The architecture has three planes: 400G transport, intent-based control, inline Prisma AIRS security
Skills to prioritize: 400G optics, EVPN-VXLAN DCI, AI traffic engineering, multi-cloud overlays, automation
The career shift: manual provisioning → API-driven orchestration

Originally published at FirstPassLab.

Disclosure: This article was adapted from the original blog post with AI assistance. Technical content has been reviewed for accuracy.