current topology and current focus

I think I’ve figured out part of the problem I’ve been having.  I haven’t been entirely focused on my studies, and I don’t really have a set goal right now.  I’ve been dancing with the idea of skipping the CCNP and going straight to the IE written.  Because of that, I’ve been reading chapters in the IE written exam certification guide, chapters in the BCMSN gook, and still reviewing notes, videos, and chapters from the BSCI studies.

With the way work has been going, I haven’t had as much time to study at work, and I don’t have the office space/time to study at home.  I live in a small apartment, and my rack is sitting in my living room.  I may need to bit the bullet and pay for the power consumption to leave the rack running at night.  I can stay an extra hour or so at work after hours to study quietly and access the rack from work.

Either way, I AM going to go for the NP.  I’m spending the next week or so going back through my written notes, watching videos again, and reading chapters in the BSCI book over the next week or so.  I bought the BSCI Lab Portfolio a month or so ago, so I’ll spend the next week going through those labs at night.

The physical topology for the bulk of the labs has four routers and one switch.

These are the routers and switch that I’ve added to the mix.  At some point, I know the lab guide will add the frame switch and possibly another router.  I need to pick up a few extra WIC-1T cards soon.

I made it through the first few EIGRP labs, tonight.  The objectives were pretty basic…

1.  Configure EIGRP on an interface.  simple

r1# configure terminal

r1(config)# int eth fa 0/0

r1(config-if)# ip addr

r1(config-if)# router eigrp 1

r1(config-router)# network

2.  Configure the bandwidth command to limit EIGRP bandwidth

r1(config-if)# bandwidth 64 ! bandwidth in kbps

3.  Verify EIGRP adjacencies

r1# show ip eigrp neighbors

or the alternative and more verbose

r1# show ip eigrp neighbors detail

4.  Utilize debugging commands for troubleshooting EIGRP

r1#  debug eigrp packets ! don’t forget to issue no debug all afterwords.

5.  Challenge:  test convergence for EIGRP when a topology change occurs.

This one was kinda weird.  The preferred path from R3 to a loopback on R1 is going to be via fast ethernet.  The lab has you ping from R3 to lo 3 on R1 with 100,000 pings(this is done using the ping $ip repeat 100000 command).  During these pings, you are to kill R1’s FA interface.  We haven’t modified the variance in EIGRP, and the AD through R2’s serial interface to R1 is more than the FD to lo 3, so the route doesn’t exist in the topology table.

When we killed FA 0/0 on R1, we obviously lost six pings while EIGRP discovered the new route through R2.  What confused me, was when I brought FA 0/0 back up on R1, we lost 33 or 34 pings while while the route through R1’s FA port came back up.

I’ll make it through the remaining EIGRP labs tomorrow night, and hopefully I’ll get through the OSPF labs.  I know there is going to be some slight re-cabling to bring the frame switch back into the mix.  I just hope I have enough WIC-1T interfaces to cover the physical topology change.


Trainsignal BSCI final review

As the chorus of the ska song goes:  “sell out with me, oh yeah… sell out with me tonight!”

I started this blog after reading CCIE Pursuit, Ethan Banks, Bit Bucket, and a few other blogs on a regular basis.  It was cool to see the progress these candidates were making, and to see some of the technical information they provide in their blogs.  I don’t think my friends list on my personal journal at are really interested in my trials and tribulations on this journey, and I figured I would get more feedback and comments by taking this route.

Shortly after staring this blog, Alex and Scott Skinger from Trainsignal contacted me and asked if I would be interested in checking out some of their training materials for the CCNA/NP exams.  I don’t know if I’m the best candidate to be reviewing these materials, but since I’m really just getting started on my path, it seemed like a really good idea.  As it turns out, I’ve learned a lot from the BSCI materials already.

Below is my review of the Trainsignal BSCI VBT training materials:

