Making Network Configuration Human Friendly

1 Introduction

• Manual network configuration requires expertise in different APIs and protocols and is costly, difficult, and susceptible to human error.Errors have been associated with outages affecting emergency calls, flight schedules, and Meta.Source: §1 · p. 1
• Existing configuration tools can require operators to learn a new domain-specific language, adding another challenge to an already arduous task.Prior work includes approaches for compiling high-level policies and generating configurations with verification guarantees.Source: §1 · p. 1
• The paper systematically studies LLM-based configuration from natural-language requirements and presents a functional prototype with related implementation challenges.Its contributions include generating P4 configurations from scratch and adapting existing BGP configurations.Source: §1 · p. 2
• LLMs can generate working P4 and BGP configurations without fine-tuning for a class of natural-language path policies, with a trade-off among accuracy, requirement complexity, and cost.The study examines whether LLMs can simplify configuration by translating operator inputs into network configurations.Source: §1 · pp. 1–2
• The work targets switch/router configuration, while applying the same principle to other configurations and tasks remains a possibility.The authors describe their work as still underway and hope it motivates further research.Source: §1 · p. 2

to Low-Level Network Configurations

• NETBUDDY translates high-level policies and requirements into low-level configurations through three steps, with a verifier checking each LLM output and providing feedback when it detects errors.The verifier is described as essential to a fully automated pipeline, but deployment and running configurations on devices are outside the assumed system scope.Source: to Low-Level Network Configurations · p. 2
• The first step converts natural-language input into a predefined formal specification that is easier to verify, covering requirements such as reachability, waypoints, and avoidances.Operators may directly add or remove entries for requirements such as link preferences or load balancing.Source: to Low-Level Network Configurations · pp. 2–3
• The verifier cannot establish whether a natural-language requirement was translated correctly, so operators must check that correctness.The input is primarily natural language, and the paper notes that the verifier can check format, syntax, and requirement conflicts or bad practices.Source: to Low-Level Network Configurations · p. 3
• NETBUDDY next produces a high-level configuration, such as routing information, to simplify the LLM task and facilitate validation; this step also requires the physical topology.The routing information represents shortest paths between end-host pairs.Source: to Low-Level Network Configurations · p. 3
• When needed, code can generate routing information because LLMs cannot compute or execute; a verifier can check outputs and return feedback, while existing code can be reused for changes that add no new requirement types.Generating code is optional because it is expensive; new requirement types may require extending the previous programs.Source: to Low-Level Network Configurations · p. 3
• The final step produces low-level configurations across varied protocols and vendor syntaxes; this paper focuses on P4 and BGP, which may require device-specific information as input.For proprietary devices or protocols not represented in LLM knowledge, NETBUDDY may need additional network-specific information to fine-tune a model.Source: to Low-Level Network Configurations · pp. 3–4

Correctness

• Correctness of natural-language-to-formal-specification translation has no established evaluation technique, and definitive evaluation is difficult because LLMs are unstable and natural language is ambiguous.Datasets for fine-tuning or quality-evaluation techniques such as RLHF may increase confidence in results.Source: §3 · p. 4

Contradictory requirements

• GPT-4 detects explicit contradictions, but may miss implicit ones; SMT solvers can test whether a formal specification has a solution.For example, it failed to report a conflict when a required waypoint could not reach the destination.Source: §3 · p. 4

Complexity

• GPT-4 correctly outputs formal specifications below 40 requirements per prompt, but higher counts cause instability, missed mappings, API failures, and truncated responses.The experiment used 802 reachability and waypoint requirements; failures became more evident near the 8192-token limit.Source: §3 · p. 4

Ambiguity

• GPT-4 translates requirements successfully when they are not too general or unclear, while higher ambiguity makes mistakes more likely.A clear reachability requirement was rewritten as a vague instruction that could mislead a human reader.Source: §3 · pp. 4–5

Complexity

• 10-requirement batches achieve GPT-4’s highest accuracy; translating 10 requirements in one message is about 6× cheaper than using 10 messages at 100% accuracy, and 36 batches correctly translate 360 requirements.Figure 2 plots accuracy and per-requirement API cost across batch sizes.Source: §3 · p. 4, Figure 2 · p. 5

LLM use and verification

• GPT-4 can fail at directly translating a formal specification into routing information but generate functional Python code; NETBUDDY’s verifier iteratively detects and helps fix syntax and functional errors.Structured JSON outputs and function calling can ease parsing, though function calls remain error-prone and GPT-4 supports only one per message.Source: §3 · p. 5

4 Proof-of-Concept Utilizing GPT-4

• The proof of concept demonstrates two GPT-4 configuration scenarios, with output verification and feedback performed manually and an automated verifier left for future work.Source: §4 · p. 5

4.1 MPLS Routing for P4-Enabled Switches

• For the MPLS scenario, NETBUDDY takes network details and natural-language requirements as input; the P4 data-plane program and device addresses are assumed to be provided.Source: §4.1 · p. 5
• NETBUDDY formalizes reachability and waypoint requirements, then uses GPT-4 interactions and a Python script to calculate forwarding paths.The example produces six paths, including a waypoint-compliant route from h1 to h2.Source: §4.1 · pp. 5–6
• Six generated forwarding paths include a waypoint-compliant h1-to-h2 route; BGP edits were semantically correct in some cases but sometimes had syntax errors.The P4 table rules were installed in a Kathará emulation and requirements were manually tested with ping and tcpdump.Source: §4.1 · p. 6, §4.2 · p. 6
• NETBUDDY uses the generated paths, topology, device settings, and deployed P4 program to produce switch table entries for the paths between hosts.The generated rules were installed on P4-enabled switches in Kathará, and requirements were manually tested.Source: §4.1 · p. 6
• For runtime MPLS changes, an added avoidance requirement modifies the existing script to force h1-to-h3 traffic onto the red path.The scenario reuses existing configuration work rather than generating everything from scratch.Source: §4.1 · p. 6

4.2 Runtime Modification of BGP Routers

• In the BGP scenario, NETBUDDY changes AS100’s primary route to AS200 from AS20 to AS30 by translating a natural-language request into router commands.The generated changes used local-preference adjustments or a route map; some were semantically correct but had syntax errors.Source: §4.2 · p. 6

• The paper’s main takeaway is that LLMs can dramatically simplify and automate complex network management tasks.Source: §5 · p. 6
• The authors hope their work motivates further research on using AI techniques for network management.Source: §5 · p. 6
• The paper situates its exploration amid AI-assisted code generation, noting that similar development and fine-tuning for networking had not yet occurred.Source: §5 · p. 6