Monday, 30 September 2013

CCIE: The Begining Of A New Task

This is the new beginning of a long and arduous task. After considering hard and taken a long time doing that, I have decided to go for this exclusive and yet at times elusive certification, the grand mama of all Cisco certifications, the Cisco Certified Internetwork Expert (CCIE). Ok it was some time ago, but this blog only started today ;-).

I have just bought IPExpert's Blended Learning Solution for the CCIE R&S track. I spoke to Matt Brooks who was nice enough to spend time answering my many questions. After doing a bit of more research and also gotten a cool discount from Mike Down's blog, I took the plunge to spend over USD 900 for the package.








I am now waiting impatiently to receive the portable hard disk drive from IPExpert and start studying a little :-). Let's hope they arrive within this week?

As some of you may be aware, I am yet to complete my CCNP (ONT left). However, I figure that since the CCIE R&S track depends mostly on the BSCI and BCMSN part, I would like to study further into this area.

I have gotten myself 13 USB LAN adaptors which will complement my Dynamips setup on my Core2Duo laptop for the labs to link up with the 4 units of Cisco 3560 switches (8-ports model unfortunately). It will be a challenge itself to get this setup but I have gotten a head start by utilizing Scott Vermillion's topologies (Scott happens to use just a Mac Mini plus 4 units of Cisco 3560 switches to pass his CCIE R&S exam).

As of now, I am flipping through my BSCI books to try and refresh all the routing protocols in my head especially my favourite routing protocol, EIGRP.

The Release Of Cisco IOS V 15.0

Cisco is playing with numbers again and this time its IOS is the victim ;-). Jumping from 12.4 to 15 lets you know that Cisco is 'afraid' of the numbers 13 and 14 (number 13 is considered unlucky in the Western culture and number 14 (because of the 4) in Asian culture).



IOS release 15.0
This is not an April 1st post: I’ve just realized that Cisco quietly released IOS 15.0M (mainstream). Haven’t tested it yet, but the images for a large variety of platforms are already available on CCO. The new features listed in the documentation include:

    Full BFD support, including static routes, BFD-in-VRF and BFD-over-Frame Relay (next step: test it on a 2800-series router);
    DHCP authentication;
    DMVPN tunnel health monitoring;
    EEM 3.1 (whatever that is, the EEM documentation hasn’t been updated yet);
    Interaction between IS-IS and LDP;
    BGP local convergence in MPLS VPN networks (the feature has already been available 12.2 SRC, now it’s available on more platforms);
    OSPF graceful shutdown and OSPF TTL security check features are available on more platforms;
    Intra-zone traffic inspection in zone-based firewall.

It looks like (as expected) the 15.0 release is a grand merge of all previous IOS trains (with a few extra features). Good job; finally we have something new to play with :)

Learning Unicast Reverse Path Forwarding - URPF

Unicast Reverse Path Forwarding is a small security feature
When configured on an interface, the router checks the incoming packet’s source address with its routing table. If the incoming packet’s source is reachable via the same interface it was received on, the packet is allowed. URPF provides protection again spoofed packets with unverifiable source.
Though basically a single line command, URPF can be a little confusing when used with access-list feature if order of operation is not understood completely.
We’ll use this simple topology to demonstrate URFP.




R1 and R2 are connected through frame-relay and a Ethernet connection.
We test our basic connectivity.

R2#ping 150.1.12.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 44/93/192 ms

R1#ping 150.1.12.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.12.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/45/84 ms

R1#ping 150.1.21.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.21.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/54/100 ms

All right we have reachability on both Ethernet and frame relay interfaces.
In order to demonstrate URPF we use two static routes on R1 and R2.
R1 uses frame-relay to reach R2’s loop back (2.2.2.2/24) and R2 user Ethernet to reach R1’s Loopback (1.1.1.1/24)

R1(config)#ip route 2.2.2.0 255.255.255.0 150.1.12.2
R2(config)#ip route 1.1.1.0 255.255.255.0 150.1.21.1

