USHIFT-7382: Add MTU boundary tests for C2CC and C2CC+IPsec#7024
USHIFT-7382: Add MTU boundary tests for C2CC and C2CC+IPsec#7024agullon wants to merge 17 commits into
Conversation
|
Skipping CI for Draft Pull Request. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: agullon The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughAdds a hardened ChangesIPsec MTU/DF-bit test coverage
Estimated code review effort: 3 (Moderate) | ~25 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 12 | ❌ 3❌ Failed checks (3 warnings)
✅ Passed checks (12 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
/test e2e-aws-tests-bootc-c2cc |
|
Caution Failed to replace (edit) comment. This is likely due to insufficient permissions or the comment being deleted. Error details |
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (3)
test/bin/c2cc_common.sh (1)
363-383: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winUnchecked command results in
configure_pod_mtu/restart_microshift_and_wait.Neither the
teewrite inconfigure_pod_mtunor thesystemctl restart microshiftinrestart_microshift_and_waitcheckrun_command_on_vm's return code. Failures will only surface later (if at all) viawait_for_greenboot_on_hosts/the bigmtu.robot MTU assertion, with a less specific error than at the point of failure. Existing helpers in this file (e.g.full_vm_name) use|| return 1for this purpose.🩹 Proposed fix
configure_pod_mtu() { local -r mtu=$1 for host in host1 host2 host3; do run_command_on_vm "${host}" "sudo tee /etc/microshift/ovn.yaml > /dev/null <<EOF mtu: ${mtu} -EOF" +EOF" || { echo "${host}: failed to write ovn.yaml" >&2; return 1; } done }restart_microshift_and_wait() { local -r junit_label="${1:-bigmtu_greenboot}" for host in host1 host2 host3; do - run_command_on_vm "${host}" "sudo systemctl restart microshift" + run_command_on_vm "${host}" "sudo systemctl restart microshift" || { echo "${host}: failed to restart microshift" >&2; return 1; } done🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@test/bin/c2cc_common.sh` around lines 363 - 383, The `configure_pod_mtu` and `restart_microshift_and_wait` helpers ignore failures from `run_command_on_vm`, so add explicit return-code propagation for the `tee` write and the `systemctl restart microshift` command. Use the same `|| return 1` pattern already used by helpers like `full_vm_name` so these functions fail immediately at the point of error rather than only surfacing later in `wait_for_greenboot_on_hosts` or tunnel checks.test/assets/c2cc/nettest-pod.yaml (1)
8-19: 🔒 Security & Privacy | 🔵 Trivial | ⚡ Quick winHarden nettest-pod further per manifest guidelines.
Missing
readOnlyRootFilesystem: true, container resource limits, andautomountServiceAccountToken: false(this pod doesn't need API access). As per path instructions: "securityContext: runAsNonRoot, readOnlyRootFilesystem, allowPrivilegeEscalation: false", "Resource limits (cpu, memory) on every container", and "automountServiceAccountToken: false unless needed".🔒 Proposed hardening
spec: terminationGracePeriodSeconds: 0 + automountServiceAccountToken: false containers: - name: nettest image: registry.access.redhat.com/ubi9/ubi:9.6 command: ["sleep", "infinity"] securityContext: allowPrivilegeEscalation: false + readOnlyRootFilesystem: true capabilities: drop: - ALL runAsNonRoot: true runAsUser: 10001 seccompProfile: type: RuntimeDefault + resources: + limits: + cpu: 100m + memory: 64Mi + requests: + cpu: 50m + memory: 32Mi🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@test/assets/c2cc/nettest-pod.yaml` around lines 8 - 19, The nettest pod spec is missing required hardening settings; update the nettest container and pod manifest to match the security guidelines. In the nettest container definition, add readOnlyRootFilesystem: true alongside the existing securityContext settings, and add cpu/memory resource limits for the container. Also set automountServiceAccountToken: false at the pod level since this test pod does not need API access.Source: Path instructions
test/resources/ipsec.resource (1)
143-151: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick winDocstring claims EMSGSIZE is asserted, but the check only verifies absence of "OK".
The docstring says this keyword Asserts EMSGSIZE (Message too long), but
Should Not Contain ${stdout} OKwill also pass for any unrelated failure (pod not found,ocCLI error, python traceback for a different reason, transient exec failure). This decouples the assertion from the actual MTU-boundary condition it's meant to verify, making the test pass for the wrong reason.Also note the near-duplicate Python one-liner between this keyword and
Ping With DF Bit And Verify(Lines 130-141) — worth extracting into a shared variable/keyword to avoid divergence if the socket options ever need adjusting.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@test/resources/ipsec.resource` around lines 143 - 151, The `Ping With DF Bit Should Fail` keyword currently only checks that `${stdout}` does not contain "OK", so it can pass for unrelated errors instead of proving EMSGSIZE; update the assertion to verify the expected "Message too long"/EMSGSIZE failure from the `Oc On Cluster`/`oc exec` command path. Keep the check tied to the actual DF-bit UDP send behavior in this keyword, and consider extracting the repeated Python socket one-liner shared with `Ping With DF Bit And Verify` into a common variable or helper keyword to avoid future drift.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@test/resources/ipsec.resource`:
- Around line 130-152: The DF-bit UDP checks in Ping With DF Bit And Verify only
validate local send success via the inline Python3 `socket.sendto()` path, so
oversize packets can still print OK even when the encapsulated packet is later
dropped. Update these helpers to verify delivery from the peer side by adding an
echo/ack check or by retrying the send in the `Oc On Cluster` command before
asserting success/failure, and keep the assertions in `Should Contain` / `Should
Not Contain` aligned with that delivery confirmation.
In `@test/suites/c2cc-ipsec/bigmtu.robot`:
- Around line 69-73: The Jumbo MTU Large TCP Transfer case is calling a keyword
that is only defined in the sibling suite file, so it is not available here.
Move Send Large Payload And Verify out of the ipsec.robot *** Keywords ***
section into the shared ipsec.resource file, then update both bigmtu.robot and
ipsec.robot to use the shared keyword so the suite import can resolve it.
---
Nitpick comments:
In `@test/assets/c2cc/nettest-pod.yaml`:
- Around line 8-19: The nettest pod spec is missing required hardening settings;
update the nettest container and pod manifest to match the security guidelines.
In the nettest container definition, add readOnlyRootFilesystem: true alongside
the existing securityContext settings, and add cpu/memory resource limits for
the container. Also set automountServiceAccountToken: false at the pod level
since this test pod does not need API access.
In `@test/bin/c2cc_common.sh`:
- Around line 363-383: The `configure_pod_mtu` and `restart_microshift_and_wait`
helpers ignore failures from `run_command_on_vm`, so add explicit return-code
propagation for the `tee` write and the `systemctl restart microshift` command.
Use the same `|| return 1` pattern already used by helpers like `full_vm_name`
so these functions fail immediately at the point of error rather than only
surfacing later in `wait_for_greenboot_on_hosts` or tunnel checks.
In `@test/resources/ipsec.resource`:
- Around line 143-151: The `Ping With DF Bit Should Fail` keyword currently only
checks that `${stdout}` does not contain "OK", so it can pass for unrelated
errors instead of proving EMSGSIZE; update the assertion to verify the expected
"Message too long"/EMSGSIZE failure from the `Oc On Cluster`/`oc exec` command
path. Keep the check tied to the actual DF-bit UDP send behavior in this
keyword, and consider extracting the repeated Python socket one-liner shared
with `Ping With DF Bit And Verify` into a common variable or helper keyword to
avoid future drift.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: ad866bf9-8cb2-4661-84c1-89b6ba52bf02
📒 Files selected for processing (8)
test/assets/c2cc/nettest-pod.yamltest/bin/c2cc_common.shtest/resources/c2cc.resourcetest/resources/ipsec.resourcetest/scenarios-bootc/c2cc/el102-src@c2cc-ipsec.shtest/scenarios-bootc/c2cc/el98-src@c2cc-ipsec.shtest/suites/c2cc-ipsec/bigmtu.robottest/suites/c2cc-ipsec/ipsec.robot
|
Addressed CodeRabbit nitpick findings:
|
|
/test e2e-aws-tests-bootc-c2cc |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
test/resources/ipsec.resource (1)
161-167: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winCapture stderr for easier failure diagnosis.
Unlike the DF-bit keywords (which redirect
2>&1), this command doesn't capture curl/dd stderr into${stdout}, so a failedShould Contain Hello fromassertion won't show why (e.g., curl connection error, timeout).♻️ Suggested tweak
${stdout}= Oc On Cluster ... ${alias} - ... oc exec curl-pod -n ${NAMESPACES}[${alias}] -- sh -c 'dd if=/dev/zero bs=${size} count=1 2>/dev/null | curl -sS --max-time 15 --data-binary `@-` http://${ip}:8080/cgi-bin/hello' + ... oc exec curl-pod -n ${NAMESPACES}[${alias}] -- sh -c 'dd if=/dev/zero bs=${size} count=1 2>/dev/null | curl -sS --max-time 15 --data-binary `@-` http://${ip}:8080/cgi-bin/hello' 2>&1🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@test/resources/ipsec.resource` around lines 161 - 167, The Send Large Payload And Verify keyword currently does not capture curl/dd stderr, so failures in the Oc On Cluster command are hard to diagnose. Update the shell command inside this keyword to redirect stderr into stdout the same way the DF-bit keywords do, so ${stdout} includes curl or dd error details before the Should Contain assertion runs. Keep the change localized to Send Large Payload And Verify and preserve the existing behavior otherwise.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@test/resources/ipsec.resource`:
- Around line 161-167: The Send Large Payload And Verify keyword currently does
not capture curl/dd stderr, so failures in the Oc On Cluster command are hard to
diagnose. Update the shell command inside this keyword to redirect stderr into
stdout the same way the DF-bit keywords do, so ${stdout} includes curl or dd
error details before the Should Contain assertion runs. Keep the change
localized to Send Large Payload And Verify and preserve the existing behavior
otherwise.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: b50d1ba5-ac25-443a-85f8-de8ec321520a
📒 Files selected for processing (2)
test/resources/ipsec.resourcetest/suites/c2cc-ipsec/ipsec.robot
💤 Files with no reviewable changes (1)
- test/suites/c2cc-ipsec/ipsec.robot
53b1ace to
096f15f
Compare
There was a problem hiding this comment.
🧹 Nitpick comments (2)
test/suites/c2cc/ipsec/mtu.robot (2)
101-112: 🎯 Functional Correctness | 🔵 Trivial | 💤 Low valueFragile default-interface detection.
ip route show default | awk '{print $5}' | head -1assumes exactly one relevant default route; with dual-stack or ECMP routes,head -1may pick an interface that isn't the one actually carrying traffic, silently mis-targeting the MTU change.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@test/suites/c2cc/ipsec/mtu.robot` around lines 101 - 112, The default-interface lookup in Configure Jumbo MTU On All Clusters is too fragile because it relies on a single routed result and head -1. Update the Command On Cluster command used to determine ${iface} so it selects the actual egress interface more robustly, and keep the rest of the MTU change/verification flow unchanged. Use the Configure Jumbo MTU On All Clusters keyword and the ${iface} assignment as the main place to fix this.
60-66: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚖️ Poor tradeoffStateful setup disguised as a test case.
Reconfigure Pod MTU To 8900mutates cluster infra (config, restart, redeploy) as a regular test case rather than a[Setup]/suite fixture. If this test is filtered out, skipped, or fails partway, later Phase 3 tests (Verify Pod MTU Configuration,Jumbo MTU At Reduced Pod MTU, etc.) will silently execute against an undefined MTU state and produce misleading pass/fail results, with no repair path inTeardown. The suite comment acknowledgesTEST_RANDOMIZATION=noneas the safeguard, but partial failure of this one test case is not handled by the current teardown/setup structure.Consider moving this into the suite structure as an explicit
[Setup]for a nested test block, or ensure downstream tests defensively re-verify pod MTU rather than assuming success of a prior sibling test case.Also applies to: 86-90
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@test/suites/c2cc/ipsec/mtu.robot` around lines 60 - 66, The MTU reconfiguration step is currently implemented as a regular test case in Reconfigure Pod MTU To 8900, which makes later Phase 3 tests depend on a sibling test’s success. Move the cluster mutation logic into suite-level setup for the Phase 3 block, or into a dedicated nested [Setup] fixture, so Configure Pod MTU On All Clusters, Restart MicroShift On All Clusters, and Redeploy Test Workloads always run before Verify Pod MTU Configuration and Jumbo MTU At Reduced Pod MTU. If you keep the test case, add defensive re-verification in the downstream checks so they do not assume the prior state transition succeeded.Source: Learnings
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@test/suites/c2cc/ipsec/mtu.robot`:
- Around line 101-112: The default-interface lookup in Configure Jumbo MTU On
All Clusters is too fragile because it relies on a single routed result and head
-1. Update the Command On Cluster command used to determine ${iface} so it
selects the actual egress interface more robustly, and keep the rest of the MTU
change/verification flow unchanged. Use the Configure Jumbo MTU On All Clusters
keyword and the ${iface} assignment as the main place to fix this.
- Around line 60-66: The MTU reconfiguration step is currently implemented as a
regular test case in Reconfigure Pod MTU To 8900, which makes later Phase 3
tests depend on a sibling test’s success. Move the cluster mutation logic into
suite-level setup for the Phase 3 block, or into a dedicated nested [Setup]
fixture, so Configure Pod MTU On All Clusters, Restart MicroShift On All
Clusters, and Redeploy Test Workloads always run before Verify Pod MTU
Configuration and Jumbo MTU At Reduced Pod MTU. If you keep the test case, add
defensive re-verification in the downstream checks so they do not assume the
prior state transition succeeded.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository YAML (base), Central YAML (inherited)
Review profile: CHILL
Plan: Enterprise
Run ID: c8d367af-0c47-4a80-8c6a-7b8945ef3cf4
📒 Files selected for processing (1)
test/suites/c2cc/ipsec/mtu.robot
f631e3f to
a06baac
Compare
|
/test e2e-aws-tests-bootc-c2cc |
a06baac to
958ac82
Compare
|
/test e2e-aws-tests-bootc-c2cc |
958ac82 to
8cdb214
Compare
|
/test e2e-aws-tests-bootc-c2cc |
176c9b3 to
78b9d67
Compare
|
/test e2e-aws-tests-bootc-c2cc |
a590b9c to
8570b5a
Compare
|
@agullon: This pull request references USHIFT-7382 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
/test e2e-aws-tests-bootc-c2cc |
Add infrastructure for testing MTU boundaries using UDP datagrams with the DF (Don't Fragment) bit set via Python3 IP_PMTUDISC_DO sockets. This avoids NET_RAW capability so the test pod complies with the restricted PodSecurity standard. New test pod: - nettest-pod (UBI9 with Python3, no package installation needed) New shared keywords in ipsec.resource: - Ping With DF Bit And Verify / Should Fail (single-pair) - Ping DF Bit Between All Clusters / Should Fail (full 6-pair mesh) - Large Payload Between All Clusters (full 6-pair mesh) - Get Pod Interface MTU - Send Large Payload And Verify (moved from ipsec.robot) New tests in ipsec.robot (1500 MTU, no infrastructure changes): - DF Bit 64B, 1350B, 1450B pass through IPsec - DF Bit 1472B rejected at pod MTU boundary (1472+28=1500) - 64KB TCP transfer through IPsec Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
Add a scenario that creates VMs on a jumbo-frame libvirt network (MTU 9000) and tests C2CC MTU boundaries without IPsec. The libvirt network XML includes <mtu size='9000'/> which sets the hypervisor bridge and all tap devices to 9000, enabling end-to-end jumbo frame support between VMs. Tests (all 6 cluster pairs): - DF Bit 64B, 8400B, 8872B, 8950B pass - DF Bit 8972B rejected at pod MTU (8972+28=9000) - 64KB TCP transfer - Full C2CC connectivity with source IP preservation Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
Add a scenario that creates VMs on a jumbo-frame network with IPsec and tests MTU boundaries through ESP tunnel-mode encapsulation. Two phases (ordered by TEST_RANDOMIZATION=none): Phase 1 — pod MTU 9000 (auto-detected from the jumbo network): - DF Bit boundary tests at 64B, 8400B, 8872B, 8950B (pass) and 8972B (rejected at pod MTU) - 64KB TCP transfer through IPsec - ESP encapsulation verified via XFRM byte counters Phase 2 — pod MTU 8900 (set via /etc/microshift/ovn.yaml): - Validates the doc recommendation to reduce pod MTU by ~100 for ESP headroom on jumbo networks - Verifies pod interface reports MTU 8900 after restart - Full pod MTU payload (8872B) passes through IPsec because 8900 + ESP overhead fits within the 9000 physical MTU - Full C2CC connectivity with source IP preservation Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
CI showed pod interfaces stuck at MTU 1500 even on the jumbo libvirt network, causing every DF-bit payload over ~1450 bytes to fail with "Message too long" and the pod MTU 8900 override to silently no-op. Root cause: a libvirt network's own <mtu size='9000'/> element only sets the MTU of the host-side bridge and tap devices. The guest's virtio-net driver only sees a larger interface MTU if QEMU also negotiates it via the domain's own <interface> XML — which requires an explicit mtu.size on the virt-install --network argument. Without it, guest NICs default to 1500 regardless of what the underlying tap/bridge supports. Add a --network_mtu option to launch_vm() in scenario.sh that appends mtu.size=<value> to the virt-install network argument, thread it through c2cc_create_vms() as a new optional 5th parameter, and pass "9000" from the c2cc-mtu and c2cc-ipsec-mtu scenario scripts. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
Add IPv4/IPv6 auto-detection (based on ':' in the address, matching the pattern already used by Curl From Cluster in c2cc.resource) to: - Ping With DF Bit And Verify / Should Fail: use AF_INET6 + IPPROTO_IPV6/IPV6_DONTFRAG when the destination is IPv6, instead of always hardcoding AF_INET + IP_MTU_DISCOVER/IP_PMTUDISC_DO. - Send Large Payload And Verify, Curl Should Fail From Cluster, Curl From Host Should Fail: wrap the URL host in brackets for IPv6. - Add NFTables IPsec Enforcement Rules: use "ip6 daddr" instead of "ip daddr" when the CIDR is IPv6. No caller changes needed — the family is inferred from the address values already passed in (Get Hello Pod IP returns whatever family the cluster is configured for). IPv4 behavior is unchanged. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
New jumbo-ipv6 network (single-stack IPv6, NAT, MTU 9000) and its
creation function, mirroring the existing IPv4 jumbo network. Kept
separate from the shared VM_IPV6_NETWORK ("ipv6") so bumping MTU for
jumbo-frame tests doesn't affect other IPv6 C2CC scenarios.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
pre-commit.check-secrets: ENABLED
IPv6 variant of c2cc-ipsec: same suite (suites/c2cc/extra/ipsec.robot), same 1500 MTU, over a single-stack IPv6 network instead of IPv4. Follows the existing c2cc-ipv6 scenario's pattern for the IPv6 bridge IP, web server URL, and mirror registry overrides. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
IPv6 variant of c2cc-mtu: same suite (suites/c2cc/extra/mtu.robot), jumbo MTU (9000), plain C2CC without IPsec, over the new jumbo-ipv6 libvirt network. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
IPv6 variant of c2cc-ipsec-mtu: same suite (suites/c2cc/extra/ipsec-mtu.robot), IPsec at jumbo MTU (9000) with the two-phase pod MTU 8900 validation, over the new jumbo-ipv6 libvirt network. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
Rename c2cc-ipsec, c2cc-mtu, and c2cc-ipsec-mtu (el98/el102) to c2cc-ipsec-ipv4, c2cc-mtu-ipv4, and c2cc-ipsec-mtu-ipv4 for symmetry with their c2cc-ipsec-ipv6, c2cc-mtu-ipv6, and c2cc-ipsec-mtu-ipv6 siblings added in this PR. Filenames only — no functional changes. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
Append .disabled to all c2cc scenario files not touched by this PR so CI only runs the MTU/IPsec scenarios under test. Revert before merge. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
1217b3a to
ddb6027
Compare
|
/test e2e-aws-tests-bootc-c2cc |
The virt-install mtu.size option is silently ignored by some QEMU/libvirt versions, leaving guest NICs at 1500 despite the jumbo libvirt network. Set the NIC MTU via NetworkManager in the kickstart post-install script instead, so the guest boots with the correct MTU before MicroShift first starts. When OVN-K creates br-ex on first boot, it inherits the NIC's 9000 MTU. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
The jumbo-ipv6 network is created on-the-fly by the scenario, but its bridge IPv6 subnet was not added to the firewall trusted zone. VMs on that network couldn't reach the hypervisor's kickstart web server or mirror registry, causing virt-install to time out. The standard IPv6 network gets firewall rules via manage_hypervisor_config.sh, but jumbo-ipv6 needs them explicitly since it's not in the managed network list. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
|
/test e2e-aws-tests-bootc-c2cc |
The previous inject_kickstart_mtu ran nmcli directly in the kickstart %post section, but NM isn't running inside the chroot so the command silently fails. Replace with a oneshot systemd service (set-jumbo-mtu.service) that: - Runs After=NetworkManager-wait-online.service (NM is up) - Runs Before=microshift.service (MTU set before OVN-K reads it) - Uses nmcli to set MTU on the active ethernet connection - Gets systemctl-enabled during kickstart (just creates symlinks) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
The VM_BRIDGE_IP and WEB_SERVER_URL assignments ran at file-source time (top-level code), but the jumbo-ipv6 network doesn't exist until scenario_create_vms() calls c2cc_create_jumbo_ipv6_network(). This produced an empty bridge IP and a broken URL (http://[]:8080), causing VM installation to fail because it couldn't reach the kickstart server. Move the bridge IP lookup inside scenario_create_vms(), after the network is created. The existing c2cc-ipv6.sh doesn't have this problem because the shared "ipv6" network is pre-created by manage_hypervisor_config.sh before any scenarios run. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
|
/test e2e-aws-tests-bootc-c2cc |
Two fixes for jumbo frame CI failures: 1. Replace systemd oneshot service with a NetworkManager connection profile file (jumbo-mtu.nmconnection) written directly in kickstart %post. NM reads connection files from disk at startup — no running daemon needed during install. The previous systemd service approach was not setting the NIC MTU before MicroShift started, leaving pod MTU stuck at 1500. 2. After creating the jumbo-ipv6 libvirt network, wait for IPv6 DAD (Duplicate Address Detection) to complete on the bridge interface. Until DAD finishes, the address is in "tentative" state and nginx cannot bind to it, causing kickstart fetch failures and VM boot timeouts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
|
/test e2e-aws-tests-bootc-c2cc |
Three changes to fix jumbo MTU CI failures: 1. Replace NM connection profile with three-layer MTU approach: - udev rule (earliest, sets MTU at device detection) - NM conf.d (default MTU for auto-created connections) - systemd service with manual enable (ip link set fallback) The NM connection profile alone failed because NM auto-creates a device-specific connection that overrides generic profiles. 2. Replace DAD tentative-flag check with a curl readiness poll: wait until the web server is actually reachable on the new IPv6 bridge address, which subsumes both DAD completion and any other transient connectivity issues. 3. Fix jumbo MTU test boundaries: OVN-K subtracts 78B Geneve overhead in multinode mode, so auto-detected pod MTU from a 9000 NIC is 8922, not 9000. Changed the near-boundary test from 8950B (which exceeds 8922) to 8850B (safely below). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> pre-commit.check-secrets: ENABLED
|
/test e2e-aws-tests-bootc-c2cc |
|
@agullon: The following tests failed, say
Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
Summary
Jira: USHIFT-7382
Add MTU boundary tests that verify packet acceptance and rejection at the pod MTU using UDP datagrams with the DF (Don't Fragment) bit set. Tests cover both plain C2CC and C2CC with IPsec, at 1500 (default) and 9000 (jumbo) MTU.
What's tested
1500 MTU (in existing
c2cc-ipsecscenario, no infrastructure changes):9000 MTU — plain C2CC (new
c2cc-mtuscenario):<mtu size='9000'/>)9000 MTU — C2CC with IPsec (new
c2cc-ipsec-mtuscenario):/etc/microshift/ovn.yaml) — validates the doc recommendation to reduce pod MTU by ~100 for ESP headroomHow it works
Uses Python3 UDP sockets with
IP_PMTUDISC_DO(setsockopt IPPROTO_IP, 10, 2) to set the DF bit. This avoidsNET_RAWcapability so the test pod (nettest-pod) complies with therestrictedPodSecurity standard. UDP overhead (28B) matches ICMP overhead, so payload sizes are equivalent toping -svalues.Files
test/assets/c2cc/nettest-pod.yamltest/resources/ipsec.resource,test/resources/c2cc.resourcetest/suites/c2cc/extra/ipsec.robottest/assets/network/jumbo-network.xml,test/bin/c2cc_common.shtest/suites/c2cc/extra/mtu.robot,test/scenarios-bootc/c2cc/el{98,102}-src@c2cc-mtu.shtest/suites/c2cc/extra/ipsec-mtu.robot,test/scenarios-bootc/c2cc/el{98,102}-src@c2cc-ipsec-mtu.shTest plan
el{98,102}-src@c2cc-ipsec— 1500 MTU DF-bit tests pass, existing IPsec tests unaffectedel{98,102}-src@c2cc-mtu— jumbo plain C2CC tests passel{98,102}-src@c2cc-ipsec-mtu— jumbo IPsec tests pass, pod MTU 8900 validatedel{98,102}-src@c2cc— unaffected (nettest-pod deploys cleanly)🤖 Generated with Claude Code