Skip to content

Support BGP-based routing for STACKIT VPN #86

Description

@lweberru

Problem

The Accelerator explicitly rejects BGP_ROUTE_BASED and does not expose the gateway/connection BGP configuration, although STACKIT VPN supports BGP-based routing.

Source on main at 2bb7c75:

The module comment attributes the omission to an unknown nested-object conversion problem through provider 0.104.0. The root now pins 0.114.0. Reproduce against the pinned version before assuming that the historical provider defect still applies; this issue is not a claim that it remains broken.

The Configurator currently explains this limitation and must keep BGP unavailable until the supported Accelerator revision exposes and validates it.

Scope

  • Verify gateway and connection BGP support with the pinned provider; track a minimal upstream reproduction if a provider blocker remains.
  • Expose and wire the required gateway settings (including local ASN) and both tunnels' BGP/peering settings through single-region and regional Connectivity inputs.
  • Implement routing-mode-specific validation without requiring static routes for BGP; preserve existing policy-based and static route-based behavior.
  • Specify and test how learned routes reach SNA routing tables, including the applicable propagation/filter controls. VPN BGP does not replace general SNA routing-table management.
  • Document the remote-peer setup, any routing-type replacement implications and compatibility constraints.

References: STACKIT VPN options, original VPN implementation #23. Separate from automatic inter-region connectivity #64 and selective per-SNA VPN configuration #85.

Acceptance criteria

  • tofu validate and plan tests pass for BGP with the reviewed provider version, including values unknown until plan/apply.
  • Both tunnels receive the intended ASN and peering configuration.
  • Invalid/incomplete BGP settings are rejected with useful messages.
  • Existing policy-based/static route-based fixtures continue to pass.
  • Single-region and regional inputs are covered; current per-SNA behavior is explicit.
  • SNA route propagation expectations and remote-peer configuration are documented and verified in an explicitly authorized integration test.
  • Configurator schema, guided UI, documentation and execution guards are updated only after the Accelerator implementation is available in its reviewed engine revision.

Activity

  1. added
    area:acceleratorAccelerator Terraform/OpenTofu roots, modules and examples
    priority:p2Important improvement; schedule after P1 and prerequisites
    effort:lArchitecture, lifecycle or multiple systems; split before implementation
    enhancementNew feature or request
    needs-investigationValidate API/provider behavior or product contract before implementation
    on Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:acceleratorAccelerator Terraform/OpenTofu roots, modules and exampleseffort:lArchitecture, lifecycle or multiple systems; split before implementationenhancementNew feature or requestneeds-investigationValidate API/provider behavior or product contract before implementationpriority:p2Important improvement; schedule after P1 and prerequisites

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions