-
Notifications
You must be signed in to change notification settings - Fork 2
[multicast] prevent VLAN translation via match key enforcement #194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
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
Created using jj-spr 0.1.0
zeeshanlakhani
added a commit
that referenced
this pull request
Jan 22, 2026
Fixes #107. Stacked on #189. This adds VLAN-aware NAT ingress matching to prevent cross-VLAN translation. Previously, a packet arriving with VLAN 100 destined to a multicast group configured for VLAN 200 would be NAT encapsulated and forwarded, effectively translating the packet to the wrong customer's network. NAT ingress table matching (mcast_nat.rs, mod.rs): - Add Ipv4VlanMatchKey and Ipv6VlanMatchKey that match on destination address, VLAN header validity, and VLAN ID - For groups with VLAN, install two entries: untagged (for decapsulated Geneve from underlay) and correctly tagged (for customer packets) - Packets with the wrong VLAN miss both entries and are not NAT encapsulated Multicast router VLAN handling (sidecar.p4): - Strip incoming VLAN tag before routing lookup in MulticastRouter4/6 - forward_vlan action re-adds the group's configured VLAN on egress - Prevents unintended VLAN translation at the routing stage Rollback changes: - Remove dead NAT rollback branches for internal groups (no NAT entries) - Add rollback support for VLAN changes in NAT and route tables Counter fix: - The underlay multicast counter condition was unreachable for packets tagged MULTICAST_TAG_UNDERLAY_EXTERNAL that were not decapped. The check for == MULTICAST_TAG_UNDERLAY excluded these packets, causing them to fall through to the external counter. Pull Request: #194
zeeshanlakhani
added a commit
that referenced
this pull request
Jan 22, 2026
Fixes #107. Stacked on #189. This adds VLAN-aware NAT ingress matching to prevent cross-VLAN translation. Previously, a packet arriving with VLAN 100 destined to a multicast group configured for VLAN 200 would be NAT encapsulated and forwarded, effectively translating the packet to the wrong customer's network. NAT ingress table matching (mcast_nat.rs, mod.rs): - Add Ipv4VlanMatchKey and Ipv6VlanMatchKey that match on destination address, VLAN header validity, and VLAN ID - For groups with VLAN, install two entries: untagged (for decapsulated Geneve from underlay) and correctly tagged (for customer packets) - Packets with the wrong VLAN miss both entries and are not NAT encapsulated Multicast router VLAN handling (sidecar.p4): - Strip incoming VLAN tag before routing lookup in MulticastRouter4/6 - forward_vlan action re-adds the group's configured VLAN on egress - Prevents unintended VLAN translation at the routing stage Rollback changes: - Remove dead NAT rollback branches for internal groups (no NAT entries) - Add rollback support for VLAN changes in NAT and route tables Counter fix: - The underlay multicast counter condition was unreachable for packets tagged MULTICAST_TAG_UNDERLAY_EXTERNAL that were not decapped. The check for == MULTICAST_TAG_UNDERLAY excluded these packets, causing them to fall through to the external counter. Pull Request: #194
zeeshanlakhani
added a commit
that referenced
this pull request
Jan 22, 2026
Fixes #107. Stacked on #189. This adds VLAN-aware NAT ingress matching to prevent cross-VLAN translation. Previously, a packet arriving with VLAN 100 destined to a multicast group configured for VLAN 200 would be NAT encapsulated and forwarded, effectively translating the packet to the wrong customer's network. NAT ingress table matching (mcast_nat.rs, mod.rs): - Add Ipv4VlanMatchKey and Ipv6VlanMatchKey that match on destination address, VLAN header validity, and VLAN ID - For groups with VLAN, install two entries: untagged (for decapsulated Geneve from underlay) and correctly tagged (for customer packets) - Packets with the wrong VLAN miss both entries and are not NAT encapsulated Multicast router VLAN handling (sidecar.p4): - Strip incoming VLAN tag before routing lookup in MulticastRouter4/6 - forward_vlan action re-adds the group's configured VLAN on egress - Prevents unintended VLAN translation at the routing stage Rollback changes: - Remove dead NAT rollback branches for internal groups (no NAT entries) - Add rollback support for VLAN changes in NAT and route tables Counter fix: - The underlay multicast counter condition was unreachable for packets tagged MULTICAST_TAG_UNDERLAY_EXTERNAL that were not decapped. The check for == MULTICAST_TAG_UNDERLAY excluded these packets, causing them to fall through to the external counter. Pull Request: #194
zeeshanlakhani
added a commit
that referenced
this pull request
Jan 22, 2026
Fixes #107. Stacked on #189. This adds VLAN-aware NAT ingress matching to prevent cross-VLAN translation. Previously, a packet arriving with VLAN 100 destined to a multicast group configured for VLAN 200 would be NAT encapsulated and forwarded, effectively translating the packet to the wrong customer's network. NAT ingress table matching (mcast_nat.rs, mod.rs): - Add Ipv4VlanMatchKey and Ipv6VlanMatchKey that match on destination address, VLAN header validity, and VLAN ID - For groups with VLAN, install two entries: untagged (for decapsulated Geneve from underlay) and correctly tagged (for customer packets) - Packets with the wrong VLAN miss both entries and are not NAT encapsulated Multicast router VLAN handling (sidecar.p4): - Strip incoming VLAN tag before routing lookup in MulticastRouter4/6 - forward_vlan action re-adds the group's configured VLAN on egress - Prevents unintended VLAN translation at the routing stage Rollback changes: - Remove dead NAT rollback branches for internal groups (no NAT entries) - Add rollback support for VLAN changes in NAT and route tables Counter fix: - The underlay multicast counter condition was unreachable for packets tagged MULTICAST_TAG_UNDERLAY_EXTERNAL that were not decapped. The check for == MULTICAST_TAG_UNDERLAY excluded these packets, causing them to fall through to the external counter. Pull Request: #194
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.
Fixes #107.
Stacked on #189.
This adds VLAN-aware NAT ingress matching to prevent cross-VLAN translation.
Previously, a packet arriving with VLAN 100 destined to a multicast group
configured for VLAN 200 would be NAT encapsulated and forwarded, effectively
translating the packet to the wrong customer's network.
NAT ingress table matching (mcast_nat.rs, mod.rs):
VLAN header validity, and VLAN ID
from underlay) and correctly tagged (for customer packets)
Multicast router VLAN handling (sidecar.p4):
Rollback changes:
Counter fix:
MULTICAST_TAG_UNDERLAY_EXTERNAL that were not decapped. The check for
== MULTICAST_TAG_UNDERLAY excluded these packets, causing them to fall
through to the external counter.