I’ve already used the phrases “skin of my teeth” and “a pass is a pass” on Twitter today for good reason.  Passing is a score of 790, and I blew that away with a 790.  One more lapse in concentration and I would have been making up more excuses instead of smiling.  I think I’ve mentioned this before, but I have this weird reaction to taking exams where I don’t get nervous at all until after I’m finished.  Walking into the testing center, I was fine.  Walking out, I was shaking like Northern Virginia.  It was so bad that I could barely hold on to the door knob when trying to leave, so I guess that I’m really prouder than I thought I was.

The exam was a total piece of crap.  Nearly every diagram was so compressed and blurry that I couldn’t see them at all.  Most of the time I can infer what the diagram is showing, but, when your bridge priorities are listed there, it’s pretty hard to find root ports.  Absolutely horrible.  There were the inevitable spelling errors in there, too.  Most of those are fine, but STP and SPT are two different topics that are both covered on this exam.  I had no problems figuring out which one they were talking about, but it’s pretty unacceptable to have spelling errors in this exam.  Of course, there were also the questions that I feel are unanswerable.  Switches in VTP transparent mode behave differently from version 1 to version 2, eh?

After being recommended at Cisco Live this year, I added the Boson ExSIM-Max to the pile of prep materials.  It not only helped teach a few new things, but it cleared up a bunch of foggy details.  I’m sure that using any other study materials will do the same to some extent, but the Boson stuff provided something else – it helped to teach me to take the exams.  I was able to go through the questions and practice figuring out what was being asked, which choices were completely wrong, and how to not get utterly frustrated with the questions.  Practice makes perfect, right?

The wife came with me to take her ICND1 exam.  She did better than she thought she would, but, alas, no dice this time.  She says that she’s glad she’s been through it now and knows exactly what to study.  I’m trying to convince her to start her own blog since she’s starting up her cert journey from such a unique place.  We’ll see how that works out.

What’s next?  I have to find a company to help me prep for the lab now.  I’m sure that’s not cheap at all.  Maybe I should just blindly sit the lab and see what happens.  Maybe not.  :)

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Down : No hellos have been received from this router.

Attempt : This state only applies to manually-configured neighbors on an NBMA network.  In this state, a router has sent unicast hellos to the neighbor but has not received any back from it.

Init : The router has received hellos, but none of the hellos have the router’s RID included as a known neighbor.

2way : The router has received hellos with its RID included.  This means the other router has received the hellos from this router, so they now have 2-way communication going.  The DR and BRD is elected at the end of this stage.

ExStart: When a router grows up and starts to have feelings for other routers, it enters the ExStart state to have further relations with a neighbor.  This is where the master/slave relationship and the initial sequence numbers are established.

Exchange : Once we know who wears the pants in this relationship, the master sends over a DBD with it’s LSAs listed.  In response, the slave does the same so that both routers have all the LSA headers they both know.

Loading : This is where the LSRs and LSUs flow.  If a router need the full LSA from the neighbor, it sends an LSR, and the neighbor should send an LSU in response.

Full : After the LSR/LSU exchange, the routers should both be in sync, so they each send an LSAck to the other to confirm.

As a bonus, here’s a nifty little animation showing neighbor states.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Type 1 – Router : This LSA type lists all the routers by RID as well as the networks to which that router connects.

Type 2 – Network : These LSAs represent broadcast network where more than one OSPF router may live.  Think Ethernet or multipoint segment.  These LSAs are flooded by the DR for that segment.

Type 3 – Net Summary : An area border routers take the type 1s and 2s from one area and floods them as type 3s into another, so all of these LSAs are from other areas.  No topology information is included in these LSAs; it’s basically an advertisement from the ABR saying the route is through him.

Type 4 – ASBR Summary : These LSAs make sure that all routers in all areas have a path to an ASBR that’s flooding type 5 LSAs.  Those routes in the area with the ASBR won’t see these.

Type 5 – AS External : These are flooded by an autonomous system boundary router and are routes redistributed into OSPF from another routing process like EIGRP or BGP.  Since these routes come from a different source, there’s no way to discover the topology past the ASBR, so we just have to trust the rumor that the network exists that way.  E1 routes gets the OSPF path cost added as it crosses the network, while E2 routes (the default) have a static cost.

Type 6 – Group Membership :  This is for Multicast OSPF and not supported by IOS

Type 7 – NSSA External : An ABSR in an NSSA floods routes to the external routing process through type 7 LSAs.  ABRs will translate these to type 5s when flooding other areas.

Type 8 – External Attributes : Back in the day, OSPFv2 had plans to overthrow iBGP.  Type 8 LSAs would have been used to carry BGP attributes while the routes themselves would be of type 5.  Type 8s aren’t supported in IOS.

Type 9,10,11 – Opaque :  Something…something…traffic engineering…blah, blah, blah.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

As always, please feel free to correct me here.  I’m learning just like the rest of us.

Hello : These messages are used to establish neighbors and serve as keepalives among other things.

