Add option to control MAC address reuse for VR public NICs

[bernardodemarco]

Description

ACS currently uses the same MAC address for the public NICs of VRs when implementing redundant VRs or when restarting an isolated network or VPC with cleanup. In the case of restarts with cleanup, ACS initializes a new VR with its NICs and subsequently applies the corresponding configuration and IP addresses.

In this scenario, when VRs are cleaned up while there is intensive traffic on the public network, traffic may still be directed to the same MAC address as the previous VR before the new VR’s public NIC is fully configured. As a result, the VR’s operating system may interpret this traffic as a spoofing attack and begin dropping packets. To address these cases, the MAC address of the public NIC can be changed when VRs are recreated during cleanup. This ensures that network traffic is only directed to the new VR once it is fully configured.

To support this behavior in ACS, the keepmacaddressonpublicnic parameter has been added to the createNetwork, createVPC, updateNetwork, and updateVPC APIs. When set to true (the default, preserving existing behavior), ACS reuses the same MAC address for the public NIC across VRs during redundancy or recreation. When set to false, newly created public NICs are always assigned a new MAC address.

Types of changes

• Breaking change (fix or feature that would cause existing functionality to change)
• New feature (non-breaking change which adds functionality)
• Bug fix (non-breaking change which fixes an issue)
• Enhancement (improves an existing feature and functionality)
• Cleanup (Code refactoring and cleanup, that may add test cases)
• Build/CI
• Test (unit or integration test code)

Feature/Enhancement Scale or Bug Severity

Feature/Enhancement Scale

• Major
• Minor

Screenshots (if appropriate):

How Has This Been Tested?

Authorization validation

1. I verified that only Admin accounts have permission to manipulate the keepmacaddressonpublicnic parameter in the following APIs:

• createNetwork;
• updateNetwork;
• createVPC;
• updateVPC.

Behavior validation

Isolated networks

1. I created an isolated network with the keepmacaddressonpublicnic parameter set to true
2. I verified that the MAC address of the public network NIC of the VR was 1e:01:89:00:00:0e
3. I restarted the network with clean up and verified that the MAC address of the NIC remained the same
4. I made the network redundant and verified that the MAC address of the NIC of the new VR was the same as the existing VR
5. I updated the parameter to false and performed a network clean up
6. I verified that the MAC addresses of the new VRs were updated to 1e:01:ee:00:00:0e and 1e:01:26:00:00:0e
7. I created a new network with the keepmacaddressonpublicnic parameter set to false
8. I verified that the MAC address of the public network NIC of the VR was 1e:01:73:00:00:0d
9. I made the network redundant and verified that the MAC addresses of the NICs of the new VRs were 1e:01:32:00:00:0d and 1e:01:82:00:00:0d

Redundant isolated networks

1. I created a redundant isolated network with the keepmacaddressonpublicnic parameter set to true
2. I verified that the MAC address of the public network NICs of the VRs were the same.
3. I added a new NIC to the VM, from a new isolated network, with the keepmacaddressonpublicnic parameter set to false.
4. I verified that the MAC address of the public network NICs of the VRs were different.

VPCs

1. I created a VPC with the keepmacaddressonpublicnic parameter set to true
2. I verified that the MAC address of the public network NIC of the VR was 1e:01:3a:00:00:0d
3. I restarted the VPC with clean up and verified that the MAC address of the NIC remained the same
4. I made the VPC redundant and verified that the MAC addresses of the new VRs remained the same
5. I updated the parameter to false and performed a VPC clean up
6. I verified that the MAC addresses of the new VRs were updated

Redundant VPCs

1. I created a redundant VPC with the keepmacaddressonpublicnic parameter set to true
2. I verified that the MAC addresses were the same
3. I created a redundant VPC with the keepmacaddressonpublicnic parameter set to false
4. I verified that the MAC addresses were different

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 3.52%. Comparing base (11538df) to head (82d70a0).

❗ There is a different number of reports uploaded between BASE (11538df) and HEAD (82d70a0). Click for more details.

HEAD has 1 upload less than BASE

Flag	BASE (11538df)	HEAD (82d70a0)
unittests	1	0

Additional details and impacted files

@@              Coverage Diff              @@
##               main   #13001       +/-   ##
=============================================
- Coverage     18.01%    3.52%   -14.49%     
=============================================
  Files          5977      464     -5513     
  Lines        537834    40063   -497771     
  Branches      66047     7537    -58510     
=============================================
- Hits          96886     1414    -95472     
+ Misses       430025    38461   -391564     
+ Partials      10923      188    -10735     

Flag	Coverage Δ
uitests	3.52% <ø> (-0.01%)	⬇️
unittests	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[bernardodemarco]

@blueorangutan package

[blueorangutan]

@bernardodemarco a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 17451

[bernardodemarco]

@blueorangutan package

[blueorangutan]

@bernardodemarco a [SL] Jenkins job has been kicked to build packages. It will be bundled with no SystemVM templates. I'll keep you posted as I make progress.

[blueorangutan]

Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 17452

[weizhouapache]

@bernardodemarco
Can you perform the tests ?

• acquire some public IPs,
• then create static nat/port forwarding/lb rules
• monitor the connecitvities
• stop the primary VR

If the public ip services are down for only 1 second or so, I think this PR is good.