Wait, Do We Still Need Network Engineers? And a Little SRv6

Fact number one: I wanted to write a small note about SRv6. Not even about SRv6 as a protocol, really, but about the road the industry travelled from plain old LDP to a world where an IPv6 address can be both a destination and an instruction.

Disclaimer #1

Before going any further, open Two Labels, One SRH, and One Very Annoying rp_filter and skim it for five minutes. That article is the polished technical result I originally wanted.

The article you are reading now is about how that result was produced — and about the increasingly awkward question of who, exactly, did the producing.

Fact number two: while scrolling through LinkedIn — the world’s best-organised vanity fair — I noticed that every second person had acquired an AI prefix.

And then there was my favourite:

An AI influencer. Magnificent. Apparently I also needed to write something about AI — or have AI do something, then write about the fact that it had done it.

Disclaimer #2

This article contains a frankly unreasonable amount of text, and most of the material inside the expandable sections was generated by AI.

There are three ways to read it:

1. Open the “AI reasoning” sections if you care about how an agent approached a long, stateful infrastructure task.
2. Open the “lab note” sections if you want a practical learning path from Linux IP forwarding through OSPF, LDP, L3VPN, TE, SR-MPLS, SR Policy, and SRv6.
3. Ignore every expandable section and read only my commentary. That version is mostly about humans, robots, and the dangerous possibility that the boundary between them is now a formatting choice.

The Lab I Was Too Lazy to Configure

I built the following topology in my beloved PNETLab:

There are two provider edges, four core routers, and four customer machines. RED and BLUE are separate tenants. The intended story is familiar: deliver traffic inside each customer network, keep the customers isolated, and evolve the transport mechanism one layer at a time.

The problem was that I did not feel like configuring any of it.

So the AI could do it.

My Real Problem with AI

My biggest problem with AI was never that the tools were weak. It was that there were too many of them.

For a long time I behaved like Buridan’s donkey: I sat between twenty impressive products, chose none of them, and quietly used free DeepSeek because it was already open in a browser tab. Eventually I decided that a ChatGPT subscription cost less than a respectable evening of pizza and crossed into a new plane of existence.

Chat was useful. Suspiciously useful. I could feel my productivity expanding in real time.

But there was also Codex.

Several freshly minted AI people told me the same thing: try it once and you will not want to work without it. This sounded less like a product recommendation and more like the opening scene of a public-health documentary, but I tried it.

They were not entirely wrong.

The uncomfortable part is that working with an agent is work. You spend time describing what you want, constructing a harness, limiting destructive freedom, deciding what counts as evidence, and teaching the agent not to celebrate too early. Sometimes that takes longer than doing the first version yourself.

The promise is not “zero effort”. The promise is leverage.

Building a Primitive Network Agent

I am a Windows person, so I opened the desktop app and created a project.

The project got a local working folder. That folder would contain inventory, credentials, diagrams, notes, scripts, and whatever code the agent created while solving the task.

Then I wrote an AGENTS.md file. Not because I had suddenly become an elite AI builder, but because an artificial intelligence is still artificial. If you do not describe its job, boundaries, and definition of “done”, it will invent all three with great confidence.

Naturally, I wrote all of that myself. Obviously.

Then I spoke to the thing.

It was alive. Or at least it had read the file and had started using phrases such as “network engineer-researcher”, which is close enough.

I gave it a trick question.

Good answer. There was no inventory, so it did not scan random addresses or hallucinate an SSH alias. It inspected the project, explained the missing evidence, and stopped.

The desktop interface separated reasoning, commands, and final answer:

Then I added a very human-readable inventory and a credentials file. No grand automation schema, just names and management IPv6 addresses. I asked whether that was enough.

Codex connected to all ten hosts and reported an almost perfectly blank lab: management IPv6 worked, data interfaces were down and unnumbered, forwarding was disabled, FRR was absent, and MPLS kernel state was not yet present. It also found a typo in my inventory: one machine described as PE-2-Left identified itself as PE-2-Right.

That was a small but important moment. The inventory enabled access; observation corrected the inventory.

First, Make a Diagram. Then Discover Why It Is Wrong

I asked Codex to draw the topology.

It generated editable Draw.io XML. Codex is, after all, a coding agent; XML is code wearing business-casual clothes.

The first diagram showed only what was known: management reachability, hosts, and unknown data ports.

It was honest. It was also useless to anyone who wanted to understand the forwarding path.

So I gave feedback: bring up the data interfaces, run LLDP, discover both ends of every link, label ports, use recognisable network icons, and remove the management clutter.

Twelve minutes later:

I compared the result with my original drawing and thought it had lost the link between P-1 and P-3. A manual LLDP check showed the neighbour. The line had merely merged visually with two other links.

