CLI and transactions
A two-view command line launched with bng-cli. You start in an operational user view for show, ping and traceroute, and enter system-view to configure. Edits stage into a candidate and apply atomically on commit, with rollback, save and load completing the transaction model. This page covers the whole grammar: views, notation, abbreviation, context help and apply timing.
User view and system-view
The prompt always says where you are: angle brackets for the operational user view, square brackets for system-view. Enter configuration with system-view and leave it with return, or quit from the config root. Global verbs — show, display, the transaction verbs, ping and traceroute — resolve from any context, so you never need system-view just to run a show or a ping.
<Netvyn-BNG> system-view [Netvyn-BNG] [Netvyn-BNG] return <Netvyn-BNG>
Configuration views
Inside system-view, related configuration is grouped into views. Entering one changes the prompt and lets you drop the leading keyword. Keyword views are system, ppp, dhcp, nat, firewall, radius, routing and arp. Object views are keyed by name — interface <name> and pool <name> — where a new name creates the object and an existing one edits it. quit steps up one level. Every command can also be typed in full from the config root without entering its view.
[Netvyn-BNG] nat # → [Netvyn-BNG-nat] [Netvyn-BNG-nat] enable # same as: nat enable [Netvyn-BNG-nat] quit # → [Netvyn-BNG] [Netvyn-BNG] pool default # → [Netvyn-BNG-pool-default] [Netvyn-BNG-pool-default] quit [Netvyn-BNG] return
Candidate, running, startup
Edits stage into a candidate and nothing touches the live system until commit. Three stores exist: the candidate holds your staged edits, running is what is currently forwarding traffic, and startup is what survives a reboot. The REST and GUI northbound use the same contract, so a change made in the portal behaves identically.
Transaction verbs
Six verbs complete the model. All are immediate.
commit # validate candidate, apply to running commit confirmed [<minutes>] # apply now, auto-revert (default 10) confirm # keep a pending commit confirmed rollback # discard candidate edits save # write running → startup load # read startup into the candidate
commit confirmed
The safety net for risky changes. If a change cuts off your own management access, doing nothing restores the previous running configuration when the timer expires; if the change is good, confirm makes it permanent. Use it for routing, default-gateway and firewall-enable changes as a matter of habit.
commit confirmed 10 # ... verify you still have access ... confirm # doing nothing instead auto-reverts
Reviewing configuration
Three commands inspect configuration state at any time. show pending also drives the asterisk marker on the prompt, so uncommitted work is always visible. display current-configuration is an alias that normalises to show running.
show pending # uncommitted candidate changes show running # the applied configuration show candidate # running with the candidate overlay
Notation conventions
The reference uses these conventions throughout. In ping <dst> [source <ip>] [count <n>] [df] [fast], only <dst> is required.
<value> a required parameter you supply [value] an optional parameter or keyword a|b|c a choice — pick exactly one [<name>...] may be repeated (a list) plain text a literal keyword, typed verbatim
Abbreviation and TAB
Any unambiguous keyword prefix is accepted — time udp 30 in the NAT view expands to timeout udp 30. Ambiguous prefixes are rejected with the list of candidates: at the config root, co is ambiguous between commit and confirm, so use com or con. TAB completes a unique prefix; if the prefix is not unique nothing completes, and ? shows the candidates.
Context help
Press ? at any point on the command line to list what is valid at the cursor — matching keywords, plus a hint describing any expected variable. It is context-sensitive: inside the nat view it lists NAT knobs, inside qos it lists QoS objects. Used with TAB it lets you build a command interactively without memorising the grammar.
Apply timing
Almost everything applies live on commit without dropping subscriber sessions. The exceptions change state fixed at daemon boot — the lcore layout, the port RSS hash, CGNAT pool and port-block allocation, and the rte_sched disciplines. For those, commit records the change and save persists it, but the running data path does not change until a restart. One exception to the exception: an in-place queue-profile tuning change — qsize, AQM or discipline — applies live on commit, which rebuilds the scheduler as a new generation, so it need not mean a restart; only structural QoS changes, such as adding, removing or reordering profiles, still do.
RESTART REQUIRED system control-cores | ht-policy | max-workers-per-10g nat pool add|remove, nat conntrack-max pool <name> range|next|remove ipv6 pool qos queue-profile add|insert|delete|move (structural; modify is live on commit) cgnat fragments rss firewall filter rules, firewall mss-clamp radius settings LIVE ON COMMIT everything else — interface, ip, ipv6, routes, ppp, dhcp, dhcpv6, nat policy|rule|snat|dstnat|timeouts, qos profiles and assignments (incl. queue-profile modify), arp, power, dispatch, logging, ipdr IMMEDIATE (no commit) show, debug, clear, ping, traceroute, account and session actions
Pending changes on exit
The CLI guards against walking away from unpersisted configuration. Leaving system-view with uncommitted edits prompts to commit them — Y commits, N discards, C stays in the view. Leaving the CLI re-checks both halves: uncommitted edits prompt to commit, then a committed-but-unsaved running config prompts to save to startup so the change survives a reboot. One-shot invocations, bng-cli <command>, never prompt.