Without URPF, we should be able to ping R2’s loopback from R1’s loopback.

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms

Now we enable URPF on frame-relay interface on R2.
Now when the incoming packet arrives at the frame interface, R2 checks the source address (1.1.1.1/24) in its routing table.
Since the interface used to reach this address is Ethernet0/0 , URPF checks fail and ping is not successful.

interface S1/0
ip address 150.1.12.2 255.255.255.0
ip verify unicast reverse-path

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)



All right!
This was the most simple part.
Now we use URPF with an access-list.

Understanding URPF Order of Operation:

Here we have to understand the order of operations.

1) When packet arrives at the interface, URPF check is done. If the check is successful, the packet is transmitted, and ACL doesn’t come into play
2) If the check is failed, ACL is consulted. Traffic is allowed or denied based on ACL entries.
3) The thing to understand here is that an ACL with deny any any will not mean that all traffic is denied. It won’t come into play unless the URPF check is failed. If URPF check is successful all traffic is allowed. If it is failed then ACL is checked an traffic is allowed or denied based on the ACL.

R2:
!
interface Serial1/0
ip address 150.1.12.2 255.255.255.
ip verify unicast reverse-path 101

access-list 101 permit tcp any any
access-list 101 deny ip any any log-input


Here we are allowing the TCP traffic and denying all other traffic in ACL.
It means that a telnet sourced from the LoopBack 0 of R1 to LoopBack 0 of R2 will be successful, but all other traffic will be denied.

From R1:
R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 ... Open


Password required, but none set

[Connection to 2.2.2.2 closed by foreign host]

Success rate is 0 percent (0/5)
R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
.....
Success rate is 0 percent (0/5)



Below is the log generated by ACL.

*Mar 1 00:16:40.171: %SEC-6-IPACCESSLOGDP: list 101 denied icmp 1.1.1.1 (Serial1/0 ) -> 2.2.2.2 (0/0),

Now lets ping the loopback with source frame-relay interface.

R1#ping 2.2.2.2 source S1/0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 150.1.12.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/48/80 ms


As you can see that though ACL is denying all ICMP traffic our ping is successful.
For the simple reason that ACL won’t be checked until URPF check is failed. And in the above case, it’s successful.


Now lets change the ACL.
Now our intention is to allow HTTP traffic between the loopbacks as well as ICMP traffic and deny all other traffic.

R2:
access-list 101 permit tcp any any eq www
access-list 101 permit icmp any any
access-list 101 deny ip any any log-input


We’ll be able to ping or telnet at port 80 but regular telnet will fail

R1#ping 2.2.2.2 source lo 0

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 2.2.2.2, timeout is 2 seconds:
Packet sent with a source address of 1.1.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/57/80 ms
R1#telnet 2.2.2.2 80 /source-interface loopback 0
Trying 2.2.2.2, 80 ... Open


R1#telnet 2.2.2.2 /source-interface loopback 0
Trying 2.2.2.2 ...
% Connection timed out; remote host not responding

R2: (:Log)
*Mar 1 00:20:18.895: %SEC-6-IPACCESSLOGP: list 101 denied tcp 1.1.1.1(35617) (S
erial1/0 ) -> 2.2.2.2(23), 1 packet



Well thats about it for URPF.
In lab exam if the feature shows up, be careful, as it can break connectivity if routers have asymmetrical routing.
Asymmetrical routing is not a problem in LAB generally as long as we have connectivity, but with URPF enabled, asymmetrical routing will break connectivity.
In that case,we can either tune unicast routing table or use the access-list with URPF to allow for connectivity.

Early Impressions of IEWB VOL 1 VER 5

A lot of people work differently, and when it comes to preparing for CCIE lab everyone has a different strategy.

Me, I am more of a reader than a handyman :) that is to say, I spend most of the time reading and far less time labbing. Even in the time I lab, I spend most of time making short labs, testing technologies than doing full scale labs. One reason is that I only have 10 dynamips IEWB full scale labs and I already did them twice anyway.

