Tuesday, May 31, 2011

3G and IPv6 More considerations:

Please note this are pretty much notes I made while going through some literature, I also assume a lot of people reading this have probably worked for ISP's and understand a typical ISP network:

A 'generic' ISP network has functional roles very much like a 3G network. They have an access network, Distribution/aggregation and a core network. 3G is a just a 'little bit' more complex but think along those lines and you'll get it.

The 3G/UMTS network is divided into two main domains:
the packet switched (PS) domain - Where I predominantly work/worked
and the circuit switched (CS) domain - where I know enough theory to run circles around most but I'm by no means an expert.

The core network elements comprise of the GGSN, the SGSN and the IMS (Think of the IMS as a mix of many many systems/applications).The GGSN is really just a customized router between the GPRS network and other networks - the first GGSN I ever run was a cisco CMX based on the 7613 chassis and a bunch of MWAM modules interfacing networks such as the general Internet and customer networks.

The SGSN is again an intermediate router between the GGSN and radio network. It's main responsibity is administrative functions other than routing: AAA, mobility management, and billing, among others - please note you can bill from either SGSN or GGSN's, If you have a DPI/PCRF, the billing function is moved further out of the actual 3G network.

The IMS as mentioned earlier is essentially the server farm, is where content and IP infrastructure servers live. So your DPI, WAP, DNS etc etc

The radio network abbreviated as UTRAN has Radio Access Network Controllers (RNC's) and base stations (BTS), which connect the handsets (UE or User Equipment) to the core network. The radio network is capable of transmitting data at various increments from 64 kbps to 2 Mbps or more - it all depends on issues like the next line describes and the technologies used - google for direct tunnel-.

The actual data rate depends on propagation, velocity of the handset, bandwidth available, and so on. This is important to note especially if you're the kind of guy that escalates issues to me:-) or if you live in South C....:-) thats a joke...laugh

IPv6 view of a 3G network:
As far as IPv6 is concerned the biggest point of concern is the pdp context. This forms the connection between the (UE) - user terminal and the GGSN. It is over this link that we transfer packets. If you're thinking - oh so like PPP - I'll say yes, just like PPP, only we use a protocol called GTP .

PDP contexts are created and torn down every time you attach/detach/re-attach. So IPv6 runs over this PDP context and that is what is referred to as an IPv6 link for a handset.

Resource usage on Handsets:
Now imagine if you are dual stacked, imagine how much power you'll be using or attach reattach for two sets of contexts and you begin to see why I still insist that all mobile handsets should be made to only support IPv6 then use 6to4 mechanisms to transition.

Also imagine a chinese manufacturer and your standard user who will buy a Nokla phone that some 'manufacturer' only enabled IPv6 and you suddenly start having very interesting support calls. I am so sure the black market for IPv6 handsets will show up and one of the key issues will be IPv6/IPv4 misconfiguration. Some intentional, some laziness, some just pure sillines.

You will definately also need slightly more memory to hold the lenghthier IP addresses. This looks trivial but again I expect some issues there.

IPv6 address assignment:
GPRS systems have always supported static and dynamic addresses. This can be stateless or stateful. The key issue with IPv6 here is the simple fact that autoconfiguration requires a mac-address, your handset doesn't have this, to counter this, we'll use rfc 2472's procedures.

There are other issues here with addressing that Im not entirely sure I get, like since we now have so many addresses, doesn't it make sense to assign static addresses? plug each msisdn with an IP on the HLR and call it a day? apparently not

Aa /64 to each handset is a huge number of addresses, however you can very well expect guys to share connections behind mobile devices in which case it actually makes sense. It also makes sense because 'most books' say so, and if you do the binary math carefully, you start seeing why /64's to each endhost is good for the transition. Heck some might even require /48's - think of tethering. Plan how to do addressing carefully.

Whether or not you'll run out of addresses depends on many variables, including size of allocation, customer takeup, and so on. Your planning is also key here. If you were an idiot subnetter in IPv4, I suggest you try cross the idiot barrier fast. IPv6 is a whole 'nother ball game. In reality even with the ratio adjusted to /64 per PDP context, and only addresses from 2xxx:: used, there are still well over 300 trillion addresses available. This should be plenty of room for the next few years. Just plan accordingly, read widely, you should be okay.

The movement of cellular hosts within 3GPP networks is handled by link layer mechanisms. So as far as IPv6 goes, it's handled just as it would be in IPv4.

Following the case above, it means the PDP context would be moved from one location to another without tearing down the pdp context. Now most movements are within base stations - micro mobility? This doesn't change your point of attachment for IP so there's no 'handover from a ggsn to another. You can also have movements that churn your point of attachment between GGSNs - macro mobility. In the initial releases of 3G, macro mobility is taken care of below IP layer by using tunnels to create an apparently flat IP network. ie a tunnel between ggsnA and B ensuring your PDP context remains BUT the more this happens the more delay and other bad things can happen to your connection.

Arghhhh.......throw in another arghhh for the fact that telco's still insist on using simcards for identifying users....the sim card should be killed...swiftly...another rant, another day

Are there motivations to move IPv6:
Where I work, IPv6 is still pretty much driven by technical enthusiasts. Management is still quiet and can be quite unsupportive and a morale drain. However it might be us techies failing to inform them. Am I motivated enough to do that? probably not, for some reason there is always someone higher up, an invisible hand out to discredit or tear them down, or generally just not ready to make things happen fast enough, so unless i can safely do it without asking eg paying for my own ccie or travel to afnog,or test IPv6 I stopped bothering; they can read my blog though:-) to get a grasp of my views.

