Ivan Pepelnjak and the discipline of testing network automation

Summary

• Ivan Pepelnjak’s public record begins with operating and interconnection work in Slovenia, including participation in the country’s first internet exchange, rather than with a vendor product.
• Through ipSpace.net he built an independent publishing, teaching and consulting platform whose strong opinions are valuable precisely when they remain distinguishable from standards consensus.
• netlab turns a topology described in YAML into repeatable multi-vendor laboratories, making routing and automation claims executable without pretending that virtual tests reproduce every hardware and production condition.
• His central contribution is a method: define authoritative data, test expected behaviour, expose dependencies and preserve the boundary between configuration generation and safe control of an existing network.

Version 26.07 shows why a lab tool can matter without becoming a controller

On 13 July 2026, the netlab project released version 26.07. The release added or extended work around GRE and WireGuard tunnels, graceful restart, BGP roles and scale-out laboratories. Those features sound like a conventional software changelog. Their significance lies in the operating model behind them. A user writes a description of a network topology and the protocols or services to be tested; netlab creates a laboratory from virtual machines or containers, builds initial configurations for several network operating systems and lets the experiment be repeated.

The project is not sold as a universal production orchestrator. That boundary is one of the strongest pieces of evidence in Ivan Pepelnjak’s record. In June 2026 he published a discussion of using netlab to configure live devices. The article explained that the software assumes a known topology and commonly a clean or lab-like starting point. It can generate configuration snippets, but it does not reconcile arbitrary existing state or guarantee that replacing configuration on a vendor command-line interface will be safe.

That candour is more important than a larger feature list. Network automation projects often begin with a demonstration in which a template produces correct-looking configuration. The difficult work begins when the target device already contains years of policy, local exceptions and undocumented dependencies. A tool that can create a laboratory is useful because it makes ideas testable. A tool that claims to control production must also understand ownership, drift, transaction boundaries, rollback and the consequences of partial failure.

Pepelnjak’s career can be read as a sustained attempt to preserve that distinction. He has written about routing, data-centre fabrics, cloud networking and automation for decades, but his strongest contribution is not ownership of any one protocol. It is the habit of turning broad architecture claims into experiments, data models and failure questions that an engineer can reproduce.

Slovenia’s early internet supplied an infrastructure origin rather than a certification myth

RIPE Labs’ historical interview with Pepelnjak places him inside the development of commercial and academic networking in Slovenia. It describes work under the constraints of connectivity behind and after the Iron Curtain and records his participation as a founding figure in Slovenia’s first internet exchange. The history is collaborative. It should not be converted into a story in which one engineer single-handedly built a national network.

The regional setting matters because it made scarcity, interconnection and operational improvisation concrete. Engineers in a small market could not assume abundant international capacity, a large domestic vendor ecosystem or immediate access to every platform. They had to understand routes, circuits, equipment and institutional relationships well enough to keep services working with limited choices.

An internet exchange is itself an agreement among networks, facilities and operators. It creates a place where participants can exchange traffic directly, but it does not replace each participant’s routing policy or upstream connectivity. Working in that environment exposes the difference between a technical feature and an operating institution. A BGP session exists only because organisations agree to connect, configure compatible systems and respond when something fails.

Pepelnjak’s later scepticism towards architecture fashion is easier to understand against that background. A design is not credible because a vendor diagram is elegant. It is credible when the dependencies are available, the operators can understand them and the system fails in a way the organisation can survive.

The public record does not provide a complete chronology of every early role or decision. It is strongest as a retrospective account of the infrastructure environment. That is enough to establish the origin of a method: start from what the network actually does, not from the prestige of the product or the neatness of the abstraction.

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

Pepelnjak’s current public biography describes him as an independent network architect at ipSpace.net and says he has been designing, implementing, teaching and writing about large-scale networks since 1990. It also lists the credential CCIE #1354 Emeritus. Those details come largely from subject-controlled pages and should be attributed accordingly; they are not an audited career census.

Over time, ipSpace.net became the main institution around his work. It publishes articles, webinars, courses, podcasts and books covering routing, data centres, cloud infrastructure and network automation. The platform allows one author to respond quickly to new technologies and to maintain a long archive that connects current claims with earlier predictions and corrections.

Independence creates a distinctive editorial position. Pepelnjak is not writing from inside one network-equipment vendor, and his material often compares several implementations. That does not make the work free of interests. Courses, consulting, lab images, sponsors and professional relationships create economic and technical dependencies. The point is not purity. It is that the structure of the interest is visible and different from vendor employment.

The site explicitly labels the articles as the author’s opinions. That disclaimer is central to their value. Strong criticism can be useful because it breaks the polite language surrounding enterprise products. It can also overgeneralise from selected designs or experiences. A responsible profile should treat the blog as a longitudinal record of technical judgment, not as an industry vote.