Recently I requested Brian Mcghann and Petr from InternetworkExpert to allow me access to their Vol 1 Beta labs and very generously they did. I am a customer of IE but due to financial constraints, I bought only first 10 dynamips labs and so the vol 1 beta access wasn’t automatically there for me.
While I am going through the labs, I must say I am impressed and there is also a feeling of déjà vu. My company financed Narbik’ bootcamp and hence I received his advance technologies workbook. I loved that. Basically Narbik took a technology and beat that to death. Quite similar approach of these Beta labs. When it comes to me, I’d prefer such approach above all other that is to learn everything about a technology rather than doing 40 full scale labs. Even before I went to Narbik’s bootcamp, my method of preparation was to read say 15 pages of documentation a day, and lab them up in small labs on dynamips. Narbik’s labs saved time I spent for cooking up a topology to test a feature.

I have not seen existing versions of Vol 1, but from what I heard those were very basic. These beta labs are not.

Though I am waiting for OSPF, security and QOS Vol 1 labs, and only after that I can rate these VOL 1 labs completely, I have to admit, I really liked these labs up till now. I even learned one new feature of EIGRP which is EIGRP stub routing with leak maps. If I were to advise anyone on how to prepare, my advice would be to go through Narbik’s Advance Technologies Workbook or( if by that time these VOL 1 labs are out) these VOL 1 beta labs, very slowly.

Do each technology in a week, and not only do the labs, read documentation about every feature and learn it properly. And at the end, do 10-20 full scale labs.

Anyway here are my initial impressions of the labs.



Bridging and Switching:

As I mentioned, my idea of technology labs is to cover all about a technology.

I feel bridging and switching sections should include small labs on following topics

IRB (Integrated Routing and Bridging). Of course, we’ll use routers for this J but technology wise the feature should be here
DAI (Dynamic Arp Inspection) (Though this topic can be potentially included in security. As I mentioned I need to see the security and QOS, before having a complete idea, as many feature I’d like to see can fall under switching as well as under these two topics. For me, DAI is more of a switching topic.)
MVR (Multicast VLAN Registration) And IGMP snooping, IGMP Profile commands etc. But then again, these features may have been covered in Multicast sections. Also IGMP snooping and DAI are inter-related, so for me these should be a part of switching.
SDM Templates
More explanation in lab 1.18. Trunk ether channel over DOT 1 Q tunnel can cause a lot of problems, if we are not sure of STP and VTP paths throughout our network. Instead of shutting down the links that can cause problems, these problems should be explored.
Port Security. ( Again, can be covered in security beta labs)


Frame Relay:


I again learned a new feature, bridging over frame relay and I thought I knew everything about frame relay.

Excellent


RIP:




Excellent labs,

Covering all the topics I think are necessary to learn RIP.



EIGRP:


I learned a new feature here. I can’t make it work though on dynamics unless I add the match interface option in Eigrp Stub Leak Route map.

This needs more research on my part though.

I’ll lab this up over the weekend, and maybe right a tutorial after understanding the feature completely.


Also, I believe strategy wise, IE is on right track.

I’ve known people going through full scale labs rigorously. This approach of learning everything, before doing full scale labs is what I’d recommend and I’ve followed.

I am really looking forward to QOS section, especially Catalyst QOS.

TTL Security Vs eBgp-Multihop

To understand the relation first lets explore what each feature job and purpose in life:
eBgp-multihop – like in IGP the default ttl for packets is 1 and that is to ensure delivery only to the directly connected network node, but unlike IGP eBgp is often (in real networks) established via interface loopback and because packet generated / sourced from Interface loopback going out the router using its next hop interface that break the communication as 1-1 = 0 and 0 TTL mean packet can’t be delivered to destination,


so what to do?
increase TTL (is the answer :-))
using the eBgp-multihop is like simply indicating what TTL should be set to the packet to ensure delivery to the desired network

ttl-security – so we now understand the eBgp affect packet going out of our system by manipulating its TTL,
How do I prevent neighbor coming 10 hops away from me?!
you set the ttl-security.

