URGENT: Cannot restore IPv4 Exchange Peering (AS45648) - "BadArgument" error on existing resource

Do not create another Mumbai Exchange Peering resource; restore IPv4 on the existing Bell-Teleservices-Peering connection, and escalate immediately if that existing connection cannot be edited because only Microsoft can correct or deprovision its backend state.

Try the supported existing-resource operation

Because IPv6 remains established, avoid deleting or deprovisioning the entire peering—it could extend the outage to IPv6.

1. In the Azure portal, search for Peerings.
2. Open Bell-Teleservices-Peering.
3. Select Settings → Connections.
4. Identify the connection for the affected Mumbai facility/device.
5. Select … → Edit connection.
6. Restore the IPv4 session address and related IPv4 settings on that existing connection, then select Save.

Azure supports modifying an existing Exchange connection and adding an IPv4 session to an active connection. The portal also reports IPv4 and IPv6 session states separately, so the established IPv6 session does not mean the IPv4 session is provisioned correctly.^1^^2^

If Edit connection is unavailable, saving produces the same BadArgument, or the correct IPv4 values are already displayed, stop retrying creation. The error confirms that the submitted definition conflicts with an existing Exchange Peering record, but it does not by itself prove that the record is stale.

Escalate the backend inconsistency

Exchange Peering deprovisioning is not supported through the Azure portal or PowerShell; Microsoft Peering must perform it. The documented lifecycle changes a connection being deprovisioned to PendingRemove.^3^

Use both escalation paths:

1. Contact Microsoft Peering using the contact link in the Exchange Peering documentation and reference the prior decommissioning request. Ask them to:
   • Reconcile the router-side decommission with the existing Azure peering object.
   • Restore/reprovision IPv4 only on the existing connection, if possible.
   • Preserve the working IPv6 session.
   • If repair is impossible, remove only the conflicting IPv4/session record rather than deprovisioning the whole peering.
2. Open the affected peering resource and select Help → Support + Troubleshooting → Create a support request.
   • Issue type: Technical
   • Service: select the closest available Internet Peering/Microsoft Peering networking category.
   • Choose the highest severity available under the support plan that reflects the production outage.
   • Required role: subscription Owner, Contributor, Support Request Contributor, or a custom role containing Microsoft.Support/*.^4^

Include these details to route the case directly to networking/peering engineering:

• ASN: AS45648
• Azure resource name and full resource ID
• Subscription and resource group
• Peering type: Exchange
• Metro, exchange, facility ID, and affected connection
• Microsoft edge/device: ier04 bom02
• Exact error: Existing exchange peering does not match with given exchange peering (Code: BadArgument)
• Exact UTC timestamps and deployment/correlation or tracking ID
• Date and reference for the Microsoft-initiated decommission
• Current states: IPv6 established; IPv4 Active/not established
• Existing and requested IPv4 session addresses and maximum-prefix settings
• Screenshot and deployment operation JSON
• Explicit request: backend reconciliation of the existing Exchange Peering object without disrupting IPv6

Do not post session addresses, subscription identifiers, authentication keys, or other account-specific data publicly; attach them only to the private support case.

Conditional legacy-peering case

Use the legacy conversion workflow only if the Mumbai peering exists in Microsoft’s systems but was never converted into an Azure resource. Legacy connections should appear under Peering connections after selecting the same ASN and metro.^5^

That workflow does not apply if Bell-Teleservices-Peering is already a normal Azure resource containing the affected connection.

References

1. Create or modify an Exchange peering using the Azure portal
2. Create or modify an Exchange peering using PowerShell
3. Set Up and Manage an Exchange Peering - Internet Peering
4. Create an Azure support request
5. Convert a Legacy Exchange Peering to an Azure Resource - Azure Portal ...