| Check interface or 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 and indicates a potential issue with other components of the IX.
Important to note:
Interface type, SFP type and cable type
- 1 Gbps 1000BASE-LX [10km; duplex on ]
- 10 Gbps 10GBASE-LR [10km; duplex on SMOF]
- 100 Gbps 100GBASE-LR4 [10km; duplex on SMOF]
MTU (Maximum Ethernet Frame Size)- 9100 bytes for VXCs between customer Ports.
- MCR and MVE support the standard MTU of 1500 bytes.
- IX and many CSP ports do not support jumbo frames, but all support the standard MTU of 1500 bytes.
- Protocol: LACP
- Interface: 10GBASE-LR (10 Gbps) or 100GBASE-LR4 (100 Gbps). 1 Gbps Ports are not supported.
- The maximum number of interfaces in a single LAG: 8
- Multi-Chassis Link Aggregation (MC-LAG) across multiple devices is not supported.
Preferred A-End VLAN (VXC/IX)- Untag (enabled) — This will limit the A-End Port to a single service. Only one VXC/IX per Port, equivalent to an access port on your device side.
- Untag (disabled) — Specify 802.1q VLAN number on the A-End Port. Each VXC is delivered as a separate VLAN on the Port. This must be a unique VLAN ID on the Port and can range from 2 to 4093. If you specify a VLAN ID already in use, the system displays the following available VLAN number. The system will randomly assign a VLAN number, equivalent to a trunk port with allowed VLANs on your device side, by leaving the VLAN ID blank.
802.1Q Tunneling () IEEE 802.1ad (Azure VXC)
- To access Microsoft Azure ExpressRoute, Q-in-Q (IEEE 802.1ad) is required. Depending on which method is chosen, your device configurations can vary, either Q-in-Q, Q-in-Q breakout, untagged VXC or MCR.
|
| Verify interface, SFP, cable and cabling are correct | - Verify that auto-negotiation (speed auto and duplex auto) is used on gigabit interfaces.
- Verify that the cross connect cable is connected to the correct port at both ends.
- Verify that SFP optic power levels (Tx and Rx) show good light at both ends.
|
| Verify configurations | - Verify that the MTU size is correct.
- Verify that the LACP configuration is correct if LAG is used. MC-LAG is not supported.
- Verify that your devices are configured as per “Preferred A-End VLAN” on the Megaport Portal.
- If a VLAN is used, confirm if the correct VLAN number is configured on your device side.
- If Azure VXC is used, verify that your devices are configured using one of the Q-in-Q methods.
|
| Verify configurations | - Verify that the interface IP address and subnet address are configured correctly.
- Verify that routing protocol configurations (EIGRP/OSPF/BGP) are configured correctly.
- Run a ping test between Layer 3 network devices (for example, Edge routers, BGP peers).
- Run a ping test between the source host and destination host (end-to-end connectivity test).
- If the ping test fails, check the table and routing table at both ends.
- If the ping test fails and there is no issue on the routing table at both ends, then take logs from both ends.
|
| Verify the optic power levels on the device | Optic light readings from the terminal help to understand whether the readings are within the threshold range. Check the device and port graphs for errors and view the Megaport optic graphs history. The graphs update every five minutes, so if flapping is rare, the graphs might not capture a drop in optical light. Ensure the optic reading is within specifications. |
| Perform a ping test to route servers within the IX network and/or bilateral peers | A ping test transmits data packets to a specific IP address and either confirms or denies there is connectivity between IP-networked devices. A confirmation includes the latency (the response time) of the connection.
|
| Verify Layer 2 connectivity (ARP) to route servers and/or bilateral peers | Layer 2 controls the flow of data between nodes on WAN or LAN segments, and is also responsible for detecting and possibly correcting Layer 1 errors. Layer 2 connectivity issues can affect the functionality of your VXCs, which connect to your MCR. When connecting to a Cloud Service Provider (CSP), ensure that the VLAN configuration details are correct. Use particular caution when connecting to Azure, as you will be using Q-in-Q.
Layer 2 connectivity issues can also affect your IX services. MAC addresses are used to authenticate your devices when using IX services with Megaport. Depending on your network design, if you are peering with Megaport or other organizations, ensure that you have specified the correct MAC address in the Megaport Portal.
Perform these checks before submitting a support request:- Check the status of your IX service with the Looking Glass tool. You can access information for both the primary and redundant route servers for live BGP data. Layer 2 issues can be more challenging to diagnose than physical Layer 1 issues. Providing Megaport with Layer 2 connectivity details will help isolate the issue.
- If you are not peering directly with Megaport, confirm any configuration changes with the company you are peering with.
- Run a ping test to verify whether you are connected to Layer 2.
- Check the ARP tables and confirm that the MAC address is visible in the Megaport Portal.
- Confirm that the configuration matches Megaport Technical Specifications.
For additional guidance, reach out to your Account Manager and request a meeting with a Megaport Solution Architect.
|
| Verify the BGP configuration | - Interface settings, including VLAN number
- BGP IP address and subnet mask
- BGP number
- BGP network addresses to be advertised
- BGP neighbor IP address and subnet mask
- BGP neighbor AS number
- BGP neighbor network addresses to be received
- BGP authentication between BGP peers
- BGP route filtering and manipulation, if applicable
|
| Check for BGP error messages | The BGP protocol sends a notification message when it detects an error with the BGP session such as an expiring hold timer, a change to neighbor capabilities, or a request to reset a BGP session. When an error is detected, the BGP session is closed.
For example, enter show log %BGP-xxxxx.
For more information, see Internet Exchange Overview. |