The move to general IP is however very well taken up. we have come from far, we've done an NGN, we have a unified core so IPv6 will be an easy one to cross once we get widespread acceptance, or its forced on us. Either way it will happen.

I also saw a nice term describing a challenge we can expect. IPv6 brain drain. Since the most senior enough managers to make retention decisions do not know much about IPv6, expect to lose some people to the ones that get it faster than you.

In the US, IPv6 is actually being driven by government. i find it weird that organizations that stand to benefit the most are the ones lagging behind the most.

Probably the clearest motivation for 3G from the telco point of view is that the integration of IP actually helps to reduce the cost of running the network.Ultimately, the goal is to carry voice traffic over packets, enabling statistical multiplexing to kick in. This should save costs on traditional support infrastructure, such as circuit-switched E1-minimum increment backhaul. Furthermore, the mass market economics of IP, when brought to bear upon the production of telecomms equipment, should result in further savings.

- read IPv6 Network Administration By: Niall Richard Murphy; David Malone


Monday, May 30, 2011

IPv6 Addressing - Mobile network considerations

Now I have of late been looking into alot of things IPv6. So much that I'll actually be throwing in a discussion around it at Afnog in Tanzania - look me up on the 7th June 11 am. After that we can grab some beers at Kempiski.

While alot of the stuff we'll discuss are not implemented. They show our (the technical guys) thinking and plans for the mobile network part. The enterprise business and IT generally have plans just like everyone else has.

So what is different with IPv6 addressing:
First of all, IPv6 is technically incompatible with IPv4 addresses. With that in mind, here are some areas we expect some 'issues'...

There are three considerations to focus on here; the network,the mobile nodes and the applications.
  1. - First of all Roaming. I don't see this happening without some automated tunneling like ISATAP. There have been commercial tests for this by Ericsson and a european telco. A native IPv6 roaming agreement will probably take a while. (I still dont get this whole roaming thing - I personally think its a 'silly business model'. also note that if some providers do not go IPv6 at around the same time you do, it ironically forces you to support IPv4 addressing when your own  (outbound) subscribers roam to networks which do not offer IPv6.
  2. Per subscriber IP addressing: We'll seemingly be using several addresses per subscriber. If you did any IPv4 planning, conservation was very key. It might seem like a huge waste assigning /64's per subscriber GGSN/PGW- thats huge unless GGSN's start supporting 12Million subscribers or more.....
  3. If you choose a dual stack scenario, Your handset will need more memory to hold IP's. At afnog we'll be discussing why the best strategy really is to have IPv6 end to end or at least at the network and handset level then leave the applications to slowly transition. This interestingly has us using NAT 'for good' ie we'll be natting IPv6 to V4.
  4. The transport network need not be IPv6 ready, an operational IPv6 network can be deployed with configured tunneling between the network nodes with IPv4-only transport. for instane betwen nodeb's and rnc's.
A flexible method for IPv6 address assignment

Thursday, May 19, 2011

What is NAT44

If you go through IPv6 training material or blogs or whatever your source is, if you have run an ISP *on a constrained budget or dodn't have AFRINIC  [1]as an RIR to get routable addresses for all your users,then the NAT technology is something you might have had to deal with.

NAT has been very successful in delaying large scale IPv6 deployment. But the end is near.

NAT44 is on most slides I have come across as an IPv6 transition mechanism. I have to say for some slides I was preparing, I had to throw it in just so I can rant about it.