The operating model is therefore close to an independent research and education practice. Public writing identifies a problem; a webinar or course develops the mechanism; laboratory tooling lets readers reproduce behaviour; consulting or paid education supports the work. The model can produce unusually coherent thinking across years, while concentrating authorship, maintenance and succession in one person.

The source of truth is a question of ownership before it is a database

One of Pepelnjak’s most persistent automation arguments concerns the “single source of truth”. The phrase is often used as if buying a database will resolve inconsistent infrastructure. His treatment is more demanding. Inventory, addressing, topology and intended services must be represented in authoritative data before templates or APIs can produce reliable changes.

A device configuration is evidence about what a device currently believes. It is not automatically the organisation’s intent. If a router contains an undocumented exception, importing that configuration into the source of truth can turn drift into approved design. On the other hand, a model that ignores discovered state can push an idealised configuration into a network that has changed around it.

The practical problem is ownership. An address-management system may be authoritative for allocations. A customer database may own service identity. A routing controller may own a subset of forwarding intent. The device remains authoritative for some operational state. Monitoring systems report observations, not policy. An organisation that calls all of these “truth” without defining decision rights has not solved automation; it has hidden a governance dispute inside data integration.

Pepelnjak’s writing encourages teams to identify those boundaries before they select templates. Who may create a site? Which system assigns an address? Which record decides the intended neighbour? What happens when the live device disagrees? Who can approve reconciliation? These questions convert a fashionable architecture term into an operating contract.

The argument has broad relevance because automation magnifies authority. A person editing one router can make one mistake. A pipeline connected to authoritative data can reproduce the same mistake across hundreds of devices. The source-of-truth design is therefore part of blast-radius control, not merely administrative tidiness.

A YAML topology is a compact theory of the network

In netlab, a user commonly begins with a YAML file describing nodes, links, device types and protocol modules. The file is concise, but it carries important assumptions. A node name identifies an object. A link implies connectivity. A module such as OSPF, IS-IS, BGP, EVPN or VXLAN adds expected relationships and configuration. Address pools and defaults turn abstract topology into concrete parameters.

The software transforms that description through a data-processing pipeline. It validates inputs, expands defaults, assigns addressing, builds device-specific data and renders initial configurations. Providers then create the virtual environment using systems such as containerlab, Vagrant or libvirt, depending on images and platform support. The result is an executable laboratory rather than a static diagram.

This architecture matters because it separates intent from syntax. The user states that two nodes should run a protocol; the project generates the different commands required by each vendor image. That is the same promise made by many production automation systems, but netlab places it in a bounded experimental context. The topology can be deleted and rebuilt, making failure cheap and repetition normal.

The YAML file is not neutral. Its schema decides what can be expressed. Defaults can hide choices. A generated address plan may be convenient but different from a production organisation’s allocation rules. A module may support the common subset of a protocol and omit a vendor-specific capability. The laboratory is a model, and its usefulness depends on how well that model matches the question being asked.

Pepelnjak’s strength as an educator is to keep the model visible. The reader can inspect topology data, generated configuration and resulting protocol state. A claim about graceful restart or route reflection can be tested rather than accepted from a slide. That does not make the laboratory identical to the production network, but it improves the quality of the question brought to production.

Provider abstraction broadens access while importing image and runtime dependencies

netlab can build environments through several providers. Container-based systems start quickly and allow dense topologies. Virtual machines can reproduce more complete network operating systems. Some users connect external or physical devices. This provider abstraction lets one topology be exercised in different environments, but it does not erase the differences among them.

A containerised network image may share the host kernel or implement features differently from a hardware appliance. A virtual machine may reproduce the control plane while omitting forwarding ASIC behaviour. Interface naming, boot timing, resource limits and licensing vary. A topology that starts successfully under one provider may expose a different race or limit under another.

Images are a practical constraint. Vendor network operating systems often require licences, account access or specific distribution terms. netlab does not own those images. A user’s ability to reproduce a laboratory depends on lawful access, compatible versions and enough compute and storage. An open orchestration project can therefore sit above closed software components.

The same is true of upstream runtimes. containerlab, Vagrant, libvirt and hypervisors provide lifecycle and connectivity functions that netlab uses. A failure may originate in the provider, image, host kernel or generated configuration. Debugging requires understanding the layer rather than treating the top-level tool as the cause of every result.

This dependency map is educational in itself. It shows why “vendor-neutral” rarely means “dependency-free”. A common model can reduce repeated work while still relying on the products it coordinates. The professional task is to make those dependencies explicit, versioned and testable.

Multi-vendor modules turn comparison into evidence, not equivalence

The project supports a broad range of network operating systems and protocol modules. That breadth allows an engineer to build the same conceptual topology with different devices and observe where behaviour converges or diverges. It is especially useful for BGP policy, routing-protocol interaction, EVPN and data-centre designs in which interoperability claims matter.

