Migrate for Anthos

Wanne try migrating your VMs to Google Anthos… Migrate for Anthos by Sreenivas M

Sreenivas Makam's Blog

Anthos is a hybrid/multi-cloud platform from GCP. Anthos allows customers to build their application once and run in GCP or in any other private or public cloud. Anthos unifies the control, management and data plane when running a container based application across on-premise and multiple clouds. Anthos was launched in last year’s NEXT18 conference and made generally available recently. VMWare integration is available now, integration with other clouds is planned in the roadmap. 1 of the components of Anthos is called “Migrate for Anthos” which allows direct migration of VM into Containers running on GKE. This blog will focus on “Migrate for Anthos”. I will cover the need for “Migrate for Anthos”, platform architecture and move a simple application from GCP VM into a GKE container. Please note that “Migrate for Anthos” is in BETA now and it is not ready for production.

Need for “Migrate for Anthos”

Modern application…

View original post 1,606 more words

The New Auto Attendants & Call Queues

Want to dirty your hands with Teams Auto Attendants and Call Queues … This is a must read blog from Randy Chapman

Hello Readers.  Hope you’re well.

Earlier this week or maybe late last week, Auto Attendants and Call Queues turned up in the Teams Admin Centre (TAC).

CQ & AA in TAC

Now that they are in the TAC, you should be aware that the Teams version of the AA and CQ is a little different to what it was in Skype for Business Online.

In Skype Online, an AA or CQ was set up starting with a service number.  Service numbers are special high-capacity numbers acquired from Microsoft for use with AA & CQ and Audio Conferencing.  With Skype Online you needed the Phone System license and Audio Conferencing and/or the Calling Plan add-on license to acquire numbers.  These licenses entitled you to acquire a certain quantity of numbers.

For users with Phone System and Calling Plans there is a formula.  (N x 1.1) + 10

Where N is the number of users with Calling…

View original post 686 more words

Network for Humans

I’ve been thinking for a long time about how the whole concept of electronic networking could be made better or at least different. This post on twitter [https://twitter.com/etherealmind/status/1110280603675566081] by @etherealmind made me regather everything going on in my head and put them in this blog… So here goes…

Why Change?

To be Frank, I’m a bit lazy and tired of the nerd-ism surrounding CIDR. I was irritated by the whole static planning that needs to be done when working in Infrastructure as code to isolate and control traffic between different application groups by using CIDR. I liked the way Docker Swarm enforces Network segmentation/isolation in a human understandable manner. The VMware NSX micro segmentation using Security Groups is also nice from an Infra-as-code workflow. But both are virtual network only constructs and not applicable for the physical networking layer… I was not able to see any way out except change the way we represent the networking endpoints which in current situation is either IPv4/IPv6 or MAC. Both of which from a human reader perspective is an 8-bit number range (IPv4) or Hexadecimal (IPv6/MAC) … Neither of which I like…. So, what could be the way out… Well I got this idea and am jotting it down as is … so expect changes later

The change in Endpoint naming convention

To start with I wanted to look at a naming convention that we humans use for objects. My first iteration was to use English alphabets from A to Z which is 24 in count, numerals 0 to 9 and a few regularly used symbols found popularly on all keyboards.

Alphabets    ->    a-z    ->    24

Numerals    ->    0-9    ->    10

The nearest bit count needed to accommodate this would be 6 => 2^6=64 slots. The alphabets and numerals eat up 34 leaving us with 30 additional space for other characters. In my second iteration, I make the naming “case restricted”, then I need to reserve 48 spaced for alphabets: 24 for small caps [a-z] and 24 for Capitals [A-Z].

This would then occupy 24+24+1=58 slots leaving 6 slots for other characters… I propose we use






If I overlay these 6 bits per character plan on a 128-bit address space (as is used currently by IPv6), I can accommodate 21 (128//6=21) and leaving 2 bits (128%6=2). I propose to use these for type indicators that I’ll describe later…. IMO 21 slots are a reasonable count for human readable endpoint name.

Structure of the Endpoint Name

IPv4 & IPv6 are fairly unbiased and allow the network admin to structure the allotment as per their whims and fancy. This is great for static infrastructures but not great if the Endpoints are going to be dynamic and vary in both rate of change but also change in count. I propose to used a biased naming structure here so that the name can be predictable within a certain boundary and leave enough space for dynamic naming. My first iteration is to use this structure






endpoint type

2 bits


0 – public fixed

1 – public mobile

2 – private fixed

3 – private mobile


Celestial location


E (earth)


Latitudinal Slot



With North Pole as reference, divide latitude into 64 slices and give each slice a char code (0-61)


Longitudinal Slot



With GMT as reference, divide longitude into 64 slices and give each slice a char code (0-61)





IND for India, USA for the US, … you get the drift right…





The definition for this could vary by country or could just default to 00 for globally mobile endpoints


service provider



Legal owner of this endpoint responsible for this endpoint


user defined



Name that I understand and the network too

Errr! Isn’t this too complicated!

Yup… It is going to be too complicated if we use the full naming convention always. But what if I make the addressing a bit IPv6-ish and move the whole tier 0 to 5 into a `::` . The :: can be filled by the network device and user only specifies if the target is public/private and the human understandable name…. Now Users will be dealing with only names like “2::dbserver1” for private servers, “0::google.com” for public servers.

I must admit I haven’t thought this through but I guess that’s enough for this weekend. More on this later if I get any more idea…

Ribbon SWe Lite step-by-step deployment on Azure

Luca Vitali tries out Ribbon SBC Lite on Azure with very detailed step by step guide … Good read

Luca Vitali [MVP]

Hi All,

Ribbon has released the Azure Marketplace version of their Virtual SBC SWe Lite.
Thanks to Ribbon, I got the opportunity to try the Preview version… and it works like a charme!

The initial configuration is quite easy, and the Azure Marketplace version come with a 30 days trial license embed, so you can start to use it immediately!

Let’s see how to deploy it.

Deploy the VM on Azure

Create a new Resource Group
I’ll use Ribbon-RG in this article

Deploy a new VM
Search for Ribbon SWe Lite in the Azure Marketpalce and follow the images below.
Choose a very strong password for the sweliteadmin account

Configure the VM

I want to add new Network Interfaces with custom names, in this example ribbonswelite-01-admin for the mandatory Admin Interface (Mgt0) that we will disable at the end, and ribbonswelite-01-wan for the production NIC that will receive Public IP…

View original post 351 more words