Auto-Generated Configuration

During every commit, the SSR platform automatically generates certain configuration elements based on the current topology and feature configuration. These elements are removed and re-created on each commit by default, meaning any manual edits to them are lost unless you take explicit ownership first.

This document covers what gets generated, what triggers it, how to prevent or customize it, and the internal mechanisms that control the lifecycle.

The Auto-Generation Lifecycle

On every commit, the system runs a three-phase cycle:

1. Removal — The system deletes all previously auto-generated elements so they can be rebuilt from scratch. There are two independent removal paths:

   • Element-level: All services, service-routes, peers, adjacencies, tenants, and service-policies where generated is set to true are collected and removed.
   • Metadata-level: An authority metadata list (authority > generated) tracks elements created by certain subsystems (plugins, DHCP server KNI, port-forwarding, software-update). All paths recorded in that list are removed, and the metadata entries are cleared.

2. Generation — Each subsystem builder runs and creates fresh elements. Before creating an element, the builder checks whether a matching element already exists with generated set to false. If it does, that element is treated as user-provisioned and generation is skipped.

3. Metadata update — Newly generated elements from metadata-tracking subsystems are recorded in the authority metadata list for the next cycle.

Two Categories of Subsystem

Not all subsystems use both removal paths. This distinction determines how to override elements:

Category	Subsystems	Removal Path	Override Method
Leaf-only	Peer Topology builder, conductor services, BGP services, DHCP relay, PIM/MSDP, alarm shelving, internal tenants.	Element-level (generated leaf) only	Set generated to false directly
Leaf + metadata	Plugin builder, DHCP server (KNI), software-update, port-forwarding.	Both element-level and metadata-level	Use override-generated true

tip

The PCLI automatically presents the correct command based on the element's category. Always use override-generated when it appears on the element. Only set generated to false directly when override-generated is not available (i.e., the generated leaf is visible instead).

How To Identify Auto-Generated Elements

Any element that the system auto-generates carries generated true in the configuration. You can inspect this field in the PCLI to determine whether an element is system-managed or user-provisioned. For a complete list of all auto-generated element types and their override methods, see the Quick Reference at the end of this page.

Taking Ownership of Auto-Generated Elements

Recommended: The create config autogenerated Single-Commit Workflow

The most practical approach uses the create config autogenerated command to avoid a two-commit cycle:

admin@conductor> create config autogenerated

This runs the same generation logic as commit but stages the results into the candidate configuration without committing. You can then review, override, and customize elements before committing once.

Workflow:

1. Configure your triggers (neighborhoods, conductor-address, BGP neighbors, etc.).
2. Run create config autogenerated — auto-generated elements appear in the candidate.
3. Enter config editing mode and navigate to elements you want to customize.
4. Override those elements (see below).
5. Make your modifications.
6. Commit once — the removal phase skips your overridden elements, and the generation phase sees them as user-provisioned.

During the commit, elements with generated set to false survive the removal phase and are skipped during regeneration, preserving your customizations in a single commit.

note

If the underlying changes (e.g., new neighborhoods, new conductor addresses) trigger configuration updates, re-run create config autogenerated to preview newly generated elements before committing.

Overriding Leaf-Only Elements

For elements generated by the Peer Topology builder, conductor services, BGP, DHCP relay, PIM, or MSDP — the generated leaf is directly visible in the PCLI:

config
    authority
        router  <router>
            service-route  <auto-generated-route>
                generated  false
            exit
        exit
    exit
exit

Setting generated to false is sufficient. These subsystems only check the leaf on the element and do not use metadata tracking.

Overriding Metadata-Tracked Elements

For elements generated by plugins, DHCP server (KNI), port-forwarding, or software-update — the PCLI shows the override-generated command instead of the generated leaf:

