In brief

  • Pepelnjak’s public career began with network operations and interconnection in Slovenia, including work on the country’s first internet exchange, rather than with promoting a single vendor’s product.
  • Through ipSpace.net, he built an independent publishing, education and consulting platform whose forceful arguments are most useful when they are not presented as standards consensus.
  • netlab turns a YAML topology into a reproducible multi-vendor lab without pretending that a virtual environment reproduces every ASIC, physical link or accumulated state of a production network.
  • His central contribution is a decision-making method: define data authority, test expected behaviour, expose dependencies and separate configuration generation from the safe management of an existing network.

Version 26.07 shows why the lab matters even though it is not a controller

On 13 July 2026, the netlab project released version 26.07. It expanded support for GRE and WireGuard tunnels, graceful restart, BGP roles and larger-scale labs. Behind the routine change list is an operational model: the user describes the topology and protocols they want to test; the software creates virtual machines or containers, assigns parameters and generates initial configurations for different network operating systems.

The project is not positioned as a universal production orchestrator. That boundary is one of the strongest features of Pepelnjak’s public work. In June 2026, while discussing the configuration of real devices, he explicitly noted that netlab assumes a known topology and generally a clean or laboratory starting state. The tool can prepare configuration fragments, but it does not reconcile the arbitrary history of a production router or guarantee that every local exception will survive when CLI text is replaced.

Such honesty matters more than a long feature list. Producing a plausible configuration for a demonstration is relatively easy. Changing a network containing years of accumulated policies, poorly documented dependencies and divided responsibility is impossible without drift detection, transactional boundaries, reconciliation, rollback and independent verification of the result.

Pepelnjak’s career consistently draws this distinction. He does not own BGP, EVPN or automation itself. He turns architectural claims into models and experiments that another engineer can reproduce or refute.

Slovenia’s early internet provided an operational foundation, not a certification myth

A historical RIPE Labs interview places Pepelnjak in the formative period of Slovenia’s commercial and academic networks. It notes his involvement in creating the country’s first internet exchange and describes connectivity constraints before and after the fall of the Iron Curtain. This is a collective history; it does not validate a story in which one specialist single-handedly built national infrastructure.

In a small market, scarcity, interconnection and improvisation were practical conditions. Engineers could not rely on abundant international capacity, a wide choice of platforms or a large local ecosystem. They had to understand routes, circuits, equipment and institutional relationships well enough to keep services available.

An internet exchange is itself an agreement among networks, facilities and operators. It facilitates direct traffic exchange, but it does not replace each member’s routing policy or transit arrangements. Such experience shows that a technical function becomes infrastructure only when organisations agree on its configuration, operation and responsibility when failures occur.

This helps explain Pepelnjak’s later scepticism towards architectural fashions. A diagram is persuasive not because a vendor has drawn it beautifully, but because its dependencies are visible, operators understand them and the organisation can survive an expected failure.

From consulting to ipSpace.net: independence became an operating model

His public biography describes Pepelnjak as an independent network architect at ipSpace.net and states that he has designed, deployed, taught and written about large networks since 1990. It also lists the qualification CCIE No. 1354 Emeritus. These details come mainly from pages controlled by the author and should be attributed accordingly rather than treated as a verified, complete career register.

Over time, ipSpace.net became the principal institution surrounding his work. The platform publishes articles, webinars, courses, podcasts and books about routing, data centres, cloud and automation. Its long archive makes it possible to compare current judgements with earlier forecasts, corrections and qualifications.

Independence makes it easier to compare several vendors and criticise their designs directly. It does not mean an absence of interests. Paid training, consulting, software images, sponsors and professional relationships create their own economic and technical dependencies. What matters is transparency about their structure, not a claim of neutrality beyond the market.

The site explicitly notes that its articles express the author’s opinion. This is an important qualification: sharp criticism can puncture marketing rhetoric, but it can also generalise from individual cases. The archive should be read as a long-running record of technical judgement, not as an industry vote.