In other words, the robot was right and the senior engineer was defeated by line geometry.

I gave it an old diagram as a style reference:

It produced a more recognisable network map, I asked for one final correction, and then the senior engineer made his essential contribution: moving a few objects by hand.

This, as every architect knows, is what seniority looks like.

A Plan Appears

Before configuring anything, I asked the agent to remind me what we were actually doing.

Its plan and mine had the same shape:

IPv4 → OSPF → LDP → L3VPN → TE → SR-MPLS → SR Policy → SRv6

That sequence matters. A long-running agent becomes dramatically more useful when the problem is not “configure SRv6” but “build a chain of independently proven states, and do not advance when one link is imaginary”.

Stage 1 — The IPv4 Foundation

My instruction was intentionally broad: execute the plan in large stages and leave a separate educational note after each one.

Codex allocated one /31 per verified point-to-point link from 10.10.0.0/27, preserved ens3 for management, enabled IPv4 forwarding only on routers, and saved the configuration without casually bouncing the management interface.

Stage 2 — OSPF: Give the Core a Memory

I asked what stage two meant.

FRR was not installed. The agent installed it on six routers, created stable /32 loopbacks from 10.255.0.1 through 10.255.0.6, enabled OSPFv2 only on core links, and kept the customer-facing interfaces passive.

O>* 10.255.0.6/32 [110/3] via 10.10.0.1, ens4
  *                       via 10.10.0.3, ens5

ip route get 10.255.0.6 from 10.255.0.1
ping -I 10.255.0.1 -c 4 10.255.0.6

Stage 3 — MPLS and LDP

I asked the most sophisticated architectural question available to me:

MPLS forwarding was enabled only on core-facing interfaces. LDP sessions used the stable loopbacks, and the agent inspected the LIB and LFIB for push, swap, and implicit-null behaviour.

The stage took longer than expected. I asked why.

One SSH command had used a template IPv6 prefix instead of the exact management address in the inventory. Then a packet capture waited for traffic that had already been sent and sat there with the quiet confidence of a command that will never return.

I asked for a solemn promise.

ethertype MPLS unicast (0x8847)
MPLS (label 22, tc 0, [S], ttl 64)
10.255.0.1 > 10.255.0.6: ICMP echo request

Stage 4 — Two Customers, One Core, No Accidental Friendship

The next layer was MPLS L3VPN.

The agent created RED and BLUE VRFs on both PEs, assigned customer-facing interfaces, established MP-BGP VPNv4 between the PE loopbacks, used distinct RDs and matching route targets, and kept the services out of the provider IGP.

At one point the interface reported that it had read Lab_Inventory and Lab_Creds, which was reassuring after the previous creative IPv6 address.

I also noticed an odd transport trick: Codex encoded Netplan YAML as base64, sent it through SSH, and decoded it on the host. It looked alarming for approximately four seconds, after which it looked like a perfectly practical way to stop three layers of quoting from eating indentation.

Stage 5 — Traffic Engineering, With the Marketing Removed

Shortest-path routing is excellent until the shortest path is not the path you want. I asked Codex to add a Traffic Engineering chapter and explain what practical problem it solved.

OSPF TE advertisements could describe bandwidth and link attributes and populate a Traffic Engineering Database. But our FRR version did not provide a complete RSVP-TE signaling and reservation plane.

Codex refused to call the result “working RSVP-TE”. This is one of the reasons the experiment was useful.

Stage 6 — SR-MPLS: Labels Become Instructions

I asked whether Segment Routing was next, and why it mattered when Traffic Engineering already existed.

Codex created a diagram without being asked. I have preserved the punctuation and, more importantly, corrected the labels.

SR-MPLS kept the existing MPLS forwarding plane but replaced per-tunnel signaling in the core with segment instructions chosen at the ingress. Node SIDs represented routers; a stack of SIDs represented a path.

During this stage the safety review paused a change to rp_filter.

This was funny because root access and a small mountain of configuration had not upset it. Reverse-path filtering, however, apparently looked like the moment the hackers would finally enter my educational lab.

Stage 7 — The Step the Agent Forgot: SR Policy

After several hours of editing I had forgotten where we were, so I asked Codex for the next logical step.

Something felt missing. Its earlier note had mentioned SR Policy.

The agent admitted the mistake. We first built an explicit SR Policy over the existing SR-MPLS domain and steered RED through it while BLUE remained on ordinary LDP.

Stage 8 — SRv6, and the Value of an Honest Failure

Now we could finally make the obvious request.

I left the laptop and went for a walk in the woods. Intuition suggested that this would not be a four-minute stage.