*admin@conductor# config
*admin@conductor (config)# authority
*admin@conductor (authority)# router <router>
*admin@conductor (router)# node <node>
*admin@conductor (node)# device-interface <kni-interface>
*admin@conductor (device-interface)# override-generated true
Are you sure you want to make '<kni-interface>' persistent?
It will no longer be auto-generated. [y/N]:

This performs two simultaneous actions:

1. Sets persistent to true in the metadata tracking entry — prevents metadata-based removal
2. Sets generated to false on the element — prevents element-level removal and causes the builder to skip regeneration

warning

Both flags are required for full protection on metadata-tracked elements. Setting only generated to false is unsafe — the metadata removal path would still delete the element on the next commit.

To revert any override and re-enable auto-generation, run override-generated false (or set generated to true for leaf-only elements). On the next commit the element will be removed and re-generated by the system.

Pre-Provisioning Elements

If you create an element with the same name that auto-generation would use before generation runs, the system detects it and skips generation. The manually created element has generated set to false by default, so it is treated as user-provisioned.

This works for adjacencies, service-routes, and services.

Auto-Generated Configuration Reference

User-Facing Configuration

This section covers auto-generated configuration that you typically interact with and may need to customize or override.

Peer Topology Builder

The Peer Topology builder automatically establishes the inter-router topology and distributes service reachability information across peer routers, enabling dynamic topology discovery and service mesh capabilities without manual configuration. It generates two related sets of elements: The peer and adjacency objects that form the inter-router topology, and the peer-type service-route objects that distribute service reachability across that topology.

Peers and Adjacencies

Field	Description
Trigger	neighborhood configured on a forwarding network-interface.
What is generated	peer objects between routers sharing the same neighborhood; adjacency objects on both sides.
Category	Leaf-only

Conditions for generation:

• The network-interface must have forwarding set to true (default) and at least one neighborhood entry.
• Topology matching: mesh ↔ mesh/hub/spoke; hub ↔ spoke/mesh; spoke ↔ hub/mesh.
• peer-connectivity must not be outbound-only on both sides.
• inter-router-security must be set on any interface with a neighborhood.

Method	Scope	Effect
Remove neighborhood from the interface	Per-interface	No adjacencies generated for that interface
Set peer-connectivity to outbound-only on both sides	Per-adjacency pair	Prevents that specific adjacency
Set generated to false on an adjacency or peer	Per-element	Takes ownership of that element
Pre-provision the adjacency before commit	Per-element	System detects it and skips generation

note

There is no global toggle. If neighborhoods are configured, peers and adjacencies will be generated unless overridden per-element.

Service-routes

Field	Description
Trigger	A router has a non-peer service-route for a shared service, and peer routers exist.
What is generated	Peer-type service-route objects on remote routers pointing back to the source.
Category	Leaf-only

Conditions for generation:

1. Service has share-service-routes set to true (default).
2. Source router has at least one non-peer service-route (e.g., next-hop) for the service.
3. Service application-type is generic.
4. Service applies-to allows the peer router.
5. Authority is not using a Peer Topology repository.

Method	Scope	Effect
Set share-service-routes to false	Per-service	Prevents Peer Topology builder route generation for that service
Configure applies-to restrictions	Per-service	Limits which routers receive generated routes
Set generated to false on a service-route	Per-element	Takes ownership of that route
Pre-provision a service-route with the same name	Per-element	System skips generation for that route

Conductor Services

The Conductor Services subsystem provides automatic connectivity from managed routers back to the conductor system, enabling centralized configuration, monitoring, and software updates. Generation is unconditional when any conductor-address is configured. There is no way to fully disable this category, but there are customization options and per-element overrides:

Field	Description
Trigger	conductor-address is configured on the authority.
What is generated	Conductor reachability service, service-policy, service-route, and related tenant objects.
Category	Leaf-only

Method	Level	Effect
management-service-generation > service-route-type	Authority or Router	Choose paths-as-next-hop (default) or paths-as-service-route
management-service-generation > service-policy	Authority or Router	Use a custom service-policy instead of the auto-generated one
management-service-generation > proxy	Router only	Enable/disable proxy of public-to-private conductor addresses
Set generated to false on a conductor service or route	Per-element	Takes ownership of that element