‘Source of truth’ defines authority before storage

Pepelnjak repeatedly returns to the idea of a single source of truth. It can sometimes sound as though buying a data store will eliminate infrastructure inconsistency. His requirement is deeper: inventory, addressing, topology and intended services must be represented in data whose authority is defined before templates or APIs can reliably change the network.

A device configuration is evidence of what the device currently “believes”. It does not necessarily represent the organisation’s intent. Importing an undocumented exception may turn drift into an approved design; ignoring observed state may impose an idealised model on a network that has already changed.

The practical question is who decides. IPAM may be authoritative for address allocation, a customer system for service identity and a controller for part of the forwarding intent. The device remains the source of some operational states. Monitoring observes, but does not create policy by itself.

Before choosing templates, the organisation must answer: who creates a site, who assigns an address, which record identifies the required neighbour, who approves reconciliation and what happens when the model diverges from the equipment. Without those answers, data integration merely hides a dispute about authority.

A YAML topology is a compact theory of the network

In netlab, the user generally starts with a YAML file describing nodes, links, device types and protocol modules. A node name declares a node; a link asserts a connection; adding OSPF, IS-IS, BGP, EVPN or VXLAN creates the expected relationships. Address pools and default values turn an abstract diagram into concrete parameters.

The software validates the input, expands defaults, allocates addresses, builds data for each platform and renders initial configurations. containerlab, Vagrant, libvirt or another virtualisation tool then creates the virtual environment when suitable images are available. The result is an executable lab, not a static drawing.

The architecture separates intent from syntax. The user states that two nodes should operate with a particular protocol; the project generates different commands for different images. This resembles the promise of production automation, but it is placed in an environment that can be deleted and rebuilt, where errors are inexpensive and repetition is normal.

YAML is not neutral. Its data model determines what can be expressed; default values conceal decisions; a module may support the common minimum while omitting a platform-specific feature. The usefulness of the model depends on whether it fits the question being asked.

Virtualisation abstraction broadens access and introduces new dependencies

The same topology can run with different virtualisation tools and network operating systems. This reduces repeated work and makes it possible to compare alternatives without buying large numbers of physical devices.

The abstraction nevertheless depends on images, licences, disk and container formats, management interfaces and host resources. An image disappearing, a licence changing or the virtualisation layer being updated can break reproducibility even when netlab itself works correctly.

Portability is demonstrated only for a specific combination. “Supported” does not mean that every feature behaves identically in every version. The netlab version, image, virtualisation tool and resource constraints must be recorded with the result.

This dependency chain does not diminish the tool. It shows that a lab is a composition of software and rights to use it, not merely a YAML file.

Multi-vendor modules turn differences into evidence, not equivalence

netlab generates configurations for many systems and common protocols. This makes it possible to test one intent across different implementations and identify differences in syntax, defaults and capabilities.

The word “support” must be used precisely. A module may cover the normal case while omitting an extension. Two devices may establish a BGP session but handle a community or an error differently. A valid configuration does not necessarily include every vendor recommendation.

The value lies in preserving an observed divergence. If results differ, the lab should not smooth them away for the sake of a unified model: the difference itself may become a production risk.

Equivalence requires behavioural testing, version labels and explicit expectations. Neutrality comes from comparing vendors, not imagining their absence.

Protocol experiments expose assumptions before an incident

BGP, OSPF, IS-IS and EVPN propagate state over time. A lab makes it possible to observe session establishment, route propagation, path selection and the withdrawal of state after a failure.

A useful test does not merely ask whether the network “works”. It defines which connectivity must survive, how long stale state may persist, which route should win and which observation will count as a breach.

A repeatable experiment changes one factor at a time: a version, timer, cost, preference, link failure or restart. This isolates a mechanism that is mixed with many others in a production network.

A lab does not predict every delay, table size, CPU load or hardware property. It tests a hypothesis rather than issuing a universal certificate.