A module name does not establish feature parity. Two vendors may both support BGP graceful restart but expose different configuration, defaults, timers and failure behaviour. One virtual image may lag the hardware release. A generated configuration may cover the common path while leaving an advanced feature to manual configuration. The support matrix must therefore be read by version and function.

This is where repeatability provides value. The engineer can record the image versions, topology, generated files and test steps. When a vendor releases new software or the project changes a template, the same laboratory can be rebuilt. Differences become observable rather than anecdotal.

The test still needs a property. “The sessions came up” is not enough. The operator may need to verify route selection, policy, failure convergence, next-hop handling or the contents of a forwarding table. netlab helps create the environment; it does not automatically define every assertion. Other tools, scripts or manual inspection may provide the checks.

Pepelnjak’s wider method is visible here: replace the category claim “multi-vendor” with a matrix of exact behaviours. This approach is less dramatic than declaring interoperability and more useful to people who have to operate it.

Protocol experiments reveal assumptions before they become incident conditions

A laboratory can reproduce a route-reflector design, a leaf-spine fabric, a redistribution boundary or a failure sequence before the production network is touched. This makes it possible to test what each control plane does with incomplete information. Does a route remain installed after a session restarts? Does a policy reject the intended prefix? Does one vendor preserve an attribute another drops?

The value is not prediction of every outage. It is removal of avoidable surprise. Many network incidents arise from interactions that were individually documented but never tested together. A design review may examine each box and miss the system produced by the boxes. A repeatable lab shifts attention from configuration syntax to network-wide behaviour.

Experiment also supports learning. A student can break the topology deliberately, inspect messages and restore it. Production change processes rightly discourage uncontrolled failure. Laboratories make failure an ordinary teaching tool. That experience builds intuition about convergence, dependencies and observability.

The boundary remains clear. Virtual time, CPU scheduling and simplified links may alter protocol timing. A five-node lab cannot prove scale behaviour in a thousand-node fabric. A successful test cannot account for every production route, policy or hardware defect. The result should be read as evidence about a defined model, not a warranty.

Pepelnjak’s contribution is to make this evidentiary discipline accessible. He does not own the protocols being tested. He provides a method and toolchain through which operators can challenge their own assumptions before the network carries the cost.

Live-device configuration is where generation meets the problem of existing state

The June 2026 netlab article on live devices is a useful counterweight to automation marketing. Generating a correct configuration for an empty device is different from changing a running network. The live device may contain local policy, manual fixes, secrets, unsupported commands or state created by another controller.

A safe production system needs to compare intended and current state, classify differences, order changes and handle partial application. Some network operating systems offer candidate configurations or transactions; others apply commands immediately. Removing a line can be as consequential as adding one. A rollback may not restore protocol state or traffic instantly even when the text is restored.

netlab can produce snippets and help build known configurations. It does not claim to solve arbitrary reconciliation. That limit protects the project from becoming a false source of confidence. Users who choose to apply output to live devices still need inventory, approvals, backups, staged rollout and out-of-band recovery.

The lesson extends beyond netlab. Any automation platform that begins with templates must eventually answer who owns existing state. If it treats every unmodelled command as drift to be deleted, it can remove legitimate safeguards. If it preserves every discovered command, it can perpetuate error. There is no general solution without an organisational decision about authority.

Pepelnjak’s writing is most useful when it exposes that decision rather than offering a magical product category. Automation is not the elimination of judgment. It is the encoding of judgment into data and procedures that can operate at greater speed and scale.

Virtual laboratories cannot certify hardware performance or operational resilience

Network operating systems in containers and virtual machines are excellent for control-plane study. They are much less reliable as evidence of forwarding performance. Hardware switches use ASIC pipelines, finite tables, buffers, queues and specialised telemetry. A virtual image may accept configuration that a particular platform cannot implement at scale.

Timing also differs. Protocol convergence in a small virtual topology is affected by the host scheduler and shared CPU. Packet loss, microbursts and queue behaviour may not resemble physical links. Redundancy tests can show control logic while missing shared power, cabling, optics or management dependencies.

A mature test strategy therefore uses layers. netlab can validate concepts and configuration generation. Vendor laboratories or physical testbeds can verify platform behaviour. Staging environments can exercise integration with production tools. Canary deployment can limit the first operational blast radius. Monitoring and rollback remain necessary after release.

This hierarchy does not diminish the virtual lab. It locates its highest value. Cheap, repeatable experiments should catch logical errors before expensive environments are used. The physical tests can then focus on the properties that only hardware and production scale reveal.

The distinction also protects readers from overclaiming. A successful netlab topology is evidence that certain software versions behaved as observed under the test. It is not proof that every supported vendor is equivalent or that the design will meet a latency, capacity or availability objective.

