Wednesday, April 25, 2012

Virtual LAN

Everybody is talking about virtualization today. Virtual servers, virtual classes, virtual anything. There is one more thing: The virtual LAN.

It must have been around the end of the 1990s when they introduced VLAN. It was a big topic, because many Ethernet devices could not deal with it; it is not 100 % backward compatible with the good old LAN. The core problem was that the packet got 4 bytes longer, and that could break the MTU, so that the last bytes did not make it any more.

Admins can just run a physical LAN cable and then split it up into different “virtual” LAN, which behave pretty much like physical LAN. The main difference is that that physically available bandwidth now needs to be shared with the different LANs. This raises the question which packets get routed first, in case that not everything fits into the LAN. With the introduction of VLAN, you can also say bye-bye to the idea that there is a fixed bandwidth like 100 MB/sec. That’s why they introduced priority bits, so that you can have up to eight different priorities. And that’s something that is useful when it comes to VoIP; because you want to make sure that voice packets don’t get dropped when there is a lot of traffic.

This actually works quite well. I remember someone called me up on the VoIP phone, screaming “the LAN is down!!!” After a short moment, I asked “how can you talk to me if the LAN is down”, and then I realized that we actually were using the VLAN. It turned out that there was a loop in the LAN, but fortunately on a lower priority than the voice VLAN, so that even under such a bad situation the voice packets made it. Voice is more important than data.

VLAN typically have 12 bits, and 3 bits for the priority. There is a lot of stuff around those bits, for example the question who is allowed to be in a VLAN, what quality is allowed in which VLAN, and so on. Switches have to work together with the devices, and if you want to have a waterproof system, there is a lot of work to do to have everything set up properly. What most people do is to pick just a VLAN number like 128, and just hope that nobody abused the VLAN for bad stuff. In most LAN that is okay, the setup is easy and the gain from that is good.

However, talking about the cloud, VLAN are also available in the cloud. When service providers offer metropolitan Ethernet, 4096 VLAN are not enough anymore. So they came up with another VLAN type, which can have millions of different VLAN, so that the service provider can offer a couple of VLAN to their customer. IMHO that is very cool. The virtual LAN extended into the Internet. Rent a DHCP server in the cloud! Fortunately, there is a backward compatibility into the on-premises VLAN, so that existing devices don’t have to worry about it. And the quality of service can also be guaranteed, so that voice packets don’t drop.

Of course everything works fine with the m9.

Thursday, April 12, 2012


For those who update the m9 recently, you might have noticed that you have to accept the “end user license agreement” before you can actually do something in the web interface of the snom m9. What’s going on here?!

Generally speaking, when customers purchase software, they have to accept to the terms and conditions for using that software. This is standard practice for software in the IT industry and there are actually no big surprises here. However, on a VoIP phone that is not so popular yet.

Some vendors prefer to ship a EULA paper. In my opinion, that is a waste of resources. If they are hidden in a stack of other paper documents in the gift box, it also does not help to make the situation more transparent.

The snom m9 is a product that is heavily geared towards software. Most of the value that comes with the device is software, and so it is logical that the software rules also apply to the device. However, it is still a little bit unusual to have to accept a license agreement on the first login.

There are examples of modern devices that do the same thing. For example, when you purchase an Apple device, you have to go through the various steps of setting the device up. This includes the acceptance of the end user license. The good news about accepting the EULA is that you are actually officially allowed to use the software. I was always wondering if someone would be allowed to use it without a license agreement.

It does not only allow the customer to use the software; it also makes clear under what circumstances that is allowed. For example, it would not okay to use the snom m9 software or some parts of it on a “clone” device (if that would ever become available). I think that is quite understandable: snom does not program all that stuff so that competitors purchases one device with legal software on it and then copy it onto their own platform. The EULA makes that clear.

The other thing is that the snom m9 does from time to time reach out into the Internet to check for provisioning data or to tell the snom server, what software versions are running on the device itself and on the registered servers. While the central provisioning (snom Active) has obviously the advantage that you can plug a device into the network without touching and if its configuration data, the reporting of software versions is important for making decisions where to focus development on. Many vendors don’t even mention that in their EULA, the snom m9 EULA clarifies that as well.

Other topics in the EULA circle around the standard lawyer topics warranty and liability. The warranty deals only with the software part (who can claim to have bug free software?), the hardware warranty is a different topic and depends on the country where the device was actually purchased. The liability part is a necessity in today’s business life to make sure than small glitches in the software do not end up in huge payments for the company. If you are running a company yourself, you will know the topic. Then there are other parts which you find in all EULA that discourage people from selling the product into countries where they should not be. Although it is hard to imagine for me how you would turn an m9 into a missile, from a legal point of view, it is better to have that covered in the EULA as well.

The acceptance of the EULA might seem to be another bureaucratic move. However in today’s business life it has become a necessity and the good news is that it is in electronic form: no trees needed to be chopped down to make it happen.