This was my first experience with any video/computer based training.  For previous certifications, including the CCNA in 2006 I have primarily relied on book study and lab time.  In 2001, I spent a year and a half in network academy, but that’s a long time to work towards a cert.  I’ve now watched the BSCI videos twice, and I’ve come to find that I really enjoy the VBT/CBT and I will continue using this type of training material to prepare for exams in the future.

Prior to receiving the videos, I used the “Authorized Self Study Guide” and the “Official Exam Certification Guide” from Cisco Press.  Both were written for the current 901 exam.  I found both to be lacking in areas and key concepts, and the end of chapter labs were lacking.  They don’t provide enough configuration examples for users to gain true understanding of the topics.  

A few of key improvements with the VBT, has been my ability to take notes without having to stop mid paragraph to write.  I can continue to listen and look up as a lecture progresses.  Chris Bryant also brings up his racks and works through configurations in various topologies throughout.  This goes an extra mile in helping to solidify what we are learning.  I have definitely had a much easier time retaining information since watching the videos.

The videos also went into greater depth on BGP, IPv6, Multicast, and other routing concepts.  IPv6 was the death of my first attempt at BSCI in February.  I got nailed on questions that I hadn’t seen information on prior.  Chris made sure to cover everything I had missed and made sure to point out specifics that could be tested. 

In closing, I feel that these videos would be a tremendous asset to ANYONE preparing for the CCNA/CCNP exams.  Chris Bryant knows the material inside and out, and does a tremendous job of teaching the material.  He relays real world experience and covers commands that, while maybe not relevant to the CCNP, are beneficial in the wild.  I have learned a lot from this series, and I feel that I am a better engineer in the last two months because of it. 

If anyone has anything to add or has any questions, feel free to leave me any comments.

been a while..

I feel like a horrible blogger.  I haven’t updated in a few weeks.  We’ve gotten into the full swing of this transition at work, and I’ve been working like a dog.  I haven’t had a day off in two weeks, and there’s no stopping in sight.

I currently work in a Foundry shop, but with our recent acquisition, we are in the process of plannning our migration to Cisco.  By August, our entire corporate network will have been re-IP’d and all gear will be standardized on 6500’s, 3750’s, 3800’s, and a few 7200’s.  I’m excited about the transition, but it’s a lot of work.

Because of everything going on, I haven’t had any time to really study or focus on labs.  The Skingers at Trainsignal were very cool in hooking me up with training materials for BSCI, BCMSN, and asked me to review the CCNA materials.  I’ve been through the BSCI videos twice, and they were awesome.  After failing the exam in february, I went back through the videos and paid attention to the sections where I was weak.  Chris Bryant had a way of explaining things so that they make sense, and he was very thorough with the material.  For some reason, I missed some topics in the books that he made sure to touch upon.  I’ve been really impressed with the VBT.  They’ve allowed me to take as many notes as I want without having to stop mid page to write, then continue.  Things seem to flow much better.  Also, having Chris pull up the racks with different topologies to demonstrate configurations and what he’s teaching is awesome. 

I’m also considering selling off some of the gear in my rack to make room for a mac mini and/or iMac.  I figure by the time I put money into RAM and flash upgrades for some of the 2600XM’s, I can get a mini, anyway.  Add a few USB nics to the mix, and I’d be set.

BTW, what’s with this new dashboard look on wordpress?  I don’t think I care for it very much.


My wife managed to keep the kids out of the bedroom long enough for me to get through the IPv6, IS-IS, and Route Map/VLSM/NAT videos from Trainsignal yesterday. I still don’t understand how I did so poorly on the IS-IS section of the BSCI exam two weeks ago. I knew EVERYTHING covered in that video.

I learned some stuff in the IPv6 video that I didn’t know, but I’m still a bit foggy on the 6to4 tunneling. I am going to go back through the authorized self study chapter on IPv6 tonight and see if I can solidify that topic for myself. If I can make it through the multicast sections today/tomorrow and redistribution by Tuesday, then I am going to try and schedule my re-take of the exam for late this week. If not, I’m going to give myself next weekend and take the exam next Monday.