Data-centre networking made cross-vendor explanation more valuable

Pepelnjak’s educational work followed the industry from classical routing into virtualisation, leaf-spine fabrics, overlays and EVPN. These technologies increased the number of layers an operator had to reason about. A packet might cross a physical underlay, a VXLAN tunnel, an EVPN control plane, a distributed gateway and a cloud or virtualisation boundary.

Vendor materials often explain each layer through a product architecture. An independent educator can compare the common protocol with the implementation choices. This is valuable because two platforms can use the same acronym while differing in route types, multihoming behaviour, control-plane scaling and operational tooling.

The risk is that comparison becomes simplification. A blog post cannot reproduce every release, hardware family and support case. Strong conclusions may be based on selected evidence. The articles’ explicit opinion status helps readers understand that they are receiving analysis, not certification.

netlab extends the explanation by allowing a reader to run examples. A course about EVPN can include a topology whose configuration and routes are inspectable. The educational product becomes more than slides, while the open tool gains use cases from teaching.

This relationship between publishing and software is one of Pepelnjak’s distinctive strengths. Ideas can be tested in code; code behaviour can generate new writing. The limitation is concentration: one principal author and maintainer shapes both the explanation and much of the tooling.

Cloud networking exposed the danger of treating provider abstractions as universal networks

Public clouds present networking through objects such as virtual networks, route tables, gateways, security groups and managed load balancers. Those objects do not map neatly to every on-premises protocol. Their behaviour is defined by provider control planes, quotas and service contracts that customers cannot inspect in the same way as a router configuration.

Pepelnjak’s cloud material often focuses on these differences. An enterprise architecture can fail when teams assume that a familiar layer-two, routing or firewall model exists behind a cloud label. The correct question is what the provider object actually guarantees, how routes are selected and which failure or visibility boundaries remain outside customer control.

Laboratories can help, but cloud services introduce cost, account and availability dependencies. A virtual reproduction may not capture a managed service’s internal behaviour. Documentation and controlled tests have to be combined with production telemetry. Vendor-neutral language is especially difficult when the platform itself defines the network semantics.

The broader lesson matches the source-of-truth argument. Automation should model the service the organisation can control, not an imagined universal device. Data needs to include cloud identities, regions, attachments and policy ownership as well as addresses and links. A configuration template built around the wrong abstraction can be consistent and still be wrong.

Pepelnjak’s value lies in making these mismatches visible before they become architecture. His conclusions remain opinions shaped by public evidence and experiments, but they give operators a method for challenging the labels sold to them.

Commercial education supports independence while creating its own constraints

ipSpace.net is not a public standards body or charity. Courses, subscriptions, consulting and related products support the work. This commercial model allows sustained attention to technical subjects that may not attract advertising-scale audiences. It also means the platform must choose topics, formats and services that readers will pay for.

The evidence pack does not provide audited revenue, customer count or audience outcomes. It would be unsafe to claim that Pepelnjak educated a whole generation of network engineers or caused a particular industry practice. The archive is extensive; the causal impact is not measured.

Independence from a vendor can make criticism easier, but paid education still depends on vendor images, conference relationships and the technologies that dominate professional demand. A course can become outdated as software changes. A strongly personal voice can attract a loyal audience and deter readers who disagree with its tone.

These are not reasons to discount the work. They explain its institution. ipSpace.net is a small, concentrated knowledge business whose product is judgment made reusable through writing, video and laboratories. The credibility of that product depends on correcting errors, dating claims and showing where evidence ends.

Pepelnjak’s open discussion of production limits is therefore commercially significant. It signals that the educational value does not depend on pretending the tool solves every problem. In a market full of universal automation claims, a bounded promise can be a competitive advantage.

Project concentration is efficient until succession becomes an operational question

netlab has contributors and uses many external projects, but Pepelnjak remains its principal author and maintainer. Concentration can produce coherence. One person can keep the data model, documentation, release notes and educational examples aligned. Decisions do not require a large committee.

The same concentration creates risk. Maintenance workload can slow releases. Knowledge may remain implicit. A change in the principal maintainer’s priorities can affect roadmap and support. Contributors may find it difficult to assume ownership if architecture and review are strongly personalised.

Open-source licensing helps by allowing others to inspect and fork the code. A licence is not a succession plan. Sustainable transition requires documentation, tests, review access, release procedures and people willing to take responsibility. The dependencies on vendor images and external runtimes make that task broader than the repository alone.

For users, the practical response is proportionate. A learning lab can tolerate more concentration than a production controller. Teams that depend on netlab for regression testing should preserve their topology files, pin versions and know how to maintain local changes. They should not convert a useful external project into an unexamined internal critical path.

The project’s explicit scope again reduces risk. Because netlab does not claim to own production state, organisations can use it as an evidence generator without giving it direct authority over the network. That is an architectural choice as much as a product limitation.

