[multicast] prevent VLAN translation via match key enforcement#195
Open
zeeshanlakhani wants to merge 6 commits intomainfrom
Open
[multicast] prevent VLAN translation via match key enforcement#195zeeshanlakhani wants to merge 6 commits intomainfrom
zeeshanlakhani wants to merge 6 commits intomainfrom
Conversation
…tering Underlay changes: - Restrict internal multicast from admin/site/org scoped (ff04, ff05, ff08) to just Omicron's reserved subnet (ff04::/64). These underlay addresses are made unique in Omicron. - Rename `AdminScopedIpv6` to `UnderlayMulticastIpv6`. - Simplify P4 to only match ff04::/64. - Use omicron-common multicast constants for validation. Source filtering changes: - Replace IpSrc::Subnet with IpSrc::Any for any-source matching. - Change IPv6 source filter from exact to LPM match. - Allow source filters on ASM groups (previously SSM-only). API changes: - API v5 adds IpSrc::Any for ASM source filtering. - API v6 enforces strict underlay subnet validation.
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
force-pushed
the
vlan-translation
branch
from
16ee0d2 to
e15d9e0
Compare
…ation_ids This includes some cleanup as well.
zeeshanlakhani
force-pushed
the
zl/admin-scope-oxnet
branch
from
1c3d2b8 to
a1c8a94
Compare
zeeshanlakhani
force-pushed
the
vlan-translation
branch
from
b0eb9c2 to
3adf3d8
Compare
zeeshanlakhani
force-pushed
the
vlan-translation
branch
from
3adf3d8 to
878c737
Compare
| /// 2. Correctly tagged ingress match -> forward (for already-tagged packets) | ||
| /// | ||
| /// This allows both packet types to match, while packets with the wrong VLAN | ||
| /// will miss both entries and not be NAT encapsulated. |
Contributor
There was a problem hiding this comment.
I'm not sure we need to push two table entries here per IP family. The reason being that we should never actually see a decapsulated multicast packet at the NatIngress table where ingress_ipv4_mcast and ingress_ipv6_mcast reside, due to the outermost !hdr.geneve.isValid() check. So the only purpose of this table is checking traffic from customer ports, and not underlay traffic from our sleds. (Unless we're looking to provide multicast transit for the control plane, but that seems unlikely). So exact matches should suffice here?
Contributor
Author
There was a problem hiding this comment.
Ah, yeah, ok, that makes sense in the logic.
Contributor
Author
There was a problem hiding this comment.
I'll fix that with the conflict updates.
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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):
Multicast router VLAN handling (sidecar.p4):
Rollback changes:
Counter fix:
Pull Request: #194