But I digress…  I’m running OS X Lion on a Macbook Air now and it’s easily my favourite computing environment.  I’ve also recently added an external screen (a Dell 22″ U2212HM) to try and prevent neckache from working on the laptop all the while.  I’m also trying (insofar as I can on the Mac) to replicate the CCIE lab environment.  From what I’ve seen on the web this roughly means:

• No tabbed terminals.
• Single 23″ display only.
• Work with electronic documentation, not hard copy.

First off I have one desktop that I use entirely for labbing.  In that I have all the terminal windows for my lab kit, the PDF of the IPexpert training materials that I’m using, a copy of MacVim (at some point I should probably start to use something more Notepad-like) and a calculator.  This pretty much mimics the software you have access to in the lab.  I also have a Chrome window open that has a bookmark that links to the DocCD.

I use iTerm2 as my terminal app of choice and it has a couple of options that make life a little bit easier when setting up a lab session.  The first of these is the Profiles menu.  I have a profile for each device – each profile being identical other than the “Command” setting.  I happen to use a shell script that runs telnet with the appropriate port numbers, but there’s nothing to stop you just setting the “Command” setting to /usr/bin/telnet <ip> <port>.

Once you have a whole bunch of profiles set up I select them all in the “Profiles” window and click the “New Window” button.  It’s then time to arrange the windows as you best see fit.

At this point, useful feature two comes in – and this is the “Save Window Arrangement” and “Restore Window Arrangement” options on the “Window” menu.  Choose the save option, give it a name and you will then find that your window arrangement has been saved for posterity.

Now when I start a lab session all I have to do is fire up the kit, give it a few minutes for the terminal server to boot and then restore the “Lab1″ window arrangement.  12 windows pop up in exactly the right place, with the right session open.  I can then either start to load on initial configs or carry on where I left off.  It makes the process of getting a lab session going that little bit easier – and with everything the lab throws at candidates we need ever bit of help we can get in preparing for it!

Image by AustinEvan on Flickr

I changed jobs at the end of October and while leaving many of my colleagues behind was difficult it’s been great to get stuck into learning a new network and working with some different technologies.

In the last few weeks I’ve been designing and configuring an expansion of an existing datacentre.  This has given me a great opportunity to sit down and read through design guides and configuration docs on both the Cisco Nexus 5k range of switches and the Cisco ACE4170.  Before this I didn’t really know anything in detail on these devices other than general awareness and various bits and bobs I’d picked up from my compatriots on Twitter.

Both of these technologies gave me plenty to learn about – they both have their fair share of limitations and restrictions on how they can be deployed and both have subtle CLI differences that have entailed scrabbling through documents, scratching heads and asking questions of those better versed in these areas than me (thanks @EriksonIan!).  These gotchas ranged from the trivial (not knowing about the “trunk” parameter to “spanning-tree port type edge”) to the more fundamental (understanding how vPC works).

It was while I was finalising the configs that I realised I’d taught myself an awful lot during the last few weeks – technologies that I had never touched were almost becoming second nature and I was starting to feel vaguely competent (but hopefully not dangerously so).  This thought took me back to my University days – the program leader of the course I was studying had a phrase that he trotted our with regularity that was basically to the effect of:

It’s only now that I can see how true that statement was.  The best people I have ever worked with have all had an extremely good grasp of the fundamentals and the ability to take a new technology, new product, new service – whatever it may be – and make sense of the knowledge and put it to good use.

My personal #1 piece of advice to any aspiring techie would have to be: “Learn how to teach yourself”.  Find out what it takes for you to learn something in-depth and retain that knowledge.  It could be that reading documentation or 3rd party books is enough for you.  You might find that labbing something up and putting practical skills to work works better, or that audio/video-based training is what you need.

Whatever it may be – find a way that works for you and go put it to good use!

A terminal server doesn’t necessarily have to be a dedicated device: as many network engineers know, a Cisco router equipped with some manner of async card makes a fairly basic but serviceable terminal server.  I’ve used both 2800 and 2900 series routers equipped with HWIC-8A and HWIC-16A modules at work, while my home lab uses a 2600XM (which does double duty as one of the “BB” routers in the IPexpert topology) with an NM-16A.  I’ve then equipped these devices with some kind of alternative network access – sometimes an old-school analog dialup or ISDN connection, other times a cheap ADSL connection – so that you can still get access to the site to troubleshoot when all other routes to the site are down.