NAT44 also goes by the names:
CGN - Carrier Grade NAT
LSN - Large scale NAT and
NAT444 - which implies multiple two NAT44 layers

There's also a distinction between SP NAT44 and Residential NAT44. The key difference really is the implementation and NAT placement. the SP gets a large box to do NAT and calls it CGN/LSN.

Lets have a quick look at the differences:
Residential NAT44
would be deployed on a CPE,
generally deployed on the SP side .
The end topology would look like the following:
CGN is NAT44 on the SP end, CPE's are also running NAT

So you'd have two RFC1918 addresses back to back. The idea is to extend the 1918 space as much as possible.  Prolong the pain if you may.

The deployment models are varied. There's a NAT on a stick model that eliminates NAT from the main data path and uses source-IP based routing - This has almost killed our network several times.

You also have an inline model that forces all traffic to use the NAT path. You get a single point of failure as bonus.

Reasons I agree with alot of people that this is not an ideal solution:
  • The most easy to identify from the diagram above is conflicting address space between the customers and SP's. there's a draft proposal for shared address space that Im yet to read.
  • A single level of NAT (NAT4?) was very prevalent, and it worked to a large extent. Applications won't be aware of the other tiers of NAT which will undoubtedly break a few things.
  • Troubleshooting will be a mess. I mean how many NAT's are we to learn - NAT, NAT4, NAT44,NAT64 - dare I say I expect someone after using all v6 space to propose NAT666 
  • Application developers will have a hard time predicting or trying to work in what technologies will be used to reach their content/run their apps.
  • There will be contention for port pools. Remember some applications leverage multiple ports to speed things up, NAT will be doing the same which means some customers will definately notice 'slow internet'.
  • Accountability and logging? forget it in NAT44.
A few reasons why it will most likely be adopted more for IPv6 transition:
- It is well understood - I think * I suspect the real culprit is the ease of deployment not a good understanding, Most network engineers have no idea how NAT affects applications and guys writing apps have no clue how the network affects their work. Some do, actually most do, they just dont seem to be running networks. They're made managers:-)
- Its easy to enforce policy
- cluelessness/laziness/low budget/misplaced priorities
- NAT44 devices on the client end wont require replacing.

- This NAT44 thing will be installed, mostly the NAT on a stick model.
- Customers WILL be affected during  the IPv6 transition
- It is inevitable that someone somewhere will be forced to host their application on an IPv6 only site. I expect this to begin happening in the next 3 years.
- Worse, it is inevitable that some devices maybe for home automation, maybe some large scale rfid tags to track rhinos , whatever, some device somewhere will be deployed without an IPv4 option.
-Even worse or better, high chances are they wont be connecting to a typical enterprise network, most likely going to be a mobile network of sortes. 3g/edge/umts/lte/wimax.
- the last fact from me here is that not many people know what is happening. there are too many prevailing not necessarily agreeing views on IPv6/IPv4 depletion, transition mechanisms and the effects on the internet.  I get the feeling 'no one really knows'...I sure as hell don't, but read widely, listen, work with others...who knows what sort of enlightened state we'll be in later.

In this part of the world -kenya, most mobile operators especially at high management level still have 'heads in the sand' as far as IPv6 is concerned. Early adoption would probably benefit them the most.

1-AFRINIC is probably the only RIR today that still has V4 addresses to dish out to LIR's.
*I posit that this could create a false sense of security for african operators forgeting that most of their customers access content 'outside' Africa, if said content is switched to IPv6, we're done for and the sad thing is most network admins might not be ready to explain to 'the suits' higher up what the hell happened.

*For any reference to an rfc, google for it or  head to the ietf site
•  “basic-nat44” (Reference [RFC 2663])
•  “napt44” (Reference [RFC 2663])
•  “stateful-nat64” (Reference [NAT64])
•  “stateless-nat64” (Reference [XLATE])
•  “basic-nat66” (same as basic-nat44 but for IPv6 family)
•  “basic-nat-pt” (Reference [NAPT])
•  “napt-pt” (Reference [NAPT])
•  “twice-nat44” (Reference [RFC2663])
•  “dynamic-nat44” (Dynamic SRC Address-only)
•  “stateless-nat66” (Reference [NAT66])
•  “napt66” (same as napt44 but for IPv6 family)

*A Juniper implementation guide
* a paper from nanog
* jeff doyles post over at network world

Tuesday, May 17, 2011

as the rooster crows:-)


Well the site came out really well, and if you ever need to listen to great tunes with a twist...head over to Jack's site .