Release activity matters because examples decay when protocols and images move

Version 26.07 demonstrates that netlab is active. GRE, WireGuard, graceful-restart, BGP-role and scale-out changes reflect both new use cases and maintenance of existing modules. Release notes provide a date-specific record; they do not guarantee compatibility with every image or provider.

Laboratory tooling suffers from a difficult form of dependency drift. Network operating systems change commands and defaults. Container runtimes and hypervisors alter interfaces. Python libraries evolve. A topology that worked last year may fail before the protocol behaviour is even reached. Continuous testing and documentation are therefore part of the product, not administrative overhead.

Users should record exact versions when they publish or share results. “Tested with netlab” is too broad. The meaningful evidence includes netlab release, provider, device image, module options and assertions. Reproducibility requires enough detail for another engineer to rebuild the environment.

Current activity also has to be separated from adoption. A release proves maintenance, not the size of the user base. Repository stars, downloads or course attendance would still be imperfect measures. The strongest evidence of value is the tool’s ability to make a defined experiment repeatable.

Pepelnjak’s long career adds continuity to that maintenance. The project is connected to decades of writing about the protocols it configures. Its future credibility will depend on whether that knowledge becomes sufficiently shared for the tool to outlast one person’s direct involvement.

Education becomes infrastructure when it changes the quality of operational decisions

Network engineers make decisions through abstractions. They do not inspect every packet or line of vendor code. They rely on mental models of convergence, policy, failure and authority. Poor models produce fragile designs even when the equipment is powerful.

Pepelnjak’s work belongs to the human layer that maintains those models. Articles challenge claims. Courses organise concepts. Laboratories create feedback. An engineer can move from “the vendor says this design converges” to a test that identifies which routes remain and under what conditions.

The effect is hard to count but operationally plausible. A lab that catches a policy error before a maintenance window has value even if no public metric records it. A source-of-truth discussion can prevent a team from importing drift as intent. These are not guaranteed outcomes, and the profile should not invent them as case studies. They describe the mechanism through which education can influence infrastructure.

The method is also transferable. Readers do not need to adopt every opinion to use the questions: What is authoritative? Which behaviour is being asserted? Can it be reproduced? Which layer is omitted? What would disprove the design? Those questions improve decisions across products.

This is why Pepelnjak is best profiled as an educator and tool builder rather than a protocol inventor. His work helps engineers evaluate systems created by others. The authority comes from sustained reasoning and executable examples, not formal power over a standard or network.

The current test is whether automation preserves local knowledge instead of erasing it

Network automation is moving towards higher-level intent, AI-assisted configuration and central policy systems. These tools can reduce repetitive work and make validation more systematic. They can also hide vendor behaviour and spread an error faster than a person could type it.

Pepelnjak’s method offers a demanding standard. The data model must state what the organisation intends. Generated output must be testable. Vendor differences must remain visible. Production deployment must have reconciliation, staging and rollback. A laboratory result must retain its model boundary.

The danger is not automation itself. It is the conversion of uncertainty into apparent certainty. A source of truth can be wrong. A virtual lab can omit hardware. A successful configuration render can fail on existing state. An AI explanation can sound coherent without understanding the local network.

The future relevance of ipSpace.net and netlab will depend on whether they continue to expose those gaps as tooling becomes more powerful. If the project becomes another universal abstraction, it will contradict its strongest lesson. If it remains a place where claims are turned into bounded experiments, it will preserve an unusually valuable function in the automation ecosystem.

BGP laboratories make policy visible because the protocol carries choices, not only reachability

BGP is often introduced as the protocol that tells networks how to reach one another. In practice it also carries policy. Operators decide which routes to accept, prefer, transform and advertise. A session can be established while the intended traffic path remains wrong. The configuration may be syntactically valid and still leak a prefix, hide a backup or select an unexpected exit.

A repeatable lab is particularly useful here because BGP behaviour depends on relationships among several nodes. The engineer can create route reflectors, autonomous systems, communities and import or export policies, then inspect the resulting route tables. Failure can be introduced deliberately: a session is removed, a path is withdrawn, or graceful restart is enabled on only one side.

The experiment does not recreate the public internet. It can expose the logic of a bounded policy and the interaction of exact software versions. That is enough to catch many errors that a line-by-line configuration review cannot. It also teaches the operator to distinguish control-plane state from forwarding outcome. A route may appear in one table but be unusable because the next hop is unresolved or the data plane lacks the expected tunnel.

Pepelnjak’s writing about BGP tends to emphasise these operational layers rather than protocol mythology. The method is valuable because it forces a design claim to name the state that should exist after convergence. “BGP works” becomes a set of observable properties: the correct prefixes are present, the preferred path is selected, backup behaviour is understood and unintended advertisements are absent.

EVPN and VXLAN show why one acronym rarely describes one implementation