One of the problems with this kind of setup (apart from the monstrosity of the green “octopus” cables that Cisco insists on still using) is making sure that such a setup is secure.  A device that gives console access to all your network devices needs to be treated the same way as the physical door to your datacenter – lock it, and lock it good!

There’s a number of good steps that can be taken to improve console security.  Firstly on the devices you are accessing via the terminal server:

• Make sure that you apply the same AAA policies that you would use for VTY (i.e. network) access on the console.  If you’re using RADIUS/TACACS+, use that on the console too.  If you have limits on logon attempts, apply that to the console too.
• In a similar vein, make sure that you have an exec-timeout configured on your console.  If you get disconnected from the terminal server while logged in to a serial line, your session will still be active; anyone else who connects to that line on the terminal server will be able to pick up your logged-in session and anything they do will be performed (and potentially logged) as if you were in front of the keyboard.  An exec-timeout will ensure that if you do get disconnected, or if you forget to log out of the device, that your session will not hang around long enough to be a liability to you.
• Remember, just because you have a terminal server there is no excuse for not securing the devices themselves.  A terminal server is very easily bypassed if physical access is gained to the datacenter.

Now for the terminal servers:

• Configure SSH on the line (“transport input ssh”).  With SSH you can still access individual lines directly – just use “<username>:<line>” as the username when you log in (for example: ssh -l jon:18 10.1.1.1 is equivalent to telnet 10.1.1.1 2018). There’s not many (if any) good reasons for keeping telnet enabled these days.
• Apply an access-class to the terminal server vty and async lines.  This will reference an ACL that specifies which hosts can SSH to the terminal server – limit this to your management subnet or jump boxes.
• If you make your terminal server accessible over the Internet (I’ve sometimes used a cheap DSL connection to provide OOB access), make sure to secure it appropriately. Configure CBAC or ZBFW on the router and consider using a IPSec VPN for access.
• Likewise if you’re still using analog dial or ISDN to access your OOB devices, make sure you secure this method of access too. Configure callback as well – it’s one more layer of security between you and the bad guys.

So in conclusion – Out-of-Band access is a great tool to have at your disposal – just make sure that access is only provided to those who need it.

My lab is based loosely on the IPexpert topology – but built mostly using 1841s.  After a successful evening of labbing I’d shut down the rack and gone to bed.  The next day I’d fired it up again only to be caught by several of the 1841s getting stuck in a loop of stack traces and reboots.  The main error of any use was:

SYSTEM INIT: INSUFFICIENT MEMORY TO BOOT THE IMAGE!

Houston, we have a problem…

My first step in diagnosing this was to look at the various routers that had booted successfully and then to look at the IPexpert “Initial” configs that I’d loaded on the previous evening.  The culprit was pretty obvious to spot within the first page of a “show run”:

memory-size iomem 15

The routers that had booted successfully had this set to 10% rather than 15%.

From cisco.com:
“To reallocate the percentage of DRAM to use for I/O memory and processor memory on Cisco 3600 series routers, use the memory-size iomem command in global configuration mode. To revert to the default memory allocation, use the no form of this command.”

Now it’s at this point that I should probably ‘fess up.  The vast majority of my 1841s are equipped with the default 128MB of DRAM and the 1841 IOS image that you need for CCIE studies typically requires 192MB.  It looks like this minor change in memory allocation was enough to make the difference between the device booting and not.

Of course at this point you have a router stuck in a loop.  I caught it at the next reboot and broke into rommon.  I had a quick look through the context-sensitive help and found a way to fix this:

System Bootstrap, Version 12.3(8r)T8, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 2004 by cisco Systems, Inc.

telnet> send break
PLD version 0x10
GIO ASIC version 0x127
c1841 processor with 131072 Kbytes of main memory
Main memory is configured to 64 bit mode with parity disabled

Readonly ROMMON initialized
program load complet
monitor: command "boot" aborted due to user interrupt
rommon 1 >
rommon 2 > meminfo

-------------------------------------------------
Current Memory configuration is:
Onboard SDRAM: Size = 128 MB : Start Addr = 0x00000000
-----Bank 0 128 MB
-----Bank 1   0 MB
Dimm 0: Not Installed
-------------------------------------------------
Main memory size: 128 MB in 64 bit mode.
Available main memory starts at 0xa0015000, size 130988KB
IO (packet) memory size: 15 percent of main memory.
IO memory is configured by user
NVRAM size: 191KB
rommon 3 > iomemset
usage: iomemset [smartinit|5|10|15|20|25|30|40|50]
rommon 4 > iomemset 10

