Recently I had the pleasure of upgrade a Megaport Cloud Router (MCR) from version 1 to the new version 2. Version 2 MCR sits on a whole new code base and a side by side migration is required. In this blog I’ll show you how we went about the process, this could also be used if migrating MCR’s in general or any cloud connectivity for that matter.

The aim is to create the smallest outage possible with the customer on-premises connectivity to the cloud datacenter. In a fault tolerant environment this is usually done via having multiple routes advertised to the on-premises routers via a dynamic protocol. In the case of my example BGP is used throughout the environment and standard times for route propagation is only a few minutes end-to-end without interference.

In my example I will be moving an Azure Express Route. The key to moving the Express Route is that there is a primary and secondary BPG session (Green) for fault tolerance. I’ll move the secondary connection (2) from my active MCR to another MCRv2 in a staged approach to maintain connectivity for as long as possible. Once each Express Route peering sessions are connected to their own MCR, I will move the Megaport physical connection (Blue) from the MCR1 to the MCR2.

Create the new MCR

Create a new MCR in the correct datacenter location.

Add a connection to the cloud provider, using the existing service key out of the Express Route Virtual Circuit panel in your Azure subscription.

We can see above that we have a secondary connection available. (This was completed ahead of starting this blog).

Finalise your connection, and after you select ‘order’ the designer view will deploy the Express Route connection for you.

Check the Connection

Give it all of an itch and a scratch and the BPG peers of Microsoft and the MCR will light up.

Head over to Azure and we can check the ARP records to see the secondary peering endpoints now populating.

Here is the primary that is still online with the existing MCR that is connected to on-premises network.

We should now have some records for the secondary connection that is between the Azure Express Route Gateway and the MCR2. Select show secondary and reviewing the interface row of ‘On-Prem’ is the MCR Express Route peering IP.

All is looking good from a layer 2 (ARP) and layer 3 perspective (BGP – below). From this point if we go look at route tables. We would see that all the primary BGP peer session will have all the on-premises routes and azure VNET routes. The secondary route table will only have the Azure routes and the peering /30 routes.

If we go check our Express Route Virtual Circuits we can validate the peering IP’s used in each session match.

Delete the connection between the MCR to on-premises router

Now we want to swing our on-premises router connectivity from the cross connect of the MCR1 (1) and physical port (2). Back in the designer view we have all of the required routers and connection objects to view. I’ve also underlined the button to ‘delete’ the virtual cross connect (VXC) between the on-premises router and my MCR1. Note – In our deployment this is where the outage will start, we will loose connectivity between Azure and on-premises router as I’ve not used VLAN tagging on the physical port in the example.

Add a connection between the MCR2 and the on-premises router

Quickly, go and create a connection between the MCR2 and your Megaport “Port” (aka. Physical Port).

Make sure its your physical port not your other MCR 🙂

I’m using the exact same peering subnet for my new MCR2 so as long as I include my correct /30 subnet then my peering relationship with the on-premises router will come back willingly in a matter of seconds.

Review what you have done in the designer view. You won’t have set anything into motion until you click ‘order’. So do it! From the below view you can see the following summary:

1. Old MCR with a single Express Route Connection
2. New MCR with single Express Route Connection
3. Physical Port with the new connection to the MCR2

Once you click order, you barely have time to scratch yourself again and the status moves from deploying (little red Megaport rocket icons), too deployed. Hurray!

Once that has all come up green. The rest of work would be done in your edge routers. The edge routers being your on-premises physical edge router connected to Megaport and your Express Route Virtual Circuits/Gateway. Do a few checks to make sure you have established end-to-end connectivity. Here is some ideas:

• Edge Router – Review the BGP Status of the MCR.
  • show ip bgp neighbors
  • Check the MCR neighbor existing and is BGP State = Active.
  • Remote AS of the MCR by default is 133937.
  • Remember the IP address of the neighbor
• Edge Router – Review received routes from MCR.
  • show ip bgp neighbors x.x.x.x received-routes
  • You’ll no doubt see routes from your VNET with a path of your MCR+Microsoft e.g. 133937 12076. (Microsoft uses AS 12076 for Azure public, Azure private and Microsoft peering)
• Azure Portal – Review the ARP records and route tables.
  • The secondary connection should show all your received routes to the Express Route Gateway from the on-premises router.
• Branch Site Router – Go check what has been advertised down to your client sites. A good old trace route will show the IP addresses of the MCR in the hops.

Finishing Up

You pretty much done at this stage. The software defined network engine has done its job, you now are in control of your own destiny with on-premises route propagation.

How good is Megaport! We love networking! Especially when its fast, scalable and consistent.

---