Now you will say, if you didn't want to be neighbor do not set him up on your side and that would be also ok, but lets say you have neighbor relation with 2 router and each is 3 hops away (normally)  now one router experienced a link fail causing it to change route to reach you and now he is 5 hops away, and your policy is to maintain neighbor relation with no more then 3 hops away.

but again you would say, so set the eBgp-multihop to 3 (or 4 if using the loopback) and you would be again correct.

so why ttl-security, mainly it is to prevent DoS attack!

hope this helped in some way to understand the difference and each feature job in life.

Cisco Introduced Changes to CCIE Lab, Scoring And Written Exam Question Format

Effective February 1, 2009, Cisco will introduce a new type of question format to CCIE Routing and Switching lab exams. In addition to the live configuration scenarios, candidates will be asked a series of four or five open-ended questions, drawn from a pool of questions based on the material covered on the lab blueprint. No new topics are being added. The exams are not been increased in difficulty and the well-prepared candidate should have no trouble answering the questions. The length of the exam will remain eight hours. Candidates will need to achieve a passing score on both the open-ended questions and the lab portion in order to pass the lab and become certified.  Other CCIE tracks will change over the next year, with exact dates announced in advance.

Effective February 17th, 2009, candidates will also see two other changes in CCIE written exams. First, candidates will now be required to answer each question before moving on to the next question; candidates will no longer be allowed to skip a question and come back to it at a later time. Second, there will be an update to the score report. The overall exam score and the exam passing score will now be reported as a scaled score, on a scale from 300-1000. This change will not affect the difficulty of the current set of exams and will assure CCIE written exams will be consistent with Cisco’s other career certification exams.”

My view -> The written exam changes are logical, the lab exam ‘interview’ could result in protests if fails are handed-out based on it…

CCIE Collaboration Transition Technologies

I put together a new playlist on our All Access Pass geared toward helping those that have decided to study primarily with the new CCIE Collaboration in mind. What will be included in this playlist is primarily new technologies, specifically those that haven’t yet been covered elsewhere in our CCIE Voice v3 products. As the weeks go on, I will continue to update this list with more and more videos covering new technologies in UC v9.1. Keep in mind that until I have this list complete with everything that is newer than UCM 7.x, that you can and should still study all of our CCIE Voice v3 products, as everything except for H.323 RAS/Gatekeeper will still be completely relevant and a very much needed base for your understanding.


Once I complete this list, I will probably leave it up for those only wanting to learn the new stuff, like those of you that are already CCIE Voice v3 certified (if you certified on CCIE Voice v2 or v1, and haven’t really used it in a while, you’re going to want to watch all the material over again as quite a LOT changed from v2 to v3). Also, once I complete this playlist with all the new technologies, I will be recording a completely new top-to-bottom CCIE Collaboration Advanced Technologies Class, that will include everything. And of course, the workbook is being completely re-written as well in our new online format, which you can see a sample of here and here. This video playlist is meant to not only hold you over until then, but also to be able to release material to you in a timely, incremental fashion.


To start with, here is 4.5 hours of material on Call Control Discovery over Service Advertisement Framework (CCDoSAF). At a most basic description, this is dynamic routing of DNs over an enhanced version of EIGRP. It is much more detailed and complex than ILS (a newer built-in dynamic routing in UCM), but it is also far more powerful and allows for things like powerful SRST configurations as well as cluster-to-cluster PSTN failover, should the primary SIP trunk become un-usable. Cisco pushes ILS much more in production, but given my last statement, and the fact that no CCIE Lab exam has ever been that much interested in real-world design -favoring complexity over ease of configuration and good design- and the fact that it is very much on the new blueprint, I’d say you best get used to it now. Who knows, you might even like it once you see what it can do. Also, I recorded these videos on a UCM v8.5 cluster, but that shouldn’t matter as this feature hasn’t changed much since then.

