Troubleshooting IX BGP Session Down - Megaport Documentation

If your Internet Exchange (IX) is down, there is likely an issue with your Border Gateway Protocol (BGP) session. Step through these troubleshooting steps to confirm whether your BGP session is the root cause of the IX issues.

Megaport operates a public, web-accessible MegaIX Looking Glass for peers and network operators to investigate the current routing state. You can query both the primary and redundant route servers for live BGP data here: MegaIX Looking Glass.

Troubleshooting actions

Action	Steps
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.

Next steps

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.

Excerpts of network device configurations

Interface configurations
Static routes and routing protocol configurations (EIGRP/OSPF/BGP)
Firewall rules and ACL configurations for the data flow that has the issue

BGP command output and packet capture information

Routing table (show IP route <ip-address>) at both ends.
Routing protocol status and the tables at both ends, for example, the BGP neighbor table that shows BGP state (show ip bgp summary) and BGP neighbor details (show ip bgp neighbors <neighbor-ip-address>).
BGP routing table entries that have BGP routing issues (output from the command show IP BGP).
BGP advertised routes (show IP BGP neighbors <neighbor-ip-address> advertised-routes).
BGP received routes (output from the show IP BGP neighbors <neighbor-ip-address> routes command- Routing table (show IP route <ip-address>)).
Traceroute logs between the source and destination host.
Packet capture logs, if possible (file size can be up to 10 M).

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

​Troubleshooting actions

​Next steps

Troubleshooting actions

Next steps