I’m disappointed. I REALLY wanted to be well on my way to knocking BCMSN out of the way by now. I guess I’m just going to have to push harder to get this stuff done.

quick update

I haven’t done a bit of studying since I failed that exam a week ago. I wanted to jump right back on the horse, this week, and get to studying my weak points (IPv6, IS-IS, and multicast). My wife and both of my daughters came down with the flu last weekend, and I’ve been fighting it all week. On top of that, I’ve been dealing with bursitis and cellulitis in my left arm/elbow.
We’ve also stepped up our effort to re-IP our entire corporate network, and made some changes to the WAN this week. Needless to say, there’s been a little too much going on to really focus on any studies. I was eligible to take the exam again yesterday. I will try to take it again in the next week or so.

I spent a good chunk of time last night into this morning messing around with dynamips on my work provided laptop. It’s a Pentium M 1.6Ghz machine with 1 gig RAM. I was trying to do labs using 2621XM as the platform, and I couldn’t get more than two routers loaded w/o crashing dynamips. I moved to 3640’s with two different IOS images this weekend (ip plus for BBR and FRSW, and Enterprise for the pod routers). So far, I’m able to get all routers fired up without spiking the processors. I started loading configs on the FRSW and the BBR’s this morning and the CPU spiked. We’ll see how the laptop handles full configs.
I know I have the rack here, but I don’t get a whole lot of time to dedicate to it, unfortunately. I’m almost at the point of selling it off just to buy a decent home PC/Mac and a laptop.

moving right along

My wife took the baby with her to another baby shower today. She left me alone so that I could get some studying done. I dunno what happened, but I’m going to call today a wash. I struggled to focus on anything, and stay with it. I made it through another BGP video, and listened to the IPv6 video while I cleaned the apartment up a bit. All in all, I really didn’t get very far.

This next week should be pretty relaxed at work. We’re still holding our breath for some upcoming information, and all of our projects are on hold. On top of that, my boss may be going out of town on a family emergency, and my co-worker is leaving to see his mother off to London for a two year mission. Maria has told me she’s going to allow me every evening this week to study (save for thursday night, when she takes the 8 year old to see the doodle bops).

I am going to get through all of the BGP chapters in the authorized self study guide and videos on Monday. Tuesday will be spent focusing on IPv6/OPSFv3, and Wednesday on Multicast. Thursday will be review and some additional lab work just to solidify everything. I’ll make the decision to take the test this week by Wednesday. Because of the work related stuff, I MAY put it off until early the following week (which would give me one more weekend to study), but we’ll see.

In the meantime, my notes from the BGP section today:
There are two main classes of attributes in BGP: well known and optional.
Within these two classes, there are two sub-classes each:

well known: mandatory and discretionary
optional: transitive and non-transitive

well known mandatory attributes are as_path, origin, and next hop
well known discretionary attributes are local preference and atomic aggregate
optional transitive attributes are aggregator and community
optional non-transitive attributes are MED (multi-exit discriminator)

optional attributes aren’t necessarily understood by all BGP speakers. If a BGP speaker sees an optional transitive attribute that it doesn’t understand, it just forwards that information onto the next peer. Attributes that are optional non-transitive are dropped by BGP speakers that don’t understand them. Chris Bryant mentioned the partial bit for optional transitive attributes. I’d like to see the behavior for all of the above. I just don’t know how likely it is with all cisco gear.

