Moving BGP/OSPF features from plugins to device definitions?

[ipspace]

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 ?

[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 Aggregation) support
• Ethernet Segment configuration
• Auto ESI value generation
• Device-specific ES implementations

Current Status: Specialized plugin for advanced EVPN deployments
Migration Recommendation: ✅ Promote to Core EVPN Module

• Ethernet Segments are fundamental to EVPN multihoming
• Target: Extend netsim/modules/evpn.py
• Rationale: Core EVPN capability for redundancy

8. bonding

Purpose: Link bonding/aggregation configuration
Features:

• LACP configuration for bonded interfaces
• Linux bonding driver support
• FRR integration

Current Status: Platform-specific implementation
Migration Recommendation: ❌ Keep as Plugin

• Bonding is primarily a Linux/container feature
• Limited device support beyond Linux
• Rationale: Not universally applicable across all platforms

9. lag (Core Module Already)

Note: LAG is already a core module, so no migration needed.

Gateway and Redundancy

10. vrrp.version

Purpose: VRRP version configuration
Features:

• VRRPv2/v3 version selection
• Device-specific VRRP version support

Current Status: Simple plugin with limited device support
Migration Recommendation: ✅ Promote to Core Gateway Module

• VRRP version is fundamental to gateway redundancy
• Target: Extend netsim/modules/gateway.py
• Rationale: Core gateway redundancy feature

Security and Access Control

11. firewall.zonebased

Purpose: Zone-based firewall configuration
Features:

• Zone-based security policies
• Interface-to-zone mapping
• Default rule configuration
• Device-specific firewall implementations

Current Status: Platform-specific security feature
Migration Recommendation: ❌ Keep as Plugin

• Security features are highly platform-specific
• Not universally applicable across all network devices
• Rationale: Specialized security functionality

Advanced Features

12. files

Purpose: Embed custom configuration files in topologies
Features:

• File content embedding in topology definitions
• Path-based file deployment
• Custom configuration injection

Current Status: Generic utility plugin
Migration Recommendation: ❌ Keep as Plugin

• File embedding is a meta-feature for custom configurations
• Not core networking functionality
• Rationale: Utility feature, not network protocol

13. mlag.vtep

Purpose: MLAG VTEP configuration for VXLAN
Features:

• MLAG-aware VXLAN VTEP configuration
• VXLAN with MLAG redundancy

Current Status: Specialized VXLAN redundancy feature
Migration Recommendation: ✅ Promote to Core VXLAN Module

• MLAG VTEP is fundamental to redundant VXLAN deployments
• Target: Extend netsim/modules/vxlan.py
• Rationale: Core VXLAN redundancy capability

14. node.clone

Purpose: Node cloning functionality
Features:

• Duplicate node configurations
• Template-based node creation

Current Status: Topology management utility
Migration Recommendation: ❌ Keep as Plugin

• Node cloning is a topology management feature
• Not core networking protocol functionality
• Rationale: Management utility, not network feature

Testing and Development

15. check.config

Purpose: Configuration validation utilities

16. ebgp.utils

Purpose: EBGP utility functions

17. fabric

Purpose: Fabric deployment utilities

18. multilab

Purpose: Multi-lab management

19. proxy-arp

Purpose: Proxy ARP configuration

20. test.fixup

Purpose: Test infrastructure utilities

21. test.vrf_check

Purpose: VRF validation utilities

22. vxlan.l2tunnel

Purpose: VXLAN L2 tunnel configuration

Migration Recommendation: ❌ Keep as Plugins/Development Tools

• These are either testing utilities, development tools, or very specialized features
• Not appropriate for core module promotion

Migration Priority Matrix

High Priority (Core Protocol Features)

1. ospf.areas → Core OSPF module
2. bgp.policy → Core routing module
3. bgp.session → Core BGP module
4. bgp.originate → Core BGP module

Medium Priority (Important Extensions)

5. evpn.multihoming → Core EVPN module
6. ebgp.multihop → Core BGP module
7. vrrp.version → Core gateway module
8. mlag.vtep → Core VXLAN module

Low Priority (Specialized Features)

9. bgp.domain → Keep as plugin (advanced use case)
10. bonding → Keep as plugin (Linux-specific)
11. firewall.zonebased → Keep as plugin (security-specific)
12. files → Keep as plugin (utility)
13. node.clone → Keep as plugin (management)

Implementation Considerations

Code Integration Points

• BGP Module: netsim/modules/bgp.py
• Routing Module: netsim/modules/routing.py
• OSPF Module: netsim/modules/ospf.py
• EVPN Module: netsim/modules/evpn.py
• Gateway Module: netsim/modules/gateway.py
• VXLAN Module: netsim/modules/vxlan.py

Backward Compatibility

• Plugin configurations should remain functional
• Deprecation warnings for old plugin usage
• Gradual migration path

Testing Requirements

• Comprehensive test coverage for promoted features
• Device-specific validation across all supported platforms
• Integration testing with existing core modules

Conclusion

Recommended for Promotion: 8 plugins (50%)

• 4 BGP-related plugins (most critical)
• 2 routing protocol extensions
• 2 redundancy/high-availability features

Keep as Plugins: 14 plugins (50%)

• Specialized/advanced features
• Platform-specific functionality
• Development/testing utilities
• Management utilities

This migration would significantly enhance netlab's core functionality while maintaining plugin flexibility for specialized use cases.

[ipspace]

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

They are also a nice way to divide-and-conquer code complexity. Imagine having a BGP template that includes all the nerd knobs that we have in bgp.session and bgp.policy plugins. Same for the BGP code.

Here's an AI generated analysis of candidate features in plug-ins, and suggested target modules:
[...]
This migration would significantly enhance netlab's core functionality while maintaining plugin flexibility for specialized use cases.

While the analysis is not bad, the conclusion is a bit on the marketing side ;) Also, we could decide to auto-load some plugins with the respective modules, automatically gaining extra functionality while retaining multiple templates and isolating specialized code.