All CCIE Voice Eng. Need To Pass Written Exam Tp Become CCIE Collaboration Certified

After a huge outcry by many on Twitter, Facebook and even a Change.org petition with currently almost 1,200 signatures gathered in less than a week, Cisco seems to have recanted their position, and will be allowing current CCIE Voice certified individuals, as well as those that certify before the February 14, 2014 switchover date, to migrate to the new CCIE Collaboration, simply by taking and passing the new CCIE Collaboration Written exam, which will debut on November 21, 2013.





Here is the official statement from Cisco.

To all of our CCIE Voice professionals. Here is a statement from Fred Weiller, Director of Marketing at Learning@Cisco:

    “We are listening to the feedback from our valued CCIE community, and will be adjusting the CCIE Collaboration requirements. As a quick preview of the evolution of the CCIE Collaboration certification, a current holder of the CCIE Voice designation will now be able to migrate to a CCIE Collaboration credential by taking the CCIE Collaboration written exam only. We appreciate all of the great feedback and patience of the community while we update our webpages to reflect this change. We will be communicating further details about this modification as soon as possible.”

An Update About: CCIE Security v4 Racks

We’re moving the SCv4 racks to beta this weekend and through next week. If you would like to try out the racks free of charge, send an email to me directly (bdennis @ ine.com) and I’ll see about getting you accommodated. I’ll reply to the emails I receive by tomorrow late afternoon (EST).

Additionally I’m going to have added to everyone’s members site account who purchased the SCv4 workbook, SCv4 Workbook Bundle or SCv3 workbook the after October 2012 enough tokens for ten sessions on the new SCv4 racks. These will appear next week in your account. Also I’ll keep the SCv4 racks priced at the old SC rack pricing of 10 tokens for the next few months.

Lastly many of you have asked about adding the primer videos to the SCv4 Ultimate Bundle which I’ve done. If you purchased an SCv4 Ultimate Bundle you should see the primer videos in your account and if not just hop on chat with Sales or email them and they’ll get it added.

Lab Practice For Eigrp, NAT and OSPF

Welcome to another mini-lab. This time its a straight forward and quite small ospf and eigrp setup. After that Pat is introduced, and then changed to a Dynamic Nat setup.


Part 1:
Configure your network as per the diagram above ( Viso File link )
edit: the dlci’s are backwards in the diagram.   R1 should use dlci 102,   R2 should use dlci 201.
This lab is compatible with my template.net from my Virtual Racks tutorial.

Part 2:
Enable Ospf process id 1 on routers 2, 3 and 4.
For R2 make the loopback 0 and Ethernet interface part of area 0
For R3 make the Ethernet interface area 0. Loopback 0 should be part of area 3
For R4 make the Ethernet interface area 0. Loopback 0 should be part of area 4

Verify ip connectivity between the three routers.

Part 3:
Configure Eigrp AS 10 on Routers 1 and 2.
For R1 include both the loopback and serial interface. Make sure the Loopback is advertised with a /24 mask.
For R2 only use the serial interface.

Verify that R2 can reach R1’s loopback address.
Question:

Can R1 ping R3 or R4? Why/why not

Part 4:
Configure PAT on R2. The serial interface should be the outside interface. Only allow the loopback addresses on R3 and R4 to be translated.

Use the Extended ping command from R3 and R4 to verify connectivity to R1’s loopback. If it isn’t working, Investigate the routing tables on all the devices.
You may configure any device to get this to work.

Part 5:
Configure pool based NAT on R2. The translation direction and allowed devices is the same as Part 4. Some of the Part 4 configuration needs to be removed. You may only configure R2 to get this to work.

The pool range is 34.0.0.1 – 34.0.0.10, prefix /24.

End.

Preparation Of Lab Set Up For Service Provider

I am now focused on prep for the SP lab. This has meant going back to start with theory on certain topics.

