Troubleshooting Throughput and Speed
If you notice any anomalies between the traffic being transmitted and the traffic you expect to receive, your network might be experiencing throughput or speed issues. We recommend that you run through the following troubleshooting steps to assist in isolating the cause.
|Check interface or CRCCyclic redundancy check.
A type of error detection code used to detect transmission errors in data. 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 SFPSmall form pluggable.
A hot pluggable transceiver used in data communication and telecommunication networks to enable data transmission between two devices. and indicates a potential issue with other components of the cross connect.
|Verify the Tx and Rx optical levels on the device||Check the transmitted (Tx) and received (Rx) light levels. This health check enables you to validate physical connectivity. Considerations:
|Verify physical connections with the data center (reseat and replace SFP, clean and replace cables, loopback test)||Open a ticket with the data center to:
|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.|
|Validate equipment performance||While troubleshooting, Megaport does not have visibility or access outside the Megaport network. To verify that the cause of an issue is within the Megaport network, Megaport Support requires customers to validate the performance of their equipment. This includes ensuring that the hardware specifications and limitations are compatible with Megaport’s Technical Specifications, and monitoring the network traffic and the workload on the hardware to avoid congestion or degraded performance. To ensure that hardware and your network is operating as expected, we recommend that you validate the performance of the following:
|Perform tracerouteA diagnostic tool that examines how data moves through the internet to determine if a destination is reachable. (or other test) to locate the symptom||Traceroute testing can help to determine if a destination is reachable. Traceroute sends a sequence of UDPUser Datagram Protocol.
A transport layer communications protocol that works on top of Internet Protocol (IP). packets between two points and shows you the route the packets take. Traceroute also measures the transit delays of packets across an IP network.
Perform end-to-end traceroute testing
|Perform 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.
Perform the test
Megaport recommends performing a 15 minute test on each side (the A-End client and B-End server, then the B-End client and A-End server) for a total of 30 minutes of testing and approximately 10 to 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:
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
If the troubleshooting actions do not resolve your issue, contact support. Before requesting assistance, collect the following information.
- 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 into 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 desired 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. Once 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 on the Megaport Portal as described in Configuring Q-in-Q?
Azure with Q-in-Q can be tricky, and it must be configured correctly to send the traffic properly to Megaport and then on to Azure.
- Are you using traffic shaping on your network?
- Packet capture logs (optional) – Packet capture (or PCAP) logs help collect network traffic, monitor bandwidth, detect malware, and assist in incident response. If relevant to the issue, provide packet capture logs for a greater understanding of your network.
When a field service technician is needed onsite at the data center, see Customer Field Services for details.