Data-centre designs frequently combine an IP underlay with VXLAN tunnels and an EVPN control plane. The architecture is attractive because it can extend tenant networks across a routed fabric while distributing endpoint information through BGP. The operational reality is a set of interacting route types, encapsulation rules, gateways and multihoming choices.

A lab can make those interactions concrete. Engineers can watch a MAC or IP advertisement appear, inspect tunnel endpoints and test what happens when a link or peer fails. They can compare symmetric and asymmetric routing, centralised and distributed gateways, or different multihoming behaviours. The ability to rebuild the topology helps separate an architectural issue from accidental configuration drift.

Vendor support remains uneven. Two systems may both advertise EVPN capability while differing in defaults, route-policy requirements, integrated routing and bridging, or which features are available in a virtual image. Documentation can describe support at a product-family level while the exact release behaves differently. The only defensible claim is therefore attached to a tested matrix.

Pepelnjak has spent years explaining such distinctions in courses and articles. netlab gives that explanation a runnable form. It does not settle which design is universally best. It helps an operator discover which assumptions are true in the combination being considered and which questions still require hardware or production evidence.

Failure testing is useful only when the expected degraded state is defined in advance

Engineers often test whether a network “recovers” after a link or node failure. That word hides the decision. Recovery may mean that all routes return, that critical traffic continues, that convergence completes within a target interval or that the system enters a safe reduced-capacity state. Without a defined property, the test can produce activity without evidence.

A netlab topology makes it easy to remove links and restart processes, but the operator still needs assertions. Which prefixes should remain reachable? Which path should carry traffic? Is packet loss acceptable during convergence? What state should be withdrawn to prevent a blackhole? A useful experiment records those expectations before the failure is injected.

The same discipline applies to graceful restart. Preserving forwarding state while a control plane restarts can reduce disruption, but stale routes may keep traffic on a path that is no longer valid. The feature is not simply “more resilient”. Its value depends on failure type, timers, peer support and the ability to detect when retained state has become dangerous.

Pepelnjak’s method places these trade-offs in front of the learner. The network is not judged by whether every protocol session is green. It is judged by whether the degraded behaviour matches the business and safety objective. That is the point at which a laboratory begins to resemble architecture rather than demonstration.

Configuration generation solves repetition but not the meaning of deletion

Templates are effective when many devices share a pattern. They reduce typographical error and make changes reviewable. A topology model can produce interface names, addresses, neighbours and policies consistently. The danger appears when the generator has to decide what should be removed from an existing device.

Addition is usually visible. Deletion is often implicit. A template that no longer contains a route map may leave the old object in place, creating drift. A replace operation may delete local configuration that was never represented in the model. Different vendors expose different merge and replace semantics, and a command accepted by the interface may produce a sequence of transient states.

A production controller needs a clear answer to each case. It can own a defined subtree and replace it completely. It can merge only approved changes. It can detect unmanaged state and require human review. Each model changes the balance between consistency and local autonomy.

netlab’s focus on creating known starting configurations avoids pretending that this problem has disappeared. The generated output is most trustworthy when the environment is disposable or when the operator has deliberately defined the ownership boundary. Pepelnjak’s live-device warning is therefore not a minor disclaimer; it is a statement about the limit of template-based authority.

Version control is necessary but cannot record the whole operational state

Treating network configuration as code brings familiar benefits. Files can be reviewed, compared, tested and rolled back. A change has an author and history. The topology used in a laboratory can be tied to the generated configuration and assertions used to validate it.

Yet a repository records only what has been placed under version control. It may not contain runtime routes, counters, dynamic leases, external cloud state or the manual command entered during an incident. A commit can show intended change without showing whether the device accepted it or whether users experienced the expected result.

The mature workflow therefore links several forms of evidence. Version control holds intent and change history. Pre-production labs test logic. The deployment system records execution. Telemetry shows observed state. Incident records explain exceptions. None should silently overwrite the others.

Pepelnjak’s source-of-truth work is useful because it resists the idea that Git alone makes a network declarative. The repository is a powerful coordination tool, but authority still depends on what it represents and how differences are reconciled. A precise model can make an organisation’s uncertainty visible; it cannot eliminate uncertainty by naming a branch “main”.

Observability must follow the model all the way to the forwarding outcome

A topology description and generated configuration tell the operator what should happen. Validation needs evidence of what did happen. Control-plane commands, structured telemetry, pings and traceroutes each reveal part of the result. The choice of evidence should match the property being tested.

Checking that an interface is up does not prove that routing policy is correct. Checking that a route exists does not prove that traffic follows it. A successful ping can miss a path used by application traffic. A dashboard can report health while a specific tenant or address family is broken. The laboratory should therefore combine state inspection with end-to-end tests and negative tests for paths that must remain blocked.

