Troubleshooting Throughput and Performance
This topic explains how to troubleshoot and isolate the cause of discrepancies between your subscribed bandwidth and actual transfer rates, and inconsistent network performance.
Megaport does not have visibility or access outside the Megaport network. To determine that the cause of an issue resides within the Megaport network, Megaport Support requires you first to validate the performance of your equipment.
Before starting technical troubleshooting
Before troubleshooting, ensure your service is not affected by scheduled maintenance or a known outage from either your Cloud Service Provider (CSP) or Megaport.
-
For CSP updates – Check your email notifications or visit the provider’s official status page.
-
For Megaport updates – View real-time service status directly in the Megaport Portal. For more information, see Monitoring Maintenance and Outage Events.
Additionally, review monitoring data in your Megaport Portal. The following items are key fields to monitor.
-
Service Logs – Check the Logs tab in the Portal for up/down events and provisioning history. For more information, see Viewing service logs.
-
Usage Graphs – Review the Usage tab to analyze traffic patterns, optical levels, and errors. For more information, see Viewing usage details.
Troubleshooting Ports and Cross Connects
For issues related to your Port, please review the items below before contacting Megaport Support.
| Category | Troubleshooting Step | Actions | Description and Analysis |
|---|---|---|---|
| Physical layer | Interface error review | Check interface or CRC errors and packet drops on the device. | Interface statistics and logs can help identify which end of the Cross Connect is causing the fault, and the potential solution. For example, an increasing number of incoming errors on a network interface generally rules out that specific SFP and indicates a potential issue with other components of the Cross Connect. |
| Hardware | SFP A small form pluggable (SFP) is a hot pluggable transceiver used in data communication and telecommunication networks to enable data transmission between two devices. compatibility |
Check your SFP. Confirm your Port capacity. Check your switch, router, and firewall models. Check the firmware version. |
Confirm your optic SFP type, speed, wavelength, and fiber type. Ensure SFPs match Megaport specs (For example, 1000BASE-LX for 1 Gbps or 10GBASE-LR for 10 Gbps). For more information, see Technical Specifications. |
| Optical level | Optical level check | Verify Tx/Rx light levels on your device. Check the transmitted (Tx) and received (Rx) light levels. |
This health check allows you to validate physical connectivity. If no Rx light is received, the service is down. If you observe degradation of Tx and Rx light levels, the service might be interrupted. We recommend you check your physical connections. If you are not transmitting (Tx) or receiving (Rx) light to/from Megaport, it might be caused by one of the following: • Fiber polarity issue – Verify by rolling the fibers at your end. • Connectivity issues within your environment or Cross Connect – Verify by performing physical loopback testing within your environment. • Connectivity issues within the Megaport environment – Verify by performing physical loopback testing from your environment toward Megaport. |
| Hardware | Network | Check your network for the following: • Port utilization • CPU utilization • Configuration • Overall network design |
If you identify any anomalies, capture the logs, graph details, or any relevant error messages. |
| Hardware | Carrier circuit | Verify carrier circuit status (if any). | Some Cross Connects are set through one or multiple carrier network devices before reaching the Megaport network. Verify that the device interfaces in the Cross Connect path are free of errors and optic light readings are operating correctly. |
| Environment | Data center verification | Open a ticket with the data center. | If errors persist, seek the data center’s assistance to verify the following: • Check the Cross Connect for damage or cleaning, if needed. • Ensure that the data center is transmitting adequate light outside of the demarcation point at its end of the connection. The data center should check the light at the demarcation point with a light reading meter. • You might request to reset and replace SFP, clean and replace cables, loopback test. |
| Configuration requirements of your device | Auto-negotiation | Check your router configuration. | Depending on the Megaport device specified in your LOA, auto-negotiation might be required. This is particularly important for some 1 Gbps services, where auto-negotiation must be enabled on your router. Check the bottom of the Customer Demarcation/Z Side section in your LOA. If auto-negotiation is set to On, you must enable it on your router. Use the negotiate auto command on your interface. |
| Your Port setting | LACP settings | Check your Port setting in the Portal. | Enable LACP if the Port is part of a LAG. Otherwise, ensure it is disabled. For more information, see Creating a Link Aggregation Group. |
Troubleshooting VXCs
For issues related to your VXC, please review the items below before contacting Megaport Support.
| Test Method | Procedures and Actions | Description and Analysis |
|---|---|---|
| Traceroute (or other test) to locate the symptom | Traceroute testing can help to determine if a destination is reachable. Traceroute: • Sends a sequence of UDP packets between two points and shows you the route the packets take. • Measures the transit delays of packets across an IP network. Perform end-to-end traceroute testing: • From the host that is originating traffic (A-End), start the traceroute to the destination host (B-End). • Then run the traceroute from the destination host to the origin host. Commands and flags might differ by device. |
Analyze the results: • Look for points in the traceroute where response times increase significantly. If identified, determine if these delays are occurring within your own network. • Verify whether any firewalls or Access Control Lists (ACLs) are prohibiting traffic from reaching the destination. |
| iPerf (Throughput tests) | iPerf is a cross-platform tool used to create standardized performance measurements and tune your network. iPerf has both client and server functionality and can create data streams to measure the throughput between two ends, in one or both directions. Recommended testing procedure We recommend a 30-minute bidirectional testing window: test first with the A-End as the client and the B-End as the server, then reverse the roles with the B-End as the client and the A-End as the server. Allow approximately 10–15 minutes between each test. This test must be run using UDP. Here is an example of the command to run on the A-End or B-End: iperf3 -c Note: UDP streams must be used to measure throughput between the two ends of the connection without the overhead of TCP negotiation, congestion avoidance, and windowing. |
Analyze the results: • Look for potential asymmetric routing. A traceroute will help to pinpoint whether the traceroute results are taking different paths, which might indicate asymmetric routing somewhere in the network. • Are there any places in the traceroute where the response time has increased significantly? If so, are those delays within your network? After testing, provide your interface statistics and take a screenshot of: • Traffic graphs (if possible) • Ingress/egress points in your network nearest to Megaport • Traffic graphs for B-End ingress/egress (if possible). Specify which device(s), Port(s), and VLANs on the network diagram to which the graphs relate. |
Next steps
If these troubleshooting steps do not resolve the issue, contact the Megaport Support. Provide the information in the table below in a .txt file when submitting your request, along with the following four mandatory pieces of information.
- Service ID – The unique eight-character alphanumeric code (this is the most critical information for the Megaport Support team). For more information, see Service Details.
- Source/destination details – Service information for each test performed.
- iPerf parameters – The specific settings used for each test.
- Timestamp – The exact time and timezone when the tests were conducted.
| Category | Details |
|---|---|
| Troubleshooting results | Provide all the troubleshooting steps you have taken in detail. For example, if loops were placed, note their location and which direction they faced. |
| Source IP address and destination IP address | The source IP address is the IP address of the host that sent the packet. The destination IP address is the IP address of the host that should receive the packet. |
| High-level network diagram | Understanding how your network design is implemented and the connection to the Megaport network helps identify additional focus areas within the troubleshooting process. Provide a network diagram that includes all devices in the path. Note each device’s involved IP addresses and VLANs. |
| Ping test results | Provide the output of each ping test performed on the service. Provide all output tests if you have multiple services related to different products (for example, a Port or VXC). |
| Traceroute results | Provide traceroute results, indicating which side of the connection initiated the test and which side was the destination. We recommend that you use the A-End and B-End information from your VXC. |
| iPerf (throughput) test results | Provide all data based on the steps above and any relevant information related to the questions below: Are you using traffic shaping on your network? If you are shaping, policing, or filtering traffic before it reaches Megaport, it can cause us to see only the shaped ingress traffic in the Megaport network. Customers and resellers must ensure that the equipment used outside of Megaport’s network can support the required speeds. Have you contacted the B-End of the connection to ensure that there aren’t any problems on that side of the path? Provide the case number, if applicable. After traffic is sent out from Megaport’s network interface to the provider interface, we no longer control that flow. Are there any other providers involved, such as telco carriers? If a carrier is involved in the network, has a case been opened with them to investigate potential routing issues? Provide the case number, if applicable. It is important to verify whether you are using a telco carrier to route traffic flow to/from your network to Megaport, as we can only troubleshoot flow through our devices. For example, we cannot account for any loss or other issue before it reaches our network. If this is an Azure connection, are you using the Q-in-Q option in the Megaport Portal as described in Configuring Q-in-Q? Azure connectivity with Q-in-Q can be complex and must be configured correctly to ensure traffic is properly delivered to Megaport and onward to Azure. For more information, see Configuring Q-in-Q. |
| Packet capture logs (optional) | Packet capture (PCAP) logs help collect network traffic, monitor bandwidth, detect malware, and support incident response. If relevant to the issue, providing PCAP logs can help give a clearer understanding of your network traffic and behavior. |
Note
For more information about when a field service technician is needed onsite at the data center, see Customer Field Services.