A live device confronts generation with pre-existing state

Configuring an empty device is a text-generation task. Changing an active device is a transition task. The current state, owners of rules, dependencies, effects of removal and activation sequence all need to be understood.

When discussing real devices, Pepelnjak acknowledges this difference. netlab can create fragments and assist with testing, but it is not a general transactional engine for reconciling every network. This limitation prevents a learning tool from promising control that it cannot demonstrate.

A production platform must compare intended and observed state, understand non-commutative operations, protect secrets, manage locks and permissions, and then verify the actual change in forwarding.

Generation is one stage. Authority, transition and evidence of the outcome make up the system.

A virtual lab does not certify physical performance or resilience

Virtual devices reproduce many control-plane functions reasonably well. They do not necessarily reproduce ASIC table capacity, physical queues, optical errors, power consumption, line-card restarts or throughput under load.

Images may contain different code, licensing conditions and limitations from physical platforms. Acceptance of a virtual configuration does not prove that a feature is available or performs as expected on every model.

Resilience also depends on independent cables, power, out-of-band access, spare parts, procedures and on-call arrangements. No virtual graph certifies those conditions.

A lab reduces risk, but it does not replace hardware, load and operational testing before a substantial change.

Data-centre networks increased the value of cross-vendor explanation

Leaf-spine designs, underlay BGP, EVPN, VXLAN and fabric controllers have added layers at which the same intent is encoded differently. Vendors apply the same acronyms to non-identical constraints and behaviour.

Pepelnjak separates a protocol from its commercial packaging. An EVPN route or VXLAN tunnel is based on public mechanisms, but its operation depends on software, ASICs and the manufacturer’s choices.

Comparison is useful for procurement and operations, but it does not have to declare a winner. A richer platform may be harder to operate; a narrower feature set may fit the team’s capabilities better.

The question is not how modern the diagram looks, but which properties the organisation can test and sustain.

The cloud showed that one platform’s abstraction is not a universal network

Public clouds offer virtual networks, gateways, route tables, load balancers and firewalls as services. They accelerate deployment, but their constructs do not correspond uniformly to traditional devices and protocols.

Much of Pepelnjak’s teaching translates these models into the language of network engineering. A “propagated” route, a zone or a failure domain has a specific meaning on each cloud platform. Identical icons in a multi-cloud diagram do not make the architecture homogeneous.

Abstraction may conceal authority: who programmes the path, which metrics are visible, which policy can be exported and how can the organisation leave the service? Those questions define cost and reversibility.

Labs reduce uncertainty, but only tests using real quotas, contracts and paths can validate operational behaviour.

Commercial training supports independence and creates its own constraints

ipSpace.net sells courses, webinars and professional services. That revenue can fund content and tools without relying on one equipment vendor.

The public record, however, contains no audited accounts, complete customer count or revenue mix. The platform’s visibility cannot be used to infer its size, margin or diversification.

The model also influences the agenda: popular professional topics may receive more resources. Vendor images and licences determine what may be demonstrated in a lab.

These conditions do not disqualify the work. They should be made visible, like the interests of any vendor or university.

Concentration around one maintainer is efficient until succession becomes a risk

netlab benefits from a coherent design. Its documentation, architecture, examples and responses to users can evolve consistently.

The same concentration creates dependency. Illness, changing priorities or less available time can slow releases and reviews. Contributor numbers alone guarantee nothing if nobody else understands the critical paths or can publish a release reliably.

Resilience is determined by documented decisions, automated tests, the quality of external contributions and the transferability of rights. An open licence permits a fork, but it does not automatically create a community capable of maintaining it.

Succession risk is a property of the system, not a judgement on an individual.

Release activity matters because examples, images and protocols age

A change to Python, a virtualisation tool or a network image can break a lab example that worked yesterday. Without maintenance, the example becomes technical debt.