Multi-vendor environments add translation risk. The same OpenConfig or CLI term may map to different internal state. A parser can misunderstand output. An API can omit a feature configured through another interface. Observability has to be tested as carefully as configuration.

This is where netlab can connect to other tools without trying to own them. It creates a reproducible environment in which assertions, collectors and analysis systems can be exercised. The lab becomes a place to test the monitoring system as well as the network. That is an important expansion of the educational method: operators learn not only how to build a state, but how to know whether it exists.

Standards provide common language, while implementations create the behaviour operators inherit

Network protocols are defined through standards and long-running community processes. Products implement those documents under constraints of hardware, code history and customer demand. The distance between specification and product is where many operational surprises appear.

An RFC may permit several behaviours, leave a feature optional or depend on another document. A vendor may implement a subset, add a proprietary extension or use a default that differs from its competitors. A virtual image may expose the control plane but not the full hardware path. The label on a feature is therefore the beginning of comparison, not the conclusion.

Pepelnjak’s cross-vendor work lives in this gap. He can explain the common mechanism, then use labs to examine implementations. The approach respects both layers. It does not treat a vendor difference as proof that the standard failed, and it does not treat standards compliance as proof that products are operationally equivalent.

For readers, this distinction improves procurement and design. Questions become more precise: Which route types are supported? What happens during mixed-version restart? Which telemetry path exposes the state? Can the feature be configured through the organisation’s automation interface? These are questions a general feature matrix rarely answers.

A useful lab preserves disagreement instead of forcing every device into one abstraction

Automation teams naturally want one model. A common schema reduces repeated code and makes policy easier to express. The temptation is to hide every vendor-specific difference behind the abstraction. That can create a clean interface that no longer describes the real choices.

A better design separates common intent from explicit deviations. The topology can state the shared requirement, while device modules document where syntax or behaviour differs. A test can assert the common outcome and retain vendor-specific checks where necessary. The goal is not identical configuration; it is predictable service.

netlab’s modularity supports this approach when its data model remains transparent. Users can inspect generated files and extend device logic. The project can add a common feature only after understanding how several platforms implement it. The abstraction remains accountable to running systems.

The principle extends to organisational design. Teams should not force all networks into one workflow merely because a central platform can represent them. Different risk, lifecycle and regulatory contexts may justify different control paths. Shared tooling is valuable when it preserves those legitimate differences instead of classifying them as error.

Pepelnjak’s strongest contribution is this preference for explicit complexity over false simplicity. The system should be made understandable, but not by deleting facts that matter to operation.

The difference between a tutorial and an institution appears in maintenance

A tutorial can demonstrate a feature once. An institution keeps the example useful as software, standards and reader needs change. ipSpace.net’s archive and netlab’s release process have begun to perform that institutional work. Documentation, issue review, compatibility updates and corrections give the material a life beyond a single presentation.

The structure remains small and personal. That allows rapid decisions and a consistent voice. It also means the boundary between author, maintainer, publisher and product strategist is narrow. A disagreement with the author can feel like a disagreement with the project itself.

Durability will depend on whether the work can support more voices without losing its method. Contributors need clear technical interfaces, review expectations and credit. Readers need corrections and version context. Commercial customers need to understand what support is actually promised. Open-source users need enough documentation to operate independently.

The project does not need to become a foundation to be credible. It does need to make the operational knowledge behind it transferable. The strongest sign would be that other maintainers can release, explain and challenge the system while preserving its insistence on testable claims.

Strong opinion is useful when the reader can see the evidence beneath it

Pepelnjak’s writing is recognisable because it is willing to call a design overcomplicated, a marketing claim misleading or an automation fashion premature. That directness can save readers from polite ambiguity. It can also make a conclusion feel more settled than the available evidence warrants.

The best use of the archive is therefore analytical rather than devotional. Readers can compare an argument with standards, vendor documentation and laboratory behaviour. When the article links to an experiment, the claim becomes easier to challenge. When it rests on professional judgment, the opinion label should remain attached.

This distinction matters in a people profile. A long career and a large archive do not create formal authority over the industry. Pepelnjak does not approve RFCs, certify vendor products or operate every network discussed. His influence depends on whether engineers find the reasoning useful and reproducible.

A strong BTW account should preserve the friction. The article can show why his criticism matters without turning every position into consensus. It can also acknowledge that a personal publishing platform may correct itself less visibly than a formal standards process with recorded ballots and appeals. Independence creates freedom; it does not remove the need for scrutiny.

The healthiest relationship between educator and audience is one in which disagreement improves the test. A reader who rejects a conclusion can still use the topology, data model or failure question. That is a more durable form of influence than agreement with a personality.

Vendor neutrality is achieved through comparison, not through the absence of vendors

