action.skip
Megaport Documentation
MVE is Down or Unavailable
PDF

Troubleshooting MVE When Down or Unavailable

If your MVE is down or unavailable, step through these troubleshooting actions.

Tip

You can verify MVE status from the Megaport Portal. On the Services page in the Portal, find the MVE and mouse over its icon. A message displays the status of the service. (The color of the icon also indicates the service status.)

Troubleshooting actions

Action Steps
Ping test to MVE Run pingA ping test transmits data packets to a specific IP address and either confirms or denies connectivity between IP-networked devices.
 tests from MVE to the following destinations:
  • MVE default gateway IP address
  • SD-WAN management server/controller
  • Public IP (for example, ns1.google.com, 8.8.8.8)
A ping test transmits data packets to a specific IP address and either confirms or denies connectivity between IP-networked devices. In the case of confirmation, a ping test shows the latency (the response time) of the connection.
Verify MVE remote access configurations
  • Check if MVE status is reachable/up in the SD-WAN management controller
  • Check if MVE status is up in the Megaport Portal
  • Check if SSH works
  • Check configurations for different vendors for further troubleshooting
Verify a Cisco configuration Check if Megaport API call communication is allowed
The Cisco vManage console uses Megaport API calls to synchronize and authenticate the MVE. If you use a vManage console that does not allow this API call, for example, an on-premises vManage, you might need to open ports on the customer firewall protecting the on-premises vManage. For more information, see Firewall Ports for Cisco SD-WAN Deployments.

Ensure internet access is granted (vManage)
For an edge device to come online, it needs internet access through the Transport & Management VPN.

To check the configuration details in vManage:
  1. Go to Configuration > Templates and click Feature.
  2. Find the template you’ve applied (created as a Cisco VPN Interface Ethernet type).
  3. Click the ellipsis (…) on the far right and choose either View or Edit to review the details.
Verify a Fortinet configuration Ensure SSH access is granted
Try to connect using SSH to the Fortinet MVE instance using the private key generated when ordering and the public IP address assigned by Megaport. The default username is admin.

For example:
ssh -i ~/.ssh/mp1-mve-sa-sandbox admin@162.43.xx.x

Note the key pasted in the Megaport Portal is the public key and the key used for SSH is the private one.
If you cannot connect with SSH to the MVE while the VM is up, you might need to delete and re-generate the MVE.

Ensure HTTPS access is allowed
Self-hosted web access to the FortiGate is delivered through a secure HTTPS session. The MVE blocks all access to the public IP addresses assigned to the device until you SSH into it and grant HTTPS access.

You can verify if access is allowed with the following command:
show system interface
Verify a Versa configuration Verify the remote access configuration in Versa Director:
  1. Select the Configuration tab in the top menu bar.
  2. Select Templates > Device Templates in the horizontal menu bar.
  3. Find your device template and click View.
In the details, you can review the configuration, including if SSH is enabled.
Verify a VMware configuration Verify the device configuration is correct in Orchestrator:
  1. Go to Configure > Profiles and select the applied configuration profile.
  2. Select the Device tab.
  3. Ensure Cloud VPN is enabled.
  4. Ensure only the device type for Virtual Edge is selected.
  5. In Interface Settings, ensure GE1 and GE2 are disabled.
  6. Select the Firewall tab.
Ensure Support Access and Local Web UI Access from specific IP addresses are allowed. (This will also help with potential troubleshooting.)
Verify ACL/FW rules on customer devices During some troubleshooting sessions where the circuit is up but you cannot ping between Layer 3Layer 3 of the OSI model is the network layer. It translates logical network address into physical machine address (IP addressing). Layer 3 routers analyze traffic based on address details and forward appropriately, requiring knowledge of the details generally exchanged in BGP sessions for routing table exchanges.
 endpoints, there might be a firewall or ACL in between.

It is essential to know the source of the ping and its destination and the path, and any intermediate devices it traverses. Megaport will require a network diagram and the traceroute result before investigation and troubleshooting. Inaccurate information might lead to wrong troubleshooting results and inappropriate solutions.

Perform these checks before raising a support request:
  • Ensure the source device is sending the ping packets by examining the egress interface/subinterface
  • Ensure the destination device is receiving the ping packets by reading the ingress interface/subinterface
  • Perform a traceroute and find the hop where the traceroute starts to time out. Examine the configuration on the hop.
On many devices, it is possible to set an interface to filter or ignore ICMP requests, leading to a failed ping, while other traffic might pass without problems.

Next steps

If the troubleshooting actions do not resolve your issue, contact support. Before contacting support for assistance, collect the following information.

  • Provide details of all troubleshooting steps.
    For instance, if loops were placed, note where they were located and their direction.

Note

WFor more information on when a field service technician is needed onsite at the data center, see Customer Field Services.