Codex spent forty-four minutes building a parallel IPv6 underlay, checking kernel and FRR capabilities, installing SID behaviour, and trying to move RED. Then it stopped without a clean final answer. Maybe the usage window ended. Maybe the robot also went to the woods.

I asked it to continue.

Thirty-two minutes later it produced an honest diagram:

The IPv6 underlay worked. An IPv4 RED packet was encapsulated with IPv6 and an SRH. A core capture saw that packet reach PE-2. The local SID matched. But after End.DT4 decapsulation, the packet did not leave through the RED VRF.

That is not a working SRv6 L3VPN.

It is also much more useful than a screenshot of a green route table followed by a claim that everything is fine.

Stage 9 — One More Stage Will Not Kill Us

Naturally, “almost works” was not a satisfying ending.

Codex built a miniature SRv6 lab inside network namespaces on one PE. That isolated Linux kernel behaviour from FRR, OSPF, BGP, and the accumulated history of the big topology. The upstream-style test passed, proving that the kernel could execute End.DT4.

The difference was reverse-path filtering.

After decapsulation, Linux validated the source address from the core context. That source was reachable only through the RED VRF. Strict RPF rejected the packet before the forwarding path had a chance to look correct.

Correcting rp_filter on the relevant data and VRF interfaces made the final hop work in both directions.

The Managerial Question

At the end I asked the agent for a postmortem.

Its answer was better than “all tasks completed successfully”. The topology had been reconstructed from evidence; each layer depended on a proven previous layer; control-plane claims were backed by forwarding evidence; and the End.DT4 failure had not been hidden.

The hard problems were at the boundary between three systems that were each individually reasonable: the Linux kernel, VRF and policy routing, and FRR. A configuration could look correct in FRR, ip route get could select the SID, the packet could reach the PE — and the service could still fail after decapsulation.

State drift was the second class of failure. Netplan, manual commands, systemd units, and FRR all had opinions. If two of them owned the same fact, the lab could regress for reasons unrelated to the technology currently under investigation.

With hindsight, the agent would have done five things earlier:

1. Define one reproducible owner for every piece of state.
2. Run a minimal upstream-compatible End.DT4 test before debugging the full topology.
3. Record a version-and-capability matrix for kernel, FRR, iproute2, and daemons.
4. Design RED as the migrating service and BLUE as the control service from the start.
5. Resolve every management address from inventory instead of trusting a remembered prefix.

That is a credible engineering retrospective. It includes the robot’s own mistakes, which is more than can be said for some human retrospectives I have attended.

What Should a Fashionable Technical Blogger Do With All This?

If my only goal had been to publish a polished technical article, I could have opened a fresh chat in the same project and written one final prompt.

The result is the shorter English article. It explains the network evolution cleanly, uses the evidence gathered during the lab, and does not force the reader to watch an AI argue with rp_filter for an hour.

This article exists because that polished result hides the more interesting mechanism: the agent did not merely compose prose. It inspected a live lab, wrote scripts, changed ten machines, generated diagrams, maintained a staged plan, hit platform limitations, made mistakes, accepted corrections, created controlled experiments, and revised its own claims when the packet evidence disagreed.

GPT-5.6 Terra was the model behind that job. OpenAI describes it as the balanced GPT-5.6 model for everyday work. I did not use the newer GPT-6 Astra, and I did not need the strongest possible model to make the point.

The harness mattered at least as much as the model name.

Conclusions

1. Network engineers are no longer needed.

2. There is no point writing educational networking articles. A neural network can write them, build the lab, and produce the diagrams while you go to the woods.

3. This is slightly terrifying. I imagine the late eighteenth century also had people insisting that steam engines were just autocomplete for horses.

4. It is also exhilarating. LLMs are a multiplier: good judgment becomes more productive, and bad judgment reaches the wrong answer at industrial speed.

The first two conclusions are jokes. Mostly.

The serious conclusion is that the valuable part of network engineering is moving upward. Typing configuration was never the whole profession; it was merely the visible part. In this experiment the human contribution was choosing the learning sequence, defining safety boundaries, refusing a fake RSVP-TE result, catching a skipped SR Policy stage, demanding packet-level proof, and deciding that “the SRH reached PE-2” was not equivalent to “the VPN works”.

Codex supplied endurance, execution speed, breadth, and an almost worrying willingness to keep trying. I supplied intent, taste, suspicion, and the right to say “no, one more stage”.

That is not a clean division of labour. It is already blurry, and it will become blurrier.

But if the future network engineer is the person who specifies invariants, builds evidence loops, and supervises autonomous changes across real systems, then the profession is not disappearing.

It is becoming less about remembering commands and more about knowing what must be true when the commands are finished.