How to View Megaport Cloud Router Traffic with MCR Looking Glass (Without Guesswork)

If you run multi-cloud or hybrid networks, you’ve probably had that moment: packets are disappearing, BGP looks fine “in theory,” and you’re staring at a black box. The Megaport Cloud Router (MCR) Looking Glass is basically a live window into your routing table, BGP sessions, and traffic paths.

In this guide, we’ll walk through what MCR Looking Glass shows you, how route selection really works, and how to use it to troubleshoot routing issues faster and with more confidence. No magic, just clear visibility into your cloud networking.

What MCR Looking Glass Actually Does

Think of MCR Looking Glass as a single page that answers all the “where is my traffic going?” questions:

• Which route is MCR using right now to reach a destination?

• What other routes could it use?

• Which prefixes did I receive from each BGP neighbor?

• Which routes am I advertising back out?

• Does a route for a specific IP even exist in the routing table?

It pulls live routing information from your Megaport Cloud Router and lays it out in one place. You’re not guessing or piecing things together from different screens.

You can even hit the same data through the Megaport public API if you want to script checks or plug it into your own monitoring.

How MCR Picks Routes (Quick Reality Check)

Under the hood, MCR is just a router running Border Gateway Protocol (BGP) with its neighbors (peers). Every neighbor tells MCR, “Here’s what I can reach and how.”

MCR:

• Receives routes from neighbors and other sources (static, connected, local).

• Stores everything in a routing table.

• Applies BGP policies, metrics, and best practices to pick the best path.

A simple example:

• Destination IP is 10.0.0.3.

• The routing table has:

  • 10.0.0.0/8

  • 10.0.0.0/24

Both match that IP, but 10.0.0.0/24 is more specific, so MCR chooses that route. This “longest prefix match” is the basic rule, and then BGP attributes and metrics layer on top when there are multiple equal candidates.

Getting Into the MCR Looking Glass

You only see useful data in the Looking Glass after you’ve provisioned at least one MCR. Once that’s done, the flow is simple:

1. Log in to the Megaport Portal.

2. Go to Services.

3. Either:

   • Pick MCR Looking Glass from the Tools menu, or

   • Click the binoculars icon next to the MCR you care about.

The page that opens is your control center. For each selected MCR you’ll see:

• A list of all your BGP sessions on that MCR’s VXCs.

• A Routing Table view with every reachable network (static, local, connected, BGP).

• Easy ways to filter and search by IP, prefix, protocol, or text.

If the routing table is big (more than 20 entries), it’s paginated. You can adjust how many routes to show per page, and total counts appear at both the top and bottom so you know how large things really are.

Choosing Which MCR You’re Looking At

If you manage more than one MCR, the first thing you’ll notice is a drop-down for MCR Selection.

• Pick the MCR you’re currently troubleshooting.

• The BGP sessions list and routing table update to match that device.

• Switch MCRs anytime if you’re comparing behavior across regions or environments.

This sounds trivial, but in real life it saves you from debugging the wrong router at 2 a.m.

BGP Sessions: Seeing Who You’re Talking To

BGP sessions are just TCP connections between your MCR and neighbor routers. Once they’re up, the two sides swap routing information.

In the BGP Sessions section, you’ll see every session running on the VXCs for the selected MCR:

• Each row is one BGP neighbor on one VXC.

• You can drill into routes advertised to and received from that neighbor.

Checking Routes Within a BGP Session

When you want to see “what exactly did I learn from this neighbor?”:

1. Type an IP address or any text in the search field to filter the sessions list.

2. Click Neighbour Routes for the session you care about.

3. A new tab opens for that session.

4. Pick whether you want to see Advertised routes or Received routes.

You can have up to five of these session tabs open at once. If you try to open a sixth, the oldest one quietly gets replaced. So keep an eye on which sessions you’re actually viewing.

Sorting BGP Session Tables

In any table under BGP sessions:

• Click the up/down triangles next to a column header to sort.

• Click again to reverse the order.

• A small arrow shows the current sort direction.

This is handy when you’re scanning for changes, like “show me the newest prefixes at the top.”

VXC Status and Details

Every BGP session sits on top of a VXC (Virtual Cross Connect). When something looks wrong, you’ll naturally ask, “Is the VXC actually OK?”

Next to each session you’ll see status icons:

• Green check: session is up.

• Red X: session is down.

• Yellow info icon: status is unknown.

