[multicast] Drop (m)vlan from multicast groups #9451
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR also addresses permission models, object deletion, and error handling questions related to reserved addresses presented in @askfongjojo's testing Google Doc (default IP Pools are covered in a follow-up, stacked PR). In thinking through the *Groups* API, permission scopes, and flexibility, @rcgoodfellow mentioned this consideration: > Do we need an explicit notion of a group object at all? Or can > instances simply allocate/deallocate group IPs from pools, and there is > no explicit management of group objects. With Fleet admins having access control to create pools and link silos to a pool, we arrived at the idea of replacing the current explicit multicast group CRUD with an implicit lifecycle, where groups are created upon the first member join and deleted when the last member leaves. **Note**: Most of the PR's changes are test-related due to moving away from the explicit multicast group(s) lifecycle. Auth Model: - Discovery (fleet-scoped): - Read/list groups and list members: any authenticated user in the same fleet. - Membership (project-scoped): - Join/leave requires Instance::Modify on the specific instance. - Creation control: - Implicit group creation only when the s silo is linked to a suitable multicast pool (by name or by explicit IP in that pool). Behavior: - Implicit lifecycle: - Create on first join (idempotent); delete when last member leaves (atomic mark-for-removal, reconciler schedules cleanup). - Addressing and validation: - Implicit allocation from the s linked multicast pools. - SSM/ASM semantics enforced: - IPv4 SSM 232/8 and IPv6 ff3x::/32 - Error handling: - Reserved/invalid multicast ranges rejected at pool/range add time. API: - Primary flows: - Group-centric member management: POST/DELETE /v1/multicast-groups/{group}/members - Instance-centric join/leave: PUT/DELETE /v1/instances/{instance}/multicast-groups/{group} - Discovery endpoints remain for list/view; there is no explicit group create/update/delete. - This is a *breaking* change, but multicast is not yet enabled or available in production Key changes: - Implicit group model; groups exist while they have members. - IP pool integration for multicast allocation with silo link gating. - Simplified API centered on join/leave flows. - Add multicast_ip to the member table for responses. - For consistency, move to `Instant` type over `SystemTime` for mcast-related caches Follow-ups (stacked PRs) - [ ] Remove MVLAN from group data model. - [ ] Default IP pool support (IPv4/IPv6 Followrequire unicast/multicast). - [ ] Dendrite: use omicron-common constants for validation.
4 tasks
zeeshanlakhani
requested review from
FelixMcFelix,
internet-diglett and
rcgoodfellow
Egress multicast (instances sending to external receivers) is not in MVP scope, so the MVLAN field for VLAN-tagged upstream traffic is unnecessary, as it probably won't be attached specifically to a group, and is worth revisiting. Changes: - Drop mvlan column from multicast_group table (schema v213) - Remove mvlan from Rust structs, SQL queries, and API views - Add TODO scope documentation When egress support lands, VLAN tagging will be reintroduced with proper uplink port configuration.
zeeshanlakhani
force-pushed
the
zl/drop-mvlan-from-group
branch
from
05ed654 to
68a0df3
Compare
…o zl/drop-mvlan-from-group
…o zl/drop-mvlan-from-group
…o zl/drop-mvlan-from-group
Introduce API version `VERSION_MULTICAST_IMPLICIT_LIFECYCLE_UPDATES`
(v2025120500) to support the transition from explicit to implicit
multicast group lifecycle management.
Changes in new API version:
- Groups are created implicitly when first member joins
- Groups are deleted implicitly when last member leaves
- Instance create/update accept `MulticastGroupIdentifier` (name, UUID,
or multicast IP address) instead of just `NameOrId`
- MulticastGroupMemberAdd now has optional `source_ips` for SSM
Backward compatibility (v20251120):
- Add `v20251120` module with compatibility types using `NameOrId`
- Explicit group create/update/delete endpoints marked deprecated
- Proper base64 validation for user_data via shared UserData serde helper
Also includes:
- Add version_policy to techport server for omdb compatibility
…o zl/drop-mvlan-from-group
…o zl/drop-mvlan-from-group
…o zl/drop-mvlan-from-group
…o zl/drop-mvlan-from-group
…o zl/drop-mvlan-from-group
Includes: - Remove GLOP (233/8), admin-scoped (239/8), and specific reserved address (NTP, Cisco Auto-RP, PTP) restrictions from IP pool validation - Only link-local multicast (224.0.0.0/24) is now rejected (not routable) - Add ASM pool fallback when join-by-name with source_ips finds no SSM pool linked - Allow source filtering on ASM addresses (IGMPv3/MLDv2 supports this) - SSM addresses still require sources per RFC 4607 The previous restrictions were overly conservative. Customers may have legitimate use cases for GLOP (AS-based allocations), admin-scoped (organization-local multicast), and protocol-specific addresses.
zeeshanlakhani
added a commit
that referenced
this pull request
Dec 23, 2025
Previously, each silo could only have one default IP pool. This change allows one default pool per (pool_type, ip_version) combination, enabling silos to have separate defaults for: - Unicast IPv4 - Unicast IPv6 - Multicast IPv4 - Multicast IPv6 This work previously branched off #9451, but now off `main`, involving changes that have to do with the mcast lifecycle changes. Includes: - Each default can now be set or unset and demoted independently. Unsetting the unicast IPv4 default does not affect the multicast IPv4 default, for example. - Add `pool_type` and `ip_version` columns to `ip_pool_resource` (denormalized from parent `ip_pool` for unique index) - Replace unique index with partial index on (resource_id, pool_type, ip_version) WHERE is_default = true - Rename `IpPoolResourceLink` to `IncompleteIpPoolResource` to reflect that pool_type/ip_version are actually populated by the linking query - Add `ip_version` field to API params for default pool disambiguation - API versioning for backwards compatibility with older clients
zeeshanlakhani
added a commit
that referenced
this pull request
Dec 23, 2025
Previously, each silo could only have one default IP pool. This change allows one default pool per (pool_type, ip_version) combination, enabling silos to have separate defaults for: - Unicast IPv4 - Unicast IPv6 - Multicast IPv4 - Multicast IPv6 This work previously branched off #9451, but is now off `main`, involving changes that have to do with the mcast lifecycle changes. Includes: - Each default can now be set or unset and demoted independently. Unsetting the unicast IPv4 default does not affect the multicast IPv4 default, for example. - Add `pool_type` and `ip_version` columns to `ip_pool_resource` (denormalized from parent `ip_pool` for unique index) - Replace unique index with partial index on (resource_id, pool_type, ip_version) WHERE is_default = true - Rename `IpPoolResourceLink` to `IncompleteIpPoolResource` to reflect that pool_type/ip_version are actually populated by the linking query - Add `ip_version` field to API params for default pool disambiguation - API versioning for backwards compatibility with older clients
zeeshanlakhani
added a commit
that referenced
this pull request
Dec 23, 2025
Previously, each silo could only have one default IP pool. This change allows one default pool per (pool_type, ip_version) combination, enabling silos to have separate defaults for: - Unicast IPv4 - Unicast IPv6 - Multicast IPv4 - Multicast IPv6 This work previously branched off #9451, but is now off `main`, involving changes that have to do with the mcast lifecycle changes. Includes: - Each default can now be set or unset and demoted independently. Unsetting the unicast IPv4 default does not affect the multicast IPv4 default, for example. - Add `pool_type` and `ip_version` columns to `ip_pool_resource` (denormalized from parent `ip_pool` for unique index) - Replace unique index with partial index on (resource_id, pool_type, ip_version) WHERE is_default = true - Rename `IpPoolResourceLink` to `IncompleteIpPoolResource` to reflect that pool_type/ip_version are actually populated by the linking query - Add `ip_version` field to API params for default pool disambiguation - API versioning for backwards compatibility with older clients
Previously, each silo could only have one default IP pool. This change allows one default pool per (pool_type, ip_version) combination, enabling silos to have separate defaults for: - Unicast IPv4 - Unicast IPv6 - Multicast IPv4 - Multicast IPv6 This work previously branched off #9451, but is now off `main`, involving changes that have to do with the mcast lifecycle changes. Includes: - Each default can now be set or unset and demoted independently. Unsetting the unicast IPv4 default does not affect the multicast IPv4 default, for example. - Add `pool_type` and `ip_version` columns to `ip_pool_resource` (denormalized from parent `ip_pool` for unique index) - Replace unique index with partial index on (resource_id, pool_type, ip_version) WHERE is_default = true - Rename `IpPoolResourceLink` to `IncompleteIpPoolResource` to reflect that pool_type/ip_version are actually populated by the linking query - Add `ip_version` field to API params for default pool disambiguation - API versioning for backwards compatibility with older clients
…zl/mcast-implicit-lifecycle
SSM addresses must always use specific_sources. This adds the `SourceFilterState` type with a `has_any_source_member` flag so SSM ignores it (always filters) while ASM respects it. [multicast] Fix SSM source filtering per RFC 4607
…zl/mcast-implicit-lifecycle
When joining a multicast group by name, if multiple default multicast pools of different IP versions (IPv4/IPv6) are linked to the silo, the API now accepts an optional `ip_version` parameter to select the correct pool.
Includes:
- Split multicast-implicit-lifecycle migration into 8 files (per DDL)
- Align column ordering (schema.rs, models) with dbinit.sql
- Fix raw SQL column order in group allocation and member attach CTEs
- Expand dataplane trait for DPD handling
- Update RPW reconciler for per-member source filtering
- Add comprehensive tests post IPv6 merge
- Revert changes to merged multicast-group-support migration
…ecycle Includes fixes within the conflict(s): - Versioned API cleanup: direct infallible conversions in v2025121200 (removed .expect() through v2026010300), removed unused duplicate impl - Extended path_param! macro to support custom types (MulticastGroupIdentifier) - DB constraint consistency: aligned params.rs and migrations for IPv4/IPv6 blocked ranges (up10, up11) - Test cleanup: clear out some redundancy
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Egress multicast (instances sending to external receivers) is not in MVP scope, so the MVLAN field for VLAN-tagged upstream traffic is unnecessary, as it probably won't be attached specifically to a group, and is worth revisiting.
Changes:
When egress support lands, VLAN tagging will be reintroduced with proper uplink port configuration.