This topic covers troubleshooting techniques for a FastConnect connection that has issues.
Some of the troubleshooting techniques assume that you are a network engineer with access to your CPE's configuration.
Microsoft Azure Connection Issues
The connection components must be terminated in a specific order. If you don't follow this order, the FastConnect virtual circuit switches to a "Failed" state and cannot be deleted.
To fix a virtual circuit in the "Failed" state, go to the Azure portal and confirm the following items:
- The ExpressRoute circuit is not in the "Failed" state. If it is, click the ExpressRoute circuit's Refresh button. The circuit should return to its normal state.
- The ExpressRoute circuit has no connections. Delete all its connections and then retry terminating the connection.
After you've confirmed the preceding items, you can continue with the termination process in the following steps:
- In the Oracle Console, delete your FastConnect virtual circuit. Ensure that it is deleted before proceeding.
- In the Azure portal, confirm that the private peering for the ExpressRoute circuit has been deleted. Also confirm that the ExpressRoute circuit's status has changed to "Not Provisioned".
- In the Azure portal, delete the ExpressRoute circuit.
Check these items:
- Port allocation: Verify that your connection is using the correct port, and the port is UP and activated.
- Optical signal: Verify that your connection is using the correct optics and transceiver, and the port is sending and receiving an optimal signal. For more information, see FastConnect Requirements.
- Fiber strands: Try rolling or flipping the Tx/Rx fiber strands.
- End-to-end physical connectivity: Verify the end-to-end physical connectivity. Also verify the Tx/Rx optic signal between your CPE, the provider's network device (if you're working with a provider), and the Oracle FastConnect router.
Check the following items on your CPE. If you're working with a provider, also have them check the items on their network device:
- BGP address: Verify that the router is configured with the correct BGP peering IP address.
- ASN: Verify that the router is configured with the correct BGP local ASN and Oracle BGP ASN. Oracle's BGP ASN for the commercial cloud is 31898. For the Government Cloud, see Oracle's BGP ASN.
- MD5: If you're using MD5 authentication, verify that the authentication string (the password) is correct.
Maximum prefixes: Verify that you are advertising less than the maximum allowed number of prefixes for virtual circuits. If you're advertising more prefixes than allowed, BGP establishment fails. Here are the limits:
- Public virtual circuits: maximum 200 prefixes
- Private virtual circuits: maximum 2000 prefixes
- Firewalls: Verify that your on-premises firewall or access control lists are not blocking TCP port 179 (BGP) or any high-numbered TCP ports.
The Oracle Console displays an alert if the virtual circuit is in the PROVISIONED state, but the BGP session is DOWN.
Typically, the alert indicates one of the following issues:
- You have not yet configured your CPE with the required information for the FastConnect connection. After you configure the CPE, the alert should no longer appear.
- You have configured your CPE with incorrect information. Verify that your CPE is configured with the correct information.
The CPE configuration information includes these items:
- BGP address for each side of the connection
- ASN for your network and for Oracle's network
- MD5 authentication string (if you're using MD5 authentication)
- Maximum number of allowed prefixes
For more details, see the preceding information shown for network and transport (layers 3 and 4) in FastConnect is DOWN.
Exception: The preceding information is not relevant if you're using an Oracle partner, and the BGP session from your CPE goes to that partner and not Oracle. In that case, contact your provider to confirm that the BGP session they have with Oracle is configured correctly.
Check these items:
- VCN security lists: Ensure you've set up the VCN security lists to allow the desired traffic (both ingress and egress rules). Note that the VCN's default security list does not allow ping traffic (ICMP type 8 and ICMP type 0). You must add the appropriate ingress and egress rules to allow ping traffic.
- Correct routes on both ends: Verify that you have received the correct VCN routes from FastConnect and the CPE is using those routes. Likewise, verify that you are advertising the correct on-premises network routes to FastConnect and the VCN route tables use those routes.
Check these items:
- VCN security lists: Ensure that your VCN security lists allow traffic in both directions (ingress and egress).
- Firewalls: Verify that your on-premises firewall or access control lists are not blocking traffic to or from the Oracle end.
- Asymmetric routing: Oracle uses asymmetric routing. If you have multiple virtual circuits, ensure that your CPE is configured for asymmetric route processing.
- Redundant connections: If you have redundant FastConnect virtual circuits, ensure that they're both advertising the same routes.
Remember that FastConnect uses BGP dynamic routing, and IPSec connections can use either static routing or BGP, or a combination.
Verify that the route tables use more specific routes for the connection you want as primary. If you're using the same routes for both IPSec and FastConnect, see the discussion of routing preferences in Routing for the Oracle IPSec VPN.