BGP best path selection:
1. use the path with the highest weight (weight is a cisco proprietary attribute)
2. use the path with the highest local preference (this is 100 by default and is the same throughout the AS. can be assigned through the bgp default local-pref # router configuration command, or done on a per-route basis with route maps. route maps are preferred)
3. use the path that was originated locally
4. use the path with the shortest as_path
5. use the path with the best origin code (IGP is preferred over EGP is preferred over ?/incomplete)
6. use the path with the lowest MED (I think I read somewhere that Cisco uses this attribute the exact opposite of the RFC standard. I want to say the command to correct this is bgp bestpath med missing-as-worst.)
7. use eBGP path over iBGP path.
8. use the lowest IGP metric to the BGP next hop
9. use the most recent path
10. use the lowest BGP Router-ID.

I have additional notes, but They work better with diagrams and sample configs. Since I don’t have visio on my laptop yet, I’ll hold off on the diagrams for now. Besides… It’s time to get in the shower and get ready to go out tonight. This was the stipulation set on me getting to study today.

More Trainsignal

I made it through all four of the trainsignal OSPF videos from Trainsignal. I will say that I am completely impressed by Chris Bryant’s teaching and have been very happy with the products so far. My only issue has been the brief explanation he gave on stub areas/NSSA. I found his explanations of NSSA, specifically, to be a little confusing. I’m familiar with how they work and have set them up in lab scenarios, so I’m not concerned for myself… I just thought a little more time could have been spent on them. Maybe he’ll get to it a little more in depth with redistribution.

I don’t have much going on today. We’re doing some work at a remote site this evening, so we’ve been pretty relaxed today. I decided to start the BGP videos, since that’s one of the areas I’m lacking. Just as a side note… I really need to get a better PC to load dynamips on. I have a great rack at home, but I can’t afford to leave it running 24/7 (power consumption). It’d be nice to be able to load a few 2600’s on my work PC, but dynamips keeps crashing. I have a P4 1.8 with 1.5 gigs of RAM, and everytime I load a pair of 2621XM’s (for IOS 12.4), the damned server crashes.

Anyway… Some of the key points from the first hour of the BGP video were:
1. Two classes of attributes: well known and optional. (He didn’t go any further than this just yet.)
2. BGP uses TCP port 179 for communication and uses keep alives to maintain connection.
3. Full tables are exchanged during the relationship establishment. Following that, updates are only sent when a change occurs.
4. Cisco recommends that eBGP peers are directly connected, though there wasn’t any mention of whether or not this is REQUIRED. iBGP peers to not need to be directly connected.
5. BGP states:
a. idle
b. connect
c. active
d. opensent
e. openconfirm
f. established (this is what you want to see when running show ip bgp neighbor and show ip bgp summary)

A Sample configuration for the above:

R1#conf t
R1(config)#router bgp 100
R1(config-router)#neighbor remote-as 200

R3#conf t
R3(config)#router bgp 200
R3(config-router)#neighbor remote-as 100

If we wanted to use loopback interfaces for additional stability (this would come into play for iBGP with multiple paths to each host, and eBGP with two direct links between peers), we would use the following:
R1#conf t
R1(config)#router bgp 100
R1(config-router)#neighbor remote-as 200
R1(config-router)#neighbor ebgp-multihop 2
(we use the multihop command because we are not peering with the IP address directly connected to us.  The 2 is the number of hops we need to traverse)
R1(config-router)#neighbor update-source lo0 (this is telling the local router to use lo0 as the source of all bgp traffic.  No matter what interface we use to communicate with, we will use that Lo as the source IP. )

One of the gotchas was to make sure that we had routes to the loopback interfaces on each side. Since we’re not running an IGP between the two, we opted to use static routes. In Chris’s video, R1 and R3 were connected through a frame switch. He used the interface option in his static route, and the adjacency never came up. When he changed the static route to use the next hop, it came up.

Chris also went through some basic network information in BGP.
First and foremost, when you advertise a network in BGP, you must use the EXACT mask that you have setup or that exists in your routing table. EX:
R1#conf t
R1(config)#interface lo1
R1(config-if)#ip addr

would require the following network statement in BGP:
R1(config-router)#network mask

R1#conf t
R1(config)#interface lo1
R1(config-if)#ip addr

would require this statement:
R1(config-router)#network mask
The command show ip bgp on the local router will tell you if the route is being advertised to it’s peers.

I want to make it through the rest of the BGP sections and IPv6 before Saturday so I can spend the day working on these labs. My wife will be at another baby shower, and is taking the rugrat with her. I’m determined to get this exam done by Friday of next week.