I’ve been using Idera (previously R1soft) CDP backup for some time now and am very happy with it. It works fine and sends out a daily email with the backup status. While this is fine for some setups, we use nagios to monitor most components of our infrastructure. There was no nagios check for CDP backups yet. The CDP backup server includes an API that enables you to get the status of the backup policies. Idera even supplies some examples on how to use the API.

With little work I updated one of these examples to a nagios check. This nagios check returns 4 statuses:

  • Unknown: if the check cannot get the status
  • Warning: if one or more policies are in warning
  • Error: if one or more policies are in error
  • OK: if all policies finished successfully

The check also returns the list of policies with their status. So when you view the check details you can easily see which policy is in error.

To run the check you need php-cli with php-soap on your nagios server.

To enable the check for a backup server follow the following steps:

Add the following command to nagios:

define command{
command_name check_r1soft_cdp
command_line php $USER1$/check_r1soft_cdp.php -H $HOSTADDRESS$

Add the following service to nagios:

define service {
use generic-service
host_name backup.server.nl
service_description Idera_CDP_Backup
is_volatile 0
check_period 24x7
max_check_attempts 3
normal_check_interval 5
retry_check_interval 1
contact_groups critical-admins
notification_interval 240
notification_period workhours
notification_options w,u,c,r
check_command check_r1soft_cdp

Make sure to update the check with the correct username and password:

#set CDP user
#set CDP user password

Please find the check script attached:
check_r1soft_cdp. Rename this file from check_r1soft_cdp.txt to check_r1soft_cdp.php.

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!

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:

When setting up SSL offloading on a Foundry ServerIron 4G-SSL the default installation allows weak (eg. DES, 56bit) ciphers and SSLv2. This is not a recommended setup, especially if you have to comply to certain security certifications, like PCI. The Foundry documentation does not give a lot of information on the ciphers that are supported. Below the commands to disable SSLv2 and allow only strong ciphers on an ssl accelerated host.

To change the ssl profile of a virtual server, always follow the following steps:

  1. Remove the ssl profile from the virtual server
  2. Change the ssl profile settings
  3. Enable the ssl profile on the virtual server

server virtual vservername
no port ssl ssl-terminate sslprofilename


ssl profile sslprofilename
no cipher-suite all-cipher-suites
cipher-suite rsa-with-3des-ede-cbc-sha
cipher-suite rsa-with-aes-128-sha
cipher-suite rsa-with-aes-256-sha
cipher-suite rsa-with-rc4-128-md5
cipher-suite rsa-with-rc4-128-sha


server virtual vservername
port ssl ssl-terminate sslprofilename

RackTables is a datacenter asset management system. By default is is configured with several object-types that are used in most datacenters, like network-switch, server, PDU, ups, etc. However, some obvious object types are missing. A firewall or loadbalancer are quite often used in datacenter environments. But RackTables is very flexible and extensible. You can easily add your own custom object type. To do this, follow the following steps.

  1. Go to Configuration, Dictionary
  2. Click RackObjectType
  3. Click the ‘Edit’ tab
  4. Add the Object-type you want and click the ‘+’

By default, you cannot attach an ip address to an object-type. This must be configured manually. You need to have the objectid of the type you just added.
When you go to the Configuration -> Dictionary -> RackObjects page and look at the HTML source of that page you see something like:

<tr><td><img src='?module=chrome&uri=pix/tango-emblem-favorite.png' width=16 height=16 border=0 ></td><td>78</td><td><div title='key=50019'>Firewall</div></td></tr>

The key=50019 is the id that you add in the list of IPV4 enabled objects.

To make the object IPv4 enabled, follow the following steps.

  1. Go to Configuration, User-interface
  2. Click the ‘change’ tab
  3. Add the object id to the textbox named ‘List source: IPv4-enabled objects’

The list of IPv4 enabled objects should be something like:

{$typeid_4} or {$typeid_7} or {$typeid_8} or {$typeid_12} or {$typeid_445} or {$typeid_447} or {$typeid_50019} or {$typeid_2} or {$typeid_50063}

I use Racktables to keep track of the devices in our network. To backup the configuration of our network devices I use rancid. To prevent having to edit and update multiple configuration files and systems, I thought it would be a good idea to centralize this and use Racktables as a source for configuring other systems. Racktables is a very extensible system that allows you to add attributes to a category yourself. I’ve added a ‘Rancid’ attribute as a dictionary item containing ‘Yes’ and ‘No’. I’ve bound this attribute to the object categories (Networkswitch, firewall and router) I want to backup with Rancid. I’ve scheduled a cronjob that runs the attached script, creating the routers.db file that is used by rancid.

The script runs an sql query to include all devices that have the Rancid attribute set to ‘Yes’.

To use this script in your environment, you have to edit the sql query to use the id of your rancid attribute in the dictionary. In my case the rancid attribute has the id ‘10003’ and the ‘Yes’ dictionary id is ‘50030’. These values can be found by looking in the racktables database.

Download the racktables-rancid export script.
Download the wrapper script

While migrating the authentication of our ASA firewalls to tacacs, we enabled ‘enable’ authentication to tacacs and tried to switch to enable mode on the console. This did not work, and caused the following message in the tacacs log file:

Wed Jan 13 17:07:42 2010 [25444]: enable query for 'username' 13 from 10.x.x.x rejected

To fix this problem the tacacs configuration for the user needs to include the enable password in the profile, as shown below:

user = username {
login = des "XXXXXXX"
member = admin
acl = mgmt_devices
service = shell {
priv-lvl = 15
enable = des "XXXXXXX"

We use the following configuration on the ASA to enable AAA to tacacs.

aaa-server tacacs protocol tacacs+
aaa-server tacacs (outside) host
aaa-server tacacs (outside) host
aaa authentication ssh console tacacs LOCAL
aaa authentication telnet console tacacs LOCAL
aaa authentication serial console tacacs LOCAL
aaa authentication enable console tacacs LOCAL
aaa authentication http console tacacs LOCAL
aaa authorization command tacacs LOCAL

Tacacs is a great way to centralize user authentication, authorization and accounting. While tacacs originally is a Cisco thing, there is an open source server version available, tac_plus (http://www.gazi.edu.tr/tacacs/index.php?page=download). Installing the tacacs server is quite straight forward. Configuring the switch is not difficult either, as long as you think about possible failures. You don’t want to be locked out of your switches when your tacacs server is not available. I use the following configuration that uses two tacacs servers and asks for the enable password when neither of the tacacs servers is available. To enter ‘enable’ mode, the configured enable password suffices. Use the following Cisco configuration for a save AAA authentication.

NOTE: Always be careful when changing authentication and authorization configuration, as this might lock you out of the device. The savest way is to do this on the console of the machine.

aaa new-model
aaa authentication login default group tacacs+ enable
aaa authentication enable default enable
aaa authorization exec default group tacacs+ if-authenticated
aaa authorization commands 15 default group tacacs+ if-authenticated
aaa authorization network default group tacacs+ if-authenticated
aaa accounting exec default start-stop group tacacs+
aaa accounting commands 15 default start-stop group tacacs+
aaa accounting system default start-stop group tacacs+
aaa session-id common
tacacs-server host single-connection
tacacs-server host single-connection
tacacs-server key TACACSKEY
tacacs-server directed-request

To restrict access to specific devices, you can configure an ACL in the tacacs configuration on the server (tac_plus.conf). See the example below.

user = username {
login = des "XXXX"
member = admin
acl = mgmt_devices
service = shell {
priv-lvl = 15
group = admin {
default service = permit
service = exec {
priv-lvl = 15
# acl's

acl = mgmt_devices {
permit =
permit =

We have a small VOIP network with 10 phone, a dedicated DSL line from Orange/Online and an external Asterisk server in a datacenter. The DSL line is terminated on a Speedtouch modem. With the default settings of the modem we experienced two problems:

  • Incoming calls did not get through
  • The sound of outgoing calls disappeared while the call was not dropped

In the Asterisk logs we could see the following message:

[Dec 30 13:40:51] WARNING[1911] chan_sip.c: Maximum retries exceeded on transmis
sion 0016c7ea-28120012-73ca27ca-35d5391a@ for seqno 102 (Critical Respo
nse) -- See doc/sip-retransmit.txt.
[Dec 30 13:40:51] WARNING[1911] chan_sip.c: Hanging up call 0016c7ea-28120012-73
ca27ca-35d5391a@ - no reply to our critical packet (see doc/sip-retrans

To fix this, you have to disable the SIP helper on the Speedtouch modem. Connect to the modem with telnet (default ip:, default user: Administrator, default password: ) and enter the following commands:

{Administrator}[connection]=>appconfig application=SIP SIP_ALG=disabled