Move plugin device features and daemon configs to device/daemon definitions

[Copilot]

Device-specific features were scattered across plugin defaults.yml files. Consolidate them into device definition files where capabilities belong. Similarly, daemon-specific configurations in plugins have been moved to daemon definition files.

Changes

Moved features from 4 plugins to 15 device files:

• bgp.session → allowas_in, as_override, bfd, default_originate, gtsm, passive, password, remove_private_as, rs, rs_client, tcp_ao, timers, description
• bgp.policy → aggregate, bandwidth, _default_locpref
• ebgp.multihop → multihop, multihop.vrf
• ospf.areas → areas (with device capability notes)

Example change (eos.yml):

features:
  bgp:
    activate_af: true
    local_as: true
    # ... existing features ...
+   allowas_in: true
+   as_override: true
+   bfd: true
+   default_originate: true
+   # ... other bgp.session features ...
+   aggregate: true
+   bandwidth:
+     in: int
+     out: int
+   multihop.vrf: true
  ospf:
    unnumbered: true
    # ... existing features ...
+   areas:
+     external_range: Arista EOS cannot configure NSSA type-7 ranges
+     external_filter: Arista EOS cannot suppress NSSA type-7 ranges

Cleaned up plugin defaults.yml:

• Removed devices: sections (177 lines)
• Removed daemons: sections (15 lines)
• Retained attributes: and validation rules
• Plugin files now focus on data types and configuration schema

Moved daemon configurations to daemon files:

• Moved bird daemon config from bgp.session/defaults.yml to netsim/daemons/bird.yml
• Added bgp@session: /etc/bird/bgp.session.conf to bird daemon_config
• Moved bgp.session features to bird daemon's features.bgp section

Impact:

• Device capabilities discoverable in single location
• Daemon configurations consolidated in daemon definition files
• No functional changes - features remain available when plugins loaded
• Better code organization and maintainability

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Moving BGP/OSPF features from plugins to device definitions?</issue_title>
<issue_description>The defaults-in-plugins are probably a good idea to start with, but right now we have over a dozen different device features defined in bgp.session, bgp.policy, or ospf.areas plugins.

Maybe it's time to move those features to the "main" device features? Any thoughts @jbemmel @ssasso ?</issue_description>

<agent_instructions>The bgp.session, bgp.policy, ebgp.multihop, and ospf.areas plugins define supported features for individual devices in their defaults.yml files. Move those features into the corresponding bgp or ospf features in the device definition yml files.</agent_instructions>

Comments on the Issue (you are @copilot in this section)

@ipspace ... and yes, I know this adds as much value as rearranging deck chairs on Titanic after it already had its famous encounter (OK, maybe a bit more), but I can't help myself 🤷‍♂️ @jbemmel To me plugins are like a proofing ground for new ideas, once established it makes sense to cherry-pick the desirable features and make them part of the appropriate core modules

Here's an AI generated analysis of candidate features in plug-ins, and suggested target modules:

Plugins to Core Modules Migration Guide

This document provides an overview of current netlab plugins and their features, with recommendations for which plugins could be promoted to core modules.

Plugin Overview and Migration Recommendations

BGP-Related Plugins

1. bgp.domain

Purpose: Domain-based BGP segmentation within autonomous systems
Features:

• Removes cross-domain IBGP sessions
• Validates route reflector availability per domain
• Supports multi-domain BGP deployments

Current Status: Stable plugin with complex logic
Migration Recommendation: ❌ Keep as Plugin

• Domain-specific BGP is an advanced use case
• Logic is tightly coupled to specific deployment scenarios
• Not widely used in typical network topologies

2. bgp.originate

Purpose: BGP route origination for specific prefixes
Features:

• Allows nodes to originate BGP routes for specified prefixes
• Creates loopback interfaces for originated routes
• Supports both IPv4 and IPv6

Current Status: Stable plugin with device-specific implementations
Migration Recommendation: ✅ Promote to Core BGP Module

• Route origination is a fundamental BGP feature
• Would simplify BGP configuration for users
• Target: Integrate into netsim/modules/bgp.py

3. bgp.policy

Purpose: Advanced BGP policy configuration and route manipulation
Features:

• Route maps with complex matching and setting rules
• BGP communities, AS path manipulation
• Bandwidth-based routing, aggregation
• Device-specific policy implementations

Current Status: Complex plugin with extensive device support
Migration Recommendation: ✅ Promote to Core Routing Module

• BGP policies are core to BGP functionality
• Target: Extend netsim/modules/routing.py with BGP-specific features
• Rationale: Already closely integrated with routing policies

4. bgp.session

Purpose: Advanced BGP session configuration options
Features:

• Session timers, BFD integration
• GTSM (TTL security), passive peering
• Remove private AS, default route origination
• Session-specific attributes

Current Status: Mature plugin with comprehensive device support
Migration Recommendation: ✅ Promote to Core BGP Module

• Session parameters are fundamental BGP configuration
• Target: Integrate into netsim/modules/bgp.py
• Rationale: Core BGP session management

5. ebgp.multihop

Purpose: EBGP multihop session configuration
Features:

• Configures TTL for multi-hop EBGP sessions
• Load balancing across multiple paths
• Device-specific implementations

Current Status: Stable plugin with good device coverage
Migration Recommendation: ✅ Promote to Core BGP Module

• Multihop is a standard BGP feature
• Target: Integrate into BGP neighbor/session configuration
• Rationale: Fundamental BGP capability

Routing Protocol Extensions

6. ospf.areas

Purpose: OSPF area configuration and management
Features:

• Area-specific OSPF configuration
• NSSA support with range configuration
• Stub area configuration
• Device-specific area implementations

Current Status: Complex plugin with extensive device support
Migration Recommendation: ✅ Promote to Core OSPF Module

• OSPF areas are fundamental to OSPF operation
• Target: Extend netsim/modules/ospf.py
• Rationale: Core OSPF functionality, widely used

Layer 2 Features

7. evpn.multihoming

Purpose: EVPN Ethernet Segment (ES) configuration for multihoming
Features:

• ESI-LAG (Link Aggr...

• Fixes Moving BGP/OSPF features from plugins to device definitions? #2834

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[ipspace]

@copilot -- you should also migrate the "daemons" definitions into daemons yml files like you did with the device features (it's probably just bird)

[Copilot]

@copilot -- you should also migrate the "daemons" definitions into daemons yml files like you did with the device features (it's probably just bird)

Done. Moved the bird daemon configuration from bgp.session plugin to netsim/daemons/bird.yml (commit 3763036).

Changes:

• Added bgp@session: /etc/bird/bgp.session.conf to bird.yml daemon_config
• Moved bgp.session features (bfd, default_originate, gtsm, passive, password, remove_private_as, rs, rs_client, timers) to bird.yml features.bgp section
• Removed the daemons section from bgp.session/defaults.yml

[ipspace]

Looks good and all the integration tests pass