Skip to main content

Tag: Networking

Upgrading Megaport Cloud Routers

Posted on October 15, 2020 - 7:29 am by

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.

New MCR in NextDC M1

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

Add an Express Route with Service Key

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.

Secondary Express Route Peering Session deployed to MCR2

Check the Connection

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

BPG Session status

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.

Azure Express Route ARP records – Primary

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.

Azure Express Route ARP records – Secondary

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.

Azure Express Route route table – Secondary

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

Azure Express Route – Peering Overview

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.

Delete the Virtual Cross Connect

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

Attach MCR to Virtual Cross Connect

Make sure its your physical port not your other MCR 🙂

Select the Physical Port attachment

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.

MCR to Physical Port details

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
Switch the physical port from old to new MCR

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!

Physical port to MCR connection – status deploying

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.
Express Route secondary connection with on-premises routes received for MCR peer IP

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.

We love Megaport

Let us take the stress out of public cloud connectivity. Get in touch with us to understand the benefits of using a service like Megaport Cloud Router.

SD-WAN made easy

Posted on March 14, 2019 - 3:22 pm by

I’ll start by asking you two questions:

Are you paying too much for your Wide Area Network (WAN)?

And, is it the best method of connecting to the public Cloud?

At cloudstep.io we are constantly looking for ways to improve our customers connectivity to the public cloud. We consider cloud network connectivity a foundation service that must be implemented at the beginning of a successful cloud journey. Getting it right at the start is imperative to allow any cloud service adoption to truely reach its potential and not suffer from underserved network issues like latency, bandwidth and round-trip.

If the public cloud is going to become your new datacenter then why not structure your network around it.

What if I could solve your cloud connectivity and WAN connectivity in a single solution. Azure WAN is a service that offers you a centralised software defined managed network. Connect all your sites via VPN or ExpressRoute to Azure WAN and let Microsoft become your network layer 3 cloud that traditional telco providers are probably charging you hand over fist for. Who better to become your network service provider for your software defined network (SDN) then one of the largest software companies in the world! Microsoft.

Commodity business grade internet services are becoming cheaper now thanks to things like the NBN where it is truely a race to the bottom in regards to price in my opinion, which is great for the consumer… finally! Procuring NBN business grade connections for each of your office locations and then use Azure WAN to quickly deploy a secure network for site-to-site and site-to-Azure connectivity.

I believe that a service like this is really here to disrupt traditional network service providers and add great value to existing or new Microsoft Azure customers.

We are always looking to save money in a move to the cloud, potentially your network cost could be your biggest reduction. Get in contact with us at cloudstep.io to see if we can help you reform your network.

IPv6 – slowly but surely

Posted on February 15, 2019 - 10:25 am by

I first blogged about IPv6 and the reasons for its slow adoption way back in 2014. A lot can change in the world of ICT over the course of five years, but interestingly the reasons for slow adoption I believe have remained somewhat constant. I’ve updated my post to include some new thoughts.

The first time I recall there being a lot of hype about IPv6 was way back in the early 2000’s, ever since then the topic seems to get attention every once in a while and then disappears into insignificance alongside more exciting IT news.

The problem with IPv4 is that there are only about 3.7 billion public IPv4 addresses. Whilst this may initially sound like a lot, take a moment to think about how many devices you currently have that connect to the Internet. Globally we have already experienced a rapid uptake of Internet connected smart-phones and the recent hype surrounding the Internet of Things (IoT) promises to connect an even larger array of devices to the Internet. With a global population (according to http://www.worldometers.info/world-population/) of approx. 7.7 billion people we just don’t have enough to go around.

Back in the early 2000’s there was limited support in the form of hardware and software that supported IPv6. So now that we have wide spread hardware and software IPv6 support, why is it that we haven’t all switched?

Like most things in the world it’s often determined by the capacity to monetise an event. Surprisingly not all carriers / ISP’s are on board and some are reluctant to spend money to drive the switch. APNIC have stats (https://stats.labs.apnic.net/ipv6/) that suggest Australia is currently sitting at 14% uptake, lagging behind other developed countries.

Network address translation (NAT) and Classless Inter-Domain Routing (CIDR), have made it much easier to live with IPv4. NAT used on firewalls and routers lets many nodes in a network sit behind a single public IP address. CIDR, sometimes referred to as supernetting is a way to allocate and specify the Internet addresses used in inter-domain routing in a much more flexible manner than with the original system of Internet Protocol (IP) address classes. As a result, the number of available Internet addresses has been greatly increased and has allowed service providers to conserve addresses by divvying up pieces of a full range of IP addresses to multiple customers.

Unsurprisingly enterprise adoption in Australia is slow, perceived risk comes into play. It is plausible that many companies may be of the view that the introduction of IPv6 is somewhat unnecessary and potentially risky in terms of effort required to implement and loss of productivity during implementation. Most corporations are simply not feeling any pain with IPv4 so it’s not on their short term radar as being of any level of criticality to their business. When considering IPv6 implementation from a business perspective, the successful adoption of new technologies are typically accompanied by some form of reward or competitive advantage associated with early adoption. The potential for financial reward is often what drives significant change.

To IPv6’s detriment from the layperson’s perspective it has little to distinguish itself from IPv4 in terms of services and service costs. Many of IPv4’s short comings have been addressed. Financial incentives to make the decision to commence widespread deployment just don’t exist.

We have all heard the doom and gloom stories associated with the impending end of IPv4. Surely this should be reason enough for accelerated implementation of IPv6? Why isn’t everyone rushing to implement IPv6 and mitigate future risk? The situation where exhaustion of IPv4 addresses would cause rapid escalation in costs to consumers hasn’t really happened yet and has failed to be a significant factor to encourage further deployment of IPv6 in the Internet.

Another factor to consider is backward compatibility. IPv4 hosts are unable to address IP packets directly to an IPv6 host and vice-versa. So this means that it is not realistic to just switch over a network from IPv4 to IPv6. When implementing IPv6 a significant period of dual stack IPv4 and IPv6 coexistence needs to take place. This is where IPv6 is turned on and run in parallel with the existing IPv4 network. Again from an Enterprise perspective, I suspect this just sounds like two networks instead of one and double administrative overhead for most IT decision makers.

Networks need to provide continued support for IPv4 for as long as there are significant levels of IPv4 only networks and services still deployed. Many IT decision makers would rather spend their budget elsewhere and ignore the issue for another year.

Only once the majority of the Internet supports a dual stack environment can networks start to turn off their continued support for IPv4. Therefore, while there is no particular competitive advantage to be gained by early adoption of IPv6, the collective internet wide decommissioning of IPv4 is likely to be determined by the late adopters.

So what should I do?

It’s important to understand where you are now and arm yourself with enough information to plan accordingly.

  • Check if your ISP is currently supporting IPv6 by visiting a website like http://testmyipv6.com/. There is a dual stack test which will let you know if you are using IPv4 alongside IPv6.
  • Understand if the networking equipment you have in place supports IPv6.
  • Understand if all your existing networked devices (everything that consumes an IP address) supports IPv6.
  • Ensure that all new device acquisitions are fully supportive of IPv6.
  • Understand if the services you consume support IPv6. (If you are making use of public cloud providers, understand if the services you consume support IPv6 or have a road map to IPv6.)

Whilst there is no official switch-off date for IPv4. The reality is that IPv6 isn’t going away and as IT decision makers we can’t postpone planning for its implementation indefinitely. Take the time now to understand where your organisation is at. Make your transition to IPv6 a success story!!