Destination:  224.0.0.5
Important Fields:
Hello interval
Dead interval
Router priority (for DR election)
  Known DR
  Known BDR
  Active neighbors

Database Descriptor (DBD or DD) : These messages send summaries of a router’s known LSAs to a new neighbor.  Receiving routers can use this information to compare to their database and ask for more details if needed.

Destination:  Unicast IP of the new neighbor
Important Fields:
  LSA header

Link State Request (LSR) : Once a router has received a DBD, it parses through the info in it to see if the message is either more up-to-date or if it has some new info in it (like a new network).  If the router needs an update, it asks for the full LSA through an LSR.

Destination:  Unicast IP of the router that sent the DBD
Important Fields:
  LSA type
  LSA requested

Link State Update (LSU) :  When a router receives an LSR, it responds with an LSU that contains the details information for the requested LSA.  It also sends an unsolicited LSU whenever it learns of new LSAs such as when you turn up a new interface.

Destination:  Unicast IP of the requesting router, 224.0.0.5, or 224.0.0.6 depending on who's updating whom
Important Fields:
  LS age
  LS sequence number
  Full LSA

Link State Acknowledgement (LSAck) : If a router receives an LSU, it responds with an LSAck to acknowledge it was received.

Destination:  224.0.0.5
Important Fields:
  LS sequence number

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Being lazy and hating doing things over and over and over again, I wrote a few bash scripts to help set up any labs you may want to run.  First and foremost, I am not a bash programmer; I mostly stole and chiseled some old code I had from back in the day to get these working.  The end result, though, is pretty good for what I’m trying to do.  You can define a lab setup with various files and start up all the routers (or switches) along with terminal server-like access to the consoles through a process wrapper.

genRouter/genSwitch

At the heart of the system is a script I call genRouter (or genSwitch if using layer 2).  Yes, I learned to program in Java when it was cool, and that’s why I name all my stuff like object methods.  Anyway, genRouter takes 4 command line parameters and, along with the variables that are set in the script, fires up a new router.  A common deployment is to use a wrapper application to bind the router process to a TCP port to use as a console, and that functionality is included in the script.  Here are the variables included.  You’ll need to change a bunch of these for the script to work.

$IOUFILES – This is a variable that tells where the IOU files are kept.
$L3IOU – This is variable that sets what IOU executable you want to use for a router.
$WRAPPEREXE – This is the full path to the process wrapper you want to use and is defined in the script.
$ETHCOUNT – This is the number of Ethernet interfaces you want to bring up on the router.  This is taken from the command line as $1.
$SERCOUNT – This is the number of serial interfaces you want to bring up on the router.  This is taken from the command line as $2.
$MEMCOUNT – This is the amount of memory you want to give the router.  This is taken from the command line as $3.  The script takes this variable, but it doesn’t do anything with it due to memory declaration problems with the IOU image.  The default is 128M.  This is something to work on later.
$INSTID – This is the IOU instance ID.  This is taken as $4 from the command line and is used to differentiate the different routers you have running simultaneously.

genSwitch does the same thing except that it uses $L2IOU to point to the layer-2 image instead of the layer-3 image.  There is a better way to do this, but I haven’t given it enough thought (or asked Google) yet.

When either script is called, it generates a TCP port number by appending the instance ID to the number 10.  If you fire up instance 842, then the TCP port to which to telnet for access to this router is 10842.  This is good for 3-digit IDs, but there will be service clashes if you use instance ID 9 or something.  That also sounds like something that needs to be fixed.

Each script also takes the process ID of the router and stores it in a file for use later.  The file is actually ./pid/$INSTID.pid, and you’ll have to create that directory.  This is a common technique to watch processes and will be used later.

startProject

The “human interface” script – the one your run from the command line – is called startProject.  This script looks in the current directory for a file called routers.db, and, using the info in there, fires off all the routers for you through genRouter.  In this file, you put in values to be used by genRouter to define $ETHCOUNT, $SERCOUNT, $MEMCOUNT, and $INSTID.  Each line is a new router, so you can use this file to start up a whole mess of them at once.

Something like this.

1 0 128 100
1 0 128 101
0 1 128 102

IOU uses a netmap file to define how router interfaces are connected to each other.  Using the same netmap file for all your labs isn’t very flexible, so I just set the NETIO_NETMAP environment variable to “./project.netmap” to run different labs from different directories.  Make sure that your routers.db and netmap files both reference the correct instance ID for each router; you’ll obviously get unexpected results if they don’t.

startProject doesn’t take any arguments; everything it needs is in your routers.db or your netmap file.  Just run startProject from wherever you put those files.

I have a “labs” directory in my $HOME, and, under that, I created directories for each thing I’m studying.  If I’m doing an OSPFv3 lab, I create a directory called “ospfv3″ or something and put my routers.db file, my netmap file, and my pid directory there.  I then fire off startProject from there to get the whole thing going.

