We got a couple of refurbished Cisco 7961G phones that I wanted to use as SIP phones with an Asterisk server. If I knew it would be so hard, I would have thrown them away and bought some decent SIP phones. However, I did not know it would be hard, and I hate to give up ๐Ÿ™‚

Just as a reference I wanted to share the config I used, and the problems I ran into.

First, the Cisco 7961G phones do not support SIP by default. They only speak SCCP, which we do not use with Asterisk. I downloaded the SIP version of the firmware with Cisco (cmterm-7941_7961-sip.8-0-4SR1.zip). I think you can also find this version somewhere on the internet. Be careful not to upgrade to the highest version in one go. You can only upgrade one version at a time. So don’t upgrade to the latest version. Take a loot at the following URL, as not all firmware versions are free of bugs…
Voip-info on 7961G

Second, when I got the firmware loaded, after I bricked the phone a couple of times, I could start the config. I have some 7960’s and they work with simple text config files. The 7961G use XML config. If there is a config error the config will not load an the phone is unprovisioned. Also I did not find a way to change the config on the phone menu itself. I’ve pasted the XML config below. Be sure to change it for your environment.

Thirdly, I had to configure the sip user in Asterisk. The phone does not support NAT and qualify. I’ve pasted the config below as well.

Last but not least… the phone does not support NAT. Where our old 7960’s work fine over NAT, this phone only accepts SIP traffic back on port 5060 which by default makes it impossible (or unmanagable) to have multiple phones behind NAT. I have configured a VPN tunnel between our Asterisk server and the location where the phones are.

I hope this helps someone save some time on configuring the 7961G for SIP with Asterisk ๐Ÿ™‚

XML config file (SEPXXXXXXXXXXXX.cnf.xml):


<timeZone>Eastern Standard/Daylight Time</timeZone>
<member priority=”0″>
<line button=”1″>
<line button=”2″>

asterisk config:

username = 100
transfer = yes
mailbox = 100
call-limit = 100
fullname = Username
registersip = no
callgroup = 1
context = employees
cid_number = 100
hasvoicemail = no
vmsecret =
email =
threewaycalling = yes
hasdirectory = no
callwaiting = yes
hasmanager = no
hasagent = yes
hassip = yes
hasiax = yes
secret = password
canreinvite = no
dtmfmode = rfc2833
insecure = no
pickupgroup = 1
autoprov = no
label =
macaddress =
linenumber = 1
disallow = all
allow = g729,alaw,ulaw,gsm