To see or tweak the VXC itself:

• Click the VXC name.

• You’ll land on its Connection Details page where you can edit settings.

This is where you jump from “BGP looks bad” to “maybe the underlying link has an issue.”

The Routing Table: Big Picture of All Reachable Networks

The Routing Table view shows every network your MCR can reach and how it plans to get there. This includes:

• Connected routes (directly on an interface).

• Static routes (manually configured).

• BGP routes (learned from neighbors).

• Local routes.

When a packet hits MCR, it looks at the destination IP, compares it against this table, and picks the best path based on prefix length, administrative distance, and BGP attributes.

Viewing the Full Routing Table

To see the whole picture:

1. Select the Routes Table tab.

2. Choose All Routes.

3. For Protocol, select All Types.

Now you’re looking at every route MCR knows. Total counts at the top and bottom give you an idea of how big your network really is from MCR’s point of view.

Viewing Routes by IP or Network

When you’re chasing one specific IP or subnet:

1. In the routing table area, choose Routes by IP.

2. Enter:

   • An IPv4 address (for example 192.0.2.1), or

   • An IPv6 address, or

   • A network with optional subnet mask (for example 192.0.2.0/24).

3. The control validates what you typed and shows the protocol type (IPv4 or IPv6).

4. Looking Glass searches the entire routing table (not just the current page) and shows matching entries.

This is great when someone pings you with “this one IP is broken” and you don’t want to scroll through thousands of routes.

Viewing Routes by Protocol

If you’re debugging a specific type of route:

1. Select All Routes.

2. Pick a protocol from the protocol list (for example BGP, Static, Connected, Local).

3. The table updates to show only routes of that type.

That lets you confirm, for example, whether a static route is shadowed by a BGP route or whether a connected network is actually getting advertised.

Text Filtering (The Fast “Just Show Me Azure” Button)

Sometimes you just want to quickly scan:

1. Select All Routes.

2. Enter a term like Azure, AWS, 20., or any other text.

3. The table filters itself and shows only matching entries.

This is the casual, “I know roughly what I’m looking for” option.

What the Routing Table Columns Mean

Instead of a dry table, here’s what each common column tells you:

• Prefix
  The destination network of the route.
  Example:
  
  

  • IPv4 host: 192.0.2.1

  • IPv4 network prefix: 192.0.2.0/24 (covers 192.0.2.0–192.0.2.255)

• Metric
  The route’s local preference or metric. Lower or higher preference depends on policy, but it’s part of how MCR ranks candidate routes.
  
  

• Protocol
  How MCR learned the route:
  
  

  • Connected: came from an interface configuration and is directly attached.

  • Static: you manually added it.

  • BGP: learned from a BGP neighbor’s update.

  • Local: local to MCR itself.

• Distance
  Administrative distance. When two protocols offer routes to the same destination, the one with the lower distance normally wins.
  
  

• Next Hop
  IP address of the next router along the path.
  If it’s 0.0.0.0, the route is local to MCR and no further next hop is needed.
  
  

• Next Hop VXC
  A clickable link that takes you straight to the VXC used for that next hop so you can edit it if necessary.
  
  

Sorting the Routing Table

Same pattern as before:

• Click a column’s up/down triangle to sort.

• Click again to flip the order.

• The triangle shows the current direction.

This helps you group routes by protocol, distance, or prefix length without exporting anything.

BGP Routes: Looking at All Candidate Paths

The BGP Table view focuses only on BGP routes. It shows:

• All BGP routes from all neighbors.

• Multiple possible paths to the same prefix.

• Which route MCR thinks is “best.”

Viewing the BGP Table

To get the full BGP picture:

1. Select the BGP Table tab.

2. Choose All Routes.

Now you’re seeing every BGP route, not just the currently selected winners in the main routing table.

Searching BGP Routes by IP

To hunt down BGP info for a specific destination:

1. Go to the BGP Table tab.

2. Select Routes by IP.

3. Enter an IPv4 or IPv6 network with optional mask (for example 192.0.2.0/24).

4. The control validates the format and shows whether it’s IPv4 or IPv6.

5. Looking Glass returns matching BGP routes for that prefix.

This is especially useful when you suspect one neighbor is advertising something different from the others.

Text Filtering in the BGP Table

For name-based searches:

1. With All Routes selected, type a search term like AWS, Azure, or a number string.

2. The BGP table filters to only entries containing that text.