Version 26.07 demonstrates active adaptation. Frequency alone does not prove quality, but it shows that assumptions continue to be checked against implementations.

Users must retain the versions of netlab, images and the virtualisation tool, together with the input files. Without that context, a screenshot cannot be reproduced.

Maintenance turns a one-off tutorial into a durable tool.

Education becomes infrastructure when it improves operational decisions

An explanation does not forward packets. It can, however, change design, procurement, migration and a team’s response to an incident.

Pepelnjak’s influence is most demonstrable at this level. His articles and courses provide mechanisms and questions that can be applied in practice. The sources do not make it possible to count every network that improved or attribute a commercial outcome to one lecture.

The value lies in reducing errors of thought: intent and syntax, model and reality, claimed functionality and verified behaviour.

A profile can discuss influence without inventing market share. Education works through the quality of decisions, not view counts.

The current test is whether automation preserves local knowledge

An existing network carries history: exceptions, customer requirements, backup paths, hardware constraints and lessons from incidents. A model that omits this history may erase it in the name of standardisation.

Yet preserving every exception without thought automates debt. The organisation must decide what is a requirement, what is drift and who has the authority to settle the dispute.

Pepelnjak’s method remains relevant because it requires both a model and an experiment. The model must produce an outcome, and observation must be able to prove it wrong.

Success does not mean that engineers disappear. It means that their knowledge becomes transferable and open to challenge.

BGP labs make policy visible because the protocol carries decisions

BGP propagates more than reachability. Its attributes express preferences, commercial relationships, traffic objectives and constraints.

In a lab, users can observe the interaction of local preference, MED, communities, filtering, aggregation and path selection. After changing a policy, they can see what is advertised, accepted and rejected.

A configuration can be syntactically correct while expressing the wrong commercial intent. The network may converge perfectly on an undesirable result.

A test should link packet forwarding to the decision: which path was selected, why, and which data authorised that choice.

EVPN and VXLAN show why an acronym does not describe the whole implementation

EVPN is a family of routes and procedures; VXLAN is an encapsulation. Products combine them with different approaches to learning, gateways, multihoming, control and hardware support.

Two vendors may sell “EVPN-VXLAN” while differing in route types, gateway behaviour or update handling. The shared name begins the investigation but does not complete it.

netlab makes it possible to build comparable scenarios and record divergences. Any conclusion must remain tied to the tested version and combination.

Interoperability is a demonstrated property of a specific system, not the magic of an acronym.

A failure test is useful only when acceptable degradation is defined in advance

Disabling a link and seeing that “something remains” is not enough. The test must define which traffic must survive, what convergence time is acceptable, how long old state may persist and which functions may be lost temporarily.

A good test injects a failure, measures behaviour and verifies recovery. A return to normal operation may reveal a different class of errors.

DNS, identity, external controllers, time, storage and out-of-band access may be absent from the lab. The scenario must identify those gaps.

The word “resilient” becomes testable only through observable criteria.

Configuration generation solves repetition, not the meaning of deletion

Adding a line is simple. Removing one may break a shared dependency, close an emergency path or trigger recalculation. The system must understand the intent of the operation.

Production use requires minimal changes, execution order, preliminary checks and rollback. Full replacement is not always safe, even when the final file is correct.

netlab largely avoids this problem through rebuildable environments. By contrast, that boundary shows what a production controller must demonstrate.

Platforms should be assessed by their transitions, not only by the text they generate.

Version control is essential, but it does not store all operational state

Git stores YAML, templates, documentation and decisions. Changes become reviewable, and code can be returned to an earlier version.

It does not automatically retain learned tables, physical state, secrets, images that are no longer available, dynamic routes, cloud quotas or the effects of external APIs. Returning to an old commit does not necessarily restore the network.

A reliable chain combines version control, inventory, backups, telemetry and recovery while documenting what does not fit in the repository.

The boundaries of a tool’s authority must remain explicit.

Observability must trace the model to forwarding outcomes

