network: fix VXLAN private gateway creation

[xujiantop-crypto]

Description

Fixes #14143.

Creating a VPC private gateway with an explicit vxlan://1005002 broadcast URI fails with unsupported type of broadcastUri specified, because NetworkServiceImpl.createPrivateNetwork only accepts VLAN and logical-switch URIs.

Allow VXLAN URIs through the existing private-network creation flow. Also correct the broadcast domain type in PrivateNetworkGuru.design: the input from network orchestration may carry a VXLAN URI but a VLAN type, which would otherwise be persisted unchanged. The correction is limited to VXLAN so native/untagged, VLAN and logical-switch networks retain their existing type.

The private-gateway NIC helper already carries the full URI and derives its broadcast type from the scheme. The KVM bridge driver already handles VXLAN. No schema or router-script change is required for these two defects.

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

Bug Severity

• BLOCKER
• Critical
• Major
• Minor
• Trivial

How Has This Been Tested?

• Before the fix, 7 tests ran: the new API test failed with InvalidParameterValueException: unsupported type of broadcastUri specified: vxlan://1005002, and the VXLAN design case failed with expected:<Vxlan> but was:<Vlan>. The other 5 cases passed.
• After the fix, all 7 tests in CreatePrivateNetworkTest and PrivateNetworkGuruTest pass, with no failures, errors or skipped tests.
• All 25 selected Maven reactor modules succeed on JDK 11, with 0 Checkstyle violations. git diff --check also passes.

This PR targets 4.22 following the contribution guide's release-branch policy for bug fixes.

The official system-VM checksum file was downloaded to engine/schema/dist/systemvm-templates/sha512sum.txt before running Maven. The local Maven download plugin cannot retrieve that URL, so only its redundant download is skipped; no build-configuration changes are included.

mvn -B -pl server -am -Dtest=CreatePrivateNetworkTest,PrivateNetworkGuruTest -Dsurefire.failIfNoSpecifiedTests=false -Ddownload.plugin.skip=true test

How did you try to break this feature and the system with this change?

The API regression exercises a VNI above the VLAN tag range and checks that the full VXLAN URI reaches network orchestration. Existing tests retain rejection of unknown and unsupported URI schemes. The guru tests check VXLAN correction, tagged VLAN, native/untagged, logical-switch and absent-URI cases, including the resulting network state, CIDR and gateway.

The full KVM/VPC scenario has not been run locally. For environment validation, create a private gateway using an explicit VXLAN URI on a VXLAN physical network with a suitable non-overlapping VNI; confirm creation succeeds, the network's broadcast URI/type agree, and the router NIC attaches to the corresponding VXLAN bridge.

[nagaboinaramgopal]

Thanks for this, the change looks right for the private gateway case. I tried it on a KVM zone.

Without the change, createPrivateGateway with vlan=vxlan://5005 fails with unsupported type of broadcastUri specified: vxlan://5005.

With the change, on a physical network with VXLAN isolation, vxlan://6005 works: the private gateway is created, the network is stored with vxlan://6005 and broadcast domain type Vxlan, and the router NIC is on brvx-6005, backed by a vxlan6005 device on the host.

A couple of questions, in case they are useful:

1. The Vlan type seems to come from NetworkOrchestrator.createGuestNetwork, which calls setBroadcastDomainType(BroadcastDomainType.Vlan) for any non-untagged vlan id regardless of the URI scheme. Correcting it in PrivateNetworkGuru.design works for private gateways. Was setting the type from the URI scheme there considered, or is the guru used on purpose to keep the change to this path?
2. createPrivateNetwork now also accepts a vxlan:// URI on a physical network with VLAN isolation. I tried vxlan://5006 on a VLAN physical network: the gateway is created, the network is stored as Vxlan, and the router gets a NIC on brvx-5006 backed by a vxlan5006 device on the host. Would it make sense to check the isolation method of the physical network and reject a vxlan:// URI when it is not VXLAN (and the other way round)?