I am still using dynamips for study but decided to combine it with some real switches, I already owned two 3550’s and needed a way to link these to my workstation. First I bought some usb nics but after discovering they all had the same mac address…..AND didn’t provide any support for jumbo frames I changed that idea to the use of a third party switch. So off I went in search of a non-cisco reasonable priced switch that could do QinQ. I ended up finding an Extreme Alpine 3804 on Ebay that had 20 x Gig Copper and 64 x 100 Copper ports for the nice sum of 300AUS. The product specs state it supports QinQ so I bought it and jumped in the car for the 3hour journey to pick it up.

The fun began when I got home and attempted to setup my virtual/real combo lab. The general setup is that each virtual router links to the simple Ethernet Switch provided by dynamips. Each port is an access port with a separate vlan id, Ie   R1 Fa0/0 is tagged as VID 101, R1 FA0/1 is tagged as 102,   R2 Fa0/0 is tagged as 201 etc.  The Ethernet switch then has a Trunk link that is bound to a physical Gig nic in my machine which then connects to the newly purchased switch. One advantage of this is that I can use dynamips to capture all traffic on the Gig interface and get to see all the tagging :).


So the issues began when I discovered I have QinQ happening in one direction, Data from the Virtual router to the Virtual switch then to the physical devices was fine, But my newly acquired switch was refusing to do QinQ.  had I bought a dud? After alot! of hair pulling and frustration it turns out that for my Extreme switch to do QinQ, the ingress frame must use a different ethertype than the one that the Extreme switch is using for Dot1q.  So basically if I configured the Switch to use the standard 0×8100 for tagging, No QinQ would occur.

Not a problem I thought and changed the Extreme Switch to use 0×9100. Now from my packet capture I could see both the Extreme switch and Virtual switch performing QinQ except they were now using different ethertypes.. So still not working properly.  Has anyone tried to change the ethertype used by the simple ethernet switch in dynamips? I ended up downloading the source code and checking it out. The source code mentions three types of Dot1q, They were DOT1Q, DOT1Q_2 and DOT1Q_3.     dot1q = 8100, dot1q_2 = 9100 and dot1q_3 = 9200.   I couldn’t workout how to configure the ethernet switch use dot1q_2.  So I changed dot1q = 9100 and recompiled dynamips.

Now everything works perfectly, Simply put my setup is layer2 tunnelling from each virtual router to a port on my physical switches.  Another advantage of this setup is that the gig nic in my workstation and all ports on the Extreme switch support jumbo frames :).

The .net file I am using can be found here

Josh.

Edit: Here a picture of my setup, Sorry about the quality but I had to crawl under my desk. And if anyone picks up on it, I did infact chop up and solder two cisco console cables to make a rs232 to rs232 console cable,.

Working of CCIE and CEO

As the CCIE Agent to the world I have been asked by a lot of CCIEs to help them find career alternatives to their current situations. Some are employed in what appear to be great jobs because the companies are multi-national or just really big. Often CCIEs working for the really big companies are only interested in moves to other really big companies. What many CCIEs have learned though is this. Big does not mean stable or equal to job security.


  In the past four years I have been in the Cisco SRS program I have also been an accidental traveler on the economic tsunami that has surged over every shore and border. Yet starting out the new adventure with Cisco during this harsh period has taught me a few things. One lesson is, Big or Really Big Company does not equal Job Security, another lesson is the average Cisco Channel reseller between 35 and 100 employees has survived and many have actually thrived.

The phenomenon has kept CCIE Agent, Limited growing. So I decided to take one of my clients to task in a very public way. Yeah I know it’s risky because the competition will try and call and candidates will go direct, all the things most recruiters are afraid of. BUT I am not a recruiter, remember? I am a career agent. This client is managed and owned by a CCIE and he serves in many capacities for his company as it grows.

Pros And Cons of IT Infrastructure Library

The Information Technology Infrastructure Library (ITIL) is a set of concepts developed by the UK government’s Central Computer and Telecommunications Agency (CCTA) to standardize IT management practices. Initially published in 1989, it has gone through a few iterations, namely ITIL v1, ITIL v2 and ITIL v3, its most recent version released in 2007. The current version is comprised of five volumes that focus on Service Management.

