Saturday, August 29, 2015

Azure VPN – ACL confusion clarified



Azure currently only supports VPN connections with static routing. For such a simple set up, there is a surprising amount of confusion in documentation, and with vendor support. Given the lack of clarification found on the internet, this may help a few others.

Similar to AWS, during Azure VPN deployment, a sample configuration template can be downloaded, which can be modified to use on your own devices. For the route-based VPN configuration, the downloaded template, as well as those shown in official documentation, like this sample Azure VPN template, includes the definition of an ACL like this:


As a network engineer will notice, the ACL is defined, but never used. When asking Azure team, the answer got back was “the template has worked for other customers”. What they said turned out to be true, here are explanations for those who care for how things really work.

First, there are two different types of VPN connections, the table below compare the two side by side (for technical details refer to excellent illustrations by packetlife.net). Here we use the Route-based VPN, which Azure refers to as “Dynamic routing”. This, by the way, is an incorrect term. Because only the establishment of VPN is dynamic, no dynamic routing like BGP is supported with Azure at the moment. More importantly, Route-based VPN does not require an ACL, while Policy-based VPN does.

VPN type
Policy-based
Route-based
Microsoft term
static routing
dynamic routing
Require ACL
yes
no
Detailed explanation and configuration



For the Route-based VPN (or Azure’s “dynamic routing”) option, Microsoft’s documentation and Azure generated configuration includes an ACL but not using it, was the source of confusion. This also explains why it still works for other customers, the ACL is simply not used. Therefore, it is recommended that the ACL be removed, to avoid further confusion to your support and operational teams.

It’s puzzling such a basic mistake remains uncorrected for so long, any network engineers at Microsoft?

Saturday, August 22, 2015

AWS ECS – data persistency test


To experiment with container services, I created a 2-container Wordpress app to run on AWS ECS
  •  The first container “mysql” runs a mysql image from docker hub, and creates a database for use by WorkPress app
  •  The second container “wordpress” runs a WordPress image from docker hub. It has a link to “mysql” container since the app needs to access its database. In addition, the container defines port mapping which maps its port 80 to port 80 on the host, thus making the app available.
It works nicely. ECS is fast. I can get a WordPress app up and running in minutes, available on the internet. However, when I stop and restart the service, all configuration and content is lost. This is expected, since by default, container data is not persistent.

ECS supports data persistency by way of container volumes. In container definition, the volume is mounted to the “containerPath” which is the content to be preserved. In volume definition, “sourcePath” references a location on the host to store the volume data. With volume backed by sourcePath, even if the containers are shut down, the app data on container volume is preserved.

In the sample 2-container WordPress app, the database container saves app database in /var/lib/mysql to /ecs/database on the host, the app container saves app configuration in /var/www/html to /ecs/config on the host.
Volume name
sourcePath (stored location on host)
containerPath (stored content on container)
vol-database
/ecs/database
/var/lib/mysql
vol-config
/ecs/config
/var/www/html

Initially this feature didn’t work. When configured from the GUI, the sourcePath variable was not taken, and no error was given. I posted on the forum. If it was a bug, it has since been corrected. When containers get restarted, the content of the blog is preserved. It is a simple and powerful technique for preserve data with apps on ECS.








Attached JSON code for the 2-container WordPress app.

{

  "family": "ECS-webapp-test-persistency",

  "containerDefinitions": [

    {

      "name": "mysql",

      "image": "seanxwang/mysqlwp:v1",

      "cpu": 10,

      "memory": 300,

      "entryPoint": [],

      "environment": [

        {

          "name": "MYSQL_DATABASE",

          "value": "wordpress"

        },

        {

          "name": "MYSQL_PASSWORD",

          "value": "wordpresspwd"

        },

        {

          "name": "MYSQL_USER",

          "value": "wordpress"

        },

        {

          "name": "MYSQL_ROOT_PASSWORD",

          "value": "wordpressdocker"

        }

      ],

      "command": [],

      "portMappings": [],

      "volumesFrom": [],

      "links": [],

      "mountPoints": [

        {

          "sourceVolume": "vol-data",

          "containerPath": "/var/lib/mysql",

          "readOnly": false

        }

      ],

      "essential": true

    },

    {

      "name": "wordpress",

      "image": "seanxwang/wordpress:v1",

      "cpu": 10,

      "memory": 300,

      "entryPoint": [],

      "environment": [],

      "command": [],

      "portMappings": [

        {

          "hostPort": 80,

          "containerPort": 80,

          "protocol": "tcp"

        }

      ],

      "volumesFrom": [],

      "links": [

        "mysql"

      ],

      "mountPoints": [

        {

          "sourceVolume": "vol-config",

          "containerPath": "/var/www/html",

          "readOnly": false

        }

      ],

      "essential": true

    }

  ],

  "volumes": [

    {

      "name": "vol-data",

      "host": {

        "sourcePath": "/ecs/database"

      }

    },

    {

      "name": "vol-config",

      "host": {

        "sourcePath": "/ecs/config"

      }

    }

  ]

}