Invoking this command will change the io memory percent
WARNING:IOS may not keep this value
Do you wish to continue? y/n:  [n]:  y
rommon 5 > reset
<system boots normally>

Result!  Obviously once you’ve done this don’t forget to change the memory-size iomem in the config and wr mem, otherwise you’ll get bitten again tomorrow!

One of the cool things about working as a network engineer is learning and investigating new technologies.  At my place of work we’ve recently been looking long and hard at the Cisco Nexus product line for both 10Gb Ethernet and FC.  In fact, as soon as the new 5596UP and 5548UP (Universal Port) models were released, we knew these switches would meet our needs.

The Nexus range, for those who’ve missed this bandwagon entirely, is based on the NX-OS software platform rather than the traditional Cisco IOS.  I don’t think any experienced network engineer could find a reason to dislike this – IOS has many glaring faults (both architecturally and from a CLI perspective) and NX-OS (which was originally the SAN-OS software from the MDS line of SAN switches) has built a pretty good reputation for reliability.  This is hardly surprising; storage engineers tend to get somewhat excited when their hosts’ storage paths are pulled out from underneath them due to a fabric switch dying…

One “not-really” problem of this is that engineers need to get their head around NX-OS and the Nexus platform and while the learning curve isn’t steep, it’s worth knowing the differences between the two platforms and having a good idea of the product range before you go shopping.  To this end I’ve put together a list of useful Nexus resources that I’ve been working with over the last month or two while we investigated the capabilities of these products.  I hope it’s useful to you!

First up is “NX-OS and Cisco Nexus Switching: Next-Generation Data Center Architectures“.  This CiscoPress book by Kevin Corbin, Ron Fuller and David Jansen covers pretty much everything you’d expect OS-wise.  Chapter 1, “Introduction to Cisco NX-OS” covers some of the more fundamental differences between IOS and NX-OS including CLI differences, the CMP (Connectivity Management Processor), Virtual Device Contexts (VDCs) and so on.  Chapter 2 covers everything Layer 2, with particular emphasis on Nexus-specific functionality including Fabric Extenders (FEX modules) and Virtual Port Channels (VPCs).  Chapter 3 is in far more traditional territory, discussing the (relatively minor) Layer 3 differences between NX-OS and IOS.  The remaining chapters cover IP Multicast, Security, HA, Serviceability, Unified Fabric and the Nexus 1000V.

Another great resource is Jeff Fry’s blog.  Jeff is an incredibly knowledgeable guy and he doesn’t shy away from sharing the knowledge!  While all the posts with the Nexus tag are great there’s a couple I think are particularly relevant:

• Nexus 7000 Training Documentation - Jeff wrote these for his team’s use and has made them available for the rest of us!  Provides a great overview of the platform from an Engineer’s perspective.
• Nexus 7000 Modules and their Racing Heritage – A fantastic overview of the different families and models of linecards for the Nexus 7k.  Great when you’re looking at the Cisco price list and haven’t got a clue what you’re ordering!

All useful stuff!

Equally as useful is Ruhann de Plessis’ Nexus category at routing-bits.com.  In particular, his overview of OTV I found really useful for getting a handle on the terminology and processes used by this particular technology.

There are of course, two caveats – firstly that these books are NOT for the current version of the CCNP certification – they are a year or so out of date.  Secondly, I’m based in the UK, so bear in mind that shipping anywhere outside the UK is likely to be expensive!

If you’re interested, either comment on this post or contact me as @xanthein on Twitter.  It’d be a shame for me to have to just bin them.

By filipe93 on Flickr

Back in 2005, fueled by the growing trend of manufacturers to make their products cheaper, disposable and less home-repairable, Make Magazine published their “Owner’s Manifesto: A Maker’s Bill of Rights“. This document laid out the tenets of the maker/hardware hacking/upcycling movement – essentially the freedom to use your legally-owned goods in whatever way you damn well wanted!

It struck me today that we network engineers could use a similar document – something we can brandish in the faces of vendors when they start doing Stupid Things™ and acting against the interests of those who install, configure, operate, monitor and tweak their products day-in, day-out.  So, without further ado – a manifesto for those on the front-line of the networking industry!