A valid file and a successful task prove only that the workflow accepted the input. Sessions, routes, forwarding tables and, where necessary, the actual packet path still need to be verified.

A correct model may be transformed incorrectly. A device may accept a command and apply it differently. A route may appear in the control plane but never reach the ASIC.

Lab checks should include adjacencies, prefixes, path selection, loss and recovery. Only then does generation become an experiment.

In a production network, observation should be independent of the channel that performed the change.

Standards provide a common language; implementations create inherited behaviour

RFCs describe messages, states and procedures, but leave options and details to products. Vendors add defaults, safeguards and limitations; operators add policy.

The whole chain creates the resulting behaviour. Pepelnjak’s work connects the standards text, product configuration and observation without conflating them.

This prevents a product defect from being blamed on the standard or claimed compliance from being treated as a guarantee of identical operation.

A useful lab preserves disagreement rather than imposing uniformity

An abstraction that is too broad may smooth differences into a configuration that is common but false. The lab then tests chiefly its own model.

A recorded divergence makes it possible to decide whether the difference is acceptable, requires a separate branch or invalidates a choice. The difference becomes a design fact.

The aim is not to glorify fragmentation, but to prevent a neutral interface from concealing a deep dependency.

The best tool provides a shared vocabulary and an honest place for what is not shared.

The difference between a tutorial and an institution appears in maintenance

A tutorial may work on the day it is published. An educational institution corrects examples, updates images, explains incompatibilities and responds to new versions.

ipSpace.net and netlab show continuity among argument, lab and subsequent correction. That continuity remains centred on one person and a privately run model, without a public mandate or guarantee of permanence.

Longevity depends on whether others can understand, transfer and maintain the content and code.

A strong opinion is useful when the reader can see the evidence

Pepelnjak writes directly about marketing claims and industry fashions. This style raises questions that commercial documents sidestep.

It becomes weaker when experience, a demonstrated mechanism and personal preference are indistinguishable. Stating that the articles express the author’s opinion helps preserve the boundary.

A lab strengthens trust when the reader can reproduce or refute the result. Authority shifts from the name to the experiment.

Directness is an editorial asset, and falsifiability is its discipline.

Vendor neutrality is achieved by comparing vendors

A modern lab cannot operate without owners of images, hypervisors, libraries and support life cycles.

Practical neutrality means not framing the question around one product, recording versions, testing several implementations and publishing limitations.

netlab provides a shared structure, but it does not erase licences or proprietary features. Honest comparison is more useful than claiming that abstraction has abolished the market.

The strongest future evidence would connect a lab to a changed decision

The sources show a substantial educational archive and an active project, but not an independent list of organisations that avoided incidents because of netlab.

A stronger case would trace the process: a defect was found, an architecture was corrected, a deployment was halted or a procedure was improved, while accounting for team contributions and other factors.

Downloads measure attention, not safety. The conclusion therefore remains limited: the method is available and persuasive, but its aggregate effect has not been measured.

A lab should begin with a question, not a topology snapshot

An attractive topology is not yet a test. It needs a hypothesis, a success criterion and an observation.

The question may concern a selected BGP path, the response to a link failure, whether a community crosses a boundary or how two images differ.

Input files, versions and observation commands should make repetition possible. A negative result is useful when it reveals a false assumption.

This is how a lab becomes a decision tool rather than decoration for teaching material.

The method deserves trust when it can disprove a favoured design

A test created only to confirm an architecture is not independent evidence. It must be able to show that the model is incomplete, the implementation differs or a failure exceeds the tolerance.

Pepelnjak’s practice places explanation, model and experiment in tension. Trust comes from the possibility of disagreement, not a claim of infallibility.

An organisation should preserve inconvenient results, give reviewers the authority to stop a change and treat exceptions as information that must be resolved.

The most durable legacy would be a culture in which automation is treated as an executable hypothesis and is always tested by the network itself.