Op 6 juni was het World IPv6 Launch Day (http://www.worldipv6launch.org/). Op deze dag zetten een aantal grote sites zoals Google, Youtube en Facebook standaard IPv6 aan. Daar merken de meetste gebruikers die nog op IPv4 zitten niets van. Het is echter een belangrijke stap in de geleidelijke in gebruikname van IPv6. Over de implementatie van IPv6 wordt al vele jaren gesproken. De IPv6 standaard is al in 1998 vastgesteld. Waarom wordt er dan nu pas zoveel over gesproken, waarom wordt IPv6 nu pas ingevoerd.

Waarom IPv6?
De reden dat IPv6 in gebruik genomen gaat worden is dat het huidige protocol (IPv4) dat op internet wordt gebruikt niet berekend was op het grote succes. Het aantal IP adressen, het nummer dat gebruikt wordt om het internet op te gaan, is niet voldoende om iedereen toegang te geven. Door de toename van het aantal mobiele telefoons met internettoegang, maar ook door de wereldwijde groei van het aantal internet aansluitingen, zijn er niet voldoende IP adressen meer beschikbaar. Door over te stappen op IPv6 is het tekort aan IP adressen in een keer opgelost. Er zijn nu voldoende IP adressen om iedere vierkante centimeter op de aarde een eigen IP adres te geven.

Het probleem is dat IPv4 en IPv6 niet uitwisselbaar zijn. Iemand met een IPv6 internet aansluiting kan geen verbinding maken met websites die alleen via IPv4 bereikbaar zijn. Omgekeerd geldt hetzelfde. Dit is de belangrijkste reden dat IPv6 niet eerder is uitgerold. Het is veel werk, het vergt een investering van de internetaanbieders en er was geen noodzaak om dit te doen. Deze noodzaak komt nu echter snel dichterbij.

IPv4 raakt nu op en de eerste IPv6 internet aansluitingen worden uitgerold. De eerste regio waar dit wordt gedaan is Azie. In Azie is sinds april 2011 geen voorraad meer van IPv4 adressen. De verwachting is dat dit in augustus 2012 ook in Europa het geval is. Vanaf dat moment moeten de internet aanbieders het doen met de IPv4 adressen die ze op dat moment hebben en is er dus weinig ruimte meer voor groei. Dat betekent dat er op dat moment dus een goede reden is voor de invoering van IPv6. Anders kunnen er simpelweg geen nieuwe klanten meer aangesloten worden. Van belang is dus dat dit moment dichtbij komt en dat dit voorbereidt moet worden.

Wat betekent dit voor mij?
Voor eindgebruikers die thuis een internet aansluiting hebben met een IPv4 adres betekent de invoering van IPv6 voorlopig nog niets. IPv4 en IPv6 zullen voor langere tijd naast elkaar bestaan. Wanneer je echter een website hebt betekent de invoering van IPv6 wel degelijk iets. Omdat een gebruiker met een IPv6 internet aansluiting geen IPv4 websites kan benaderen, kan deze gebruiker een website die alleen op IPv4 beschikbaar is niet bereiken. Wanneer je bijvoorbeeld een webshop hebt kan dit op termijn flinke gevolgen hebben. Zo heeft een universiteit in Amerika onlangs met spoed de services op IPv6 beschikbaar moeten stellen omdat uitwisselingsstudenten in Azie op IPv6 werkten en de IPv4 diensten van de universiteit in Amerika dus niet meer konden bereiken.

Problemen waar je tegenaan kunt lopen zijn de volgende:

  • IPv4 adressen hebben een ander formaat dan IPv6 adressen. In bepaalde websites worden IP adressen opgeslagen in een database. Het kan dus voorkomen dat dit niet meer werkt
  • Sommige sites maken gebruik van zogenaamde GeoIP functionaliteit. Dit houdt in dat het IP adres van een bezoeker automatisch gekoppeld wordt aan een plaats of een land. Deze functionaliteit is niet zomaar beschikbaar voor IPv6
  • Bepaalde sites maken gebruik van beveiliging op basis van IP adressen. Delen van een website zijn bijvoorbeeld alleen beschikbaar vanaf een bepaald IP adres. Deze beveiling werkt niet zonder meer voor IPv6.
  • Omdat IPv4 en IPv6 verschillende protocollen zijn werkt de firewall die je voor IPv4 hebt ingesteld niet voor IPv6. Je moet dus een aparte firewall policy opstellen voor IPv6

Er zijn uiteraard nog vele andere problemen waar je tegenaan kunt lopen. Door te testen zul je de meeste van deze problemen op tijd vinden.

Wat doet Redbee?
Wij hebben ons netwerk al enige tijd geleden geschikt gemaakt voor IPv6 en zijn momenteel bezig dit naar onze shared servers uit te rollen. Virtuele servers, dedicated servers en colocatie servers hebben reeds de beschikking over IPv6 connectiviteit. Wanneer je hier gebruik van wil maken neem dat contact met ons op. Daarnaast bieden we de mogelijkheid aan gebruik te maken van een aantal teststations die beschikken over een IPv6 verbinding. Deze teststations hebben we bereikbaar gemaakt vanaf het IPv4 internet zodat je hiermee je site kan testen. Tot slot hebben we een IPv6 readyness checker gemaakt: http://rogierm.redbee.nl/dns.php Met deze tool kun je zien of de nameservers van je domein en je website klaar zijn voor IPv6. Als je domein en site door Redbee worden gehost en deze volgens de checker niet klaar zijn voor IPv6, neem dan contact met ons op. We zullen dit dan zo snel mogelijk in orde maken.

Wat moet ik doen?
Er zijn een aantal acties die je nu al kan nemen om de overstap naar IPv6 goed voor te bereiden:

  • Ga in gesprek met de maker van je website. De maker van je website kan het beste inschatten of het gebruik van IPv6 voor problemen gaat zorgen. Zij kunnen je ook het beste adviseren over de aanpassingen die nodig zijn om deze op een goede manier op te lossen.
  • Test je website met IPv6. Redbee biedt diverse test mogelijkheden aan, ook wanneer je zelf niet de beschikking hebt over een internetverbinding met IPv6. Op die manier kun je toch testen met IPv6.

We helpen je graag bij de overstap naar IPv6, aarzel dus niet om contact op te nemen!

After an upgrade of one of our internal KVM systems to CentOS 6.2 some of the VMs did not started after boot. When I tried to manually start them via virsh they failed with the following error:

error: internal error unable to reserve PCI address 0:0:2.0

I fixed this by changing the xml that defines this VM:

edit vm-id

Search for the device with IRQ 2, eg:

<interface type='bridge'>
<mac address='52:54:00:bc:ab:96'/>
<source bridge='br205'/>
<model type='virtio'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>

Edit this section and change the slot=’0x02′ to some other unique value, eg slot=’0x04′ and save this.

Now you can start the VM without any problem.

This issue seems to happen to more people after an upgrade to 6.2 (see below). The cause does not seem to be known, but it is easily fixed.



Time synchronisation in KVM, Xen or VMWare guests is a difficult subject. The best solution depends on the type and version of hypervisor and the type and version of OS that runs in the guest. This way it gets quite complicated. Each hypervisor vendor has a document on timekeeping:

While it is useful to have all a solution for all hypervisors on all types of hardware with all sorts of guest OS’s, most virtualisation shops have quite a stable and homogeneous environment. We mostly run a recent (5.4 or higher) version of CentOS as guest OS on a KVM hypervisor running on CentOS 6 running on a recent Intel Xeon platform.

This means that if:

  1. The hardware has a Time Stamp Couter (TSC) $ cat /proc/cpuinfo | grep constant_tsc
  2. The Guest has the kvm-clock echo /sys/devices/system/clocksource/clocksource0/current_clocksource

If the above is true, it is not recommended to use NTP in the VM Guest. Using NTP on the VM Host Server, however, is still recommended.

Summarizing: If the hostserver has TSC, and the guest is using the kvm-clock, you should only run NTP on the hypervisor.

Since the Cisco VPN client does not work under OSX Lion anymore there was no easy way to connect with certificate authentication. It took some time but I managed to get it working under Lion with the build in VPN Client. Find the steps below to get the certificates imported and working with the VPN Client.

  • Create key: openssl genrsa -des3 -out vpn-cert2.key 1024
  • Create CSR (make sure that the CN is a simple name, no spaces or special characters): openssl req -new -key vpn-cert2.key -out vpn-cert2.csr
  • Request certificate with your CA
  • Create a p12 file from the key and the certificate: openssl pkcs12 -export -inkey vpn-cert2.key -in certnew-3.cer -out vpn.p12
  • Import the p12 file (containing the key and certificate) in the system keychain (not the login keychain, that doesn’t work): sudo security import vpn.p12 -k /Library/Keychains/System.keychain
  • If needed you can import the CA in your keychain and trust the imported certificate: sudo security add-trusted-cert -k /Library/Keychains/System.keychain root.ca.pem
    Note:Make sure that if you import your own CA, that you do it this way. Otherwise the VPN server certificate will not be verified correctly.

To use the certificate for VPN authentication do the following:

  • Open System Preferences
  • Go to Network
  • Click + to add network interface, Select Interface: VPN, VPN Type: Cisco IPSec
  • Click Create
  • In the Server Address type the hostname of the firewall. This is really important. The firewall has a certificate configured on the FQDN. Make sure the server address is the name of the certificate in the firewall. This FQDN can be found in the trustpoint configuration (see below)
  • Enter the username
  • Click Authentication Settings
  • Select Certificate and Click Select
  • Select the correct certificate that you just imported
  • Click OK
  • Click Apply

When you are not able to select the certificate you created the problem is that the CN is not supported. Make sure the CN that you used to create the CSR does not contain spaces or special characters.

Firewall trustpoint config:

crypto ca trustpoint CA1
enrollment terminal
fqdn fw.xxxx.com
subject-name CN=fw.xxxx.com,OU=IT,O=XXX Limited,C=NL,St=NH,L=Amsterdam

Last week I was looking at testing SplashID Enterprise. While a first installation with the MySQL database running on a Mac Mini was working fine, the installation with the Splash Enterprise Admin client failed when the database was running on a default Linux (CentOS) installation. I tried contacting SplashData support, but they could not help me, so I tried to debug myself. I enabled the query log so I could see the queries executed by the Admin client. These queries showed that SplashID ran queries reffering to specific tables in upper case (eg. MYSQL.USER). I manually tried some of these queries and these queries failed with “unknown table” error.

Now I found the problem, I thought it was easy to fix it. I just had to make MySQL case-insensitive. This sounds easier than it actually was ๐Ÿ™‚ Lots of articles talked about the character set and the collation, but these only affect the data in the tables, not the actual table name itself. Some googling let met to the lower_case_table_names setting in MySQL. It appears that Windows, Unix and MacOSX all have different default settings, and therefor behave differently.

Setting the following line in the my.cnf in the [mysqld] section solved my case problem with SplashID. MySQL now changes all table names to lower case.


Update: I have not tested SplashID Enterprise yet, so I don’t know if it is any good ๐Ÿ™‚

I’ve never really liked facebook, but also never really felt annoyed by it. But lately there are so many stories on the internet and in the news about facebooks total disregard for privacy. It might be just me noticing this, but I think not ๐Ÿ™‚ Anyway, just for fun I decided to collect the stories that show what impact changes in facebook can have.

Private photo’s public?
Afgeschermde facebook foto’s zichtbaar
facebook exploit macht alben nicht freunden einsehbar

Of course, there are also positive sides on facebook and what its use and users can achieve with it:

I know facebook is a free service (as in beer), but that should not mean that they can use your data whichever way they want…

Last month I ran some performance tests over a Cisco ASA 5550 using iperf. There were some performance issues when the ASA was hit with a lot of simultaneous requests. The ASA 5550 is a powerful device so I did not expect any performance problems with 2000 concurrent requests. Our stresstests reported connection problems when the number of concurrent requests increased above 2000 while traffic was way below the maximum supported throughput. To check the wirespeed performance of the ASA I decided to run an iperf test. This test showed expected bandwidth results, but a lower MTU (1408), while all intermediate components are configured at 1500.

Some investigation showed that this was caused by a default maximum MSS setting in the ASA. It appears that the ASA has a default max MSS of 1380. This is set by the command:

sysopt connection tcp-mss MSS_size_in_bytes

The default is 1380 to prevent fragmentation on possible IPSec connections in the path.

To get to MTU 1500 the ASA needs to support an MSS of 1460. This is configured with the following command:

sysopt connection tcp-mss 1460

More information can be found here:

Several blogs and manuals with examples on kvm or xen setups use NFS as storage backend. Mostly they state that for production use iSCSI is recommended. However there are examples where NFS is part of the architecture, eg. OpenNebula. I tried to find specific statistics on the performance differences between NFS, iSCSI and local storage. During this search I encountered some pointers that NFS and Xen is not a good combination, but never a straight comparison.

I decided to invest some time and setup a small test environment and run some bonnie++ statistics. This is not a scientific designed experiment, but a test to show the differences between the platforms. Two test platforms are setup, 1 with a Xen server (DL360G6) (xen1) and a 12 disk SATA storage server (storage1), and another with a KVM server (DL360G5) (kvm1) and a 2 disk SATA storage server (storage2) . Both servers are connected with a gigabit network. I’ve also run a test with a 100mb/s network between the kvm1 and storage2 server. For reference I’ve also done tests with the images on localdisk.

I realize that LVM and iSCSI storage is most efficient, but storage with image files is very convenient and in case of cloud setups sometimes the only option.

Seq output Seq input Random
Per Chr Block Rewrite Per Chr Block Seeks
Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
Xen-guest-via-nfs-tapaio 1G 3570 5 2436 0 1366 0 26474 41 24831 0 6719.0 1
xen-guest-via-iscsi 1G 25242 40 12071 1 15175 0 32071 42 47742 0 7331.3 1
kvm-guest-nfs-1gb-net 1G 8140 16 17308 3 11864 2 40861 81 71711 3 2126.6 54
kvm-guest-nfs-qcow-100mb 1G 1922 3 9874 1 3994 0 10720 22 10441 0 595.4 33
kvm-guest-nfs-qcow-100mb-2nd 1G 9735 21 2039 0 3197 0 10729 22 10463 0 685.3 38
kvm-guest-nfs-qcow-100mb-3rd 1G 5327 10 7378 1 4421 0 10655 18 10512 0 706.3 39
xenserver-nfsmount 1G 41507 60 60921 7 29687 1 33427 48 64147 0 4674.4 11
kvmserver-nfs-1G 20G 31158 52 32044 17 10749 2 19152 28 18987 1 90.3 1
localdisk-on-nfs-server-cloudtest3 4G 41926 65 43805 7 18928 3 52943 72 56616 3 222.6 0

The ย conclusion of the tests is that local storage is fastest. NFS storage with Xen is not a good combination. Xen runs best with iSCSI backed storage. KVM with NFS runs significantly better. It is safe to say that if you want to use NFS use it with KVM, not with Xen. In any case iSCSI is always the best option for Xen. I have not yet tested KVM with iSCSI but I expect this to perform better than NFS.