Management Over Forwarding Interface (MOFI) Services

The MOFI builder automatically provisions management services for various network management and operational functions, enabling these services to be delivered over forwarding interfaces (data plane) when management interfaces are not available. This provides management connectivity through active data paths.

Field	Description
Trigger	A network-interface configured with management: true on a forwarding interface.
What is generated	Services and service-routes for NTP, DNS, SNMP, Syslog, IPFIX, HTTP-HTTPS (package updates), and Audit functions.
Category	Leaf-only

The builder generates services for the following management traffic types:

Service Type	Purpose
NTP	Network Time Protocol for clock synchronization
DNS	Domain Name System for name resolution
SNMP	Simple Network Management Protocol for device management
Syslog	System logging for centralized log collection
IPFIX	IP Flow Information Export for flow telemetry
HTTP-HTTPS	Software package downloads for system updates
Audit	Audit event forwarding for compliance logging

Method	Scope	Effect
Remove management: true from the interface	Per-interface	Prevents MOFI service generation for that interface
Disable management services in authority config	Authority	Prevents generation globally (if supported)
Set generated to false on a MOFI service or route	Per-element	Takes ownership of that element

note

MOFI services are generated with the lowest priority to ensure they don't override user-configured services with the same names. Pre-provisioning a service with the same name before generation will prevent the auto-generated version from being created.

BGP Services and Service-Routes

The BGP subsystem automatically establishes reachability to BGP peers, enabling dynamic routing protocol operation and network convergence without manual service definition.

Field	Description
Trigger	BGP neighbor transport configuration
What is generated	BGP peering service and service-route objects for BGP neighbor reachability
Category	Leaf-only

Method	Scope	Effect
Set bgp-service-generation > disabled	Per-BGP-neighbor	Fully prevents generation for that neighbor
Set bgp-service-generation > service-policy	Per-BGP-neighbor	Override the generated service-policy
Set bgp-service-generation > security-policy	Per-BGP-neighbor	Override the generated security policy
Set bgp-service-generation > route-reflector-client-mesh	Authority	Generate service-route mesh for route reflector clients
Set generated to false on a BGP service	Per-element	Takes ownership of that service

You can fully disable BGP service generation on a per-neighbor basis using the disabled option.

DHCP Server KNI Device-Interfaces

The DHCP server subsystem automatically provisions kernel network interfaces required for DHCP server operation, handling the internal networking plumbing transparently.

Field	Description
Trigger	host-service of type dhcp-server configured on a network-interface
What is generated	KNI device-interface objects for DHCP server operation
Category	Leaf + metadata

Setting	Level	Effect
dhcp-server-generated-address-pool	Authority (application-identification)	Changes the address pool for generated KNI interfaces (default: 169.254.130.0/24).
override-generated true on the KNI interface	Per-element	Takes ownership of that element.

There is no flag to fully disable DHCP KNI generation. Remove the dhcp-server host-service to prevent generation.

DHCP Relay Services and Routes

The DHCP relay subsystem automatically provisions the DHCP relay service and reachability paths to DHCP servers, enabling DHCP client support on networks without a local DHCP server.

Field	Description
Trigger	DHCP relay agent configured on a network-interface
What is generated	DHCP relay service and service-route objects
Category	Leaf-only

Method	Scope	Effect
Remove DHCP relay configuration	Per-interface	Prevents generation
Set generated to false on the service or route	Per-element	Takes ownership of that element

Application Identification (App-ID) Services

The App-ID subsystem automatically creates granular service categories for application identification, allowing fine-grained traffic classification and policy enforcement without manual service creation.

Field	Description
Trigger	generate-categories set to true on a service
What is generated	Category-based child service objects under the parent service
Category	Leaf-only

