Skip to content
Megaport Documentation
IX BGP Session Down

Troubleshooting IX BGP Session Down

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.

Tip

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 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 IX.

Important to note:

Interface type, SFP type and cable type
  • 1 Gbps 1000BASE-LX [10km; duplex on SMOFSingle-mode optical fiber.
    An optical fiber with a small core size that supports a single mode or path of light at any time.    ]
  • 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.
LAGLink Aggregation Group.
Uses multiple parallel network connections to increase throughput beyond the limit that a single link (one connection) can achieve.
  • 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 (Q-in-Q802.1Q tunneling (also known as Q-in-Q or 802.1ad) is a technique used by OSI Layer 2 providers for customers. 802.1ad provides for both an inner and an outer tag whereby the outer (S-tag) can be removed to expose the inner (C-tag) tags that segment the data.) 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 Layer 2The data link layer of the OSI model. L2 provides node-to-node data transfer (a link between two directly connected nodes). Most Megaport Virtual Cross Connects (VXCs) operate at L2. 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 Layer 3The network layer of the OSI model. L3 translates a logical network address into a physical machine address (IP addressing). 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 ARPAddress Resolution Protocol.
    An ARP routing table contains a list of MAC address (Layer 2) to IP address (Layer 3) mappings.     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 tracerouteA diagnostic tool that examines how data moves through the internet to determine if a destination is reachable. 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 impact 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 raising a support request:

  1. 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.
  2. If you are not peering directly with Megaport, confirm any configuration changes with the company you are peering with.
  3. Run a ping test to verify whether you are connected to Layer 2.
  4. Check the ARP tables and confirm that the MAC address is visible in the Megaport Portal.
  5. 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 ASAutonomous System.
    A very large network or group of networks with a single routing policy.     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).

    Note

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

    Last update: 2024-04-15