1. Open standards please. We’re all tired of lock-in, and redistributing between EIGRP and OSPF gets old pretty quickly.
2. Likewise, producing your own standard when the open standard is still being drafted is only one step away from Microsoft’s “embrace and extend“.
3. Off the shelf parts: nobody wants to pay $900.00 for a 256MB CompactFlash card – or is the gold plating mandatory?
4. Is it too much to ask for a list of line cards on one page, with port types/density, QoS features and oversubscription details for each? Yeah, I thought as much.
5. Likewise, why do I have to dig, harangue my VAR and give my inside leg measurement just to get information that is essential to deploying your products?
6. Nobody likes spending all day on a problem only to find that the documentation they’ve been working off is wrong. Update it or bin it!
7. Training/certification: DO teach us how to configure your products.  DO NOT make us learn your latest ‘marketecture’ just so we can pass an exam (thanks to @ioshints for that term).
8. 9600, 8N1.  It works, bitches.
9. If your product needs rack rails, make them easy to fit and remove. Yeah, I’m looking at YOU, Cisco WAE-512 and F5 BIG-IP 1600.
10. Talking of rails: ship rails/ears with everything. Even the smallest offices have racks these days.
11. No default usernames, passwords, SSIDs, WPA keys.  A product that’s vulnerable out the box can really ruin someone’s day.
12. When your kit goes wrong, I don’t expect to spend 3 days going back and forth between vendor and VAR trying to prove that it’s definitely a hardware fault (I’m looking at you Check Point). New kit, now please.
13. Lastly, listen to your engineers. We might not always have decision-making abilities but there’s always the chance we could sway a purchasing decision one way or the other…

If you’ve got anything you want to add to that list, leave a comment please!

Instead, I want to focus on tools you can use to test multicast from host-to-host via your lab network.  Yes you can use the old standby of:

R5(config-if)#ip igmp join-group 239.1.1.1

and then ping the multicast group address from another router – but where’s the fun in that?  Fortunately there’s some good tools out there you can use to good effect for testing this kind of thing – and there’s two in particular that I’ve been using today – emcast and mnc.

Emcast

Emcast is a toolkit for creating multicast-enabled distributed apps.  It’s very much aimed at coders/developers, but it does include a standalone generic multicast utility, which is what most people would be interested in under these circumstances.  It would appear to compile on most Linux/UNIX-based operating systems, but does require GLIB, which caught me out when I first tried compiling it under Mac OS X.  Once installed however, it’s very easy to use:

Usage: ./emcast [OPTION]... <URL>
	-b <size>   		buffer size
	-h          		display help
	-l <0 or 1> 		turn loopback on or off
	-o<name> <value>  	set option <name> to <value>
	-O<name> <value>  	set option <name> to <value> before joining
	-q	    		quiet mode (no input/output)
	-t <ttl>    		time-to-live

On the sender, I put together a little one-line shell script that would send the output of the UNIX ‘date’ command to the multicast group once a second:

while true; do date; sleep 1; done|emcast -t 10 239.1.1.1:1234

The parameters are pretty simple: -t sets the TTL to a value sufficiently high that it won’t decrement to 0 in transit, and the second parameter is the multicast group address and UDP port number to send the data to.

MNC

Mnc (multicast netcat) is a very similar tool. I originally looked at this as an alternative to emcast after I got caught out by the GLIB issue above.  It’s very much a beta tool – no niceties such as configuration scripts or even downloadable tarballs here, but it does work very well.  Very easy to use:

mnc -i 10.3.1.1 -l -p 1234 239.1.1.1

And the parameters are:

• -i: interface to bind to when listening.
• -l: listen, rather than sending.
• -p 1234: UDP port 1234.
• 239.1.1.1: multicast group address.

Testing

To test this, I fired up the loop above to get some data flowing to the group.  A quick check on the directly-connected router:

R1#sh ip mro | beg ^$

(*, 239.1.1.1), 00:00:47/stopped, RP 1.1.1.1, flags: SJC
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
 FastEthernet0/0, Forward/Sparse-Dense, 00:00:47/00:02:35

(10.1.1.2, 239.1.1.1), 00:00:46/00:02:56, flags: PT
 Incoming interface: FastEthernet0/0, RPF nbr 0.0.0.0
 Outgoing interface list: Null