Yes yes yes he's a ccie and close friend so the content is valid here:-) go check it out...download a tune, or two...maybe all 3 volumes.....

Data Center design , a LLD and a meeting in middle earth

on webex meetings you can't really tell where any one is now can you, for all I know Gandalf and Frodo are on the call while flying over the shire....

So it was around 3pm (Monday) and a meeting request pops up. Easy I tell my self, open it, two attachments hmm...pdf- well we can read that. double click, takes a while to load up, double click the other one just so we can at least have a clue on what both are:

Document 1: - LLD from from cisco on UCS design
Document 2: - another one for the DCI - Data center interconnect.

Total: 220 Pages. Review and discuss on Tuesday.

Well my DC-fu sucks, rather sucked, my experience with NX-OS never went beyond me drooling over the boxes and marvelling and dreaming at all the adventures I'll have with the shiny box, and al those modules you can pull out on a nexus 7K....awesome...by the way if you did a data center before 2009, the skills are not transferable, so many changes in there, its all about virtualization now, many more services, fancy terms...aiyaiyaiii...

Lets go back a bit: last month I had purchased or rather loaded Interconnecting Data Centers Using VPLS (Ensure Business Continuance on Virtualized Networks by Implementing Layer 2 Connectivity Across Layer 3) to my bookshelf on safari. (now I know vpls is a terrible choice for DCI, i also know why), I also went through most of the DC webinars  (I can't think of a better educational investment than Ivan's webinars and a yearly Safaribooks subscription) and re-learnt the difference between OTV,VPLS and pseudowire) a separate post will describe how and why we use them here (I work for a telco).

So yes I think I moved from novice to just about clueful in a month. Today we have a kickoff meeting where I'll try and show off all my wondrous knowledge in the hope someone decides Im fit to be let loose on the shiny boxes....Yes I managed to go through the documents at a price....Im still sleepy, coffee doesn't seem to be helping much....

Monday, May 16, 2011

IPv6 deployment status

IPv6 deployment status
Kenya's ipv6 deployment sucks, heck we don't have AAAA records even for google.co.ke,safaricom.co.ke etc...which pretty much means June 6 th - IPv6 day will hopefully break something - I hope that happens if only to get the sleeping execs up....

Sunday, May 15, 2011

webex file formats (arf/wrf) and Ubuntu 10.x

Now I went out and subscribed to webinars that are recorded on webex . Unfortunately for me, ubuntu doesn't have a player for arf and wrf formats. If you're in that bowl of soup...fear not, here's what you do:

webex provides a host of tools to make your life easier. The one you need is the converter for arf to mp4 that vlc or most media players can handle.

Its really simple:
wget http://support.webex.com/supportutilities/nbr2mp4.tar
untar and extract a '.sh' file
tar - xvf nbr2mp4.tar
chmod +x

a folder nbr2_mp4 will be created, go in there and run
./nbr2mp4 'abcd.arf'
output will be
or whatever you want to name it.
you can change the FPS - frames per second to whatever you need. I left the default 5 for my case.

As its working, you can preview the file just to be sure it works with vlc in the /tmp directory. a file like:

cd /tmp
ls -lrta 
-rw-r--r--  1 jgitau jgitau 1355776 2011-05-15 18:50 wbx_nbr_3523.h264
will be available. when its done - it takes a while, you'll get an mp4 file that you can play.

vlc wbx_nbr_3523.h264

some interesting reading