Very handy when you’ve tagged descriptions or used specific naming conventions.

What the BGP Table Columns Mean

Key BGP-specific columns:

• Prefix
  The destination network, same idea as in the routing table.
  You can also copy the prefix easily when you need it somewhere else.
  
  

• Best Route
  Shows whether MCR picked this route as the preferred path for the prefix:
  
  

  • Check mark: this is the best route.

  • X: this is a backup or less preferred path.

• Next Hop
  IP address of the next router for this BGP path.
  If it’s blank, the route is local or connected and doesn’t need another router to reach it.
  
  

• Next Hop VXC
  Link to edit the VXC that carries traffic to that next hop.
  
  

BGP Route Details: Why One Path Wins

When you expand a BGP route, MCR shows the attributes it used to rank paths. Looking Glass pulls these values straight from the router. Some are learned, some might be set by your policies.

To see them:

• Click the down arrow next to a prefix in the BGP table.

You’ll see attributes like:

• AS path
  A list of all autonomous system numbers (ASNs) the route passed through.
  Example: 132863 58941 58941 4826
  Shorter AS paths are usually more attractive because they can mean a closer destination.
  
  

• Multi-Exit Discriminator (MED)
  A hint from a neighboring AS on which entry point should be preferred when there are multiple ways into that AS.
  
  

  • Only really compared when the AS path is the same.

  • Lower MED is preferred.
    You can tune MED if you want MCR to favor one VXC over another when talking to the same AS.

• Origin
  Where the prefix originally came from:
  
  

  • IGP: came from an Interior Gateway Protocol; lowest, most preferred value.

  • EGP: from an Exterior Gateway Protocol; medium value.

  • Incomplete: learned through “other” means (like static); highest, least preferred value.

Looking at these fields is how you answer, “Why is MCR picking this path instead of that one?”

Static Routes: The Manual Overrides

Static routes are the old-school, “I know exactly where this network lives” entries you configure by hand.

To see only static routes:

1. Open the Routes Table tab.

2. Select All Routes.

3. For Protocol, choose Static.

This lets you:

• Confirm that your static routes are present.

• Check that they aren’t being overridden by more attractive BGP or connected routes.

• Clean up anything you no longer need.

Keeping the Data Fresh (Reloading)

Networks change all the time. Routes are added, withdrawn, and updated constantly as links flap or configurations change.

The important bit:

Looking Glass does not auto-refresh routing data after you select an MCR.

• When you first pick an MCR, it pulls a snapshot of routes and BGP info.

• If you change something in the network, you need to manually reload to see the latest state.

So when you’re troubleshooting and you just made a routing change, hit reload before you trust what you’re seeing.

When You Want to Test End-to-End, Not Just Routes

MCR Looking Glass is perfect for seeing how routes behave. But sometimes you need more: real servers in different locations to test latency, throughput, and failover across your Megaport paths.

That’s where pairing your network with fast, disposable infrastructure is handy. Instead of waiting weeks for hardware, you spin up test nodes near your endpoints and actually push traffic across the routes you just inspected.

👉 Try GTHost bare metal servers as your on-demand test endpoints and quickly see how your MCR routing decisions work in real traffic scenarios across regions.

Quick FAQs

Is MCR Looking Glass only for BGP experts?

Not really. It helps if you know the basics (prefixes, next hops, AS paths), but the UI is straightforward. You can start with simple tasks like “does a route exist for this IP?” and slowly build up to reading BGP attributes.

Does Looking Glass show only the best routes?

The main routing table shows the effective routes MCR is using. The BGP Table goes deeper and shows all BGP routes, including non-best ones, so you can see what alternatives exist and why they’re not chosen.

Can I access this information programmatically?

Yes. Megaport exposes a public API that lets you query many of the same details available in Looking Glass. That’s useful if you want automated health checks, route audits, or integration with your own monitoring stack.

Conclusion

MCR Looking Glass turns your Megaport Cloud Router from a mysterious box into something you can actually reason about: you see every route, every BGP session, and exactly how MCR decides where to send traffic. That makes network troubleshooting faster, more predictable, and a lot less stressful.

When you combine that visibility with quick, global test nodes, you get real end-to-end control over how your cloud networking behaves. That’s exactly 👉 why GTHost is suitable for multi-cloud routing labs: you can bring up bare metal servers in minutes, push traffic through your MCR paths, and see immediately whether your routing design does what you expect.