(*, 224.0.1.40), 02:37:27/00:02:36, RP 0.0.0.0, flags: DCL
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
 Serial0/0, Forward/Sparse-Dense, 02:29:59/00:00:00
 Loopback0, Forward/Sparse-Dense, 02:37:27/00:00:00

Looks good.  10.1.1.2 in this case is the machine that is sending the multicast data.  Time to fire up mnc on the other machine:

[Anathem:~/tmp/mnc-read-only]$ ./mnc -i 10.3.1.2 -l -p 1234 239.1.1.1
Tue Jan 11 00:06:07 GMT 2011
Tue Jan 11 00:06:08 GMT 2011
Tue Jan 11 00:06:09 GMT 2011
[...]

Working very nicely indeed!  Some quick verification from the client’s directly-connected router:

R5#sh ip mro | beg ^$

(*, 239.1.1.1), 00:00:14/stopped, RP 1.1.1.1, flags: SJC
 Incoming interface: FastEthernet0/0, RPF nbr 10.2.1.2
 Outgoing interface list:
 FastEthernet0/1, Forward/Sparse-Dense, 00:00:14/00:02:46

(10.1.1.2, 239.1.1.1), 00:00:13/00:02:58, flags: JT
 Incoming interface: FastEthernet0/0, RPF nbr 10.2.1.2
 Outgoing interface list:
 FastEthernet0/1, Forward/Sparse-Dense, 00:00:13/00:02:46

(*, 224.0.1.40), 00:00:45/00:02:14, RP 0.0.0.0, flags: DCL
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
 FastEthernet0/0, Forward/Sparse-Dense, 00:00:45/00:00:00

R5#sh ip igmp group
IGMP Connected Group Membership
Group Address    Interface                Uptime    Expires   Last Reporter   Group Accounted
239.1.1.1        FastEthernet0/1          00:01:17  00:02:05  10.3.1.2        
224.0.1.40       FastEthernet0/0          02:39:47  00:02:02  10.2.1.5       

I think that counts as a success!

References

• Cisco Multicast Quick-Start Configuration Guide: http://www.cisco.com/en/US/tech/tk828/technologies_tech_note09186a0080094821.shtml
• Routing TCP/IP Volume II – Jeff Doyle (Cisco Press): http://www.ciscopress.com/bookstore/product.asp?isbn=1578700892
• Emcast: http://www.gizmolabs.org/~dhelder/junglemonkey/emcast/
• MNC: http://code.google.com/p/mnc/

As virtually everyone in the industry knows, the CCIE certification is based on a day-long practical examination held at various Cisco facilities worldwide. In order to take that exam, you first have to pass the CCIE written test – a qualification exam to ensure that those sitting the lab exam really do know the theory behind the practice.  While I’ve not taken this exam yet, general consensus seems to be that while it isn’t particularly difficult or require über-deep knowledge, it is very broad in what it expects the candidate to know.

Sure enough, consulting the CCIE R&S v4.0 Blueprint (login/registration required) shows the breadth of material required. All the major enterprise IPv4 and IPv6 IGPs are there, together with BGP.  Layer 2 topics include Spanning Tree and Frame Relay, with MPLS being a new addition.  Multicast, QoS, Security and Network Services round out the technical topics quite nicely.

Obviously to learn all these topics to the required level of detail is going to take more than a single book and I’ve done a fair bit of research into what people recommend as reading material for the CCIE written exam. I’ve included this information here in the hope that it’ll be useful to those looking to take this exam soon.

Routing TCP/IP – Volume 1, 2nd Edition
Jeff Doyle & Jennifer Carroll, Cisco Press
One of the ‘bibles’ of networking, this book will teach everything you need to know in terms of IGPs, routing, IPv4, IPv6, redistribution and route filtering/control.

Routing TCP/IP – Volume 2
Jeff Doyle & Jennifer Carroll, Cisco Press
Continuing on where the previous volume left off, this book covers mostly BGP and Multicast.

Internet Routing Architectures
Sam Halabi, Cisco Press
I think it’s fair to say that this book will cover nearly everything you need to know about BGP, with the possible exception of Multiprotocol BGP (MP-BGP).  However I imagine that will be nicely covered in the next book on the list…

MPLS Fundamentals
Luc de Ghein, Cisco Press
This is the only book on this that I don’t own in one form or another.  However it’s been recommended to me by many people on twitter whose opinions I respect.  Of course if this book doesn’t cover something, then Ivan Pepelnjak’s “MPLS and VPN Architectures” series will.