As with any type of guidelines, there are proponents and opponents who constantly argue about ITIL. The proponents argue that ITIL offers many cost saving measures, which in the current context of the recession makes enormous economic sense. It also helps to organize and manage IT departments. The biggest factor in its favor is that ITIL has been implemented in various parts of the world and has been proved to work.


That being said, it also has its own disadvantages. While ITIL does start to get everyone speaking the same language, its language/terminology is far from complete because it only handles a very small area of IT.

Parts of its language/terminology conflict with other parts of IT's understanding of that language, such as how software developers view "Release Management" and "Configuration Management". This means implementing ITIL to the letter will cause instant conflict with other teams that already have such solutions in place, as part of their own best practice frameworks.

Most people overcomplicate the implementation of ITIL. People and enterprises that lack experience in ITIL tend to implement it one discipline at a time, trying to "scope" its implementation and make it simple. Anyone that has experience in implementing ITIL will tell you that this will lead to far more problems than it will solve. Expenses will be high. Disciplines will be incomplete and in many cases not implemented. Rollouts will take many years. Rollouts will take a great level of time, money, and energy. Tools will be incompatible to each other. Tools will naturally be antiquated as you move from the 1st discipline you rollout to the Nth, which might be years later.

Nevertheless, even with all these disadvantages, to quite a number of people, ITIL remains an excellent management tool. The regular updates, worldwide acceptance and the sheer longevity of the concept are enough to outweigh all its disadvantages.

IT And Network Positions

1- Network Admin
Mention the words network admin to most, and these are the thoughts that are likely running through their head: “Isn’t he the reason I can’t see Facebook and Twitter? Sure, I get a blazing fast connection to the Internet, but what good is that if I can’t get to Youtube? He’s probably reading my email too!” No love there, and the network admin gets no love for the network being up, either — only grief when it goes down.

2- System Admin
Access rights granted by sysadmins are just a hurdle in the completion their peers’ tasks. Sadly, the other good work they do goes unnoticed, primarily because even IT professionals have no clue what else they are responsible for. And all it takes is one bad experience trying to get system access for a user to lose any admiration for all system administrators.


3- IT Manager
Unlike other professions, where manager would be at the top of the list, IT managers are hurt by the perception that they don’t do the “real work.” IT managers earn respect for their advancement up the career ladder, but this is offset by their perceived lack of technical skills. It may be unfair ,but managers lack IT cred. In addition, employees believe that their managers may have a general idea of their work but lack a detailed understanding of exactly what they do.

4- Reporting Specialist
When you get right down to it, the reporting specialist is nothing more than a glorified cleric, pulling data from the system, putting numbers into charts, and spitting out reams of paper in the process. If you have to deliver charts with bad numbers to your manager, you may need to use this time-honored phrase: “Don’t shoot me. I’m Just the messenger!”

5- Technician
Never appreciated until a hardware or system emergency occurs, the lowly technician becomes associated with bad circumstances. You know there’s trouble if the tech shows up. He or she may be given the moniker “hero for the day,” but more often than not, users just want technicians to fix their system and be on their way. The uninformed may compare the technician’s skills to the auto mechanic or the Maytag repairman. Usually in crisis mode, the high stress, low pay, and difficult hours typical of the technician do not garner much prestige.

6- Help Desk Analyst
Help desk analysts are the Rodney Dangerfields of the IT world. The people answering the phone on the help desk get no respect from clients or other IT professionals. They are expected to solve as many problems as possible at tier one but are not paid the wages befitting that level of technical expertise. When the phone rings, there is almost always an unhappy customer on the line. Help desk analysts take unwarranted verbal abuse for circumstances beyond their control and are rarely recognized for their efforts. Their performance is typically measured by the number of calls they take and complete per hour — not exactly a formula for friendly verbal banter, low stress, and thoughtful problem resolution. Respect? Even Rodney Dangerfield got more respect without the added stress.


