Posted By Kepler Lam

Want to change to a non-technical topic, though I am not a travel blogger, this time I really want to share the aurora (northern light) viewing experience in YellowKnife (Canada) just on last month (late September).


The weather there is really very nice and not cold. Around 5-8°C during the night time. We stayed 3 nights in YK, and thank God that I can have a very spectacular view of aurora on the first and most of time in 2nd night (Photo above). Though the 3rd night is quite cloudy, still able to view a bit of aurora (below). When I saw this amazing show on the sky, how can't I sing the hymn How Great Thou Art!


Some people told me that they went to Euro to see Aurora, but can’t see much and some even unable to see.  As there are 2 factors affecting the visibility of aurora:

  1. The weather – should be clean sky, not much cloud
  2. Strength of the Aurora

Located in the northern interior part of Canada, Yellowknife has higher chance to have clean sky and it is also under the Aurora Oval i.e. it satisfies the above 2 conditions. Mentioned in the YellowKnife Village Website that they have up to 240 days per year that can see aurora.

To be able to see aurora, obvious it needs to be at dark. Since at summer, sunset will be very late. So the recommended viewing season is from late Aug to the early April (excluding Oct). Personally, for those (like me) who live in warmer place better go before end of September, as the temperature is still acceptable. One of my friends who visit at late Aug can also see very beautiful aurora and not so cold.

Besides the high chance of able to see aurora, the spending is not that much (compare to Euro). Excluding the round trip air-ticket between Hong Kong and Vancouver, if just counting the trip starting on Vancouver:

  1. Round trip air-ticket between Vancouver and YellowKnife – around CAN 750/person
  2. 3 night hotel plus tour (aurora village at night) package - around CAN 700/person

To fit your budget, I suggest 3 different options:

  1. Book Flight+Hotel package, then book tour in each separate night
  2. Book Flight only, then book Hotel+Tour package
  3. Book Flight+hotel+tour packagefrom tour agent

Option 1 is the most flexible and should be the cheapest, as say if you go 3 nights, then maybe you already able to see aurora at first 2 nights, and weather forecast on 3rd night to be cloudy, then you can save money and won’t go on 3rd night. But you may need to consider the availablility of the night tour (book at the same day) especially on peek season, as it maybe full.

So to compromise (like what I did), can consider option 2. Though you may waste money and time if weather forecast for a particular night is not so favor, you guarantee have a seat.

While option 3 maybe the most expense, is obvious the easiest way. But we found that most of the travel agent only provide winter tour (not before Nov).

For photographing, I am not expert at all. But as general recommendation, before you go, you should get familiar of the manual operation of your camera (at least know how to set the ISO level, shutter speed and aperture) and how to use your tripod to point to different area of the sky. You know what, I spend less than half hour to practice, just few hours before going to view the aurora!

Posted By Kepler Lam

In a customized OpenStack training, the client asked for an example of using the Python code to create an instance, here I want to share how to do it.

Basically the script consists of the following steps:

  1. Import the python client library
  2. Get the authentication information
  3. Create a client object by passing the authentication parameters
  4. Use the client object to perform different operations

Let me show you the code for each step.

Import the python client library

from novaclient import client

Get the authentication information

Create a dictionary variable and get the credential information from corresponding environment variables.

def get_nova_creds():
    d = {}
    d['username'] = os.environ['OS_USERNAME']
    d['api_key'] = os.environ['OS_PASSWORD']
    d['auth_url'] = os.environ['OS_AUTH_URL']
    d['project_id'] = os.environ['OS_TENANT_NAME']
    return d

Create a client object by passing the authentication parameters

creds = get_nova_creds()
nova = client.Client('2.0',**creds)

Use the client object to perform different operations

Once you create the Nova client object, you can use it to find out information (such as image, flavor etc.) that are required to launch a new instance. Following shows an example:

image = nova.images.find(name="cirros-0.3.4-x86_64")
flavor = nova.flavors.find(name="m1.tiny")
network = nova.networks.find(label="mynet2")

Now you can use the client object to launch an new instance:

server = nova.servers.create(name = "myinstance4",
                                 image =,
                                 flavor =,
                                 nics = [{'net-id'}],



Posted By Kepler Lam

When a tenant network is created in any project, Neutron will allocate a unique VLAN number (which OpenStack refer it as segment ID) for that tenant network. Note that this VLAN number is ONLY used in the physical network but NOT inside the OVS of the compute node. This is the most confusing thing, as OpenStack beginners will always have the misconception that the segment ID is used internally in the compute nodes.

Now let’s see what happen in the compute node. When you create a new VM and attach it to your tenant network, Nova component of the OpenStack will find a compute node to launch your VM. Then Neutron will try to allocate an “internal” VLAN of the OVS inside the compute node and put your VM to that internal VLAN. Neutron will instruct the OVS to map the internal VLAN traffic to the physical VLAN when going out to the physical NIC of the compute node and vice versa. Obvious, if 2 VMs are on the same tenant network, they will be put in the same internal VLAN.

The term “internal” here has the meaning of local, it means that the VLAN value of the OVS maybe different in different compute node, even if they belong to the same tenant network. But they will be translated to the same VLAN of the provider network when traffic goes onto the physical network. In short, the provider VLAN bridges the internal VLANs of all compute nodes for the same tenant network.


Why is it so complicated? Why not directly use the VLAN number inside the OVS so that translation is not required. From my point of view, if you use VLAN for the provider network, it seems that it’s really unnecessary. But what about VXLAN and GRE? As the address space of VLAN is not large enough to have a one-to-one mapping to the VXLAN or GRE segment ID, so it make sense to use a local VLAN number within the compute node, as you will never put all tenant networks in one single node. The number of VLANs should be good enough within one single node. In fact, Cisco DFA uses similar trick in the leaf switch.

Once you understand the above implementation, there should be no magic for the case of using GRE and VXLAN as the provider network.

OK, let’s see what happen if we use VXLAN (or GRE) for the physical network. Actually the only different is that when you create a tenant network, instead of allocate a VLAN for that network segment, OpenStack will allocate a VXLAN ID (VNID) (or in GRE it will allocate a key) for that network, once again this ID is referred as segment ID.

Then when you create an instance (VM) on that tenant network, once again OpenStack will find a compute node to launch your VM. However, the VM will be put onto one of the internal VLAN of the OVS in that compute node. As internally, OVS uses VLAN (not VXLAN nor GRE). Nonetheless, OpenStack will instruct the OVS to remember the mapping between the internal VLAN and the segment ID. So when the Ethernet frame goes out of the compute node to the physical network, the OVS will encapsulate it onto the corresponding VXLAN using the mapped VNID (segment ID). Similarly, in the case of GRE, the frame is encapsulated in the corresponding GRE tunnel with the mapped key.

In simple word, it just making use of VXLAN (or GRE) to bridge the internal VLANs of the compute nodes, so that all those VLANs are now in the same layer 2 domain.

Posted By Kepler Lam

Continue with my previous blog entry which I have mentioned that OpenStack can make use of VLANs in physical network for tenant network segregation.

Yet, what is the limitation of VLAN? What is the maximum number of VLANs you can use? Yes, only 4K, that needs to be shared with all the tenants in your cloud. Also, all your compute nodes’ physical NIC need to be on the same layer 2 network.

Then what’s the solution? If you have followed my previous blogs, you will figure out that VXLAN is one of the promising solutions. As the VNID of VXLAN supports 24 bits addressing space i.e. 16 million LAN segments. Moreover, by using VXLAN, the compute nodes’ physical NIC need not to be on the same layer 2, they can be in different subnets of the physical network, so that they can be anywhere in your data center.

Besides using VXLAN, there is another option that Neutron provides, which is the traditional GRE tunnel. GRE is just like VXLAN, both are tunneling technology that making use of IP network to encapsulate the Ethernet frames. However, GRE is point-to-point in nature, while VXLAN can make use of IP multicast to carry multi-destination Ethernet frames. In GRE header, there is 32 bit key field that can be used to identify different tenant network number.

To summary, you have 3 choices:

  1. Use VLAN,
  2. Use GRE
  3. Use VXLAN.

Let me discuss the detail one by one.

If you want to use VLAN, your compute nodes should be reside on the same layer 2 domain of your physical network, the physical NIC of your compute nodes need to connected to a trunk port of the uplink switch. And all those trunk ports need to be the same layer 2, i.e. cannot be routed. Just like the figure below:


In the traditional Cisco 3-tier data center design, layer 2 domains are resided within the same aggregation block. As the layer 2 boundary is between the aggregation and the core, unless you extend your layer 2 over the core, otherwise, your compute nodes cannot be attached to access switches in different aggregation blocks.


That’s the reason for Cisco Nexus to provide the Fabric Path technology so that you can extend the layer 2 anywhere in your data center. Similar solution is the Cisco DFA and ACI.

Talking back to the OpenStack, let me discuss the relationship between the tenant network and the VLAN of your physical network.

When a tenant network is created in any project, Neutron will allocate a unique VLAN number (which OpenStack refer it as segment ID) for that tenant network. Note that this VLAN number is ONLY used in the physical network but NOT inside the OVS of the compute node. This is the most confusing thing, as OpenStack beginners will always have the misconception that the segment ID is used internally in the compute nodes.

Let me discuss the relationship between the tenant network and the VLAN of your physical network in next blog entry. Please follow here to the part 3 of this blog.

Posted By Kepler Lam

Recently, I have a consultation request for the OpenStack and Cisco DFA integration which is a relativity new solution, and I find that although there are documentations and blogs discussing the network architecture about OpenStack, most of them are focusing on the internal network inside the compute node (hypervisor). It seems that there is not much information about the relationship of the physical network (OpenStack refer it as provider network) and the tenant network (network that defined in OpenStack). Here in this blog I try to bridge the gap, so that I wish it will be easier for networking guys to understand how to design the physical network for the OpenStack.

At first, just want to have a brief introduction about OpenStack (in case you don’t know what it is). OpenStack is not a single vendor product, instead it’s an open source software developed by the community. They refer it as a cloud operating system. From my point of view, if you are familiar with VMware, OpenStack is somewhat like the vCenter. You can use OpenStack to manage different compute nodes, create and launch VMs (OpenStack refer it as instance) in those compute nodes. Of course, can also create different LAN segments (virtual in some sense) for the VMs.

In cloud environment, one of the important features is to support multi-tenants. OpenStack allows the administrator to create different tenants (which is referred as projects). As a tenant administrator, you can create different tenant networks in your project, and attach instances on different tenant network. Basically a tenant network is a layer 2 domain (like the traditional VLAN, or right now Cisco refer it as bridge domain in terms of the Cisco ACI). So VMs on different tenant networks should be in different subnets and need a layer 3 device to route traffic between them.

Following figure illustrates how OpenStack Web UI (dashboard) looks like after creating 2 tenant networks of each 2 VMs on it:


What I am going to discuss is the relationship of the tenant network and the provider (physical) network. Let’s first have a look on the whole network picture. Your compute nodes are actually connected to your physical network. Yet the VMs are not directly connected to the physical network, instead they are logically connected to an internal switch OVS within the compute node. So logically it’s like the following diagram (in fact it’s more complicate then that, internally it’s not only one single bridge, but I just want to simplify the picture so that networking people can understand it much quickly).


Now the question is, how does each tenant network mapped to the physical network? Recall that each tenant network (no matter within the same tenant or different tenants) is a layer 2 domain. So the most natural way is to use VLAN in the physical network for the layer 2 segregation – it’s true that one of the methods is to configure the OpenStack network component (they call it Neutron) to use different VLAN for different tenant network traffic.

However, besides VLAN, OpenStack provides 2 more solutions, please follow here to the part 2 of this blog.


Posted By Kepler Lam

In the DESIGN course, there is a question about how to bridge different network segments in different sites on to the same layer 2 network. One of the obvious solutions is using GRE tunnel between routers.

But here, I am not going to discuss how to configure GRE tunnel, as there are many documents on it. What I am going to discuss is, if you cannot change the router configuration (say if the router is not managed by you), then can you directly bridge 2 or even more Windows PC to the same layer 2 network? The solution is using the UBridge tool.

Long time ago, I have discussed how to use the Ethernet over UDP feature of UBridge. By using the new release, right now you can use the VXLAN encapsulation. Moreover, you can use the head end replication to bridge more than 2 PCs.

For example, if you have 3 different PCs on 3 sites and have IP address, and respectively, and want to bridge them all over subnet

Then you can click here to download the UBridge tool, install the Winpcap. Create a loopback interface (or use other existing interface other than the one for the VTEP IP) in each PC. Configure the loopback interface of the 3 PCs to have IP address, and respectively.

Now, in PC1, execute:

C:\> ubdg 5000#V:E@ 5000#W:E

Select the loopback interface as prompted.

Similarly, under PC2:

C:\> ubdg 5000#V:E@ 5000#W:E

Similarly, under PC3:

C:\> ubdg 5000#V:E@ 5000#W:E

You should be able to ping among the loopback interfaces of all the PCs.

Some other design choose, such as it you don’t want to use the full mesh configuration, you can actually use the hub-and-spoke design by using the relay mode, you can further encrypt the traffic. Please refer to my other VXLAN blog entries.

Posted By Kepler Lam

In this last part of the blog entries, I will discuss the encryption feature of UBridge (open source tool under Windows platform) for VXLAN. As mentioned before, VXLAN just carry Ethernet frames over IP network without any encryption. As the original design of VXLAN is to be just used within Data Center, it is not a big deal without encryption.

But if you extend your VXLAN over a public network, encryption may become an important feature. As such a requirement, UBridge now supports encryption of the original Ethernet frame.

Currently, only pre share key (PSK) configuration using BlowFish encryption algorithm is being supported. Other stronger encryption algorithm maybe supported in future release. As the original goal is to make UBridge as an Ad Hoc tool that to be used example in testing environment, and not to be prolonged use.

Like other PSK technology, it’s susceptible for brute force attack. So use it at your own discretion.


To configure encryption, you just need to define a PSK and configure it after the remote VTEP parameter separated by an asterisk. Then when UBridge sends Ethernet frame over that leg, the frame will be encrypted. Obviously, all other VTEP(s) also need to be configured with the same key.

Just follow my previous example of the provider and access mode VTEPs in Part 3, if you want to encrypt traffic between them. Only the corresponding leg need to be configure with a key. Say if you want to use ‘secret’ as the key.

Then for the provider mode legs::

  • Provider leg: 5000#V:E@*secret:8472

Now execute ubdg:

C:> ubdg 5000#V:E@ 5000#V:E@*secret:8472

For the access mode VTEP,:

  • Access mode VXLAN leg: 5000#V:E@*:*secret:8000

Now execute ubdg:

C:> ubdg 5000#V:E@*:*secret:8000 5000#W:E

Posted By Kepler Lam

As discussed in part 1 blog entry, all VTEPs must use the same UDP port number within the same VXLAN. This is a hindrance to extending the VXLAN to some VTEPs behind a PAT device. Unless static NAT or port mapping is being used.

Furthermore, even with the unicast mode, which can be used among VTEPs over the Internet. But it still requires the VTEP addresses to be known from each other. That further prevents VTEP device to move around behind NAT devices, as the IP address is no longer static in such case.

It’s not surprising that the VXLAN has such limitations, since most of VTEP devices are static devices that not being move around. But with the UBridge which can be executed in Windows platforms, i.e. you can run it in your laptop PC and move around anywhere.

Now with a new innovation of dynamic VTEP, you can still able to bridge your Windows laptop even behind any PAT device over the Internet, just like a remote access VPN. Dynamic VTEP consist of two different VTEP modes:

  1. Provider mode VTEP (like a VPN server) – which allows a VTEP device to be configured without specifying the remote VTEPs. It dynamically learns the remote VTEP address and UDP port number.
  2. Access mode VTEP (like a VPN client) – which allows a VTEP device without a fixed global IP and be placed behind any PAT device.

Note that the provider mode VTEP still requires a global IP and a fixed port number, despite that it can be statically mapped behind NAT device.  

To configure a provider mode VTEP and relay to other VXLAN, you just need to create a leg and specific ‘0’ as the remote VTEP parameter. And create other legs for other VXLAN domain.

Example, to configure your Windows machine as a provider mode VTEP, suppose your PC has an IP address which will be the VTEP address connected to the IP network. You need to relay remote access mode VTEP to an existing data center VXLAN that uses a standard multicast mode with multicast group address using VNID 5000 and UDP port number 8472. (Of course, HER mode VTEPs can also be relayed).


Then create 2 legs::

  • Bridge to data center VXLAN: 5000#V:E@
  • Provider leg: 5000#V:E@

Now execute ubdg:

C:> ubdg 5000#V:E@ 5000#V:E@

For the access mode VTEP, just put an asterisk on the local VTEP address parameter. For example, suppose your local PC is now behind a PAT router, and has an internal IP address Suppose the above provider mode VTEP is mapped with a global IP and UDP port 8000. You want to bridge a local loopback interface of your PC to the data center VXLAN. Then create 2 legs:

  • Access mode VXLAN leg: 5000#V:E@*:
  • Winpcap leg for your loopback (UBridge will let you to select NIC to be bridged): 5000#W:E

Now execute ubdg:

C:> ubdg 5000#V:E@*: 5000#W:E

Select the loopback interface when prompted.

Posted By Kepler Lam

As discussed before, original VXLAN standard defines that BUM frames are carried over IP multicast packets. But as many data center network is not multicast enable, so eventually different vendors have enhanced the VXLAN by using unicast mode (head end replication – HER).

UBridge supports both modes at the same time with one single VTEP address, so that you can extend a multicast mode VXLAN with other unicast VTEPs.

Before discuss the configuration of UBridge, lets take a look on the pros and cons of the these 2 modes:

  • Just imagine the overlay IP network that used to carry the Ethernet frames as a very large layer 2 switch. The BUM frames are those that need to be replicated to all outgoing ports in original switch design, then it makes sense to use IP multicast packets to carry those frames to multiple destinations. The pros is that the local VTEP doesn’t need to define all the other remote VTEPs, instead all VTEPs just need to join the same multicast group.
  • On the other hand, for unicast mode, all VTEPs need to know each others in order to replicate the BUM frames to other VTEPs. i.e the VTEPs are need to be fully mesh, which obviously causes scalability issues on numbers of VTEPs.

In order to solve the scalability issue, UBridge can bridge different VXLAN domain together as one single VXLAN. Here the term VXLAN domain refer to a set of VTEPs that either uses multicast mode or in a full mesh unicast configuration. UBridge can act as a relay (just like the route reflector of BGP), so that not all VTEPs need to know each others.

You can indefinitely cascade as many as VXLAN domains by UBridge to form a very large VXLAN.  
Now let me discuss the configuration. If you already follow some of my previous blog entries, then you should know that the UBridge uses the concept of session legs. In order to relay several VXLAN domains, you need to configure one leg for each domain.

Example, if your local PC has an IP address which will be the VTEP address connected to the IP network. You want to bridge the following to VXLAN with VNID 5000 using default UDP port number 4789:

  • PC’c local loopback interface
  • A VXLAN that uses standard multicast mode with multicast group address
  • And two other unicast mode VTEPs and which will be in full mesh with your local VTEP.
  • One more standalone VTEP to the VXLAN. The VNID to be used is 5000.


Then you need to create 4 legs in which 3 of them belong to VXLAN type, one belongs to Winpcap type.

For the 3 different VXLAN legs:

  • Bridge to multicast VXLAN: 5000#V:E@
  • Bridge to 2 full mesh VTEPs: 5000#V:E@
  • Bridge to the standalone VTEP: 5000#V:E@

For the Winpcap leg, if you know the Winpcap name of the loopback interface e.g. \Device\NPF_{5F97CBE5-7D16-48FB-BC77-0E0DE084F049}, then the leg will have the syntax:

5000#W:E@\Device\NPF_{5F97CBE5-7D16-48FB-BC77-0E0DE084F049}Or just use: 5000#W:E

Now execute ubdg:
C:> ubdg 5000#V:E@ 5000#V:E@ 5000#V:E@ 5000#W:E@\Device\NPF_{5F97CBE5-7D16-48FB-BC77-0E0DE084F049}

Posted By Kepler Lam

Currently, VXLAN is normally only used within the Data Center. It is rare to extend the VXLAN over the Internet. Since there are limitations on the original VXLAN specification that makes it hard to implement over the Internet.

However, by using the new released UBridge tool (inside the iptools project of sourceforge) wihich implements some unique enhanced features over the original specification, that let you easily extend the data center VXLAN anywhere, any time to any Windows PC.


The original specification has few restrictions that haven’t been addressed for extending the VXLAN over the Internet. The restrictions are:

  1. Original VXLAN defines that BUM frames are carried over IP multicast packet. Yet, the Internet is not multicast enable.
  2. Although VXLAN used UDP to carry Ethernet frame over the IP network, original specification requires that all VTEPs must use the same UDP port number within the same VXLAN. This makes it difficult to extend VTEPs that behind a PAT router/firewall to bridge with the data center VTEPs. As the UDP port number may change after the router/firewall.
  3. The other obvious problem is the security issue, as VXLAN doesn’t encrypt the original Ethernet frame, thus it’s not safe to extend VXLAN over Internet.

To address the above issues, UBridge has the following enhancements:

  1. Instead of using multicast, UBridge can use unicast to replicate BUM frames to other VTEPs. Though this is not a new concept, as other venders also have such extension. However, UBridge can use one single VTEP IP address to support both multicast and unicast mode at the same time. It means that you can use the UBridge to relay a VXLAN in data center that uses multicast mode to other VTEPs on the Internet that uses unicast mode.
  2. A unique feature which is called provider (like server) and access (like client) mode VTEPs has been implemented. So that devices behind PAT device can act as access mode VTEP to initiate sending traffic to VTEPs that are in provider mode (usually in data center that need to be mapped with a global IP). Once the provider mode VTEP receives traffic from access mode VTEP, it will use the UDP port number of the access VTEP for returning traffic.
  3. Pre-share key encryption that uses the blowfish cipher is now supported, so that it can safely carry VXLAN traffic over the Internet.

Another important factor is that UBridge can be run in almost all kinds of Windows O.S. such as XP, Win 7/8, Win Server, so you can directly bridge your standalone PC to the VXLAN without using any other VXLAN gateway device. UBridge is open source freeware and execute in user mode. You don’t even need to install it, if you don’t need to bridge local NIC (e.g. just use it as a multicast and unicast relay), you can directly execute it on USB flash. Even if for the local NIC bridging, you need just installing the Winpcap but not the UBridge itself.

The coming blog entries will discuss the above features in detail.






User Profile
Kepler Lam
Hong Kong


You have 148811 hits.

Latest Comments