Cisco QoS Exam Certification Guide
Wendell Odom & Michael J Cavanaugh, Cisco Press
This book should cover a large percentage of the QoS topics on the Blueprint.  One notable exception however is SRR (Shaped Round Robin) on the 3560 switch. For that I’d recommend the Cisco 3560 Switch Configuration Guide off the DocCD.

SWITCH Foundation Learning Guide
Richard Froom, Balaji Sivasubramanian, Erum Frahim, Cisco Press
While this book is aimed at candidates studying for the CCNP SWITCH exam, the content is generally equally applicable to the LAN switching sections of the CCIE. Be prepared to do some reading around any areas that are on the blueprint but aren’t covered here though.

CCIE Routing and Switching Certification Guide
Wendell Odom, Rus Healy, Denise Donohue, Cisco Press
And finally we have the official exam certification guide.  This one volume should serve as an excellent recap prior to taking the written exam – however in my opinion it is no substitute for learning each and every topic from scratch from the other books on this list.  That said, it does offer a concise recap of the vast majority of the topics that need to be covered.

Hopefully this list will give CCIE candidates an idea of where to begin reading in preparation for the written exam. I might well add more books to this list at some point, but for now I think I’ve got plenty to be working on! There’s three final tips that I’d like to share.

Firstly, all the links above go to the ciscopress.com eBook pages. I’ve recently bought myself an iPad and was very pleased to find that Cisco Press had switched from DRMed PDFs to watermarked files instead.  The iPad has allowed me to carry around my entire reading list for this exam – something that you could never do with the dead tree editions! I’d highly recommend this way of studying – it frees you from being chained to a desk and makes studying while on the train to work (for example), very easy.

Secondly, keep an eye on http://www.ciscopress.com/deals/. A fair few of the books above were bought from this page for $9.99 each, a considerable saving on list price!

Thirdly, given that you will need to know it for the lab exam, I highly recommend getting to grips with the Cisco DocCD.  No longer distributed on CD, the name has continued to refer to the section of Cisco’s website that contains configuration guides and command references. This is the only material available to you in the CCIE lab exam, so getting to grips with it early on would seem to be a good idea.

Happy studying!

First off – TSHOOT.  As many have said, this exam is a fairly major departure for the CCNP-level exams. Candidates face a number of questions, the majority of which will be trouble-ticket type questions based on a known topology and a known list of technologies (exam blueprint).  This information gives the candidate a vast resource of information that can be used to direct his/her studying.  I would also invite candidates for this exam to look at Kevin Wallace’s TSHOOT Videos.  They really do help clarify techniques that will be useful in the exam itself.  I looked at them the morning before I took the exam and it helped me get my mind into exam gear, given that I’d done no preparation in the 2 weeks before the exam (I was traveling for work and as a result was insanely busy).

On the whole I found TSHOOT very straightforward. My comments on Twitter at the time were basically that if you were a network engineer and you had to troubleshoot as part of your job, you’d have no problems with the exam.  This is possibly also the only time I will ever consider an exam ‘fun’!  Make sure that you check out the resources available on Cisco’s site.

The ROUTE exam, as far as I remember, was more difficult than TSHOOT.  While TSHOOT is virtually entirely focused around practical skills, ROUTE requires you to know a lot of theory as well as the practical side of things. I think the areas I found most difficult were around OSPF in Frame Relay environments and IPv6, as I’ve never had to work with either in production.

The other odd thing about the ROUTE exam was the topics that were removed – notably IS-IS and Multicast.  IS-IS probably made sense as it doesn’t seem to have had much uptake in enterprise environments – and remember, the R&S track has always been aimed at the enterprise.  On the other hand I’m surprised that Multicast was removed and was also surprised not to see any mention of QoS.  These are all topics I’ll need to work on more when I start studying for CCIE.

Similar comments apply for the SWITCH exam – there are technologies that should have been covered that weren’t.  I’m also not sure if I agree with the approach regarding Voice, Video and Wireless in that exam – either teach enough to be useful or don’t cover it at all.  As it stands I think that these topics should be kept separately on the relevant specialist exams as the current level of detail required is pretty flimsy.

So – now that CCNP is done and dusted, what’s next? I think I’m going to aim to take my CCIE R&S Written Exam at some point next year, aiming to get the lab completed at some point in the next 18-24 months.  Hopefully this will be achievable and hopefully I’ll be better at blogging about my experiences as I go!