well this weekend has passed lazily. I watched green lantern - first flight thrice (third time bacause my neighbors son insisted on it - we both loved it.

Read Joomla!™ 1.6: A User’s Guide: Building a Successful Joomla! Powered Website, Third Edition. over at safari - I have been working on a few sites. Between Joomla, Drupal and Plone I have to choose a CMS. Joomla and Plone4 seem to be winning out for various reasons but thats neither here nor there.

I also went through Ivan's webinar on upcoming internet challenges and decided oh hey...look some affect me:-)...

The top one is the fact that TV over access networks is now a reality in Kenya. DSTV started streaming over safaricom's network. Which means my cell phone is a tiny media house now. It's not yet 'that killer app' but we're headed there. compared to netflix's 1M subscribers connecting through Level 3 doing about 3Tbps, we're nowhere near that capacity.

NAT - arghh this one pains me, its even worse -for me-that some of the solutions being proposed for ipv6 is NAT.....we're lazy...again

The other one is business model failures. and misleading service definitions. I think we're still experimenting with how to bill data. I expect a lot of money to be wasted especially with DPI's and trying to bill per service. Imagine if you were billing skype as a service, now Microsoft bought them and suddenly your DPI will probably need to look at totally new metering bits/rule base to decide on what/how to bill. The effort is not worth it. chances of messing up and pissing off customers is high.

In a few networks I know, DPI is used for good. It ensures fair usage for all.

Unbundling the local loop in Kenya is quite easy with the right policies. Heck I think it would fit very nicely for a startup based in one of the upcoming high growth counties.

and there's more and it goes on...some day i'll be writing better...for now you're stuck with my thoughts and notes...

Thursday, May 12, 2011

KRA data center woes

Kenya Revenue Authority's data center had a power upgrade go wrong and affect several services by disrupting the supply chain of goods, specifically there are widespread fears that this could trigger another fuel crisis, or worse be used as an excuse for one.

Looking back at my escapades with data centers, many many lessons have been learnt. The one that tends to ring true over and over again is how power and its design is important in a data center. Trying to recover services especially poorly documented services can take ages.

It also brings home the fact that no matter what scale of services you are running, business continuity is not something to take lightly. Make all the critical data centers and services fully redundant.

I cant think of a single excuse a revenue collecting authority can have for such an outage. none. the technology and any other resource that might have been a limiting factor several years back is now widely available.....oh well I guess this is a good time to brush up on data center design....it wont be fun...too much has changed, and remained the same...which means mega confusion

Tuesday, May 10, 2011

term of the day

A term I had not come across that definately made it to my document's to get done list* This is probably a *hint* to one of the things keeping me busy this week....
Founder vesting

Monday, May 9, 2011

I was young once.....

I had pretty much the same boy dreams, go out play in the mud not get bullied, bully girls especially ones i was attracted to (was it just me?). I mud slid, rode 'shot gun' in a pickup, picked my nose...you know little boy things.

My mother had the usual dreams for her son. He'll be a doctor and take care of all of us in old age! she imagined. Or he will go to America and come back an educated young man - can't even remember what i was to study there:-). (It was a fad that has most of my cousins currently living overseas). I laughed at jokes and farted around and went out and rode my grandfathers bike, or played hide and seek at the mango farm.....

Today, I still play, the toys are bigger, Im chasing the same things I used to, I try to be nice to the girls, I have travelled more than most and I turned out to be a pretty decent network engineer/farmer/brother/friend/uncle....so life has been good, it has been very random, weirdly twisty and I have been very very lucky so far.....its great to be me - and no I had nothing better to write but hey--its life go be alive....

hmm ok so Im reviewing some materials for the CISSP certification - might as well get that over with - (I attended the training a while back but had no idea if I wanted the certification or not) - then realized banks love it.

I'm also subscribing to Ivan's webinars just so I can get all the data center webinars he's been conducting. see I had something technical to say:-)

Thursday, May 5, 2011

ccie plaque

Well look what finally arrived ............

Cloud what?

Look If you are one of those bozo CIO,CTO,CCC,CKT or whatever acronym that will make me rich by moving your stuff to a cloud while concurrently being thoruoughly clueless about it, please:

1: Get my contacts right. You might forget it during a meltdown and I need the money.....
2: And this is important, learn,read up on cloud services, what they are, what to do when the clouds go 'poof' automagically. Just because jesus rode one doesn't make them fool proof.

Seriously guys, you still need redundancy, you still need to think about the design and you most definately need regular audits no matter who is providing the service to you. Yet another reason I don't advocate for Kenyan companies hosting anything outside our borders....especially if its mission critical like those idiots who installed systems that monitor 'patients pacemakers' in the 'clouds'.

If you are a network admin, get clued in on this 'cloud thing', its gonna be bread and butter alongside IPv6. Start small, install vmware, mess around with esx, steal a nexus switch or oh well justlearn something to sound intelligent when the friggin' cio/cto wants to talk cloud....
I especially liked this one:

Tuesday, May 3, 2011

wireshark Filters

I was messing around with wireshark today.You have two kinds of filters:
Display filters and capture filters. Capture filters are especially important if you don't have alot of space and post processing 'power' on your laptop/pc.

Display Filters samples:
Only display packets sent to or received from
Filter 1: ip.addr ==
Filter 2: ip.src == or ip.dst ==
Only display packets sent to
Filter: ip.dst ==
Only display packets sent from
ip.src ==
Only display TCP port 53 packets
tcp.port eq 53
Only display TCP port 110 or UDP port 53 packets
tcp.port eq 110 or udp.port eq 53
Display packets from every IP apart from
ip.addr !=
Only display or DNS traffic
arp or dns
To see POP passwords
pop.request.command == PASS
To display FTP commands including USER and PASSWORD:
For displaying ALL frames with the word PASS in them:
frame contains 50:41:53:53

