In the cloud era, someone recently asked me why I still list CCIE in my professional signature. The answer isn't nostalgia: it's that when AWS goes down, when an Azure migration gets stuck, when an IPsec VPN between two sites won't come up, the only engineer who shows up and fixes it is the one who learned at twenty-two how to negotiate an OSPF adjacency across a broken Frame Relay interface. In this article I'll tell you three real stories and why the CCIE still matters in 2026.
I got started with networks at twenty. I got my CCNA the first year, CCNP the second, and CCIE on my fourth attempt after a year and a half of home lab with twenty second-hand routers in the garage. The CCIE of that era — the R&S before the cloud era — was an eight-hour practical exam in a real lab where you were given an impossible network design and had to make it work without official documentation. First-attempt pass rate was around 4%. The exam is different today but the spirit is the same: it's not about knowing how to configure, it's about understanding why it works.
What a CCIE really is
Let me explain something that's often misunderstood. A CCIE isn't a course where someone teaches you things. It's an exam at the end of a years-long self-taught process. Nobody tells you what to study. There's an official list of topics — BGP, OSPF, EIGRP, MPLS, VPN, QoS, network security, multicast, IPv6, MPLS-VPN, services, voice — and you have to build a home lab to practise them until you can configure them with your eyes closed. The exam doesn't ask theory. It gives you a concrete scenario and you have to make it work.
The difference with other certifications is that you can't pass the CCIE by memorising. You can memorise the commands and still fail. What passes you is having spent hundreds of hours debugging labs in your garage, having found the weird bugs, having learned to read a four-hundred-line show output and spot the problem in ten seconds. That skill is impossible to fake. That's why the CCIE had — and still has — a particular prestige in the sector.
Today, in 2026, many people say the CCIE is obsolete because "everything is moving to the cloud" and "physical routers are disappearing". Let's look at three concrete cases where that opinion shows a misunderstanding of how modern infrastructure actually works.
Case 1: BGP broken between datacenter and AWS Direct Connect, Saturday afternoon
Mid-sized software company based in Madrid. Hybrid infrastructure: on-prem datacenter in Madrid (databases and legacy systems) and a VPC in AWS Ireland (new microservices). Both environments connected via Direct Connect with BGP running between them. SLA with AWS says 99.9% uptime.
On a Saturday afternoon in August, at 5:30 pm, the Direct Connect link starts dropping packets intermittently. It doesn't go down completely — traffic keeps flowing — but latency jumps from the usual 15 ms to spikes of 400 ms, and some TCP sessions break. The AWS engineers open a support case and give the usual answer: "we don't see problems on our side, check your local equipment". The local equipment is a Cisco ASR 1001-X managed by the company with remote supervision.
The operations director called me at 6:15 pm. He explained the situation. I was in Alicante, the router was in Madrid. Nobody was on-site. I asked for remote access via VPN and console. Five minutes later I was in.
The first thing I looked at wasn't BGP. It was the interface error counters on the uplink port to AWS. The output was revealing: several CRC errors and quite a few input errors that hadn't been there before. Not many — about 200 per minute — but enough to break TCP sessions at high throughput. Immediate hypothesis: something in the physical layer is starting to fail. The problem was that AWS claimed everything was fine on their end.
Then I looked at BGP. The session was "Established" and prefixes were being announced correctly. But while reviewing the BGP counters I saw something strange: the number of "BGP updates received" from AWS was growing much faster than normal. About five times more updates per minute than the historical average. That meant AWS was constantly re-announcing prefixes. Something on their side of the network was causing route flapping.
That's when I understood the pattern. The problem wasn't mine or clearly AWS's — it was a shared physical link between both networks (Direct Connect goes through the local provider's network, in this case a third-party optical transport operator) that was starting to fail at layer 1. The CRC errors I was seeing on my router were a consequence of physical problems upstream. And the massive BGP updates from AWS were their system reacting to the instability of that same link.
I called AWS support. I asked them specifically to check the physical-layer error counters on their side of the Direct Connect. Ten minutes later they confirmed what I was seeing: CRC errors growing. The problem was escalated to the optical operator, who identified a degraded fibre splice in a junction box somewhere between Madrid and Dublin. They fixed it that night.
Total incident: three hours of partial service, no complete outage, and a precise diagnosis that allowed escalating directly to the real cause instead of losing days with support ping-pong. The company paid me an urgent weekend rate. Cheap compared to the cost of eight or twelve hours with the service down.
The question is: could this have been diagnosed without understanding BGP deeply, without knowing how to read interface counter tables, without intuition about what to look for when the provider's support finds nothing? I don't think so. Or at least, not in three hours.
Case 2: intermittent MPLS that nobody could diagnose
Italian multinational with offices in Milan, Rome, Turin and Catania. Between the four sites they had an MPLS VPN contracted with one of Italy's big telcos. The service worked well most of the time, but every few weeks — unpredictable, no obvious pattern — the Catania site would lose connectivity with the other three for fifteen or twenty minutes. It didn't formally disconnect. It just had 30-40% packet loss during that period and then went back to normal.
The Italian operator checked the connection several times. "We don't see any problem on our network". The multinational's techs, who were good but not MPLS-operator specialists, swapped local routers, swapped cables, changed QoS configuration. Nothing. The problem persisted.
They contacted me on a recommendation. I went to Milan, sat down with the network team and asked them for one thing: continuous traffic captures on the four sites' CE routers, recording every ten minutes the error counters, TTL, dropped packets and loss rate. What the Italian operator calls its "private network" is really a piece of shared internet with MPLS routing on top, and when there are backbone problems, the loss shows up asymmetrically.
Two weeks later — when the problem appeared again — the counters I'd set up told the full story. During the incident, packets going from Catania to Milan left with TTL 254 (normal) but arrived in Milan with TTL 242. That meant they went through twelve routers instead of the usual four or five. They'd been rerouted along a longer path, probably because the operator had lost a main MPLS link and their IGP backup was going through a congested path. That congestion wasn't on the normal path, so the operator's techs, who were looking at the links the traffic "should" go through, saw nothing wrong. But the packets were going somewhere else.
With that concrete evidence — anomalous TTL, correlated loss rates, timing coinciding with the operator's internal maintenance windows — I reported the case directly to the operator's NOC with irrefutable data. They admitted the problem. It was a re-routing policy they activated on weekends during maintenance windows that caused that overload. They adjusted the policy. The problem disappeared.
The technical diagnosis here wasn't complicated. It was about knowing what to look at. MPLS packet TTL isn't something a junior operator checks. But for someone who's done MPLS labs for years and understands how networks work underneath, it's the first clue when there's unexplained asymmetric loss.
Case 3: VoIP migration of 450 extensions with zero downtime
Call centre company based in Alicante, 450 employees, IP telephony based on a seven-year-old Cisco Unified Communications Manager infrastructure. The CEO decided to migrate to a modern 3CX-based platform to cut costs. The 3CX vendor offered a turnkey migration, but with the warning of a "necessary cutover window" of 4-6 hours during the night. For a company operating 24 hours serving clients in three time zones, that wasn't acceptable.
They hired me to design a zero-downtime migration. The technical challenge: move 450 extensions from CUCM to 3CX, keeping internal dial numbers, call groups, external routing policies and the ability for any agent to make a call at any moment during the migration.
The plan I designed had four phases:
- Phase 1 — Parallel provisioning: during the week before, I configured the 3CX system with an exact replica of all extensions, groups and policies. Every agent would have a new 3CX account but nobody would use it yet.
- Phase 2 — Dual trunk: I negotiated with the SIP operator a 72-hour period in which the company's external numbers would reach both systems simultaneously. During those 72 hours, both systems would receive calls but only one would answer them according to routing logic I controlled from a small custom edge router (a Raspberry Pi with Asterisk as SIP proxy).
- Phase 3 — Group-based migration: I moved agents in blocks of 20 during the working day without interrupting their service. Each group received their new pre-configured IP phone, the Raspberry Pi detected automatically which group had switched, and from that moment on, calls for those agents were routed to the new 3CX. Agents kept handling calls throughout the process.
- Phase 4 — Old CUCM shutdown: once all groups were migrated (seven days after start), I shut down the old CUCM and redirected all remaining traffic to 3CX. Real downtime window: zero minutes.
The technical trick of the project was the custom SIP proxy, which I wrote myself in Python on a Raspberry Pi 4. That proxy decided in real-time, call by call, which system to send it to based on which range of extensions was migrated at that moment. Hardware cost: €120. Script development time: two days. Value for the client: four hours of downtime avoided during the most sensitive night of the year (fiscal month-end).
The difference between knowing how to configure and understanding why
The three cases above have something in common: the diagnosis or solution wasn't in any manual. There was no official document where to look up "what to do when MPLS TTL drops unexpectedly" or "how to migrate CUCM to 3CX with no downtime". The solution was built by applying fundamental knowledge — how BGP works underneath, how MPLS behaves in real conditions, how SIP sessions negotiate — to a concrete problem.
That's exactly what the CCIE teaches. Not configuration techniques (which change every two years and can be learned on YouTube), but structural intuition. How to read a router's routing table and understand what's going to happen to a specific packet. How to know when OSPF backup is kicking in. How to think about a network end-to-end when you have four different operators in the path.
The cloud doesn't eliminate these problems. It abstracts them a bit, but when something goes wrong, somebody has to understand what's happening in the layer the client doesn't see. That somebody is almost always someone with CCIE-level training or equivalent, because the other people — modern good cloud engineers — tend to have deep knowledge of their specific platform but little visibility into what happens outside it. And the problems that matter in enterprise infrastructure happen between platforms, not inside them.
What will still matter in 2030
If I had to predict which skills will remain relevant in five years in the networking sector, my list would be:
- Understanding fundamental protocols (BGP, OSPF, IPv6, MPLS, TLS) well enough to debug them when they fail, even in cloud environments where they're abstracted.
- Knowing how to read packets. Wireshark is still the most useful tool for a network engineer and it will remain so. People who can interpret a pcap spot problems nobody else spots.
- Understanding the physical layer. When cables and fibre fail, cloud systems don't tell you clearly. Someone has to understand that intermittent packet loss can be a degraded fibre splice.
- Knowing how to program at a low level. Modern network engineers write scripts to automate things. But those who really make the difference know how to write a SIP proxy in Python, or a small Wireshark plugin, or a program that parses BGP logs in real-time. That kind of code isn't learned in a course — it's learned by solving problems.
- Having the patience to read official documentation. RFCs, Cisco technical notes, IEEE specifications. Good engineers read them. Mediocre ones just search on Stack Overflow.
Conclusion
Does the CCIE still matter in 2026? My honest answer is: the title matters less and less (few clients really understand what it means), but the skills the CCIE forces you to develop matter more than ever. In a world where everyone uses cloud platforms that abstract the network, people who can diagnose what's happening underneath that abstraction are increasingly rare and valuable. And when something critical fails — when AWS is down in a zone, when BGP is negotiating strangely, when a telephony migration threatens to stop a call centre — those people are the ones who save the day.
I don't list the CCIE in my signature to show off. I list it because it indicates that at some point I had to learn what's underneath the abstractions. And in my experience, that's a quality signal very few people can fake. If you're about to hire someone for critical infrastructure, or if your network is having problems nobody understands, look for someone who's been through that school — with or without the official certification. A Saturday afternoon can be the difference between three hours of downtime and three days.