7- Systems Analyst
The systems analyst is admired for his or her expertise in the multiple roles needed to build a successful system. They’re self-supervised and independent, and managers get out of their way and let them do their job. They are envied for their autonomy, high pay, and challenging work. They earn admiration for their high level of education, knowledge, and accomplishments. This unique combination puts the systems analyst at the top of the list.

8- Programmer
The programmer enters the room and a hush falls across the crowd. One person with awe and reverence showing on his face whispers in a respectful hush, “That’s the programmer who wrote the AI code!” Okay, programmers may not receive this amount of aggrandizement, but they are typically held in a special place of esteem. To the average person, programmers do nothing short of magic. They make the Web come to life with a multitude of useful applications. They create new and strange virtual worlds. They enable computers to do everything from gaming to running essential functions of business. And they do so with mysterious and enigmatic languages known to only those select few who are the keepers of the code.

9- DBA
If you have done any database work at all and are fortunate enough to have a database administrator, you will appreciate the workload that the DBA removes from your plate. A smart developer learns early on that a good, experienced DBA is critical to the successful completion of the project. Part art and part science, DBAs’ skills can have a significant impact on the performance of the systems they help develop and support.

10- Project Lead
Project leads who get their hands dirty and help with all phases of the project lifecycle are respected for their technical as well as their management skills. The role is not given to newcomers. Only those with years of experience make it to project lead. This alone is enough to earn the high esteem of the other project team members.

As A Result
Much of what I have written is totally unfair to the IT professional. Unfortunately, I believe it’s how many people perceive the IT roles I have listed — and perceptions can be difficult to overcome. While it is true that stereotypes and perceptions often predetermine prestige, it is equally true that prestige can be earned in the most mundane of jobs as well as lost by those in the most respected of jobs. Unlike the social classes of Victorian England, where right of birth was the sole determinant of one’s class, the working classes of IT are open to all who are talented enough and industrious enough to achieve them. The reporting specialist, or any other IT role for that matter, can be a stepping stone to a better paying position with higher prestige. For example, I turned my reporting position into a developer’s role by automating the weekly charts. If you are looking to climb the prestige ladder, you can do the same. You only need to be clever enough and wise enough to recognize and seize the opportunities that present themselves.
I am reminded of the old joke where the body parts get together to decide which is most important and therefore should lead. One of the morals of the story is that all of the body parts are important. If you have a job that is low on the prestige ladder, you should walk proudly with your head held high. You know how hard you work. You know the unique skills required to do your job. You know how important you are to the overall success of the company. Never let anyone, including me, tell you otherwise.

Difference Between IP Services Image And IP Base Image

The IP base is for the Standard Multilayer Software Image (SMI) switches, and the IP services image is for the Enhanced Standard Multilayer Software Image (EMI) switches in Cisco IOS  Software Release 12.2(25)SEB and later.

For the Catalyst 3750 and 3560 switches, Cisco IOS Software Release 12.2(25)SEA and earlier referred to the image that provides Layer 2+ (L2) features and basic Layer 3 routing as the Standard Multilayer Image (SMI). The image that provides full Layer 3 routing and advanced services was referred to as the EMI.

The inter VLAN routing feature is supported on both IP base or SMI and IP services or EMI image Layer 3 switches. For Layer 2-only switches, you require a Layer 3 routing device with any of the previous images.

The IP Base feature set includes advanced quality of service (QoS), rate limiting, access control lists (ACLs), and basic static and Routing Information Protocol (RIP) functions. Dynamic IP routing protocols (Open Shortest Path First (OSPF), BGPv4, Enhanced Interior Gateway Routing Protocol (EIGRP)) are available only on the IP services image.

The IP Services image provides a richer set of enterprise-class features, which includes advanced hardware-based IP unicast and IP Multicast routing. Support for IPv6 Layer 3 switching in hardware is also available with the addition of the Advanced IP Services license to either the IP Base or the IP Services images. Both the IP base Image and the IP services image allow for Layer 3 and Layer 4 lookups for QoS and security.