startProject is terribly written.  It doesn’t check any values at all, and just send what it reads directly to genRouter without asking any questions.  A real sysadmin would laugh hysterically at this script (as I do).  Perhaps someone can fix it up.  :)

killProject

I bet you know what this does.  It goes into ./pid/ and kills off all the processes that are stored there.  Nothing fancy at all.

The Files

Here are the scripts themselves.  Just put them somewhere in your path and change the variables as in genRouter and genSwitch as needed.  You may have to do a “Save As…” or just copy-and-paste the text into files yourself.

genRouter
genSwitch
startProject
killProject
All of them in a tar.gz

I don’t want any trouble from anyone, so I don’t have a copy of IOU to give away.  Please use your own set of sleuthing skills to find a copy on the dark parts of the InterWebs.  :)

Send any bbq recipes questions to me.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

For those interested, here’s my schedule.

Sunday, 10 July

13:00:  CCIE R&S Written (Woohoo…one of my goals for 2011!)

Monday, 11 July

09:30 – 11:30:  BRKRST-2311 – IPv6 Planning, Deployment and Operation Considerations
12:30 – 14:30:  BRKSEC-2003 – IPv6 Security Threats and Mitigations
15:00 – 17:00:  BRKIPM-1261 –  Introduction to IP Multicast (I know NOTHING about multicast)

Tuesday, 12 July

08:00 – 09:30:  BRKCRS-3466 – Understanding the ACL Architecture on the Catalyst 6500
10:00 – 11:00:  GENKEY-4700 – Keynote and Welcome Address
12:30 – 14:30:   BRKRST-2500 – Campus QoS Design
16:00 – 18:00:  BRKRST-2312 – An Overview of IPv6 Routing

Wednesday, 13 July

08:00 – 10:00:  BRKARC-2350 – Routing Operations in Cisco IOS Routers
10:30 – 11:30:  GENKEY-4701 – Cisco Technology Keynote
12:30 – 14:30:  BRKRST-2501 – WAN and Branch QoS Design
16:00 – 18:00:  BRKRST-2042 – Highly Available Wide Area Network Design

Thursday, 14 July

08:00 – 10:00:  BRKRST-2301 – Enterprise IPv6 Deployment
12:00 – 14:00:  BRKSEC-2202 – Understanding and Preventing Layer 2 Attacks in IPv4 Networks
14:30 – 15:30:  GENKEY-4702 – Closing Keynote (SHATNER!)
16:00 – 17:30:  BRKCDN-1109 – XDE: an Environment for Customizing Network Management

Friday, 15 July

Fly home at some unknown time

It should be a great time indeed. Be gentle, though; it’s my first time.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

Total TAC cases opened related to 3750s: 21
Number of 3750G-12S-S replaced: 21
Number of 3750G-24TS replaced: 7
Total number of RMAs issued: 28
Total number of 3750s in the company: ~120
Failure rate: 23.3%

I can accept a handful of failures, but 23%?!?!? That’s one fine platform you’ve developed there, Cisco. Keep up the good work.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

This is one of those little things in life that make me happy.  Since the active ASA always has the same hostname and IP address, I find it hard to keep track of to which firewall I'm actually connected.  That "configurtions are no long in sync" message you get when you conf t on the standby firewall really irks me.  With the prompt command, I can see which firewall I'm on and in what state it is.

Here are the options you can use.

firewall(config)# prompt ?

configure mode commands/options:
  context   Display the context in the session prompt (multimode only)
  domain    Display the domain in the session prompt
  hostname  Display the hostname in the session prompt
  priority  Display the priority in the session prompt
  state     Display the traffic passing state in the session prompt

Note that the command is similar to the service timestamps in IOS where you can stack options.  I wound up setting my prompts to "hostname priority state" so I can see that information without having to do a show failover.  If you run contexts, I'm sure that would be a good one to include as well.  I imagine adding "domain" may make the prompt too long for use, though.  Heh.

Send any candy hearts questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts

%DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Gi0/25 because of VTP domain mismatch.
%DTP-5-DOMAINMISMATCH: Unable to perform trunk negotiation on port Gi0/26 because of VTP domain mismatch.

That scared me a bit, but, a few seconds later, all the trunks came up and started passing traffic.  After a little looksie, we realized that the switch we added had a null VTP domain and was in server mode.  When connected to another switch via a trunk, a switch in this configuration will listen out for any VTP information and will add itself to any VTP domain it finds.  Since we had an established domain on the upstream switch, the new switch added itself to the domain and brought the trunks up.  The scare was little more than a little naivety mixed with a dash of paranoia from the early debacle.

Obviously, this is not the way we want to do switch implementations.  Rule #1 for putting a switch on the network:  Set the VTP domain and mode before you plug it into the network.

Off topic:  This project is seriously cursed.

Send any magic potions questions my way.

Aaron Conaway

I like to lean my head to the left, hit it with the palm of my right hand, and document what knowledge falls out.

Website - More Posts