Thursday, 18 January 2018

The OSPF show ip ospf rib command

Wow, been at this job for years now and this is the first time I've really looked at this command.

In OSPFv2 and v3 it shows a lot of useful information that I have at times struggled to work out for myself.

Firstly, when recursing the OSPF database to work out routes, costs and so forth I have to do a RIB walk in my head and then look at the respective LSAs.  This is time consuming and often not efficient or easy.  Now I'll go straight to this command (and the detailed option) to get these things sorted.

Before I move on I recommend you just put a very simple OSPF lab together and run OSPFv2 and one for OSPFv3 in Area 0 on all interfaces.  Use the base of any of INE's Lab WBs as they are familiar and easy to follow.

Both OSPFv2 and v3 support the command.  It is a way to look at the OSPF-specific RIB and that basic fact is covered in many-a-blog and even documented to some extent by Cisco.  What is lacking is the meaning of the output and for me the meaning of the LSAs identified per prefix.

Sunday, 4 December 2016

CCIEv5 Lab. My first attempt and advice.

So, I failed.

I passed TS and Diagnostics.

I failed on the configuration section.

Things to learn and my advice:

Stuff to know:

  1. Unlike v5 this is all virtual, meaning:
    1. No noise in the room (as you're connected via a local switch to Skylab in the US of A)
  2. The delays on commands inputs are noticeable but workable - much like INE's delay from the UK
  3. The delays on moving the browser screens around are noticeable but workable
  4. You get a very simple setup of two screens, a keyboard and a mouse
    • The keyboard is the one specified so get one at least a month before (as it slowed me down a lot) (Amazon.co.uk Keyboard)
    • The mouse is about as cheap as you can get but fine
  5. PuTTy is boring and no multi-window options are available as far as I could tell
  6. The lab isn't a lab anymore.  For me it was just a spare room in the Feltham office and a proctor who didn't seem to or need any knowledge of the exams (we had R&S and Security in the same room) or the topologies
Stuff to learn:
  1. Get familiar with the keyboard layout as the pipe is off from most keyboards and the return key is tiny
  2. Get familiar with PuTTy in single window mode
  3. You can open as many PuTTy windows per device as you want and will do without meaning to.  Shut down what you don't use or need
  4. Read all the details before you start
  5. Read all the details of each section and question before you start them except all of the config section as it takes a lot of time
  6. For TS you don't need to match every detail (see later)
  7. For TS you don't get any help with a visual zoom or image of the affected area
  8. Never give up.  Never, ever, ever give up!
When I did my lab I used the additional 30 mins on the TS section as I hadn't completed all 10 tickets and not because I wanted to check the ones I'd done.  I spent a lot of time on two as I tried very hard to match details of the requirements' ''match the following output'' to my show output so was convinced on those two tickets I had failed.

The end of TS was when the timer expired and at that point I had only submitted responses for 7 tickets and had not started work on question 8.

With less than 80% submitted (7/10) and knowing I'd got two partially wrong I was convinced I'd failed.  This is where nearly everyone fails and not on the diag or config sections so it felt like I was done.

So, I carried on until the lunch break (Cisco's canteen) and considered leaving there and then.  We all talked about the lab at lunch and had the same feeling that we'd failed the TS section due both not submitting answers for all 10 or knowing we'd got many wrong.  This wasn't a TDA transgression as we only talked in general terms and anyway we were sitting the same exam.

I went in after lunch for the 4 1/2hrs config section knowing I'd failed.  I spent my time learning to use the keyboard (as the ones I'd used were all American layouts but didn't have the pipe key far out on the right hand side nor a tiny return key).  This is really bad when you are so used to muscle memory on the two most important items.

I learned to use PuTTy better, learned about window layout, learned about the questions, learned about how different everything was from my time on INEs workbooks and materials, learned that there was nothing I couldn't do in the questions, learned that they did throw those benders in most sections to make you think while you hammered out the stuff you know off-by-heart but I didn't try and complete the section with 100% in the time.  I had made the assumption I couldn't pass so was to make use of the time and experience as best I could.

So, I failed.  I failed partly because I believed everything I'd read in the question directions and the marking scheme.  I failed because I stopped trying to pass the last section.  I failed because of me.  Don't ever give in people.

So, in summary:


  • Don't assume Cisco are telling you the truth on the marking schemes - I think they mark them better now than ever and look at what's done, how and why; how you fixed the issues and not just that you did.  This is great and will weed out those who cheat
  • Don't ever stop working in the Lab.  You may have done better than you thought
  • Grab multiple sheets of paper from the proctor (?) when you start if, like me, you want to write things down for question tracking, detail visibility and general working out
  • Get one of those keyboards
  • The lab is overpriced.  Yes, money is required to build and run the environments, to provide support and pay for a room, a keyboard, a mouse and a few monitors but not the $1900 plus tax they want
  • This is now a great qualification to get - the written alone is super hard and can't be cheated on in most cases as they bring out 100s or new questions every couple of weeks or month...as I've seen on the three times I took to pass it (for the third time in 5 years).  The lab is hard but not impossible (I hope as I've yet to compete it)
  • INE is awesome but not perfect
  • You need your own kit
  • You need to put in many 100s or 1000s of hours and can't do it without sacrifice
  • As soon as you pass the written, go straight to the lab.  It'll solidify your theoretical knowledge and make you a better engineers/designer/architect/support guy/gal/person
Till the next time.  I really hope this helps people who are looking to sit it as this would have saved my bacon:



Alan

Friday, 16 September 2016

The CCIE Lab Attempt.

Myself and a friend are to attempt our first CCIE Lab on the 30th September 2016.  I hope to add information about the preparation and the outcome once it is done.

For now there's only time to study and think about studying.  I've been ill for 2 days and that has seriously affected my ability to to this.  I feel a whole lot better now so thought I'd start the post with my thoughts on why I'd write this.

So, study is hard, the CCIE syllabus is too large to actually know all of it to the level you'd like.  I made the mistake of thinking over time I could know it all.  When I was 19, maybe.  Actually before I smoked a lot of weed and did a lot of other fun drugs I think so.  Now, it's hard.

So, I changed focus about 3 months back (as the date approached) and I decided to not put it off again. Study for the exam!  This has so far been excellent as I'm picking up the details for what's coming and getting better overall at putting a complete solution together.  I highly recommend this approach and to do all of INE's labs, mock labs, trouble shooting labs and loop back and do them all again, slowly.  The second time around go in deep, see the issues, use the show commands to see the details and know what they mean.

I have converted all of INE's R&S configurations to work on GNS3 with 15.5(2)BX (sic) IOS if anyone wants them.  They are not perfect as things like BFD crash GNS3 but they give you nearly all of what you need.  The rest I'll get from rack rental and my own switches and routers.

OK, you all have a nice day and I'll update this as I get time.

Monday, 28 October 2013

Dynamips for WB Vol 1 of INE's material.

I've just put up my Dynamips configurations, .net file and so forth for WB1 of INE's great study solution on to the GD folder mentioned in the previous post.

Same details apply here except I've not been through these for a while.  Be careful and take your time making things work.  Take a look at this post and details within for people using Windows


http://www.routergods.com/2012/so-long-iou-welcome-back-gns3/


In the folder you'll clearly see which is WB Vol I and Vol II and the respective .net file needed.  For Vol I it's "Secondary_INE_Topology.net"


Again, any comments or suggestion let me know.


Dynamips with INE R&S WB Vol I and on a Mac: Automated Terminal Sessions, Configurations, Topologies and more

It's been a long time since I started my journey and a long time since I put anything up on my blog.  I have no excuses for taking my time.  I have been working on the CCIE all this time but in slow motion, I have designed and built several large and many small Networks, I've trained up some 30 or more people, passed my CCIE written, got the CCDA and CCDP in double quick time, been boarding lots, been climbing lots, had fun with my 17 year old son, have changed job three times, have a great GF to play with, I stopped for a while and started again, I mess around with other things, I have to solve lots of issues with using Dynamips, solve issues with my Rack and generally have Datacoms coming out of my ears at work, home and pleasure.  No excuses, it's hard getting a CCIE however you look at it.

In this post I'm going to try and put up a lot of my hard-won Dynamips knowledge with special attention to the following:

  1. Topologies to work from for WB Vol I
  2. An automated Applescript for opening all the Terminal tabs needed to use Dynamips
  3. Configurations and solutions to many problems within Dynamips
This is a link to a public folder on Google Drive (GD).  Please try it and let me know issues, success, details etc.


You'll access two folders and a file.  The Vol I and Vol II folders are how I've structured the Dynamips environment on my Mac.  If you maintain this and copy it to yours the .net file will point to it from the Desktop.  You may have to modify other details to point everything to the correct location and, of course, you'll have to add your own binaries but here are the ones I use:


c3725-adventerprisek9-mz.124-15_T13_unZ.BIN


c3725-advipservicesk9-mz.124-25d.UnZ.BIN


Noting that you have to UNZIP them before Dynamips will function.


The file is an Applescript to open 13 tabs in a single window, name them to the respective device, open up the local host port and show ip interfaces brief at initiation.  Don't worry too much about the secondary functions of showing ip interfaces etc. as I didn't put a time delay in to allow the Dynamips VM to boot up but if you allow Dynamips to run for a couple of minutes first it'll all work well.


You can however use the script to open Terminal quickly any time you want because I've not put that delay in.


To run the script just put it on your desktop and open it, then hit the run button. To make sure it works when you don't have Terminal open it activates Terminal twice so just close the secondary window if one appears.


OK, back to the Dynamips work:


  • I have and am using INE's CCIE R&S WBs and Dynamips topologies.  The .cfg files have come from a SED script I wrote to fit the Dynamips topology with 3725s with EtherSwitch modules.
  • Inside the folder you'll find startup configurations for each of the 20 labs.  It is important to delete all the 'working' configuration VMs before loading a new lab configuration - they are stored in the 'working' folder.  Then, copy the 13 .cfg files to the 'Initial Configs' folder and start GNS3 with the .net file.  Finally, you must ensure the respective VLANs are added to the switches, check the VTP statuses are as-per the configs originally given by INE.
  • Once running, check you have the connectivity needed - Frame Relay maps need to match the DLCIs and turn off keepalives if you're going back-to-back, check BB links and other LANs.
  • With L3 interfaces on the switch modules you may have issues with the adjacencies.  If so, create VLANs to connect them and SVI the switch ends.
  • With Routing adjacencies set the hello and dead intervals to 20 and 200 where you have them flapping.
  • Other information on solutions to common issues can be found in the text file I use to mark which Lab I'm working on: "Currently Using Lab X initial configurations.txt"
  • Remember that Dynamips is a tool and isn't perfect.
  • Also remember that Dynamips is AWESOME for people like me who have need for study instantly at random intervals in random places :)

Thanks,

Alan

Tuesday, 3 May 2011

Access-Lists that use TCP Source Ports

Now to be clear there's a lot of options with access lists in the IOS. The particular issue that struck me was that when using the TCP option there is an additional field that isn't used much, or even seen that much in the learning material, and I came upon it via the CCIE R&S Book of Wendell Odom.

The question went something along the lines of identify the valid access list to allow only the traffic from a Telnet server. It was phrased as a question of access-group allocation and direction but was asking to identify traffic that had a source of TCP port 23 but could be directed back to the initiator on any TCP port.

The solution was to use the TCP port specification as the SOURCE not the DESTINATION. Easy when you are used to seeing this but I feel it's a good thing to put up a quick post about. Cisco has multiple links to it's use:

http://www.cisco.com/en/US/products/sw/secursw/ps1018/products_tech_note09186a00800a5b9a.shtml#extacls

http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtaclflg.html#wp1051199

And so on...

The point here is better explained with an example that doesn't follow the much-used

access-list 101 permit tcp any 10.0.0.0 0.0.0.255 eq 23

And to use this type

access-list 101 permit tcp 10.1.1.0 0.0.0.255 eq telnet 10.1.4.0 0.0.0.255 established

Here we get only traffic that is coming from a source port of 23 (telnet) so it represents any returning traffic from a telnetable host (telnet server).

Saturday, 10 July 2010

The Config-register in C3550s

Certainly the Cisco 3550 and probably other Cisco IOS devices don't have the option to change the configuration register from the default. Now my C3550s have a value of 0x10F. This is different from your average, and the well-drummed-into-you-from-the-CCNA-to-CCNP, router and switch. This makes it difficult to understand why you can't issue the config-register command at any point while messing with you lab or production device.

I had a bit of trouble finding this out via the DocCD i.e. Cisco's on-line version of it that is now a CCIE must-have here:

http://www.cisco.com/cisco/web/psa/default.html?mode=prod

and ended back with Google and found this reference:

http://www.cisco.com/en/US/products/hw/switches/ps646/products_configuration_example09186a0080169623.shtml#concept5

So, you can't edit it and you can't use it to password recover. To do that you need to clear the systems files by reloading the unit by holding down one of the buttons on the front of the device and getting into the initial system configuration and changing name of the config.txt to config.old and re-loading the whole thing once the passwords have been reset. It's a little more involved than that but it'll get you there if you follow Cisco's advice here:

http://www.cisco.com/en/US/products/hw/switches/ps628/products_password_recovery09186a0080094184.shtml

So, that's done now. Time to move on.