Now What ?

So it’s been nearly 30 days since my first CCIE voice lab attempt and I’m soon able to take a re-sit. So where am I and what have I been doing ?

Well contrary to popular wisdom of throwing back into the books and finding where I went wrong, over analysing my mistakes and generally fretting about a re-sit, I had a holiday! And thus we go slightly off-topic. I played golf (well hit a golf ball around most of a golf course) for the first time in 20 years, thanks to my two best friends in the world – nothing better for dismissing a score report, which turned up as I was entering the first tee (as I knew what it said – I wasn’t going to let it spoil my day – although three days later when I had a look it did read better than I had expected!), than creaming a little white ball 200 yards down the middle of the fairway (I like to think that’s what I did – the reality was more 50 yards and very left or right!). I (with family of course) went to Port Douglas in Far North Queensland where I swam with turtles here.

We also got to see some really live and wild crocodiles too! He’s 3 metres in length and eating a mud crab claw!

The rest of the holiday was a celebration for my parents’ 40th wedding anniversary and my Dad’s 60th birthday – so much merriment occurred.

I also did do some study – it' just eats at you when you know there were things in the exam that you should have known and didn’t, so I now understand how to configure some of the things I didn’t expect to see (see I broke rule number 1 – expect everything to be there!), and I already feel that I have filled in some of those tiny cracks that will better prepare me for next time.

I have been struggling with flu-like symptoms since I’ve returned so I haven’t touch a router or phone in anger since the exam. I’m now looking at dates in June for Brussels – there seem to be plenty towards the back half of the month. I will have that booked shortly and we’ll go again, after all very few people pass first time do they!

Hand crafted AXL scripts and HTTP/1.x

In my current day-job, I sometimes create hand crafted pieces of AXL scripting for some of the trickier reporting aspects of auditing of provisioning process. These AXL scripts will most probably these days be crafted in Java, as I like the eclipse development environment which makes it very easy to debug these scripts (I’m not a professional developer – just someone who went to university and was taught how to write code in many languages). Just before I went away for my month to Australia and the CCIE Voice Lab, I had some reports that my script wasn’t working. Often these are just minor issues like a user not having AXL privileges or the input file format not being quite right, but this one was different – the script worked fine on our CUCM 6.1.3 and CUCM 7.1.5 servers, but not on our newly upgrade 6.1.5 servers.

So after that month off, I came back to reports that it still wasn’t working and could I investigate. So I fired up eclipse and dived right back into debugging mode. The response I was receiving from CUCM was “HTTP/1.1 400 Bad Request” – this I was not receiving from the other servers (i.e the none 6.1.5 clusters). I could not work out what was going wrong – I tried forcing the authentication to fail – still the 400 errror. I compared to other pieces of had-crafted AXL that we have, and they looked the same as mine. In the end I was on the point of giving up when I noticed in an example on Cisco’s developer site that one code snippet had the following:
        POST /axl/ HTTP/1.1
whereas my code had:
   POST /axl/

So I hunted through CUCM release notes for any mention of this change – no luck. I checked the tomcat release notes (having noted that the tomcat version changes between 6.1.3 and 6.1.5) and still no luck  - although there were a lot of changes related to POST processing. Checking the original http RFC-1945 states that “

The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. If the protocol version is not specified, the recipient must assume that the message is in the simple HTTP/0.9 format.”

However it seems that the tomcat within CUCM does not any longer adhere to that (although I can’t find this documented) and follows the HTTP/1.1 RFC-2616 section 5.1 which explicitly states that a request must have the HTTP-Version.

So I changed my code to contain the HTTP version and like magic it worked again. If only I used less hand-crafted scripts this would never have been an issue!