For the capture filters, the same sort of format is used. Please follow this link on how to go about some of them....a good third-world-networker needs to know his/her way around wireshark or whatever you use for packet capture.

Monday, May 2, 2011

I think Im driving this bus now!

As I watch Himawan's  webex recording on the ccie program and some new bits he worked into the program. His story fascinates me. I like the focus and dedication he has shown so far. I decided to post this just for me to keep track of things.

its been an interesting month. as a couple of you know,after passing CCIE, I have been away from work focusing on some personal projects that had been long neglected, resting and giving my career plans some serious attention.

At this point, my main motivation is money, I borrowed lots of money to take the CCIE (I'll do a post on what it costs a third world networker to do some of these things) so it really has to pay that back - and then some. Soon, the focus can move back where it matters. Getting the best exposure and personal satisfaction from what I do on a day to day basis. 

Now Im back at work and I think I can pretty much throw my digested mind map here.

Option 1:
Stay at my current job, negotiate for more cash. This is my preferred option, but Im a terrible negotiator. The only issue I foresee here is the remuneration. That sucks. Other than that it is the perfect place to work, it offers the best opportunities for technical growth and I doubt the grass will be any greener elsewhere as far as a good work environment goes. There's also exciting change happening and it almost has that 'start up feeling' that I like. It also exposes me to everything I'd like to be doing technically. LTE, CCIE SP, IP transformation,project management and a training component.

Option 2:
Work for a cisco partner that actually requires my ccie number more than my skill - for now. This is most definately the easiest option as far as getting more money and a new job goes - 2 solid offers received already so yeah a ccie helps. But most of them do not do service provider networks so I'd be bored senseless. I hat being bored. However we/they can grow the business and get some SP's in. I'd also most likely pursue a JNCIE* and a CCIE-Security - to kill the boredom and they would be paying:-).

Option 3:
Work for a Telco integrator like NSN or Ericsson or Huawei. Definately worth looking into. I am fascinated by LTE, IP RAN and the whole mobile network ecosystem/revolution. I also have a very strong background having run a mobile PS core for 3+ years before my current IP NGN role. I probably wouldn't pursue any other certfications. However I'd most definately improve on my multivendor skills so some juniper and Alcatel experience would be pursued.

Option 4:
Work for Cisco. Well I guess just for the multiple CCIE's (I would really like the voice and SP) and the opportunities that would open up. This option is actually quite high up on my list especially if at some point I get a role that deals with the ASR 5K's and general SP -NGN mobile networks like stuff. I however know for sure that this BU is not represented in Kenya and I'm not really interested in starting from the bottom or from another office and working through the maze that is Cisco.

Option 5:
consult - basically take on contracts and go work wherever id be needed.anything from GGSN's, IP NGN, migrations, ipv6, whatever ....  I would get to travel and earn lots of cash. Im not so sure why I dont like this option given that its the easiest path for me. I'd have to be desperate to pull this trigger.

Option 6:
Set up my/our own shop and hustle it out as a consulting/training company. This takes quite some work. Just working on filling a business model working in business plans, deciding on partners etc is enough headache already. While I have lots of practical experience, I tend to over think things so ehh...hmm... I can pursue whatever certifications I feel are relevant to market the 'shop'. I'd probably have to do more to improve on my voice and security. I also have a very good network as far as contacts go.. This definately offers more long term benefits but in the short term it will be quite busy. definately also near top of my list.....

Option 7:

become a farmer:-) -- I could just go deal with Kenya's food security issues....it's a sector waiting to be exploded:-)

Im sure I've missed some out.

So anyway May marks the second month before I make these decisions so stick around...we'll see how it goes. Either way for all those that have been asking, yes, a ccie comes in handy especially in the EMEA region. go get one:-)

Oh I also lifted the following slides:
*They were shared on the webex above and I'd suggest you watch that. I make an assumption that the numbers are public...

Sunday, May 1, 2011

hiatus - just a short one

Ahh have.had taken some time off work/blogs/internet and generally umm people...I almost feel great....one more month to go before making some major career decisions (I had decided on a two month period to re-evaluae my career goals and seek/improve opportunities)...so this month (May) is bound ot be a bit tense and interesting for me....