netlab is often described as multi-vendor, and ipSpace.net regularly compares platforms. The work still depends on vendor software, documentation and engineering choices. Images have licences. Features arrive on different schedules. Some products expose better automation interfaces than others. A common tool cannot create parity where the underlying systems diverge.

Neutrality should therefore mean that the method does not grant one vendor’s terminology automatic authority. The same service objective can be expressed once and tested across several implementations. Differences are recorded rather than hidden. A vendor can perform well in one scenario and poorly in another without the analysis becoming a general ranking.

This has commercial relevance. Buyers often compare feature tables that use identical check marks for capabilities with very different limits. A laboratory can examine the exact version and use case before a procurement decision hardens into architecture. It can also reveal the cost of operational diversity: more images, more tests, more exceptions and more specialised knowledge.

The result is not always an argument for more suppliers. A team may rationally choose one platform because it can support and test it deeply. The value of cross-vendor evidence is that the choice becomes explicit. Lock-in is then a priced dependency rather than a surprise discovered during migration.

Pepelnjak’s work helps create that evidence, but it cannot substitute for contractual support, physical testing or the organisation’s own operating experience. Vendor neutrality is a decision process, not a badge attached to an open-source repository.

The strongest future evidence would connect laboratories to changed operational outcomes

The public record shows a large body of writing, current software releases and detailed technical documentation. It is weaker on independently measured outcomes. We do not know how many production incidents were prevented by a netlab test, how many organisations changed source-of-truth design after a course or how many users depend on the project for routine regression.

Those gaps do not invalidate the work. They limit claims about scale and causation. A richer evidence base would include published operator case studies with exact test properties, before-and-after change data, contributor histories and examples of failed assumptions discovered in the laboratory. Negative results would be especially valuable because they show that the method can challenge a preferred design.

Independent educational research could also examine whether students who build and break repeatable topologies retain stronger operational understanding than those who learn from slides alone. The answer cannot be inferred from the existence of the tool.

For the project itself, succession evidence would matter. More maintainers with authority over releases, modules and documentation would show that the institution is becoming less dependent on one person. A transparent support and funding model would clarify which parts are community infrastructure and which are commercial service.

Until such evidence appears, the defensible judgment remains bounded. Pepelnjak has made network automation more testable and has built a method that many engineers can use. The exact size of that influence is unknown, and its production value depends on what each organisation does after the laboratory result.

A laboratory should begin with a question, not a topology screenshot

A virtual network can become theatre if the objective is merely to make many devices appear on a screen. The number of nodes, vendors or coloured links says little about the quality of the experiment. A useful laboratory begins with a proposition that can fail: whether a route is preferred under a given policy, whether graceful restart preserves forwarding under a defined interruption, whether an EVPN route is imported only into the intended tenant, or whether a failure remains inside the expected domain.

That starting point changes the topology design. Only the nodes, links and services needed to test the proposition should be present. Initial state has to be explicit. Observations must be collected from more than one layer, because a control-plane route, a forwarding-table entry and an application result are related but not identical. A test also needs a failure condition. Without one, a green result may show only that the script completed, not that the network met its intended property.

netlab is valuable because its topology and module model can make these experiments repeatable. The same input can be rebuilt after a software-image change or a device-module update. Differences then become evidence that must be explained. Yet the tool cannot decide whether the original question was commercially important, whether the selected traffic represents production or whether a passing result justifies rollout. Those judgments remain with the operator.

Pepelnjak’s educational method is strongest where it encourages readers to reduce a broad architecture claim to such a bounded test. “This design converges quickly” is not yet an experiment. “After this link fails, these prefixes remain reachable within this interval and no route escapes this policy boundary” is. The discipline protects teams from being impressed by a demonstration whose success conditions were never stated.

The method earns trust when results can disprove the preferred design

Testing is weak when it is arranged to confirm a decision already made. A multi-vendor lab can be used as marketing: choose the features that work, omit difficult combinations and call the remaining matrix interoperable. It becomes engineering only when a result is allowed to block procurement, delay a maintenance window or force a change in the model.

That requires preserving negative evidence. Parser errors, unsupported commands, route differences and unstable behaviour should not be cleaned out of the record merely because they make a diagram untidy. The exact image versions, topology data, configuration outputs and test observations need to be stored together. Otherwise a later team cannot tell whether the conclusion still applies after an upgrade.

The same principle limits automation claims. A generated configuration can be syntactically valid and still implement the wrong service. A laboratory can show that a particular mechanism works under specified conditions, but it cannot prove that production has the same state, capacity, timing or failure independence. The transfer from test to operation is a separate decision, with its own evidence and rollback plan.

Pepelnjak’s most defensible contribution is to make that scepticism practical. His writing is often forceful, but the lab gives readers a way to challenge it. They can change a topology, replace a device, alter a policy and observe whether the argument survives. The authority of the method therefore comes not from agreement with the author, but from reproducibility and the possibility of being wrong.