Method	Scope	Effect
Set generate-categories to false (default)	Per-service	Prevents category-based child service generation
Set application-identification to disabled	Per-service	Disables app-id entirely for that service

The default is false (disabled). Category services are only generated when explicitly opted-in.

PIM Multicast Services and Routes

The PIM subsystem automatically establishes reachability for Protocol Independent Multicast (PIM) control traffic, enabling multicast routing operation across the network.

Field	Description
Trigger	PIM routing configured on a router
What is generated	PIM multicast service and service-route objects
Category	Leaf-only

No independent disable flag. Remove the PIM configuration to prevent generation. Set generated to false per-element to take ownership.

MSDP Services and Routes

The MSDP subsystem automatically provisions Multicast Source Discovery Protocol (MSDP) peering connectivity, enabling inter-domain multicast source discovery and reachability.

Field	Description
Trigger	MSDP routing configured
What is generated	MSDP peering service and service-route objects
Category	Leaf-only

No independent disable flag. Remove the MSDP configuration to prevent generation. Set generated to false per-element to take ownership.

Plugin-Generated Elements

Plugins extend the platform by automatically generating plugin-specific services, routes, and configuration elements as needed.

Field	Description
Trigger	Varies by plugin.
What is generated	Plugin-specific services, routes, and other configuration.
Category	Leaf + metadata.

Use override-generated true on any plugin-generated element to take ownership.

---

Infrastructure and System Configuration

This section covers auto-generated configuration managed by the platform for internal operations. Most users do not need to interact with or override these settings.

Software Update Proxy

The software update subsystem automatically configures internal proxy settings for software updates on managed routers, ensuring seamless update delivery without manual configuration. This is a hidden, internally managed setting. It is unconditionally set when managed routers exist. There is no opt-out mechanism and no override is available.

Secure Conductor Onboarding (SCO)

The SCO subsystem automatically manages the secure onboarding mode for routers and configures pre-shared keys (PSK) required for secure conductor communication. This enables secure, automated onboarding of managed routers without manual key management.

Field	Description
Trigger	Routers with system/secure-conductor-onboarding/mode configured
What is generated	SCO operating mode (EXCLUSIVE or DISABLED) and pre-shared keys for routers
Category	Leaf-only

Method	Scope	Effect
Set secure-conductor-onboarding > mode to disabled	Per-router	Disables SCO for that router
Set secure-conductor-onboarding > mode to exclusive	Per-router	Enables SCO and triggers PSK generation

note

SCO operates at the system level and is automatically managed based on the configured operating mode. PSKs are only generated when SCO is enabled and are required for the conductor to authenticate the router.

Resource Groups

The Resource Groups subsystem automatically associates configuration resources (routers, services, tenants, security profiles, etc.) with role-based access control (RBAC) resource groups. This enables policy enforcement for resource group-scoped access controls without manual resource enumeration.

Field	Description
Trigger	Configuration resources exist in the authority; roles define resource groups.
What is generated	Resource entries in roles linking to configuration objects.
Category	Leaf-only

Supported resource types include:

• Network elements (routers, districts).
• Services and traffic policies (services, service-classes, traffic-profiles).
• Security and access (tenants, security profiles, LDAP servers).
• Operational configuration (alarm shelves, performance profiles, DSCP maps, IPFIX collectors).
• Extensibility (STEP repos, PCLI aliases, session-types).

Method	Scope	Effect
Pre-provision resources with specific names	Per-resource	System detects them and skips auto-generation
Set generated to false on a resource entry	Per-element	Takes ownership of that resource entry

note

Resource groups are generated with lowest priority; user-provisioned resources with matching names prevent auto-generation. This enables administrators to define custom resource mappings when needed.

Alarm Shelving

The alarm shelving subsystem automatically manages alarm suppression (shelving) based on internal platform logic, suppressing non-critical alarms during expected operational conditions.

Field	Description
Trigger	Internal alarm shelving logic
What is generated	Alarm shelf entries
Category	Leaf-only

Set generated to false per-element to take ownership.

Internal Tenants

The platform automatically provisions internal logical containers (tenants) for services and features that require tenant isolation without burdening users with these internal details.

Field	Description
Trigger	Conductor services, BGP, or other internal features are active.
What is generated	Internal tenants such as _internal_, _bgp_speaker_.
Category	Leaf-only

warning

These tenants are required for the platform to function. Setting generated to false is technically possible but not recommended — it may impact platform functionality.

Auto-Generated IDs

The platform automatically assigns unique identifiers to configuration elements when not explicitly provided, ensuring all config elements have required IDs without manual assignment. This is a fundamental platform requirement. It cannot be disabled or overridden.

---

Protection Mechanisms in Detail

This section provides deeper technical detail on how the two mechanisms interact. Most users can rely on the guidance above — the PCLI shows the correct command automatically.

The generated Leaf

Every auto-generated element has a generated boolean:

• generated true — element is collected for removal during commit and regenerated
• generated false — element is skipped during both removal and regeneration

The Authority Metadata Tracking List

A hidden list at authority > generated tracks elements created by certain subsystems. Each entry has a persistent flag:

• persistent false (default) — the element's path is collected for removal
• persistent true — the path is retained and NOT collected for removal

Interaction Matrix

State	Removed?	Regenerated?	Assessment
generated true, no metadata.	Yes (leaf)	Yes	Normal leaf-only behavior
generated false, no metadata.	No	No	Safe — fully protected
generated true, metadata persistent false.	Yes (both paths)	Yes	Normal metadata-tracked behavior
generated false, metadata persistent false.	Yes (metadata)	May be	Unsafe — metadata removal still deletes it
generated false, metadata persistent true.	No	No	Safe — what override-generated true sets
generated true, metadata persistent true.	Yes (leaf)	Yes	Unsafe — leaf removal still deletes it

PCLI Visibility

The generated leaf and override-generated command are mutually exclusive in the PCLI:

• If a metadata entry exists → generated leaf is hidden; override-generated is shown.
• If no metadata entry exists → generated leaf is visible; override-generated is hidden.

Import/Export Behavior

The export config and import config PCLI commands save and restore the full configuration to/from a GZIP-compressed XML file on disk (stored in /etc/128technology/config-exports/).

Both the generated leaf on individual elements and the authority > generated metadata list are fully preserved during export and import. The export serializes the entire configuration tree without filtering.

This means:

• All auto-generated elements, their generated boolean values, and any override-generated state survive a round-trip export/import.
• The authority > generated metadata entries (including persistent flags) are included.
• The configuration behaves identically after import — the same PCLI commands are available, and the same override protections are in effect.
• Elements with generated true will still be removed and re-generated on the next commit after import.
• Elements previously overridden (generated false or persistent true) remain protected.

Quick Reference

User-Facing Configuration

Element	Dedicated Disable Option	Per-Element Override
Peer Topology builder service-routes.	share-service-routes false	generated false
Peer Topology builder peers/adjacencies.	Remove neighborhood	generated false
Conductor services	No (customization knobs only)	generated false
MOFI services (NTP, DNS, SNMP, etc.).	Remove management: true from interface	generated false
BGP services	bgp-service-generation > disabled	generated false
DHCP relay services.	Remove relay config	generated false
DHCP server KNI interfaces.	Remove dhcp-server host-service	override-generated true
App-ID category services.	generate-categories false (default)	generated false
PIM/MSDP services	Remove routing config	generated false
Plugin-generated elements	Varies by plugin	override-generated true

Infrastructure and System Configuration

Element	Dedicated Disable Option	Per-Element Override
Secure Conductor Onboarding (SCO)	Set mode to disabled	Not typically overridden
Resource Groups	Pre-provision resources	generated false
Internal tenants	No	generated false (not recommended)
Software-update proxy	No	Not available
Auto-generated IDs	No	Not available